Eventual crappiness มันคืออะไร และ จะป้องกันอย่างไรดี ?

วันนี้ได้อ่านบทความเรื่อง How to prevent eventual crappiness ซึ่งได้อธิบายไว้ว่า

Eventual crappiness – eventually all software will become crap

มาดูกันว่ามันคืออะไร ? มีข้อเสียอะไรบ้าง ? และเราสามารถป้องกันได้อย่างไร ?

Eventual crappiness คืออะไร ?

มาจากคำว่า Eventual consistency ซึ่งมีความหมายว่า ข้อมูลอาจจะยังไม่ update ค่าล่าสุดแบบ realtime แต่ผ่านไปช่วงเวลาหนึ่งข้อมูลจะ update ค่าล่าสุดแน่นอน ส่วนคำว่า Crap แปลว่า ขี้ หรือ ของที่ไร้ประโยชน์ เมื่อนำมารวมกันก็ได้คำว่า Eventual craziness มันก็คือ ถ้าคุณยังพัฒนา 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 ที่เขียนออกมา แต่ให้เน้นว่า สิ่งที่ทำนั้นมันทำให้เราเข้าใกล้เป้าหมายหรือไม่ วิ่งใกล้ ๆ ไปคนเดียวได้ แต่ถ้าจะวิ่งไกล ๆ ต้องไปกันเป็นทีม

สิ่งต่าง ๆ เหล่านี้ นำมาใช้เพื่อสร้างระบบที่มีคุณภาพ

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