By: 3000anv 
on 6 May 2012 - 02:59
Tags:
Forums:
ผมเริ่มศึกษา Java ใหม่ครับ ตอนนี้คือผมเขียนเป็นภาษาอังกฤษ แบบ log เกม RPG ยังไงยังงั้นเลย
if found X (go pick a box) แล้วค่อย decompose ลงย่อยลงมา ๆ (ติด error แดงไปหมด)
แล้วค่อยแก้ Syntax ที่ยังไงก็ Error รวดเดียวโดยกางหนังสือไปด้วย
ผมพบว่าพอใช้วิธีนี้จะพบ Logical error น้อยมาก (แต่จะ error syntax แบบแก้ทีละบรรทัดเอาเลย)
แต่ทำ Assignment เสร็จช้ามากๆ
อยากทราบว่าเวลาโปรแกรมเมอร์ศึกษา ภาษาใหม่ๆ (เช่นไปทำงานบริษัทที่มีภาษาเฉพาะ)
หรือ สร้าง โปรแกรมจะใช้วิธีแบบนี้ถือว่าถูกหลักการทำงานจริงหรือไม่ครับ ปรกติเขียนกันแบบใหนครับ
Get latest news from Blognone
Follow @twitterapi
Hiring! บริษัทที่น่าสนใจ
Blognone Jobs Premium
Cloudnone
- Kubernetes คืออะไร [Part 1] เกิดขึ้นมาอย่างไร? ทำไมต้องใช้มัน? | Cloudnone EP.14
- CI/CD ยังไงดี ตั้งเซิร์ฟเวอร์เอง vs เช่าคลาวด์ | Cloudnone EP.13
- รู้จักโน้ตบุ๊กบนคลาวด์ เช่าใช้งาน Jupyter Notebook ที่ไหนดี | Cloudnone Ep.12
- สรุปข่าวใหญ่ปี 23 และคาดการณ์เทรนด์ปี 24 ในวงการ Cloud | Cloudnone EP.11
- สรุปของใหม่และสาระสำคัญจาก AWS re:Invent 2023 | Cloudnone Special EP
ปกติถ้าผมต้องเขียนโค้ดหรือแกะโค้ดส่วนที่ยาวและซับซ้อน ผมจะเขียนลำดับการทำงานที่จะทำเป็นภาษาไทยเลยครับ เขียนไม่ให้หลงทางเฉยๆ ไม่เน้นสวยงาม ถ้าผมจะทำเอกสารเก็บไว้ดูเองหรือให้คนอื่นดูค่อยแปลงจากลำดับงานภาษาไทยอันนั้นเป็น Diagram เอาครับ
ปกติเวลาทำโปรแกรมจริงๆไม่เคยเขียน pseudo code แบบจริงๆจังๆนะครับ ใช้เฉพาะตอนที่จะขึ้นกระดานอธิบายคนอื่นๆมากกว่า
เพราะถ้าเขียนเป็นตัวหนังสือธรรมดามันใช้เวลาเขียนนาน
และก็ไม่ได้ใช้อธิบายโปรแกรมทุกส่วนด้วย เอาไว้อธิบายเฉพาะส่วนที่มีปัญหาไม่เข้าใจกันจริงๆ ให้เข้าใจ concept เท่านั้นเอง
ส่วนเวลาเจอภาษาใหม่ๆก็จะฝึกเขียนโปรแกรมเล็กๆจนกว่าจะเริ่มเข้าใจใน syntax และศึกษาจนรู้ว่าพอจะมี library class function อะไรที่จำเป็นต่อการใช้งานบ้าง ถึงจะเริ่มนำมาใช้งานจริงๆครับ
ส่วนเวลาทำงานจริงมันจะซับซ้อนขึ้นเพราะในการทำงานจริงมีหลาย module ต้องแตกแต่ละ module ออกมาเป็น class ย่อยๆ และกำหนด method ที่จำเป็นต้องใช้ และยังต้องมี test case ด้วย ซึ่งการกำหนดความสัมพันธ์ของแต่ละ class แต่ละ module อาจจะใช้ diagram หลากหลายตัวช่วยในการทำงาน
พอเขียนไปสักพัก คุณจะเริ่มชินจนเขียนโค้ดลงไปแทนการเขียนซูโดโค้ดครับ ยกเว้นตรงจุดที่ซับซ้อนก็จะใส่เป็น comment TODO ไว้ แล้วค่อยกลับมาเขียนให้เสร็จทีหลัง
ถ้าเขียน ผมคงเขียนไว้ดูเฉยๆ อ่ะครับ แล้วก็มานั่งดูว่า ตัวไหนที่เราจะแยกเป็น class ได้จริงๆ
เขียนไปเขียนมา มันก็กลายเป็นเขียน class ไปเลยจนเคยตัว
เขียนซูโด เฉพาะเวลาที่ขี้ไม่ออกอ่ะครับ
ผมเริ่มศึกษา Java ใหม่ครับ ตอนนี้คือผมเขียนเป็นภาษาอังกฤษ แบบ log เกม RPG ยังไงยังงั้นเลย if found X (go pick a box) แล้วค่อย decompose ลงย่อยลงมา ๆ (ติด error แดงไปหมด)
แล้วค่อยแก้ Syntax ที่ยังไงก็ Error รวดเดียวโดยกางหนังสือไปด้วย ผมพบว่าพอใช้วิธีนี้จะพบ Logical error น้อยมาก (แต่จะ error syntax แบบแก้ทีละบรรทัดเอาเลย) แต่ทำ Assignment เสร็จช้ามากๆ
อยากทราบว่าเวลาโปรแกรมเมอร์ศึกษา ภาษาใหม่ๆ (เช่นไปทำงานบริษัทที่มีภาษาเฉพาะ) หรือ สร้าง โปรแกรมจะใช้วิธีแบบนี้ถือว่าถูกหลักการทำงานจริงหรือไม่ครับ ปรกติเขียนกันแบบใหนครับ
สู้ๆครับ
ผมชอบแยกเขียนเป็นบล๊อคมากกว่าครับ บล๊อคนี้ทำประมาณนี้ อะไรงี้
การเขียน psuedo code ช่วยให้เราเห็นความคิดในภาพรวมได้ดียิ่งขึ้นครับ เวลาไปเขียนโปรแกรมก็กลับมาดูได้ว่าตอนนั้นเราคิดอะไร
ผมเขียนเป็นบางครั้ง เวลาที่การทำงานมันคิดแค่ในสมองไม่ได้ อาจจะเป็นเพราะซับซ้อน หรือเพราะเราไม่ชินอะไรก็แล้วแต่
หลักๆ ก็เหมือนนักดนตรีครับ คงไม่มีใครเริ่มเขียนเพลงจากเขียนโน๊ต
แต่เขียนเสร็จแล้วก็ต้องลงไปเป็นโน๊ต เพื่อนส่งต่อให้คนอื่นๆ เล่น ... มันเป็นเหมือนภาษากลางครับ
ไม่จำเป็นต้องเขียน แต่ถ้าทำได้ก็จะเป็นการยกมาตรฐานตัวเองครับ
ไม่เขียน psuedo code มาสักชาติครึ่งได้แล้วครับ คือมันไม่ค่อยมีประโยชน์น่ะนะ ถ้าไม่สามารถเขียนโค๊ดของภาษานั้น ๆ ให้ชัดเจนพอได้ ก็คงเขียน psuedo code ให้มันชัดเจนและอ่านรู้เรื่องไม่ได้หรอกครับ
อารมณ์ประมาณสตีฟจ๊อปส์เกลียด PowerPoint น่ะนะ
อาจจะมีเอามาใช้บ้างตอนพรีเซนท์หรือต้องอธิบายให้คนอื่นเข้าใจ แต่ผมว่าพวกชาร์ทได้ผลมากกว่าเยอะครับ
เฉพาะตอนที่เขียน algorithm พิลึกๆที่ผมกลัวจะลืมกลางคันเท่านั้นล่ะครับ
แถมไอ้ซูโดโค้ดนี่คือคอมเม้นที่ใส่ลงไปในโค้ดนี่ล่ะ
ตามปรกติแล้ว ขั้นตอนการ develop ของผมก็คือ
โดย service spec. นี่จะส่งให้ลูกค้าพร้อมกับตัว service ที่เสร็จแล้ว
ซึ่งในการทำงานจริงๆผมต้องการแค่ Interface Layout ตัวเดียวก็เริ่มเขียนได้แล้ว ส่วน flow นั้นเขียนทีหลังเอา -.- ซึ่งเวลาเขียน code ผมก็จะ comment เป็น pseudo code ไว้เพื่อจะได้ไม่ต้องมานั่งนึก flow เองทีหลัง + เวลาคนอื่นมาแก้ต่อจะได้กาง flow แล้วดู code ตามได้เลย
เวลาทำงานจริงน้อยมากที่จะมีใครมาเขียน Psuedo code แล้วค่อยแปลง
ปกติจะคิด logic แล้วเขียนเลย
แล้วค่อยมาทำ doc อธิบาย ให้ user ฝั่ง it แบบ Psuedo code ง่ายๆ
และอีกชุดแบบภาษาคนแบบง่ายๆชาวบ้านให้ user ที่เป็น operation user จริงๆ
ที่ว่า user ฝั่ง it นั่นคือในความจริงแล้วบางบ.ที่เล็กๆเค้าก็มี it ของตัวเองไว้แค่ maintain ระบบเฉยๆ แต่เวลามี implement ระบบใหม่ๆแบบทั้งยวงจะจ้างเอา
ผมว่าซูโดโค้ดเขียนยากกว่าโปรแกรมเองอีก - -
May the Force Close be with you. || @nuttyi
ผมว่าที่ทำมานี่ถูกทางแล้วนะครับ แต่อยากให้เปลี่ยนจากการเขียน psuedo เป็น comments มากกว่าครับ
บอกไปเลยว่าทำอะไรเรียงเป็นขั้นตอนครับ ทำเป็น comments เอาไว้ถึงวิธีการทำงานของโปรแกรมในแต่ละส่วน ลำดับความคิดของเรา จากนั้นค่อยมาเขียน code จริงๆครับ เขียนเสร็จก็ไม่ต้องลบ comments นะครับ ทำแบบนี้งานจะเสร็จเร็วกว่ามากครับเพราะเรากำหนดไว้แล้วว่าจะทำอะไรต่อไป มีแผนงานเรียบร้อย
อีกข้อดีคือเวลาเราทำงานเป็นทีมหน่ะครับ ถ้าเราลางานคนอื่นก็เข้ามาทำต่อได้ทันที โดยอ่านจาก comments ที่เราเขียนไว้ว่าแนวคิดของเราจะทำอย่างไรต่อ แถมเมื่องานเสร็จยังเก็บไว้ดูย้อนหลังได้อีกต่างหากสะดวกมากครับ ที่บริษัทผมทำกันแบบนี้ครับ
วิธีนี้มีปัญหาอย่างเดียวคือโปรแกรมเมอร์ที่ไม่เก่งจะไม่มีความคิดรวบยอดว่าต้องเขียนโปรแกรมทำงานอย่างไร ขั้นตอนต่อไปต้องทำอะไรต่อ มักจะชอบลองทำทีล่ะส่วนถ้าไม่ได้ก็จะเปลี่ยนวิธี คือไม่ได้หาข้อมูลมาก่อนว่าควรแก้ไขปัญหานี้อย่างไร
comments ควรจะทำต่อเมื่อ "จำเป็นจริงๆ" เท่านั้นครับ เพราะว่าไม่มีใครมานั่งดูแล comments มันมีหลายกรณีมากที่ว่ามีคนแก้โค๊ดแต่ไม่แก้ comments ทำให้เกิดอาการงงว่าสรุปว่าอันไหนถูกอันไหนผิด สุดท้ายก็ต้องยึดตามโค๊ด เพราะ comments มันไม่ได้ถูกใช้งานนี่นา (แล้วจะเขียนทำไมแต่ต้น)
ถ้าเกิดเขียน comments เพียงเพราะว่า โค๊ดมันงง อ่านไม่รู้เรื่อง อันนี้แสดงว่าโค๊ดยังไม่ดีพอ ต้องแก้ใหม่ครับ
อย่างผมทำงานเป็นซัพพอร์ท คอยแก้บั๊กให้โปรดักท์ที่มีอายุกว่าสิบปี comments เชื่อถืออะไรไม่ได้เลยครับ เพราะว่าตัวโปรแกรมมันวิวัฒนาการไปไกลกว่ามาก ส่วนใหญ่แล้วก็ต้องมาแกะโค๊ดอยู่ดีครับ
ถ้ามีโอกาส มีเวลา ลองหาเล่มนี้มาอ่านดูครับ แล้วจะเข้าใจว่าทำไมการมี comments มาก ๆ ถึงเป็นสิ่งที่ไม่ดี : Clean Code
ขอบคุณครับ
ผมซื้อ Tablet ได้ไม่ถึง 2 อาทิตย์ แต่ดองหนังสือจนอ่านได้ถึงปีหน้าเลยมั้ง =*=
ของผม จนจบชีวิตนี้แล้วก็คงยังไม่หมดล่ะครับ
ถ้าเป็นเล่มนี้รู้สึกว่าจะถูกพูดถึงในหัวข้อ Good comments -> todo comments หน่ะครับ เห็นแว๊บๆใน wiki ของบริษัทครับ
ที่บริษัทผมใช้ XP กันครับ ดีใจที่เห็นคนพูดถึง agile กัน หัวหน้าผมชอบเอาเนื้อหา agile , version control มาโพสใน wiki ของบริษัทให้ลูกน้องทะเลาะกันเล่นๆ
บริษัททำธุรกิจด้านไหนครับ
ใน Wiki มีอะไรมั่ง
ถามห้วนนิดนึงครับ เพราะฟังแล้วชอบ แต่ไม่รู้จะตั้งคำถามหวานๆ ยังไง
หวานพอไหม
หวานเจี็ยบครับ 555
เดี๋ยวหยิกแขนเขียวเรย
1.พัฒนา software ครับเน้นที่เว็บไซต์เป็นส่วนใหญ่ครับ
2.ใน wiki ส่วนใหญ่จะเป็นคนในทีมช่วยกันเอาข้อมูลของแต่ละส่วนที่ตัวเองทำงานมาโพสใส่ไว้หน่ะครับ เป็นข้อมูลเกี่ยวกับการพัฒนาใหม่ๆ ส่วนใหญ่โพสทิ้งไว้แล้วจะมีคนเค้าไปเพิ่มเนื้อหาให้ครับ แล้วเราจะถกกันในนั้นครับว่ามันน่าจะมาจากอะไรใช้ทำอะไร จะมีของใหม่ๆอยู่เรื่อยๆครับ
อีกอย่างคือจะเป็นส่วนของลำดับการทำงานครับ :P เอาความลับบริษัทมาเปิดเผยซะแล้ว
เออคงไม่ใช่ตำรวจนะครับ ที่เอามาโพสไว้ไม่ใช่หนังสือทั้งเล่มนะครับเป็นแค่ส่วนหนึ่งครับสบายใจได้ไม่ผิดกฏหมายแน่นอน
ผมไม่ใช่ตำรวจครับ
พอดีว่าบริษัทผมไม่ใช่บริษัทซอฟแวร์เฮาส์ เป็นแค่โกดังสินค้าเล็กๆ แต่ว่าเราก็มีทีมพัฒนาโปรแกรม ซึ่งผมเองก็อยากจะให้มี Wiki เอาไว้เป็นส่วนกลางเพื่อแชร์ความรู้เหมือนกันครับ
ผมอยากให้องค์กรของผมเป็นองค์กรณ์แห่งการเรียนรู้เหมือนกันนะ ไม่ใช่ว่าใครรู้อะไรแล้วก็รู้อยู่คนเดียว
นอกเรื่องนิดนะครับ
จุดนี้แหละ ที่ G+ ตอบโจทย์ผมได้ดีครับ ปัจจุบันผมใช้ G+ เป็น Global R&D Conferrence Board เพราะ Circle ที่เป็นแบบ Normal Close ซึ่งไม่เหมือนใครนี่แหละ ทำให้ G+ สามารถ "ใช้ทำงาน" จริงๆ ได้ แต่กลับ "ใช้เล่น/ประชาสัมพันธ์/แก้เหงา" ได้ไม่ดีอย่าง FB
ทุกงานสามารถลงใน G+ ประสานงานกันได้แบบ Globalize โดยที่ไม่หลุดรั่ว และสามารถเลือกเฉพาะรายลูกค้าเข้าสู่ Circle ให้เห็นเฉพาะ Stream ของงานตัวเอง ในขณะที่ Staff ของเราเองที่เกี่ยวข้อง เห็น Stream ตามหน้าที่งานตัวเองของลูกค้าทุกรายได้หมด
เคยเห็นข่าวเรื่อง FB VS G+ มาหลายข่าวแล้ว แต่ไม่รู้จะ Jam ออกความเห็นยังไง พอดีคุณ PaPaSEK พูดมาแล้วโดนพอดีครับ (ตรง Wiki)
สรุปความเห็นของผมสำหรับคุณ PaPaSEK ว่า ลองพิจารณา G+ สิครับ น่าจะตอบโจทย์นี้ให้คุณได้ดี
ผมไม่ได้ใช้ทั้ง XP และ Agile ครับ เล่มนี้อาจจะขึ้นปกด้วย Agile แต่ผมว่าเนื้อหาส่วนใหญ่เกี่ยวกับการลงโค๊ดมากกว่าขั้นตอนหรืออะไรทำนองนั้นล่ะครับ
คือผมมองว่า comments มันควรจะมี "เท่าที่จำเป็น" ยิ่งมีมากยิ่งหมายถึงว่าโค๊ดไม่ดีครับ
ผมคิดว่าการมี TODO เยอะ ๆ ก็ไม่ใช่เรื่องดี เพราะผมพบว่าโค๊ดโปรแกรมผม (อายุ 10+ ขวบ) มี TODO เป็นร้อยเลยครับ (และไม่มีใครคิดจะมา DO ด้วย 555) มีเท่าที่ควรมี และถ้าจะไม่คิดจะทำต่อแล้วก็ควรเอาออก เพราะว่าบางทีมันสร้างความหวังให้คนอ่านนะ 555 คือ ควรจะมี TODO แค่ในช่วงระหว่างโปรเจค และก่อนโปรเจคจบควรจะเอาออกให้หมดครับ แล้วอะไรที่ไม่ได้ DO ก็เป็น Bug ไป
อ้อ TODO ใส่ใน Issue Tracking System เหมาะสมกว่ามากครับ
ตัวที่จำเป็นต้องมีก็พวก คำประกาศสิทธิและความเป็นเจ้าของ หรืออะไรทำนองนี้ ล่ะมั้ง
ส่วน comments อื่น ๆ ผมยังไม่เห็นประโยชน์อะไรเท่าไหร่ครับ version history ให้ดูบน Source Control เอาก็ได้ ส่วน Logic ที่อ่านแล้วงง ๆ ควรแก้ใหม่ให้อ่านรู้เรื่อง อะไรแบบนี้ล่ะครับ
จากลักษณะที่พูดมาน่าจะเป็น Mumbling มากกว่านะครับ จากประโยคนี้ครับ "(และไม่มีใครคิดจะมา DO ด้วย 555) มีเท่าที่ควรมี และถ้าจะไม่คิดจะทำต่อแล้วก็ควรเอาออก เพราะว่าบางทีมันสร้างความหวังให้คนอ่านนะ "
เพราะ Todo มันต้องทำถ้าไม่ทำโปรแกรมก็ทำงานไม่ได้ครับมันจะต่างจาก Mumbling ครับ "ถ้าจะไม่คิดจะทำต่อแล้วก็ควรเอาออก" <- นี่คือลักษณะของ Mumbling แน่นอนครับ ในหนังสือก็มีกล่าวไว้บ้างครับ ในหัวข้อ Bad Comments -> Mumbling
ช่วงหลังคนนิยมใส่ไว้ใน IDE มากกว่า ซึ่งก็แล้วแต่ความนิยมครับ ไม่ว่าจะอยู่ใน code หรือ IDE มันก็ทำหน้าที่เดียวกันครับ
ที่เจอก็มีตั้งแต่ "จะแก้จากอย่างนึงเป็นอีกอย่างนึง" ยัน "เดี๋ยวมาเขียนนะ" (แต่เป็น empty method) แล้วก็เช็คอินขึ้นไปเลย สิบปีผ่านไปมันก็อยู่อย่างนั้นแหละ ปัญหาที่ผมเจอคือคนที่เขียนโค๊ดเค้าจะเทสต์โค๊ดแค่ผ่านแล้วก็เช็คอิน บางทีก็ลืมไปว่าโค๊ดยังทำงานไม่ถูก (แค่เทสต์ผ่านเฉย ๆ)
ผมคิดว่า TODO คือ บันทึกช่วยเตือนว่าต้องทำอันนั้นอันนี้ ซึ่งก็ควรจะทำให้เสร็จทั้งหมดก่อนที่จะเช็คอิน แต่บางครั้งด้วยการบีบเข้ามาของเวลา หรือว่าเจอปัญหาอะไรสักอย่าง (หรือแม้กระทั่งมักง่าย เทสต์ผ่านแล้วถือว่าใช้ได้) ก็เช็คอินมันทั้งที่ยังมี TODO นั่นแหละ
บางคนใส่ assert(0) เอาไว้ใต้ TODO ด้วยนะ เท่ห์มาก พอฟังก์ชั่นถูกเรียกปุ๊บก็เจ๊งเลย
ผมคิดว่าโค๊ดที่อยู่ในโปรดักชั่นจริง ๆ ไม่ควรมี TODO ครับ คืองานไม่เสร็จแล้วจะปล่อยขึ้นไปได้ยังไง ส่วนที่ยังไม่ได้ทำก็ควรจะไปอยู่ใน issue tracking (ไม่ใช่ IDE นะครับ อันนี้เห็นอยู่คนเดียวคงไม่เวิร์ค) เป็น issue ใหม่ มีคนมาจัดการเป็นกิจลักษณะไปเลย คือ ทำให้พวกผู้บริหารสามารถเห็นได้ชัด ๆ ว่ามันมีปัญหา ไม่ใช่ดองอยู่แค่ในบรรดาโปรแกรมเมอร์ที่เห็นโค๊ดเท่านั้น (ซึ่งเอาเข้าจริง ๆ ก็ไม่เห็นหรอก)
จริง ๆ ผมว่านะ ถ้าจะเขียน TODO ในโค๊ดเนี่ย เขียนบน Stick-It แล้วแปะเอาไว้บนจอคอมยังเวิร์คกว่าเลย อย่างน้อยก็เห็นชัวร์ๆ ว่ามี บางครั้งเราเจอ TODO ของเราปนกับ TODO คนอื่นในโค๊ดมั่ว ๆ ก็ไม่รู้อีกว่าอันไหนเราจะทำ อันไหนเราจะไม่ทำ
ปล. เดี๋ยวผมกลับไปอ่านอีกรอบดีกว่า เริ่มจำไม่ค่อยได้แล้ว - -'
เอางี้ครับผมสรุปให้เลยดีกว่าครับ น่าจะไปคนละเรื่องกันแล้วล่ะครับ เดี๋ยวจะออกทะเลไปไกลกว่านี้ครับ
หนังสือที่พูดถึงกันเนี่ยมันเป็น agile ครับ ซึ่งจะเห็นไว้ว่าเค้าให้ความสำคัญกับ comments มากเพราะมีให้ 1 บทเลย ที่เป็นแบบนี้ก็เพราะว่า agile นั้นไม่เน้นเอกสารครับ เราเน้นคุยไปทำไปมากกว่า แต่ละวันก็จะมีงานออกมาให้ดูกันครับว่าเป็นแบบนี้หรือปล่าวที่เราต้องการ เรื่องของเรื่องคือมันไม่มีเอกสารอ้างอิงกลับครับ ดังนั้นการใช้ comments จึงสำคัญมากครับ ในหนังสือก็บอกไว้แล้วครับว่ามันสำคัญ แต่ปัญหาคือมีคนไม่เข้าใจการใช้งานครับ เค้าจึงเขียนบทนี้ขึ้นมาครับ โดยแยก comments ออกเป็น 2 ส่วนครับ ส่วนแรกคือ
1.Good Comments เช่นพวก Todo , Legal
1.Bad Comments เช่นพวก Mumbling และที่คุณพูดทั้งหลายทั้งปวงในความเห็นนี้ล่ะครับ
ทั้ง 2 หัวข้อนี้เค้าแบ่งชัดเจนครับ มีตัวอย่างชัดเจนมากกว่าแต่ละ comments มีลักษณะเป็นอย่างไร เพราะเค้าให้ความสำคัญมากครับ ตัวอย่างเยอะมาก คำแนะนำของเค้าคือ Bad Comments ไม่ควรทำครับ ซึ่งมันก็คือทั้งหมดที่คุณพูดมานั่นล่ะครับ รวมถึงปัญหาคนนิสัยเสียที่ไม่ยอมแก้ comments ครับ
ผมก็ชักงงๆว่าตกลงเราคุยในหนังสือเล่มเดียวกันหรือปล่าวครับ เพราะที่ยกตัวอย่างมามีแต่ bad comments ซึ่งเค้าก็เขียนอยู่แล้วครับหรือพยายามจะอธิบายผมว่านี่คือ bad ไม่ควรเขียน ผมอาจไม่เข้าใจเอง
สิ่งที่เราควรจะคุยกันหลังจากนี้มันไม่ใช่หัวข้อของ TODO ซึ่งเป็น Good Comments แล้วครับ และส่วนของ Bad comments ที่เค้าเขียนไว้ในหนังสือก็ไม่ต้องยกตัวอย่างแล้วก็ได้ครับ แต่เราควรจะมาแยกว่าอะไรคือ Good อะไรคือ Bad ในแบบที่ไม่มีในหนังสือมากกว่าครับ แบบนี้น่าจะได้หลายๆความเห็นที่ทำให้มองภาพรวมได้ดีกว่าครับ ไม่งั้นมันก็วนแบบนี้ล่ะครับ เสียเวลาปล่าวๆครับไม่เกิดประโยชน์
เขียน python สิครับ โค้ดจริงหน้าตาก็เหมือนๆ pseudo code แหละ
pittaya.com
f = e = d =c = b = a
รบกวนถามเพิ่มเรื่องการพิมพ์สัมผัสกับ โปรแกรมเมอร์ ส่วนมากจะพิมพ์สัมผัสกันรึปล่าวครับ
เอาเป็นว่า ผมยังไม่เคยเห็นโปรแกรมเมอร์นั่งจิ้มดีดเลยครับ
เพื่อนผมนั่งจิ้มดีดด้วยนิ้วชี้อย่างเดียวแต่เร็วเท่าผมพิมพ์สัมผัสครับ (หรืออาจจะเร็วกว่า) =.="
เอาเป็นว่าถ้าคุณอยู่กับคอมพิวเตอร์ไปนานๆ มันจะเป็นเองครับ ถึงจะไม่คล่องขนาดที่ว่าหลับตาพิมพ์ได้ก็เถอะ
แต่ด้วยลักษณะงานของโปรแกรมเมอร์ มันก็ไม่จำเป็นต้องใช้การพิมพ์ติดต่อกันยาวๆ หรือต้องใช้ speed ในการพิมพ์ที่เร็วมากๆอยู่แล้ว
แต่ถ้าเป็นฝ่าย it support ทางฝั่ง server ผมเจอคนพิมพ์ command ใช้ vi ใช้ terminal แบบเร็วมากๆอยู่หลายคนเหมือนกัน
เอาเป็นว่าผมจิ้มดีดครับ ไม่เคยใช้นิ้วก้อย นิ้วนางนานๆ ใช้ที
ผมก็พิมพ์เร็วพอสมควรนะ ... แต่บางทีมือมันไวกว่าสมอง พิมพ์ช้าเพราะนึกไม่ออกว่าจะพิมพ์อะไร
"มือไวกว่าสมอง" (- -)b
จากที่สังเกตคนรอบตัวหลายๆคน
ส่วนใหญ่จะพิมพ์ได้โดยไม่มองคีย์บอร์ดและเร็วมาก แต่ใช้แค่ 2-4 นิ้วในการกดครับ
เรียกได้ว่าเป็นการพิมพ์สัมผัสอีกประเภทนึง ไม่เหมือนที่สอนๆกันมา
เรื่องพิมพ์สัมผัสนี่ก็แล้วแต่บุคคลนะครับ เคยเห็นทั้งสองแบบ
แต่โดยส่วนตัวเห็นว่าถ้าเราทำสายงานนี้แล้วควรจะฝึกให้เป็น และการพิมพ์สัมผัสนี้ผมคิดว่าจะต้องมีการฝึกฝนครับ ไม่สามารถทำไปเรื่อย ๆ เดี๋ยวก็พิมพ์สัมผัสเป็นได้ครับ มันก็จะกลายพันธ์ุเป็นแค่จิ้มดีดแบบเร็ว มันไม่สามารถไปถึงระดับพิมพ์ดีดแบบเร็วได้ครับ และการพิมพ์สัมผัสไม่เป็นนั้นจะทำให้เสียจังหวะในการใช้สายตามองแป้นพิมพ์ครับ จะทำให้เครียดเพิ่มขึ้นกว่าพิมพ์สัมผัสครับ