- ไม่นานมานี้ได้ยินวิธีวิทยาการพัฒนาซอฟต์แวร์ที่น่าสนใจจากการสนทนากับ CEO และวิศวกรสายเทคที่มีชื่อเสียงคนหนึ่ง วิธีนี้ทำให้นึกต่อไปถึงฮิวริสติกและการทำให้เป็นนามธรรมในแบบอื่น ๆ
วิธีของเขา
- เริ่มลงมือทำฟีเจอร์ตั้งแต่ต้นวัน ถ้าทำไม่เสร็จก่อนจบวัน ให้ลบทิ้งทั้งหมดแล้วเริ่มใหม่ในวันถัดไป สามารถเก็บ unit test ที่เขียนไว้ได้
- หากผ่านไปหลายวันแล้วยังทำฟีเจอร์นั้นไม่สำเร็จ ให้คิดถึงพื้นฐาน อินฟราสตรักเจอร์ หรือการรีแฟกเตอร์ที่จำเป็นเพื่อให้ฟีเจอร์นั้นเป็นไปได้ แล้วทำส่วนนั้นก่อนค่อยกลับมาที่ฟีเจอร์
- วิธีนี้คล้ายกับขบวนการ Extreme Programming ในช่วงปลายยุค 90 และต้นยุค 2000
ความคิดเกี่ยวกับวิธีนี้
"เขียนทุกอย่างสองรอบ"
- คำแนะนำที่ให้กับวิศวกรจูเนียร์: แก้ปัญหาให้ได้และบันทึกโค้ดไว้ใน branch จากนั้นเขียนใหม่อีกรอบ
- ผู้เขียนค้นพบวิธีนี้โดยบังเอิญหลังจากโน้ตบุ๊กพัง การเขียนใหม่ใช้เวลาเพียง 25% ของการทำรอบแรก และผลลัพธ์ก็ดีกว่ามาก
- ใช้เวลา 1.25 เท่าเพื่อให้ได้โค้ดคุณภาพสูงขึ้น 2 เท่า มีประโยชน์กับโปรเจ็กต์ที่ต้องดูแลระยะยาว
- วิธี "เริ่มใหม่ทุกวัน" นั้นสุดโต่งยิ่งกว่า และทุกครั้งที่เขียนใหม่ก็มักจะพบวิธีแก้ที่ลื่นไหลกว่าเดิม
"ปริมาณก็คือคุณภาพแบบหนึ่ง"
- คำพูดของสตาลินนำมาใช้กับวิศวกรซอฟต์แวร์ได้ สำหรับวิศวกรจูเนียร์ โค้ด 100,000 บรรทัดแรกเป็นสิ่งจำเป็น
- วิธี "เริ่มใหม่ทุกวัน" ช่วยให้เขียนครบ 100,000 บรรทัดนั้นได้เร็วขึ้น
- การแก้ปัญหาเดิมซ้ำ ๆ เป็นประโยชน์ต่อการจดจำแพตเทิร์น
- ด้วยโค้ดสมบูรณ์แบบ 5,000 บรรทัด คุณอาจเห็นแพตเทิร์นสำคัญครบแล้ว ส่วนอีก 95,000 บรรทัดที่เหลือคือการปรับโครงข่ายประสาทผ่านการทำซ้ำ
เปรียบเทียบกับฮิวริสติกแบบ "เอาปืนจ่อหัว"
- เวลามีคนเสนอวิธีแก้ปัญหา ให้ถามว่า "ถ้าต้องทำให้เสร็จภายใน 24 ชั่วโมง คุณจะทำอย่างไร?"
- วิธีนี้ช่วยทลายกรอบคิดและอคติจากการยึดติดกับจุดตั้งต้น บ่อยครั้งสามารถนำไปสู่แผนที่ทำให้เสร็จได้ภายในหนึ่งวันในเวลาเพียงไม่กี่นาที
- ในความเป็นจริงแผนนั้นอาจทำไม่เสร็จภายในวันเดียว แต่แนวทางใหม่มักทำให้เสร็จได้ภายในไม่กี่วัน
- จุดประสงค์ของการทดลองทางความคิดนี้ไม่ใช่เพื่อสร้างคำตอบที่ใช้งานได้จริงทันที แต่เพื่อกำหนดขอบล่างของคำตอบ
การหาเส้นทาง
- แก่นสำคัญคือการหาเส้นทางใน problem space แต่ละเส้นทางคือคำตอบหนึ่งแบบ และหน้าที่ของวิศวกรคือการหาเส้นทางที่ดีที่สุด
- น่าคิดถึงความคล้ายคลึงกันระหว่างฮิวริสติกเหล่านี้กับอัลกอริทึมการหาเส้นทางแบบต่าง ๆ
- เช่นเดียวกันกับฮิวริสติกทางวิศวกรรม การเป็นวิศวกรที่เก่งขึ้นก็คือการหาเส้นทางที่ดีกว่าใน problem space
สรุปโดย GN⁺
- บทความนี้สำรวจวิธีวิทยาและฮิวริสติกที่มีประสิทธิภาพในการพัฒนาซอฟต์แวร์
- วิธี "เริ่มใหม่ทุกวัน" และ "เขียนทุกอย่างสองรอบ" มีประโยชน์ต่อการยกระดับคุณภาพโค้ด
- การแก้ปัญหาแบบทำซ้ำช่วยเรื่องการมองเห็นแพตเทิร์นและการปรับโครงข่ายประสาท
- ฮิวริสติกแบบ "เอาปืนจ่อหัว" มีประโยชน์ในการกำหนดขอบล่างของคำตอบ
- การหาเส้นทางที่ดีที่สุดใน problem space คือบทบาทหลักของวิศวกร
5 ความคิดเห็น
บ้าไปแล้วหรือ? เรื่องแบบนี้ในทางปฏิบัติมันจะเป็นไปได้จริงหรือ นอกจากพวกคนที่มีเวลาเหลือเฟือแบบสุด ๆ เท่านั้น?
คงเป็นไปไม่ได้ในสภาพแวดล้อม SI ของเกาหลีสินะ.. ฮ่าๆ คงได้แค่ในโปรเจกต์ส่วนตัวเท่านั้น
วิธีการนี้เป็นแนวทางที่ไม่เคยนึกถึงมาก่อนเลยนะครับ
ต้องลองสักครั้งแล้วล่ะ ฮ่าๆ
ผมเห็นด้วยอย่างมากกับการเขียนใหม่
ก่อนหน้านี้ผมเคยเผลอลบโค้ดที่ทำอยู่ไป แล้วพอต้องเขียนใหม่
ก็เลยได้ทำโดยคำนึงถึงสิ่งที่ก่อนหน้านี้เมินไปเพราะขี้เกียจเปลี่ยนดีไซน์ระหว่างทาง
ผลลัพธ์กลับยิ่งออกมาดีกว่าเดิม
ความเห็นบน Hacker News
การเขียนฟีเจอร์ใหม่สองรอบเป็นกลยุทธ์ที่ดี แต่สำหรับนักพัฒนาฝั่งธุรกิจหรือผู้จัดการโครงการ อาจดูเป็นความล่าช้าที่ไม่จำเป็น
คำถามอย่าง "ถ้าต้องให้เสร็จภายใน 24 ชั่วโมงล่ะ?" เป็นคำถามที่ผู้จัดการโครงการถามไม่ได้
โค้ดที่ดีเกิดจากการเลือก abstraction ที่เหมาะสม
ถ้ามีเพื่อนร่วมงานที่มีความสามารถ ก็สามารถแสดงให้เห็นได้ว่าในเวลาสั้น ๆ ทำอะไรได้บ้าง
เห็นด้วยกับความเห็นที่ว่าการเขียนซอฟต์แวร์สองรอบเป็นเรื่องที่ดี
ถ้าผ่านไปหลายวันแล้วยังทำฟีเจอร์นั้นไม่ได้ ก็ควรทำโครงสร้างพื้นฐานหรือการรีแฟกเตอร์ที่จำเป็นก่อน
"ภายใน 24 ชั่วโมง" กับ "เขียนทุกอย่างสองรอบ" มีความเชื่อมโยงกัน
โพสต์นี้เป็นหนึ่งใน "คำแนะนำด้านการเขียนโปรแกรม" ที่ดีที่สุด
บางครั้งการปล่อยให้ background thread ทำงานเพื่อแก้ปัญหาก็เป็นสิ่งจำเป็น
แนวทางต่อไปนี้มีประโยชน์