นักพัฒนา software ทั้งหลาย
จากที่ผ่านร้อนผ่านหนาว ผ่านประสบการณ์ต่างๆ ทั้งดีและร้าย มานั้น
ลองหยุดและมองย้อนกลับไปหน่อยสิว่า
เราได้เรียนรู้อะไรจากมันบ้าง ?
เรื่องแรกคือ การพัฒนา (Development)
เริ่มต้นจากพัฒนาสิ่งเล็กๆ หรือเรียบง่ายก่อนเสมอ
จากนั้น จะเริ่มทำการต่อยอด และ ขยายต่อไป แบบ step-by-step
ไม่ว่าจะเป็นการพัฒนาระบบใหม่ หรือ ต่อยอดจากระบบเดิมก็ตาม
ที่น่าแปลกใจเลยก็คือ เรามักจะเจอคำว่า งานงอก อยู่อย่างเสมอ
ทั้งๆ ที่เราทำการวางแผนอย่างละเอียดตั้งแต่ต้น
ดังนั้นแทนที่จะวางแผน และ ทำตามแผน
ให้หันกลับมาเรียนรู็จากการลงมือทำแบบ step-by-step ดีกว่าไหม
เพื่อทำให้คุณพบวิธีการแก้ไขปัญหาที่ดีกว่า และ เหมาะสมกว่า
เชื่อเถอะว่า
ระบบที่มันซับซ้อน ก็เริ่มต้นมาจากระบบที่เรียบง่ายนี่แหละ
ดังนั้น เริ่มต้นให้มันง่ายเข้าไว้ อย่าเยอะ
Do one thing at a time
ในเวลาหนึ่งๆ ให้ทำเพียงอย่างเดียว
ทั้งการเพิ่ม ลบ แก้ไข หรือ การเปลี่ยนแปลงเรื่องต่างๆ
อย่าทำหลายๆ เรื่องพร้อมกัน ไม่งั้นผลที่ออกมามันจะแย่มากมาย
ให้ใส่พวก logging และ การจัดการกับ error ตั้งแต่ต้น
ยิ่งเป็นระบบใหม่ๆ แล้วนั้น ควรเพิ่มเข้าไปตั้งแต่ต้น
บ่อยครั้งพบว่า ต้องตามกลับมาเพิ่มที่หลัง
มันจะเป็นเรื่องที่น่าปวดหัว และ น่าเบื่ออย่างมากมาย
และสิ่งที่เก็บไปนั้น ควรจะต้องสามารถนำมาใช้ประโยชน์ได้ง่าย
ไม่ใช่เก็บลง log file เฉยๆ ซึ่งมันไม่สามารถนำมาวิเคราะห์อะไรได้เลย !!
สิ่งที่ต้องให้ความสำคัญคือ
ทุกๆ บรรทัดของ code ที่คุณเพิ่มไปนั้น
ต้องได้รับการประมวลผล หรือ ทดสอบ อย่างน้อย 1 ครั้ง
ตัวอย่างเช่น code ติดต่อฐานข้อมูล
คุณมักจะทำการ try-catch เพื่อดักจับ error ในการทำงานกับฐานข้อมูล
แต่พบว่า ในการทดสอบ หรือ ประมวลผล
ไม่มี process ใดเลยเข้าทำงานในส่วนของ error
ดังนั้น คุณจะมั่นใจใน code ของคุณได้หรือ ถ้าเกิด error ขึ้นมา ?
แต่ส่วนการทำงานของระบบ ต้องได้รับการทดสอบ
ก่อนที่จะนำมาทดสอบรวมทั้งระบบ
นั่นคือ ต้องมี unit test ก่อนที่จะ integration test
ต้องมี integrate test ก่อน system test
เพื่อทำให้เรามั่นใจว่า แต่ละส่วนของระบบงานทำงานได้ดีและราบรื่น
มันคือ การสร้างความชื่อมั่น และ มั่นใจล้วนๆ
ลองคิดดูสิว่า ถ้าคุณยังไม่มั่นใจเลย
แล้วใครจะมั่นใจ และ เชื่อมั่นคุณกันล่ะ !!
ต่อมาให้จำไว้ว่า ทุกสิ่งทุกอย่างมันต้องใช้เวลามากกว่าที่คุณคิดเสมอ !!
ในการพัฒนา software นั้น เรื่องของการ estimate ให้ถูกต้องนั้น
มันยากมากๆ แต่เราก็พยายามกันเสมอมา …เช่น
ต้องใช้เวลาเท่าไรในการพัฒนา feature นั้น feature นี้
ถ้าการพัฒนาเป็นไปอย่างราบรื่น ไร้ซึ่งปัญหา
แต่เมื่อเริ่มเข้าสู่การพัฒนา คุณมักจะเจอปัญหาที่ไม่คาดฝันเสมอ
เช่น ถ้าไปแก้ไขระบบเก่า คุณก็อาจจะเจอ bug เดิม
หรือเมื่อทำการ merge ดันไปเจอ bug เข้าให้
หรือเมื่อทำการ upgrade framework/library ต่างๆ ที่ใช้งานเป็นต้น
กฎของ Hofstadter กล่าวไว้ว่า
It always takes longer than you expect, even when you take into account
เรื่องของ Legacy system นั้น
ก่อนอื่นคุณต้องทำความเข้าใจกับมันก่อนที่จะลงมือทำอะไร
ทั้งเรื่องของการทำงาน สิ่งที่เกี่ยวข้อง รวมทั้ง solution ต่างๆ
ไม่เช่นนั้น เราจะพบว่า code ใหม่ที่เราเพิ่ม หรือ แก้ไขนั้น
มันส่งผลให้ระบบเดิมทำงานผิดพลาดอยู๋อย่างเสมอ !!
ดังนั้น คุณควรมีความสามารถในการอ่าน code มากกว่าการเขียน code นะครับ
เมื่อคุณอ่าน code แล้ว ก็อย่าลืม run code เหล่านั้นด้วยล่ะ
เพื่อทำให้คุณมั่นใจว่า ระบบมันทำงานได้นะ
จากนั้นจึงเริ่มลงมือแก้ไขต่อไป
เรื่องที่สอง เกี่ยวกับการแก้ไขปัญหา
เชื่อเถอะว่า bug มันเกิดขึ้นได้เสมอ
แต่ประเด็นมันอยู่ที่ว่า คุณรู้จุดที่ก่อให้เกิด bug รวดเร็วเพียงใด ?
ในโลกของการพัฒนา software มีคำสวยๆ เท่ๆ แต่กินไม่ได้ คือ
Get it right at the first time !!
ถึงแม้ว่าคุณจะเก่งเพียงใด มาจากโลกไหน และใช้พลังไปมากเท่าไร
สุดท้ายระบบที่คุณพัฒนาขึ้นมาก็มี bug !!
ดังนั้น ให้เปลี่ยนใหม่ว่า ค่อยๆ ทำ ค่อยๆ แก้ไข ไป
คำถาม
คุณรู้เมื่อไร ว่าระบบมี bug ?
คุณใช้เวลาในการหาจุดที่เกิด bug นานเท่าไร ?
เมื่อคุณได้รับ bug เข้ามาแล้ว คุณสามารถ reproduce bug ได้ไหม ?
ถ้าคุณตอบว่า ไม่ได้
คำถามคือ แล้วคุณจะแก้ไข bug ได้อย่างไร ?
ดังนั้น สิ่งที่คุณต้องทำก่อนแก้ไข bug คือ reproduce มันขึ้นมา
เพื่อทำให้รู้ว่า ลูกค้าพยายามกำลังจะทำอะไร
เพื่อทำให้รู้ว่า ระบบถูกใช้งานอย่างไร
ดังนั้น อย่าเดา อย่ามั่ว อย่าสุ่ม เอาเอง
ถ้าคุณบอกว่า มันแก้ไข หรือ reproduce ยาก
นั่นเป็นสิ่งที่บ่งบอกว่า ระบบของคุณมันมีการออกแบบที่ยาก หรือ ไม่ดีแล้วนะ
ดังนั้น การ reproduce bug จึงมีประโยชน์ในกลายๆ มุมมอง
พยายามแก้ไข bug ที่คุณรู้ และ เข้าใจถึงปัญหาก่อนเสมอ
ส่วน bug อื่นๆ ค่อยตามไปดูทีหลัง
ไม่เช่นนั้น คุณจะไม่ได้แก้ไข bug อะไรเลย
ส่วนใหญ่ที่พบ bug ที่เรารู้มันจะส่งผลต่อ bug ที่เราไม่รู้เสมอ
เรื่องที่สาม การทำงานร่วมกัน
เรื่องแรกคือ การพูดคุยให้เป็นแบบ face-to-face ให้มากที่สุด
เนื่องจากการพูดคุยแบบนี้ จะมีประสิทธิภาพที่สุด
ไม่ต้องมานั่งตีความ หรือ รอ จากพวก email, chat ต่างๆ
เมื่อเราติดปัญหา อย่าแก้ปัญหาด้วยตัวคนเดียว
ให้ทำการกำหนดขอบเขตเวลาในการแก้ไขปัญหาซะ
ถ้าทำไม่ได้จริงๆ ก็ให้ไปถาม และ ขอความช่วยเหลือจากเพื่อนร่วมงาน
เชื่อเถอะว่า ทุกๆ คนพร้อมจะช่วยเหลือ
เนื่องจากทุกๆ คนก็ติดปัญหเหมือนกับคุณนั่นแหละ
เพียงแต่ไม่กล้ามถามเท่านั้นเอง
ดังนั้นการถาม เป็นสิ่งที่คุณควรทำ และ ไม่ควรอายนะครับ
ด้าน-ได้-อาย-อด นะ
สุดท้ายคุณห้ามลืม การให้ credit ต่างๆ จากเจ้าของความคิดนะครับ
เนื่องจากคนส่วนใหญ่ชอบเอาสิ่งที่ดีเข้าตัวเอง
ส่วนสิ่งที่ไม่ดีโยนให้คนอื่นเสมอ
… อย่าทำแบบนี้เด็ดขาดนะครับ …
เรื่องอื่นๆ ที่อยากจะแนะนำ
ทุกคนต้องมีความพยายามที่จะทำความเข้าใจระบบ
ทุกคนต้องมีความพยายามที่จะศึกษาสิ่งต่างๆ
ทุกคนต้องมีความพยายามที่จะเรียนรู้สิ่งใหม่ๆ
ทุกคนต้องมีความพยายามที่จะเรียนรู้การทำงานแบบ step-by-step
ถ้าคุณเจอปัญหาที่ยากๆ ให้พยายามกำหนดกรอบเวลาทำงานซะ
ถ้าเกินนั้น ให้คุณพักผ่อนซะ อย่าไปฝืนกับมันมากนัก
เนื่องจากเราลงแรงไปกับมันมาเยอะแล้ว
การพักผ่อนมันจะทำให้คุณผ่อนคลาย
และบ่อยครั้งพบว่า
หลังจากตื่นนอนมา เราสามารถหาวิธีแก้ไขปัญหาได้เสมอ
อย่ากลัวการเปลี่ยนแปลง
เนื่องจากในโลกการพัฒนา software มันคือ
โลกที่มีการเปลี่ยนแปลงตลอดเวลา
ดังนั้น ให้กลับมาคิดว่า คุณจะพร้อมรับมือกับการเปลี่ยนแปลงได้ดีเพียงใด
สุดท้าย
จงพร้อมที่จะเรียนรู้สิ่งใหม่ๆ อยู่ตลอดเวลา
ทั้งเรื่องของเทคโนโลยี
ทั้งเรื่องของภาษาโปรแกรม
ทั้งเรื่องของการอ่านหนังสือ
จงเรียนรู้อยู่อย่างสม่ำเสมอครับ
นั่นคือเส้นทางในการพัฒนาตัวของคุณเอง …
แล้วคุณล่ะ ได้เรียนรู้อะไรจากการพัฒนา software บ้าง ?
… หรือทำเพียงให้มันเสร็จๆ ไปเถอะ …
