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