Monthly Archives: October 2016

ควรเขียนโค้ดใหม่บ่อย ๆ

เมื่อกี้ดู talk นี้ตอนทำอาหาร ล้างจาน พอทำเสร็จแล้วต้องกลับมาเปิดดูซ้ำอีกครั้งหนึ่งทันทีเพราะมีรายละเอียดที่น่าสนใจเยอะมาก แนะนำให้ทุกคนที่อยู่ในวงการพัฒนาซอฟแวร์ดู หลาย ๆ แนวคิดมีเหตุผลและน่าสนใจแต่ท้าทายสิ่งที่เราคิดและพยายามทำกันอยู่ในปัจจุบันพอสมควร

ผู้พูด คือ Chad Fowler อดีต CTO ของ Wunderlist ที่ถูก Microsoft ซื้อไป ตอนนี้เค้าเปลี่ยนตำแหน่งไปเป็น General Manager

หัวข้อจริงๆ ของ talk คือ Impermanance – the ironic key to systems that survive โดยในภาพรวมเค้าเล่าถึงระบบของ Wunderlist ที่ก่อนเค้าเข้าไปทำงานเป็น Monolith Ruby application แล้วตอนนี้กลายเป็นระบบที่เป็น microserivces ซึ่งมีหลักหลายร้อย service

เค้ากล่าวว่า “The system is the asset. Code is a liability.”

เค้าเปรียบเทียบการที่ร่ายกายคนเราอยู่มาได้จนถึงวันนี้ เกิดจาก cell แต่ละส่วนในร่างกายตายและถูกสร้างขึ้นมาใหม่อยู่ตลอดเวลา

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

ระบบที่รันอยู่นานและไม่เคยเปลี่ยนเลยพอถึงเวลาที่เราจะต้องเปลี่ยนมันจะเปลี่ยนยาก ซึ่งเป็นความเสี่ยง ถ้าเราเปลี่ยนมันอยู่บ่อย ๆ เราจะมีความมั่นใจที่จะเปลี่ยนจะแก้ไขมันอยู่เสมอ

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

เค้าเล่าว่าหลังจากเปลี่ยนเป็น microservice ในปีแรก โค้ดประมาณ 80% ถูกเขียนใหม่ ไม่ได้ถูกเขียนใหม่เพราะแค่เขียนใหม่ แต่เขียนใหม่เพราะต้องบำรุงรักษา ปรับปรุงหรือเพิ่มฟีเจอร์ให้แก่มัน

เค้ามีนโยบายให้ทีมงานเลือกใช้ภาษาอะไรก็ได้ แม้กระทั่งเด็กฝึกงาน ขอแค่เข้ากับระบบ deploy และระบบ metric ที่มีอยู่ได้ ประโยชน์ที่ได้รับคือ ไม่มีปัญหาเมื่อจะต้อง upgrade อะไร เพราะทำอยู่เสมอ ๆ อยากลองใช้ภาษาอะไรก็ทำได้ง่าย เค้าเคยมีเหตุการณ์ระบบมีปัญหาตอนกลางคืน และคนที่อยู่เวรวันนั้นอ่าน Haskell ไม่รู้เรื่องเลยเขียนใหม่เป็น Elixir เพื่อแก้ปัญหาตอนนั้นซะเลย

อีกนโยบายหนึ่งของเค้า คือ no shared code ระหว่าง component เพราะมันจะทำให้การแก้ไขแต่ละ component กระทบกันทำให้เกิดการเปลี่ยนแปลงยาก ให้ใช้ share service แทน

ระบบของเค้าใช้การ communication ในรูปแบบง่าย ๆ ได้แก่ http/json เป็นส่วนหนึ่งที่ทำให้เขียน component ใหม่ได้ง่าย เค้าบอกว่าระบบที่เข้าใจง่ายสำคัญกว่าระบบที่มีประสิทธิภาพ (แต่สุดท้ายระบบที่เค้าเขียนให้เข้าใจง่ายนี้ก็เร็วกว่า monolith ของเก่ามากอยู่ดี)

