ในบทความที่แล้วเราได้คุยกันถึงเรื่องของ วิธีแก้ปัญหาที่ดี มักเกิดจากการที่เราเห็นปัญหาที่ ‘ชัด หลายมุม และมีจำนวนเยอะ’ มากพอจนกระทั้งเห็น pattern ที่เราสามารถ leverage มันได้
แต่เชื่อว่าหลายคนคงรู้ดีว่าโดยปกติแล้ว การจะเห็น pattern หรือ insight ที่นำไปสู่วิธีแก้ปัญหาที่ดี มันไม่ได้เกิดขึ้นตั้งแต่การคิด solution ในครั้งแรก แต่มักเกิดจาก discovery ระหว่างทาง ผ่านการเอา solution ที่คิดไว้ไปลองแก้ปัญหาจริง ๆ ยกตัวอย่างเช่น
-
การคิด algorithm มาเพื่อแก้ปัญหาอะไรสักอย่าง แต่พอลองเอาไปใช้งานจริงกลับพบบัคหรือเคสที่เราลืมนึกไป
-
หรือการที่เราปล่อย software/product อะไรบางอย่างออกไป แล้วพบว่ามี requirement อะไรบางอย่างที่เราไม่ได้คิดถึงมันตั้งแต่แรก หรือโหดหน่อยคือพบว่า user ใช้ software เราในการทำอย่างอื่นที่เราไม่ได้ตั้งใจเอาไว้
อะไรพวกนี้เป็นอะไรที่เราไม่ได้คิดว่ามันจะเกิดขึ้นแต่แรก เหมือนกับแผลที่เกิดขึ้นระหว่างทาง พอเรามีแผลมากขึ้น เราก็อาจจะรักษามันโดยการ hot fix หรือเพิ่มโค้ดที่ไม่ได้อยู่ใน design แรกที่วางไว้
ผลก็คือเมื่อเวลาผ่านไป โค้ดของเราก็ยิ่งมีความซับซ้อนมากขึ้น เริ่มพันกันมากขึ้น จนเริ่มถึงจุดที่การแก้ทำได้ยากขึ้น ไม่มีใครอ่านเข้าใจ และไม่มีใครอยากไปแตะมัน
(ถึงแม้ในแง่นึงการเขียนโค้ดจะเป็นการสั่ง computer ให้แก้ปัญหาให้เรา แต่ในอีกแง่ซึ่งสำคัญมากยิ่งกว่า คือการเขียนให้คนที่เป็นนักพัฒนาอ่านรู้เรื่อง)
“A simple, powerful program that delights its users and does not vex its builders — that is the programmer’s ultimate goal.” — Jon Bentley, Programming Pearls
สิ่งหนึ่งที่เราทำได้ก็คือการ ‘Refactor’ มันหรืออาจจะ ‘Rewrite’ ไปเลย (แน่นอนว่ามี cost ที่ต้องแลก); ซึ่งเป็น process หนึ่งที่สำคัญ ที่ทำให้เราได้กลับมา revisit design decisions ใหม่ แล้วออกแบบมันราวกับว่า “ถ้าย้อนเวลากลับไปได้จะออกแบบแบบนี้”
“I would spend time rewriting whole sections of code to make them more cleanly organized. I’m a firm believer that the best way to prevent bugs is to make it so that you can read through the code and understand exactly what it’s doing …” — Bill Atkinson, In Writing MacPaint
สุดท้ายเราก็จะได้โค้ดที่ well design ที่เรียบง่าย อ่านเข้าใจง่าย และพัฒนาต่อไปในแนวทางที่เราคาดเอาไว้ต่อได้แบบไม่ติดขัด … และพอเวลาผ่านไปเราก็จะเจอแผลที่เราคาดไม่ถึงอยู่ดี วนเป็นวัฏจักรแบบนี้ต่อไปเรื่อย ๆ
ส่วนตัวเรามองว่าสิ่งนี้เป็น natural learning process ที่เราหลีกเลี่ยงไม่ได้ เราไม่สามารถออกแบบสิ่งต่าง ๆ รอไว้ล่วงหน้าเพื่อที่จะหลบแผลที่อาจจะเกิดขึ้นในอนาคตได้ นั่นเป็นเพราะเราไม่สามารถมองเห็นอนาคตได้; ความเป็นจริงเป็นอะไรที่มีรายละเอียดเยอะ และซับซ้อนเกินกว่าที่จะเดาอะไรแล้วถูก: “Reality has no resolution limit”
สำหรับเราเอง ไม่ว่าจะเขียนโค้ด ออกแบบ software ออกแบบ product หรือแม้กระทั้งเขียนบทความ เราก็รู้สึกว่า principle นี้ยังใช้ได้ดีและ effective อยู่เสมอ: “Ship fast. Collect scar tissues. Improve & Redesign. Iterate.”
“… If you want to get it smooth, you’ve got to rewrite it from scratch at least five times.” — Bill Atkinson, In Writing MacPaint
