February 06, 2021
2 min read

"Make it work, Make it right, make it fast!"

refactoring
software engineering

หลายสัปดาห์ก่อน ผมได้เล่าเทคนิคเล็ก ๆ ของการเขียนโปรแกรมอย่างเรื่อง 1,2, Refactor! จากหนังสือ Refactoring: Improving the Design of Existing Code (Book) ไปแล้ว วันนี้ผมจะมาเล่าอีกเทคนิคหนึ่งกัน

นั่นคือ "Make it work, Make it right, Make it fast"

Kent Beck's Quote

ถ้าเริ่มจาก เขียนโปรแกรมเพื่อให้เสร็จไวที่สุดเท่าที่จะทำ ได้โดยยังไม่สนความสวยงามแล้วค่อยมา Refactor ให้มันเป็น Code ที่สวยงาม

มันจะเร็วกว่า การพยายามเขียนโปรแกรมที่สวยงามตั้งแต่แรกเยอะ (มาก)

ฉะนั้น สั้น ๆ สำหรับ tip นี้คือ ทำให้มัน work ก่อน.. แล้วค่อยทำให้มันถูก วางถูกที่ถูกทาง อ่านง่าย เข้าใจง่าย .. แล้วค่อย optimize มันก็ได้ ไม่สายหรอก! (เร็วกว่าด้วย)

🔗Make your Coding Faster

ความคิดเห็นส่วนตัวผมบอกว่า ถ้าอยากเขียนโปรแกรม ไว ๆ นอกจากการหัดพิมพ์ดีดให้เร็วแล้ว ก็มักจะใช้เทคนิคนี้นี่แหละครับ

มาไล่ไปทีละ Step กัน

🔗Step 1. Make it work

Step แรกคือ Make it work, เราแค่เขียนโปรแกรมเพื่อให้มันใช้งานได้ โค้ดมันอาจจะน่าเกลียดและยุ่งเหยิง อ่านแล้วเข้าใจยาก

มันโอเค... 👍🏻

ถ้ามันทำงานถูกต้อง มันใช้งานได้ มันผ่าน Testcases ที่เราเขียนไว้ทั้งหมด จะแย่ยังไงมันก้ส่งมอบ Value ได้แล้้วกันน่า!

ผมไม่ได้บอกว่าทำให้้สวยตั้งแต่แรกไม่ได้นะ ถ้ารู้้ว่าเขียนแบบไหนละสวยก็เขียนเลย เว้นแต่ว่าตัวเรายังไม่แน่ใจ ก็จงอย่าไปเสียเวลากับการทำ Code ให้มันสวยที่สุดในตอนนี้

ยังไม่ต้องมี Design pattern หรือ Principles ก็ได้ หรือถ้าเรารู้สึกว่ามันอาจจะทำแบบนี้แบบนั้นได้ อาจจะเพียงแค่ใส่ TODO Comment แปะเอาไว้กันลืมก็เพียงพอแล้ว

ฉะนั้น เขียนแค่พอมันทำงานถูกต้องสมบูรณ์ก็เพียงพอแล้ว แค่มันทำงานได้ผู้ใช้ของเราก็ยิ้มแย้มแล้วล่ะ 🤤

🔗Step 2. Make it right

หลังจากเมื่อเราได้ Working Solution มาแล้วนั้น ถึงเวลาทำให้พวกเราเหล่าโปรแกรมเมอร์ยิ้มแย้มกันบ้าง 😆

เริ่มจากเรามาดู โค้ดของเรากันดูว่ามีจุดไหนที่ปรับปรุงให้ดีขึ้นได้บ้าง

ลองมองดูว่าโค้ดของเรามี Code Smell แบบไหนอยู่บ้าง, ลองดูตาม Software Engineering Principle, หรือว่า โค้ดของเรามัน Clean พอรึยัง พอที่เราและทีมอ่านแล้วไม่เกิดข้้อสงสัยหรือยัง

ปรับปรุงจนเรารู้สึกว่า "ดีพอ"

คำว่าดีพอสำหรับแต่ละคนนั้นไม่เหมือนกัน ถ้าสำหรับตัวผมคือ แค่เราและทีมอ่านมันแล้วเข้าใจว่ามันทำงานยังไง และสบายใจถ้าต้องทำงานหรือแก้โค้ดชุดนี้ เท่านี้ผมเรียกว่า "ดีพอ" แล้วครับ

ถ้าคิดว่ามันยังตั้งชื่อได้ดีกว่านี้้ ก็แก้มันซะ ถ้าคิดว่ามันยังมี Testcases หรือ Scenarios ที่เราลืมหรือพลาดไป ก็เขียนมันตอนนี้ ถ้าคิดว่ามันยังจัดวาง Code Structure ไม่ดี ก็ทำมันซะตอนนี้เลย