ส่วนที่เปลี่ยนยากที่สุดของระบบเค้าเขียนด้วย Haskell มันสมบูรณ์แบบมากและไม่เคยต้องถูกแก้เลย ซึ่งในตอนแรกก็ภูมิใจกับมันมาก แต่แล้วพอวันที่เกิดปัญหามาถึงเกิดปัญหาที่รุนแรงกว่าและแก้ไขได้ยากกว่าปกติ เค้าบอกว่าถึงโค้ดจะสมบูรณ์แบบแต่สิ่งรอบข้างเปลี่ยนแปลงอยู่ตลอดเวลา เช่น dependency เก่าอาจจะใช้ไม่ได้แล้ว

ระบบของเค้าไม่เน้นใช้ testing ในการควบคุมคุณภาพของระบบ แต่เน้นที่การ monitoring, metric ที่ครอบคลุมอยู่ทั้งระบบ เช่น ถ้าผู้ใช้งาน sign-in ไม่ได้เค้าจะรู้ทันที เค้ากล่าวว่าเราป้องกันปัญหาทุกอย่างไม่ได้ เราจึงควรหาวิธีที่ทำให้รู้ปัญหาได้อย่างรวดเร็วและสามารถแก้ไขมันได้อย่างรวดเร็ว

มีครั้งนึงที่ลูกทีมของเค้าอยากให้วางกรอบเลือกใช้ซักแค่ไม่กี่ภาษาก็พอ ซึ่งในตอนแรกเค้าก็ดีใจ เพราะเค้าไม่ต้องเป็นคนพูดเอง เมื่อลูกน้องพูดด้วยตัวเองก็แปลว่าพวกเค้าเต็มใจทำ แต่สุดท้ายแล้วเค้าก็มาคิดว่ามันจะทำให้กลับไปเจอปัญหาเก่า ๆ เช่น upgrade version ยาก หรือสุดท้ายบริษัทกลายเป็นที่ ๆ เขียนกันอยู่ภาษาเดียว เช่น Scala แล้วก็จะมีปัญหาเมื่อวันหนึ่งก็ต้องมาใช้ C# เพราะถูก Microsoft ซื้อ

“Small is not a goal”
“Healthy, longevity is the goal”
“Systems that survive are made of components that can change”
“If it hurts, do it more often” (เอามาจาก XP) ถ้าอะไรที่มันต้องเปลี่ยนอยู่แล้วก็เปลี่ยนมันบ่อย ๆ และหาทางทำให้การเปลี่ยนแปลงนั้นมันไม่รุนแรงและเปลืองทรัพยากร
Impermanence -> Decoupling, Longevity, Agility

คำถามช่วงท้าย

Q: การมีหลายภาษาแล้วไม่ expert มีผลไหม?
A: ปกติภาษาที่มีใช้ก็จะมี expert อยู่ในทีม แต่ถ้าเค้าไม่อยู่แล้วก็เขียนใหม่

Q: มีปัญหาด้านความรู้สึกภายในทีมไหมกับการที่ต้องทิ้งโค้ดตลอดเวลา เปลี่ยนแปลงตลอดเวลา (จากบทสนทนาและเสียงผมค่อนข้างมั่นใจว่าคนถามคือ Dave Thomas)
A: มี ต้องพยายามสร้างความเข้าใจถึงประโยชน์ และ celebrate การเปลี่ยนแปลงอยู่เสมอ ๆ

— x —

ใครอ่าน/ฟังเรื่องนี้แล้วสนใจ ผมขอแนะนำบล๊อกโพสซีรียส์เรื่อง The New Normal ครับ จากคนละคนกันแต่วิธีคิดคล้าย ๆ กัน

http://blog.cognitect.com/?tag=NewNormal+Series

เป็นแนวคิดที่เปิดหูเปิดตาดีอยากให้ได้อ่านกัน เคยเขียน email ไปขอแปลแล้วเค้าบอกว่าไม่ให้ republish