คำตอบของ Dan Abramov จากคำถามใน HashNode

วันนี้ Dan Abramov มาตอบคำถามใน HashNode เกี่ยวกับ 2 ปีที่ทำงานที่ facebook ว่าได้เรียนรู้อะไรบ้าง ? ดังนั้นจึงทำการแปลและสรุป รวมทั้งเพิ่มเติมไว้นิดหน่อย น่าจะมีประโยชน์สำหรับนักพัฒนากันบ้าง ข้อแรกเรื่องของทีม ของ manager ที่ดี ซึ่งทำให้ชีวิตการทำงานมันแจ่มมาก ๆ เรื่องคน เรื่องทีม เรื่อง manager เรื่องความไว้เนื้อเชื่อใจ มันสำคัญต่องานมาก ๆ เพราะว่างานที่ออกมามันก็สะท้อนทีมและองค์กรนั่นเอง ข้อสองเรื่อง Big rewrites often fail การเขียน code ใหม่จำนวนมาก ๆ มันมักจะ fail เยอะ ดังนั้นถ้าต้องการเขียนใหม่ แนะนำให้เขียนแบบค่อยเป็นค่อยไป เนื่องจากการเขียนใหม่ทั้งหมดนั้นเราคาดหวังว่าจะแก้ไขปัญหาได้ แต่มันมักจะสร้างปัญหาอื่น ๆ ตามมาอีกมากมาย ยิ่งถ้าคุณไม่ได้เขียน version ก่อนหน้านั้นมา ยิ่งไปกันใหญ่ ข้อสามเรื่อง Big rewrites can succeed ดูเหมือนมันจะขัดแย้งกับข้อสองน่าดู แต่ว่าจะเขียนได้นั้นก็ต่อเมื่อมีชุดของการทดสอบ เช่น integration test ที่ดี เน้นย้ำว่าดีนะ นั่นคือไว้ใจและเชื่อถือได้ รวมไปถึงวิธีการส่งมอบสิ่งที่สร้างไปถึงมือผู้ใช้งาน จะเห็นการเขียนใหม่ได้จาก React 16 ข้อสี่ สำหรับ library ต่าง ๆ ที่นำมาใช้งานควรต้องเขียนชุดการทดสอบระดับ public api สำหรับการทดสอบนั้น ต้องช่วยว่าระบบมันทำงานได้อย่างถูกต้อง รวมทั้งต้องง่ายต่อการเปลี่ยนแปลงอีกด้วย เช่นการเปลี่ยน library เป็นต้น ดังนั้นการทดสอบก็ต้องคิดให้มากเช่นกัน Unit testing มันดีแต่ใช้ให้เหมาะสม ข้อห้า สำหรับ code ที่ซับซ้อนมาก ๆ แนะนำให้ทดสอบแบบ fuzz testing !! อย่างแรกเลย Fuzz testing มันคืออะไร ? จาก Wikipedia อธิบายไว้ว่า มันคือวิธีการทดสอบที่จะเตรียมข้อมูลที่ invalid, unexpected และ random ขึ้นมา จากนั้นทำการดูการทำงานของระบบว่า จะพังหรือไม่ ? memory leak หรือไม่ ? การทดสอบพังหรือไม่ ? จากข้อมูลเข้าที่เราไม่ได้คาดคิด อาจจะส่งผลให้เกิดผลลัพธ์ที่ไม่คาดฝันขึ้นมาได้ ข้อหก เกี่ยวกับ code ที่เขียนให้คิดว่า สิ่งที่สร้างขึ้นมามันจะพัฒนาต่อไปอย่างไร ? นั่นคืออย่าคิดเพียงว่าปัจจุบันเป็นอย่างไร ให้คิดถึงอนาคตที่ต้องเป็นไปด้วย นั่นคืออย่าเขียนเพียงให้มันเสร็จ ๆ การเขียน code แต่ละทางมันมีทั้งข้อดีและข้อเสีย สิ่งที่เราต้องทำอยู่ตลอดเวลาคือ การคิดและตัดสินใจ ซึ่งมันอาจจะดีหรือไม่ดีก็ได้ เพราะว่าผลที่ตามมาคือ อาจจะทำให้คุณไปถึงหรือไม่ถึงเป้าหมายได้ ดังนั้น คิดนะ Think about code in time ข้อเจ็ด เราไม่จำเป็นต้องรู้ทุกสิ่งอย่าง แต่เราจำเป็นต้องรู้และเข้าใจเป้นอย่างดีเมื่อต้องเข้าไปยุ่งเกี่ยวกับส่วนนั้น นั่นคือ เราต้องเรียนรู้เพื่อเข้าใจในสิ่งที่ไม่เข้าใจนั่นเอง ข้อสุดท้ายเรื่องวิธีการคิดที่เป็นระบบ เมื่อเกิดปัญหาเรามักจะเข้าไปไล่อ่าน code แบบ sequencial ไปเรื่อย ๆ ซึ่งเป็นวิธีการที่ไร้ประสิทธิภาพและเสียเวลาไปอย่างมาก ดังนั้นสิ่งที่เราควรคิดคือ เราจะมีวิธีการจัดการมันอย่างไร ยกตัวอย่างเช่นมีปัญหาระหว่าง A ไปยัง B การแก้ไขลองเขียน log ตรงกลางระหว่าง A กับ B ก่อน เพื่อดูว่ามีข้อผิดพลาดของการส่งข้อมูลบางชุดหรือไม่ก่อน ? ซึ่งมันช่วยตัดไปหาไปได้เยอะหรือสักครึ่งนึงแล้ว จากนั้นจึงไปดูอีกฝั่งต่อไป มันจะช่วยทำให้การ debug และหาข้อผิดพลาดได้ดีขึ้นมาก

นั่นคือ Observe -> form a hypothesis -> come up with a way to test it -> repeat

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