Screen Shot 2558-01-02 at 4.32.00 PM
ในปี 2015 นี้
คุณในฐานนะที่เป็นนักพัฒนา software นั้น
ถ้าให้เลือกทำ  technical practice อย่างใดอย่างหนึ่ง
เพื่อทำให้การพัฒนา software ดีขึ้น
คุณอยากจะทำอะไร ?

ในการเป็นนักพัฒนา software นั้น

แน่นอนว่า คุณต้องรู้และเข้าใจเกี่ยวกับ technical practice ดีๆ จำนวนมาก
ซึ่งถ้านำมันมาใช้งาน ก็จะทำให้ software ที่พัฒนามานั้น ออกมาดี

ปล. ไม่ใช่เฉพาะการ coding นะ
แต่ยังรวมไปถึงการคุย requirement, analysis, design, testing, review และ การ deploy

แต่โชคไม่ดีเท่าไร ที่นักพัฒนาไม่ค่อยนำมาใช้งานมากนัก !!
หรือนำมาใช้งานกันอยู่แล้วนะ ?

มาในปี 2015 นี้

ถ้าให้คุณเลือกทำสักอย่างหนึ่งใน technical practice ที่ดี
คุณจะเลือกอะไร ?
สิ่งที่คุณเลือกมันมีประโยชน์อย่างไร ?
แล้ว คุณจะเริ่มต้นตรงไหนดีล่ะ ?

ตัวอย่างเช่น

1. Continuous Integration

ต้องการทำให้ code ของระบบมันทำงานได้อยู่ตลอดเวลา
นั่นคือนักพัฒนา จะทำการ sync code มาให้บ่อยที่สุดเท่าที่จะทำได้
เพื่อทำการ build, test และ deploy ให้บ่อยที่สุด
เพื่อให้รู้ feedback ได้รวดเร็ว
เพื่อทำให้สามารถแก้ไขข้อผิดพลาดได้อย่างรวดเร็ว

หรืออย่างน้อยทำแบบนี้ วันละ 1 ครั้ง
ดังนั้น ถ้าคุณทำแบบนี้ซ้ำๆ ทุกวัน แล้ว
คุณน่าจะต้องการระบบที่ทำงานแบบอัตโนมัติขึ้นมา

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

ดังนั้น ถ้าคุณอยากจะไป Continuous Delivery, Dev-ops แล้ว
ก่อนอื่นคุณต้องเรียนรู้ Continuous Integration ก่อนนะ

2. Testing คืองานของนักพัฒนาด้วย

ต้องการทำให้ code ในส่วนที่เราพัฒนา หรือ แก้ไข ยังคงทำงานได้ตามที่คาดหวัง
การทำให้นักพัฒนามีความรับผิดชอบ
ในการทดสอบของสิ่งที่พัฒนาขึ้นมานั้นเป็นสิ่งที่ดีมากๆ
และถ้าสามารถทำการทดสอบแบบอัตโนมัติได้
มันจะเป็นสิ่งที่ยอดเยี่ยมมาก
ซึ่งสามารถนำการทดสอบนี้ไป run ในระบบ Continuous Integration ได้อีกด้วย

แนวทางนี้เป็นแนวทางที่ดีมากๆ
สำหรับการส่งมอบ software ได้อย่างรวดเร็ว
สำหรับการลดค่าใช้จ่ายในการทำ manual testing
สำหรับลดงานที่คุณต้องไปรอ tester หรือไปสู้รบกับ tester อีกด้วย

ดังนั้น หมายความว่า
นักพัฒนาจะต้องมีความสามารถในการเขียน Automated test ที่ดี เช่น

  • Unit test
  • Integration test
  • Acceptance test
  • UI test
  • และการใช้งานพวก Static code analysis ได้อย่างดี

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

  • ทั้งการส่งมอบที่รวดเร็วขึ้น
  • ทั้งจำนวน bug ที่ลดน้อยลง
  • ทั้งความเชื่อมั่นที่มีต่อ code สูงขึ้น

ถ้าคุณมัวแต่ถาม โน่น นี่ นั่น
ถ้าคุณมัวแต่ถามหาข้อดีข้อเสีย
โดยไม่ลงมือทำอะไรเลย คุณก็ยังคงอยู๋ที่เดิมตลอดเวลา

ดังนั้น มาลองทำเถอะ จะได้รู้ว่ามันดี หรือ ไม่ดี อย่างไร ?

3. Code Review หรือ การ Paring

วิธีการหนึ่งที่ทำให้ code ที่เขียน ดีขึ้นกว่าเดิมมาก (Better code)
คือการทำ Code review โดยให้นักพัฒนาคนอื่นๆ เข้ามาช่วย review code ของเรา

เป้าหมายแรกในการทำ code review
ก็คือ การหาปัญหาภายใน code
นั่นคือการตรวจสอบว่า code ทำงานได้อย่างถูกต้องตามที่คาดหวังหรือไม่
ต่อจากนั้น จึงเริ่มดูในส่วนการจัดการ error ต่างๆ ทั้งจาก input และ output
และดูในส่วนของ security เช่น การเข้ารหัสข้อมูล การเก็บ log ต่างๆ
สุดท้ายจึงดูการทำให้ code ดีขึ้นกว่าเดิม เช่น

  • ทำให้ code อ่านง่ายขึ้น
  • ทำให้ code เข้าใจง่ายขึ้น
  • ทำให้ code ปลอดภัยมากขึ้น
  • ทำให้ code ง่ายต่อการแก้ไข