ทำทุกอย่างที่เพื่อให้โค้ดชุดนี้เป็นสิ่งที่​ "ดีพอ" และใช่สำหรับพวกเรานั่นเอง

อย่างหนึ่งที่สำคัญ คือ อย่า Over-engineering .. ถ้าสมมุติว่า feature นี้ที่ทำอยู่มี Throughput อยู่ที่ 1,000 Transaction Per Second ( TPS ) ซึ่งเพียงพอต่อการใช้งานในปัจจุบันแล้ว อย่าเสียเวลาไปแก้มันให้เร็วขึ้นเลย

พวกเราโปรแกรมเมอร์ยังมี features อีกมากมาย, bug, defect ที่รอให้เราไปสร้าง Value ให้กับผู้ใช้อยู่ ไปทำพวกนั้นดีกว่าครับ อย่าเสียเวลากับการ optimize ในตอนนี้เลย

🔗Step 3. Make it fast

แต่เมื่อเวลานั้นมาถึง วันที่เรารู้้ว่ามัน "เร็ว" ไม่พออีกแล้ว มันคือช่วงเวลาที่เราต้อง Optimize งานของเราซักที

เราจะรู้ได้ยังไงว่าเวลามาถึงแล้ว? ง่ายที่สุดที่ผมจะแนะนำคือใช้ Tools ช่วยครับ และเดี๋ยวนี้มี Tools มากมายที่เข้ามาช่วยเรื่องนี้อย่าง Instana, New Relic, AWS CloudWatch และผองเพื่อนอีกมากมายเลย

หรือจะเป็น Matrics อื่น ๆ ที่มักใช้กันเช่น Web Vitals ก็ได้้เป็นต้นครับ

ซึ่งถ้าหากเราคิดมาแล้วว่ามันมี Value ที่สมควรจะต้องทำแล้วนะ เราค่อยมาทำปรับปรุง มา Optimize กันตอนนี้นั่นเองครับผม

การปรับปรุง Performance นั้นมีหลายแบบ และสิ่งที่หลายคนคงนึกถึงคงจะเป็น Scale Out/Scale Up, การเปลี่ยน Algorithms ที่ใช้, การเปลี่ยน Tools ที่ใช้, การทำ Services ใหม่ขึ้นมาทดแทน, ฯลฯ และอีกมากมายหลายเทคนิคให้เลือกใช้กัน

แต่สำหรับผมแล้ว ผมยังคงเชื่อเรื่อง Beyond Good Enough is Waste และ YAGNI (You aren't gonna need it) มาก ๆ

เราเป็นโปรแกรมเมอร์ และเราเองสามารถสร้าง Value ได้อีกมากมายเมื่อเทียบกับการใช้เวลาทั้งหมดเพื่อทำแค่บางสิ่งบางอย่างให้ดีที่สุด

แต่มันคนละเรื่องกับทำเพื่อสนองความต้องการของตัวเองนะ .. เช่นเรารู้ว่าแค่นี้มันก็ใช้ได้ดีแล้ว แต่ใจเราอยากทำให้มันเป็น O(1),O(log n), ทำให้มันใช้ Resource น้อยลง ก็ทำมันเถอะครับ 😂 ถ้าเวลายังพอมี รู้ว่าต้องทำไง ก็ตามหัวใจตัวเอง ความสุขและความสนุกมันควรอยู่ในงานที่ทำทุก ๆ งาน (เพราะบางครั้งผมก็เป็น..)

สำหรับใครที่ยังอยากได้ความเห็นเพิ่มเติมว่าเราควร Optimize Performance ตอนไหน แล้วควรทำทุกส่วนหรือทำยังไงบ้าง อ่านสรุปของพี่ปุ๋ย Somkiat.cc เพิ่มเติมจะดีมาก ๆ ครับ

🔗Summary

มาถึงตรงนี้ถามว่าเราจะเขียนโปรแกรมไวขึ้นได้ยังไง?

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

และสุดท้ายผมอยากฝากเอาไว้ว่าวิธีนี้มันไม่ใช่ Silver Bullet ที่แก้ปัญหาได้ทุกอย่างบนโลกของโปรแกรมเมอร์นะครับ มันเป็นแค่วิธีการทำงานแบบหนึ่งเฉย ๆ

ผมอยากให้ทุกคนลองนำไปปรับใช้ดู ลองหาจุดที่พอดีกับตัวเอง แค่ไหนที่เรียกว่า Make It Right แค่ไหนที่เรียกว่า Make It Right และแค่ไหนที่ควรจะคิดเรื่องของ Make It Fast

ถึงวันนั้้นกลับมาแชร์ให้ผมฟังด้วยนะครับ!

🔗Good Resource

สำหรับใครอยากหาอะไรอ่านต่อ ผมแนะนำ List ด้านล่างนี้เลยครับผม

The views and opinions expressed in this article are purely mine and do not necessarily reflect the positions of any companies for which I have worked in the past, present, or future.