วันนี้ได้อ่านบทความเรื่อง How to prevent eventual crappiness
ซึ่งได้อธิบายไว้ว่า
Eventual crappiness – eventually all software will become crap
มาดูกันว่ามันคืออะไร ?
มีข้อเสียอะไรบ้าง ?
และเราสามารถป้องกันได้อย่างไร ?
Eventual crappiness คืออะไร ?
มาจากคำว่า Eventual consistency ซึ่งมีความหมายว่า
ข้อมูลอาจจะยังไม่ update ค่าล่าสุดแบบ realtime
แต่ผ่านไปช่วงเวลาหนึ่งข้อมูลจะ update ค่าล่าสุดแน่นอน
ส่วนคำว่า Crap แปลว่า ขี้ หรือ ของที่ไร้ประโยชน์
เมื่อนำมารวมกันก็ได้คำว่า “Eventual crappiness”
มันก็คือ ถ้าคุณยังพัฒนา code แย่ ๆ ออกมา ซึ่งมันทำงานได้นะ
เชื่อเถอะว่า เมื่อผ่านไปช่วงเวลาหนึ่งแล้ว
code เหล่านั้น จะกลับมาทำร้ายคุณ !!
เชื่อหรือไม่ว่า ?
ในตอนแรกที่เราเริ่มสร้างระบบขึ้นมา
มันเป็นอะไรที่แจ่ม ยอดเยี่ยมกระเทียมดองมาก ๆ
แต่เมื่อเวลาผ่านไปสักระยะ
คุณกลับพบว่าสิ่งที่สร้างขึ้นมามันเริ่มส่งปัญหา
จากนั้นคุณจะทำอย่างไรดีล่ะ ?
ก็กลับไปสร้างใหม่ไงล่ะ !!
และเมื่อเวลาผ่านไปมันก็กลับแย่อีก
วนเวียนแบบนี้ไปตลอด ซ้ำแล้วซ้ำอีก !!
มันยังไงกันนะ ?
ดังนั้น เรามาหยุด เพื่อใช้เวลามาคิด และ คุยกันหน่อยดีไหม ?
ลูกค้าของคุณคิดอย่างไรกับสิ่งที่คุณสร้าง ?
น่าคิดนะ
แต่ถ้าคุณดันไปบอกลูกค้าว่า
ขอเวลาไปคิดก่อนว่า สิ่งที่สร้างมันดีไหมล่ะ ?
ลูกค้าคงจะบอกว่า
คุณจะบ้าหรอ
เราจ้างคุณมาเขียน code และส่งมอบระบบงานนะ
ไม่ใช่มานั่งคิด !!
ดังนั้นถ้าลูกค้าไม่มีเวลาให้
สิ่งที่ชอบทำกันคืออะไรล่ะ ?
ถามได้ งั้นเราก็เผื่อเวลามันทุก ๆ งานเลย
หรือหลาย ๆ คนเรียกว่า Buffer
ซึ่งอาจจะใช้เกิน หรือ ไม่ใช้เลยก็ได้
แต่สุดท้ายก็ลงเอยเช่นเดิม คือ ความล้มเหลวไม่เป็นท่า !!
นั่นคือ สิ่งที่ส่งมอบให้ลูกค้าหรือ ?
ดังนั้น ก่อนอื่นแนะนำให้สร้าง TRUST
หรือ ความเชื่อมั่น ความไว้ใจ ให้กับทางลูกค้าอยู่อย่างเสมอ
นั่นคือ ก่อนที่สร้างแต่ละ feature
ควรทำการพูดคุยกับลูกค้าก่อนว่า
สิ่งที่ลูกค้าต้องการคืออะไร
พร้อมกับให้คำแนะนำ เพื่อปรับปรุงให้ดีขึ้น
ที่สำคัญมันทำให้ต่างฝ่ายต่างเข้าใจในสิ่งที่กำลังจะทำ
จากนั้นให้ทำการสร้าง checklist การทำงานขึ้นมาซะ
ว่าจะต้องสร้างอะไรบ้าง
อย่าลืมว่าเป็นงาน และ ภาษา ที่ลูกค้าเข้าใจนะ
เพราะว่า ตอนนี้คุณกำลังคุยกับลูกค้าอยู่
จากนั้นให้ลูกค้าทำการ review ว่าครบไหม ?
จากนั้นให้คนอื่น ๆ ในทีมทำการ review ว่าพร้อมกับการสร้างหรือไม่ ?
เพื่อจะได้ไม่ต้องสร้างสิ่งที่ไม่จำเป็นขึ้นมา
เพื่อจะได้ไม่ต้องเกิดสิ่งที่เรียกว่า งานงอก ขึ้นมา
นี่คือ การคิด ก่อน ทำ (THINK before DOING)
จากนั้นก็ทำการ
เขียน code ที่มันสามารถอธิบายตัวเองได้
เขียน code ที่มีการออกแบบที่ดี
เขียน code ที่ทำการทดสอบได้ง่าย
แต่ code ดี ๆ เหล่านี้จะเกิดขึ้นมาไม่ได้ ถ้าไม่ได้ทำสิ่งต่าง ๆ เหล่านี้
1. ทำการ review พร้อมให้คำแนะนำในการแก้ไข
จาก blog เรื่อง ทำไมต้องทำ Code Review ด้วยล่ะ ?
จำไว้ง่าย ๆ ว่า
เมื่อเราได้ feedback ที่มันแย่ ( มาจากความจริงนะ )
มันจะทำให้เราดีขึ้น
ถ้าเรายอมรับ และ แก้ไขมันซะ
ซึ่งมันทำให้เราดีขึ้น
แน่นอนว่า ย่อมส่งผลให้ระบบดีขึ้นด้วยเช่นกัน
2. งานอะไรที่ต้องทำซ้ำ ๆ ก็ให้มันทำงานแบบ Automate มันซะ
ปกติทำการ deploy อย่างไร ทั้ง development, test server ?
ยังทำแบบ manual หรือไม่ นั่นคือ packaging และ deploy เอง ?
ปกติยังใช้ FTP/SCP ในการส่งไฟล์หรือไม่ ?
ปกติยัง restart web server เองเมื่อมีการแก้ไขไฟล์หรือไม่ ?
ปกติการเขียน release note ยังทำแบบ manual หรือไม่ ?
และอื่น ๆ อีกมากมายที่ต้องทำเอง ซ้ำแล้วซ้ำเล่า !!
ลด ละ เลิก เถอะนะ
เพราะว่า อะไรก็ตามที่ทำแบบ manual หรือให้คนทำนั้น
มักเกิดข้อผิดพลาดได้เสมอ
ซึ่งขั้นตอนการทำงานควรเป็นดังนี้
coding -> commit -> push -> DONE
คำว่า DONE นั้นหมายถึง ขั้นตอนต่าง ๆ ที่ทำงานแบบอัตโนมัติ
เช่น การ build, test และ deploy
แล้วคุณจะพบว่า
เราได้เวลากลับมามากจนน่าตกใจ !!
3. ทำการ refactor code ของระบบอยู่อย่างเสมอ
ลองถามตัวเราเอง และ ทีมสิว่า
ระบบที่กำลังสร้างนั้น มันง่ายต่อการเพิ่มความสามารถใหม่ ๆ เข้าไปหรือไม่ ?
มันเหมือนกับการต่อ jigsaw หรือไม่ ?
ถ้าตอบว่าไม่ แสดงว่าควรหยุด แก้ไข ปรับปรุง
code เดิมให้ดีก่อน
code เดิมให้ง่ายต่อการเพิ่มเติม
code เดิมให้ง่ายต่อการแก้ไข
ไม่เช่นนั้น
คุณจะพบว่า เมื่อเวลาการพัฒนาผ่านไปนาน ๆ
จะพบว่า สิ่งที่สร้างมันก่อให้เกิดปัญหาอย่างรุนแรง
แต่เรามักจะไม่หยุด เพื่อแก้ไข
ส่วนใหญ่ ชอบเพิ่มคนมากกว่า … แต่ปัญหายังคงอยู่
สุดท้ายสิ่งที่สร้างไป ก็ยังสร้างปัญหาอยู่เช่นเดิม
ดังนั้นควรทำการแก้ไข และ ปรับปรุง code หรือ refactor code ซะ
แต่ไม่ใช่เพียงแค่ code เท่านั้นที่ต้องปรับปรุง
ขั้นตอนการทำงาน และ เครื่องมือก็ต้องปรับปรุงด้วยเช่นกัน
คนก็เช่นกัน !!
ลองดูสิว่า แบบ form ต่าง ๆ เราจำเป็นต้องกรอกหรือไม่ ?
ลองดูสิว่า เราต้องการการ tracking เวลาการทำงานต่าง ๆ หรือไม่ ?
สุดท้ายก็มากรอกวันสุดท้ายก่อนส่ง !!
ลองดูสิว่า ขั้นตอนการทำงานแบบ Automate ของเรามันดีหรือยัง ?
เช่น สามารถสรุปรายงานแต่ละวันได้หรือเปล่า ว่าทำอะไรบ้าง และ เสร้จอะไรบ้าง ?
นี่คือ คำถามง่าย ๆ เพื่อดูว่าขั้นตอนการพัฒนาของคุณ
ว่ามันมี Waste หรือ เสียเวลาให้กับสิ่งที่ไม่จำเป็นมากน้อยเพียงใด ?
คุณอาจจะพบว่า เราเสียเวลาไปแบบไร้ค่าเยอะมาก ๆ ก็เป็นได้
4. คำว่า TEAMWORK มันสำคัญสุด ๆ
เราไม่ต้องการทีมที่เก่งมาก ๆ
แต่
เราต้องการทีมที่ทำงานร่วมกัน
เราต้องการทีมที่ช่วยเหลือซึ่งกันและกัน
เราต้องการคนที่ไม่ขี้เกียจ
เราต้องการคนที่ปรับปรุงตัวเองอยู่อย่างเสมอ
ดังนั้น เมื่อคนหนึ่งทำผิดพลาด
คนอื่น ๆ จะหยุดและเข้ามาช่วยกันแก้ไข
โดยไม่ชี้หน้า ด่าทอ ต่อว่า ว่าใครผิด
ช่วยกันทำงาน
ช่วยกันคิด
ช่วยกันตัดสินใจ
หลายหัว ย่อมดีกว่า หัวเดียวเสมอ
แต่ละงาน ย่อมมีคนช่วยกันทำงานมากกว่าคนเดียว
ทำแบบนี้จนเป็นนิสัยของทุกคนในทีม
ดังนั้น อย่าเน้นเพียงจำนวนบรรทัดของ code ที่เขียนออกมา
แต่ให้เน้นว่า สิ่งที่ทำนั้นมันทำให้เราเข้าใกล้เป้าหมายหรือไม่
วิ่งใกล้ ๆ ไปคนเดียวได้
แต่ถ้าจะวิ่งไกล ๆ ต้องไปกันเป็นทีม
สิ่งต่าง ๆ เหล่านี้ นำมาใช้เพื่อสร้างระบบที่มีคุณภาพ
เพื่อส่งมอบสิ่งที่ดีให้กับลูกค้าอยู่อย่างสม่ำเสมอ
มันไม่ได้ยากเลย ถ้าคุณเพียงแค่เริ่มทำ
และมีความรับผิดชอบในสิ่งที่ทำมากพอ
และเมื่อทำงานเป็นทีม มันจะง่ายมาก ๆ
