เรื่องที่ 5 ที่นักพัฒนาควรรู้ และ เข้าใจก็คือ Automate Your Coding Standard
หรือ การตรวจสอบ Coding standard ควรทำแบบอัตโนมัตินะครับ
ในทุกๆ ระบบงานที่จะพัฒนานั้น ผมมั่นใจว่าทุกๆ คนมีความตั้งใจ และ เจตนาดีมากๆ
และเราจะมีข้อตกลงในการทำงานร่วมกัน
และบ่อยครั้งเรามักจะเขียนข้อตกลงเหล่านั้นในรูปแบบของเอกสาร (Document)
และหนึ่งในข้อตกลงนั้นก็มักจะมี Coding Stand ของการพัฒนาระบบ
ก่อนเริ่มพัฒนาระบบงาน
มักจะมีการประชุมที่เรียกว่า Kick-off project
โดยที่ Lead developer มักจะทำการเปิดเอกสารข้อตกลงต่างๆ ขึ้นมา
เพื่ออธิบายให้สมาชิกในทีมเข้าใจ
ในกรณีที่ดีที่สุด
สมาชิกทุกคนในทีมจะเห็นด้วยกับข้อตกลงเหล่านั้น
พร้อม และ ยินดีที่จะปฏิบัติตาม !!
แต่เมื่อการพัฒนาเริ่มต้นไปเรื่อยๆ กลับพบว่า
ทีมพัฒนากลับละทิ้งข้อตกลงที่เคยเห็นชอบด้วยกันทิ้งไปเสียหมด
หนึ่งในนั้นคือ เรื่องของ Coding Standard
… มันแปลกดีนะ … แต่มันคือเรื่องผิดปกติที่เกิดขึ้นจนเป็นปกติ !!
เมื่อทำการส่งมอบงานแล้ว ก็มักจะพบว่า code มัน
รกรุงรังรุงรังติดรอเรือ มากมาย
และก็ไม่มีใครรู้ด้วยว่า มันเกิดขึ้นตั้งแต่เมื่อไร ?
แล้ว ทีมพัฒนาเดินไปในทางที่ผิดเมื่อไรนะ ?
เราเห็นชอบ เห็นด้วยกับข้อตกลงต่างๆ ใน Kick-off project แล้วนะ ?
หรือว่าบางคนในทีมอาจจะไม่ได้ให้ความสนใจกันนะ ?
หรือว่าบางคนในทีมอาจจะไม่เข้าใจหรือเปล่านะ ?
หรือว่าบางคนจะดื้อเงียบ ?
หรือว่าข้อตกลงมันดีแล้วล่ะ แต่ได้รับแรงกดดันที่สูง ทั้งจำนวนงานที่เยอะในเวลาที่จำกัด ?
หรือว่าเรื่องพวกนี้มันไม่ได้มีคุณค่าต่อผู้ใช้งานนะ ดังนั้น สร้างแต่ feature การทำงานดีกว่านะ ?
ยิ่งไปกว่านั้น การทำตาม Coding Standard มันเป็นเรื่องที่น่าเบื่อสุดๆ ถ้ามันไม่สามารถทำแบบอัตโนมัติได้
ลองคิดดูว่า ถ้าคุณต้องไปนั่งจัดรูปแบบของ code ที่มันยุ่งๆ เอง
โดยไม่มีตัวช่วยใดๆ ทั้งสิ้น มันจะนรก และ น่าเบื่อเพียงใด
ปัญหามันเยอะเลยนะ …. แต่เรามี IDE ช่วยไม่ใช่หรือ ?
แล้ว ทำไมเราต้องการ Coding Standard ตั้งแต่เริ่มต้นด้วยล่ะ ?
เพื่อจัดรูปแบบของ code ให้อยู่รูปแบบเดียวกันไงล่ะ
จะได้ไม่มีหลากหลายรูปแบบ แบบตามใจฉันนะ
จะได้ไม่มี code นั่นของฉัน code นั่นของแก
เพื่อหลีกเลี่ยง bug หรือ ข้อผิดพลาดที่อาจจะเกิดขึ้นได้ด้วย
โดยรวมแล้ว Coding standard นั้นจะช่วย
ทำให้เราจัดการกับ code ของระบบงานได้ง่ายขึ้น
ทำให้เรารักษาความเร็วในการพัฒนาระบบได้ตั้งแต่ต้นจนจบการพัฒนา
แต่การที่ให้ทุกคนในทีมเห็นชอบในข้อตกลงเดียวกันนั้น
มันเป็นเรื่องที่งี่เง่ามากๆ เพราะว่า สุดท้ายแล้วมันไม่ได้ช่วยเลย
ตัวอย่างเช่น
ถ้าคนหนึ่งใช้ spacebar 3 ครั้งในการเว้นช่องว่างของ code
ส่วนอีกคนใช้ space 4 ครั้ง
… แล้วข้อตกลงจะมีไว้ทำแมวอะไร ??
เพียงข้อตกลงนั้นไม่เพียงพอหรอกนะ
จำเป็นต้องมีเครื่องมือสำหรับช่วยจัดรูปแบบ code
จำเป็นต้องมีเครื่องมือสำหรับช่วยตรวจสอบรูปแบบ code
และเครื่องมือเหล่านั้นต้องทำงานแบบอัตโนมัติให้ได้ 100% ด้วย
ตัวอย่างการใช้งาน
- ทำการตรวจสอบและจัดรูปแบบ code อย่างอัตโนมัติทุกๆ ครั้งที่ทำการแก้ไข code
- ใช้ Static code analysis ในการตรวจสอบ code เพื่อหาว่ามี code ส่วนไหนบ้างที่ไม่เป็นไปตามข้อตกลง ถ้าพบ code ส่วนนั้น ให้หยุด และ แก้ไขทันที ส่วนในขั้นตอนการ build ก็ต้องหยุดทันที
- เรียนรู้และเข้าใจในเครื่องมือที่นำมาใช้งาน ตัวอย่างเช่น IDE ก็ให้ทำการ configuration เกี่ยวกับการจัดรูปแบบ code ของคนในทีมให้ตรงกันซะ
- การวัดค่าต่างๆ มันไม่ค่อยช่วยอะไร แต่ใช้ค่าเหล่านั้นเพื่อช่วยปรับปรุงการพัฒนาของทีมดีกว่า เช่นค่าของ test coverage ถ้ามันมีค่าน้อยมากๆ ให้ระบบ build มัน fail ไปเลย ซึ่งทุกๆ คนจะต้องหยุดเพื่อทำการแก้ไข
ให้พยายามทำตามสิ่งที่อธิบายไปในส่วนงานที่สำคัญๆ
เนื่องจากคุณไม่สามารถที่จะให้ทุกๆ ส่วนทำงานแบบอัตโนมัติได้หมดหรอกนะ
สุดท้ายแล้ว
ในเรื่องของ Coding standard นั้นมันสามารถเปลี่ยนแปลงได้อยู่อย่างเสมอ
เนื่องจากคงามต้องการของระบบมันเปลี่ยนแปลงไปเรื่อยๆ
แต่อย่างไรก็ตามคุณควรจะทำการกำหนดข้อตกลงร่วมกัน
นำเครื่องมือ และ แนวปฏิบัติที่อธิบายมาใช้ตั้งแต่เริ่มต้นการพัฒนา
ปล.
อย่ามาทำทีหลัง หรือ ผลัดวันประกันพรุ่ง
เพราะว่า การกลับมาแก้ไขนั้นมันไม่สนุกเลย
หรือ อาจจะไม่เคยกลับมาแก้ไขเลยก็ได้