ถ้าตีราคาออกมา การทำ Code review มันมีค่าใช้จ่ายที่สูงมากๆ
แต่ถ้าทำมันอย่างถูกต้อง มันจะเป็นกิจกรรมที่

  • ใช้เวลาน้อย
  • ใช้ความเสี่ยงเป็นที่ตั้ง
  • ใช้ปัญหาเป็นที่ตั้ง
  • นำเครื่องมือมาใช้ เพื่อให้เกิดประสิทธิภาพ
  • และที่ขาดไม่ได้ คือ คน จะต้องใช้เวลาไปกับปัญหาที่สำคัญเท่านั้น ไม่ใช่สำคัญไปหมดทุกอย่าง

อีกวิธีการหนึ่งนอกเหนือจาก Code review ก็คือ การทำ Paring
หรือการให้คนอื่นๆ มาช่วยดูและทำงานไปด้วยกัน
สี่ตามันดีกว่า 2 ตาอยู่แล้วใช่ไหม ?

เป้าหมายของการ Paring มันแตกต่างจาก Code review มาก
เนื่องจากคน review จะทำการหาปัญหา (Defensive programming)
แต่การ pairing มันทำให้

  • code ของคุณนั้นดีขึ้น
  • code ของคุณนั้นมี bug น้อยลง

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

ข้อเสียของ paring นั่นก็คือค่าใช้จ่ายไงล่ะ
แทนที่ 2 คนจะทำงานได้ 2 งานพร้อมๆ กัน
ส่วนการ paring กลับทำได้เพียงงานเดียว !!

แต่ลองกลับไปดูสิว่า ที่บอกว่า 2 งานนั้น มันทำได้จริงๆ ไหม ?
ได้คุณภาพจริงๆ ไหม ?

ลองทำดูสิครับ ว่าสิ่งที่คิด กับสิ่งที่เกิดขึ้นจริงๆ มันเหมือนหรือต่างกันอย่างไร ?
อย่าเพียงแต่กด like แต่ต้องลงมือทำด้วยนะครับ

4. Refactoring

การออกแบบระบบคืออะไร ?
การทำงานร่วมกันคืออะไร ?
การ review การออกแบบคืออะไร ?
พวกความเสี่ยงต่างๆ เช่น security, operation ในการออกแบบ คืออะไร ?

คุณทำสิ่งต่างๆ เหล่านี้ตอนไหน ?
คุณทำสิ่งต่างๆ เหล่านี้บ่อยแค่ไหน ?
สิ่งที่คุณออกแบบ กับ สิ่งที่คุณสร้างมันขึ้นมา เหมือนกันไหม ?

ผมไม่รู้หรอกว่าแต่ละที่ แต่ละทีม เป็นอย่างไร
แต่สิ่งต่างๆ เหล่านี้ ผมทำอยู่บ่อยๆ และ อย่างต่อเนื่อง
ทั้งการออกแบบ ไปจนถึงทุกๆ ครั้งที่ code มันโตขึ้นเรื่อย
ก็จะทำการเปลี่ยนแปลง ปรับปรุง ระบบให้มันดีขึ้นเรื่อยๆ
นั่นคือ การทำ refactoring ระบบนั่นเอง
ซึ่งทำให้ทั้ง code การออกแบบ การทดสอบ และอื่นๆ
มันสามารถดูแลจัดการได้ง่ายขึ้นอย่างต่อเนื่อง
และแน่นอนว่า วิธีการนี้มันเป็นสิ่งที่สำคัญมากๆ ในการพัฒนาระบบ

บางคนอาจจะบอกว่า
ในการ refactoring code นั้น มันง่ายมากๆ เมื่อใช้งานผ่าน IDE
แต่คุณรู้ไหมว่า หลักในการ refactoring code มันเป็นอย่างไร
ซึ่งนั่นแหละที่มันยากมากๆ (แต่ใช่ว่าจะทำไม่ได้)
ดังนั้น
คุณควรให้เวลาว่างมาศึกษาวิธีการ refactoring code
เพื่อทำให้ code ของคุณมันดีขึ้นกว่าเดิม

การ refactoring code ควรจะเกิดขึ้นอยู่ตลอดเวลา
หรืออาจจะเกิดขึ้นในทุกๆ วัน
รวมทั้งอาจจะนำ metric ต่างๆ เข้ามาช่วยวัดการ refactoring ได้อีกด้วย

ขั้นตอนการ refactoring code แบบง่ายๆ มีดังนี้

  • เริ่มจากการอ่าน และ ทำความเข้าใจ code ให้ดีก่อน ลองคิดดูถ้าคุณ refactoring code ใน code ที่ไม่รู้เรื่อง คงไม่ใช่แนวทางที่ดีอย่างแน่นอน
  • หาชื่อที่ดี มีความหมาย และเหมาะสม ของตัวแปร และ method/function ต่างๆ
  • ทำการ extract method ออกมา เพื่อลดขนาดของ method ลง
  • ทำการลบ code ที่มันซ้ำซ้อนออกไป
  • พยายามย้าย method/function ออกไปยัง class ใหม่ๆ ตามหน้าที่การทำงานของมัน

เมื่อคุณเสร็จสิ้นการ refactoring code ในแต่ละรอบแล้ว
นั่นคือคุณได้เริ่มเข้าสู่การ re-design และ re-architecture แล้วนะ

โดยสรุปแล้ว

4 ข้อข้างต้นนี้เป็นตัวอย่างสำหรับ technical practice ที่ดี
ที่ช่วยทำให้คุณพัฒนา software ได้ดีขึ้น

ถ้าให้คุณเลือกทำสักอย่างหนึ่งใน technical practice ที่ดี
คุณจะเลือกอะไร ?
สิ่งที่คุณเลือกมันมีประโยชน์อย่างไร ?
แล้ว คุณจะเริ่มต้นตรงไหนดีล่ะ ?
และจะทำอย่างไร ?

ลงทุนทำดีวันนี้ เพื่อช่วยเหลือคุณในอนาคตนะครับ