mastering-programmer
จากบทความเรื่อง Mastering Programming เขียนโดยคุณ Kent Beck
ได้อธิบายว่าเส้นทางสำหรับ Effective programmer ว่าควรเป็นอย่างไร
จึงได้นำมาแปลและสรุปตามความเข้าใจของตัวเอง
ในเรื่องของ Time และ Learning
ซึ่งน่าจะมีประโยชน์ต่อ programmer บ้างนะครับ

เรื่องของการจัดการเวลา (Time) ประกอบไปด้วย

1. Slicing
ทำการแบ่งปัญหาใหญ่ ๆ ออกเป็นปัญหาย่อย ๆ
จากนั้นทำการเรียงลำดับความสำคัญตามความเหมาะสมต่อสถานการณ์นั้น ๆ
ซึ่งทำให้เราเห็นว่าอะไรที่มีความสำคัญตามที่ต้องการ

2. One thing at a time
ควรทำงานทีละอย่าง กินทีละคำ
เพื่อทำให้เรา focus และมีสมาธิต่อสิ่งที่ทำ
ซึ่งมันส่งผลดีต่องานนั้น ๆ เป็นอย่างมาก
และช่วยทำให้เรารู้ feedback จากสิ่งที่ทำได้อย่างรวดเร็วขึ้น
นั่นคือ เราพยายามลด overhead หรือ สิ่งที่ไม่จำเป็นออกไปให้มากที่สุด

3. Make it run, Make it right, Make it fast
มันเหมือน ๆ กับ Make it work, Make it right and Make it fast นั่นเอง
แต่ประเด็นหลักคือ
เราต้องทำการ slice ปัญหาออกมา นั่นคือมี 3 ส่วน
ลงมือทำแต่ละอย่างไปตามลำดับ
ผลที่ตามมาคือ ง่ายต่อการเปลี่ยนแปลงนั่นเอง

เคยไหมที่คิดแต่ละทำให้ระบบงานมันทำงานเร็ว ๆ
แต่ยังไม่เคยทำให้ระบบงานมันทำงานได้เลย
และสิ่งที่ทำอยู่นั้นมันถูกต้องหรือไม่
สุดท้ายก็ไม่สามารถแก้ไข หรือ เปลี่ยนแปลงอะไรได้เลย !!
ได้เพียงปะผุไปวัน ๆ …

4. Easy changes
เมื่อเราพบว่าส่วนใดมันยากต่อการเปลี่ยนแปลงแล้ว
สิ่งที่ต้องทำเป็นอย่างแรกคือ ทำให้ง่ายเข้าไว้ !! (Simple not easy)
ซึ่งบางครั้งมันอาจจะยากก็ได้ (ยากง่ายของแต่ละคนไม่เท่ากัน)
จากนั้นทำให้มันง่ายต่อการเปลี่ยนแปลง
นั่นคือการ slice และ แยก (isolate) ออกมา

5. Concentration
ถ้าคุณต้องการเปลี่ยนแปลงหลายสิ่งอย่างแล้ว
ให้คุณทำการเรียงลำดับของสิ่งต่าง ๆ
จากนั้นเริ่มทำการเปลี่ยนแปลงไปทีละอย่าง

6. Isolation
ถ้าคุณต้องการแก้ไขเพียงบางส่วนเท่านั้น
ให้พยายามแยกส่วนงานนั้นออกมาเพื่อแก้ไขให้ได้

7. Baseline measurement
ก่อนที่จะเริ่มทำอะไรควรมีตัวเลขตั้งต้นไว้สำหรับการวัดผลเสมอ
เพื่อทำให้เรารู้ว่า หลังจากทำการแก้ไขแล้ว
มันส่งผลออกมาอย่างไรบ้าง
อย่าใช้แต่สัญชาตญาณและความรู้สึก !!

เรื่องของการเรียนรู้ (Learning) ประกอบไปด้วย

1. Call your shot
ก่อนที่จะทำการ run code ของคุณ
ลองคิด และ ทำนายก่อนสิว่า ผลการทำงานจะเป็นอย่างไร !!
มันเหมือนบอกว่า เราควรเขียน test หรือ หยุดการมโนลงไปหรือเปล่านะ
และให้เรารู้ตัวเองว่ากำลังทำอะไร
ไม่ใช่ run code ไปเรื่อย ๆ ผิดตรงไหนก็แก้ที่นั่น
ซึ่งไม่น่าจะเป็นเรื่องที่ดี

2. Concrete hypotheses
เมื่อระบบงานที่สร้างทำงานไม่ถูกต้องตามที่คาดหวัง
ก่อนอื่นต้องทำความเข้าใจก่อนว่า เราคิดอะไรผิดไปบ้าง ?
ก่อนที่จะลงมือแก้ไขและเปลี่ยนแปลง
นั่นคือการตั้งข้อสันนิษฐานนั่นเอง

แต่ถ้ามันมีเยอะ ก็ให้พิจารณาก่อนว่ามันแตกต่างกันอย่างไรบ้าง ?
เพราะว่า มันอาจจะเป็นเรื่องเดียวกันก็ได้

แต่สิ่งที่ต้องทำเสมอคือ คิด เข้าใจ ก่อนลงมือทำ

3. Remove extraneous detail
พยายามขจัดสิ่งที่ไม่เกี่ยวข้องออกไป
เช่นการเขียนรายงาน bug ต่าง ๆ
ควรเขียนขั้นตอนการ reproduce bug ให้สั้นและกระชับที่สุด

เมื่อทำการแก้ไข bug ให้แบ่งเป็นปัญหาย่อย ๆ ออกมา
โดยเริ่มด้วย test case ที่สั้น และ ง่าย
แน่นอนว่า ต้องเกี่ยวข้องกับ bug นั้น ๆ

เมื่อต้องเริ่มใช้งาน API ใหม่ ๆ
ให้เริ่มจากตัวอย่างง่าย ๆ ก่อนเลย

เนื่องจากถ้าคุณเริ่มด้วยท่ายากแล้ว
เมื่อเกิดผิดพลาดขึ้นมามันย่อมใช้เวลาและแรงเยอะ
นั่นคือค่าใช้จ่ายที่สูงขึ้นมาก (มันแพงมาก ๆ)

4. Multiple scales
การ scale นั้นมันเกิดได้หลายแบบผสมกัน
ดังนั้นอย่าไปยึดติดมากนัก
เนื่องจากปัญหามันอาจจะเกิดจากการออกแบบ ไม่ใช่จากการทดสอบ
เนื่องจากปัญหามันอาจจะเกิดจากคน ไม่ใช่จากเทคโนโลยี

โดยสิ่งต่าง ๆ เหล่านี้
เป็นคำแนะนำสำหรับลดความเสี่ยงในเรื่องของการจัดการเวลา
เป็นคำแนะนำสำหรับการเรียนรู้ที่ดีขึ้น