TechX Sharing : Maintainable Code and Manage Bad Code
SCB TechX มีการจัด Knowledge Sharing ภายในบริษัทอยู่เป็นประจำ และเมื่อวันที่ 12/11/2564 ก็ได้มีการจัด Knowledge Sharing ในหัวข้อ Maintainable Code and Manage Bad Code โดย พี่ปุ๋ย สมเกียรติ ปุ๋ยสูงเนิน ที่เป็น Technical Coach และ Software Craftsman จาก สยามชำนาญกิจ
Blog นี้จึงทำการสรุปมาให้ทุกคนได้อ่านกันว่าเจ้า Maintainable Code and Manage Bad Code ที่พี่ปุ๋ยแชร์เนี่ย มันมีเนื้อหายังไงกันบ้างนะ บอกไว้ก่อนเลยว่า Session นี้เนี่ยยาวนานมากกกกกก คุยกันตั้งแต่ 16.00 จน 19.00 ยังคุยกันไม่ยอมหยุดด
✅ Maintainable System
เราจะ Maintain System ของเราอย่างไร เมื่อ System ของเราไม่ได้ทำแล้วทิ้ง เมื่อทำแล้วต้องดูแลต่อไปเรื่อยๆ ปัจจุบัน System ก็มีที่ถูกสืบทอดกันมาจากบริษัทสู่บริษัท จากรุ่นสู่รุ่น คำถามจากการสืบทอดกันมารุ่นต่อรุ่นคือ
เราได้ทำให้มันดีขึ้นบ้างมั้ย ? หรือ สุดท้ายเรารอให้มันตายไป แล้วสร้างขึ้นมาใหม่ ?
แต่ก็ต้องยอมรับว่า System เวลาเราสร้างขึ้นมามันย่อมประกอบไปด้วย สิ่งที่ดี และก็สิ่งที่ไม่ดี คำถามคือแล้วเราทำอะไรกับสิ่งที่ไม่ดี ?
แล้วถ้าจะแก้ปัญหาเหล่านี้สร้าง System ที่มัน Maintainable เนี่ยมันมีประมาณนี้นะ
✅ Teamwork
การทำงานแน่นอนว่าเราคงไม่ต่างคนต่างทำงาน ก็คือเราย่อมทำงานไปด้วยกันกับคนอื่น(>1 คน) แน่นอนคงไม่มีคำว่า Team ที่มีสมาชิกใน Team เพียงแค่คนเดียว
สมาชิกใน Team ก็มีหลากหลายความคิด หลากหลาย Skills แต่สุดท้ายต้อง Blend กันเป็น Team ขึ้นมาเพื่อสร้างอะไรบางอย่างออกมาทั้ง Output และ Outcome
- Output คือ การสร้าง Product ของ Team
- Outcome คือ Reletions ของ Team หรือ Skills Improvement ของ Team
เราจะสนแต่การ Delivery Output ไม่ได้โดยไม่สน Outcome เราสร้าง Product ได้แต่สุดท้ายคนไม่มีใครอยากทำงานอยู่ด้วยกัน ความสุขในทีมลดลงเรื่อยๆสุดท้ายทีมก็จะแยกย้ายกันออกไป ซึ่งนี่เป็น Classic Problem ของ Developer เลยก็ว่าได้
✅ Software Delivery
ตั้งแต่ Requirement(Idea) ไปจนถึงมือผู้ใช้งาน ทั้ง User และ Customer ทำยังไงให้สามารถ Deliver ได้เร็วที่สุดพร้อมด้วย Performance ที่ดี การพัฒนา Software สัมพันธ์กันหมดทั้งการ Test หรือแม้แต่ Infrasturcture
ก็เหมือนกับการปลูกต้นไม้ มันไม่ใช้แค่ต้นไม้ต้องดี แต่ดินที่ใช้ปลูกก็ต้องดีเหมือนกันถึงจะส่งเสริมกัน แต่พอดินดี ต้นไม้ดี เติบโตสวยงาม แต่ไม่มีคนดูแล ต้นไม้ก็จะขาดน้ำ ขาดอากาศ ดังนั้นทุกอย่างมันสัมพันธ์กันหมด
โดยการพัฒนา Software มักจะสนใจอยู่ 3 ส่วนประมาณนี้
- Make it work
- Make it right
- Make it fast
คำถาม Classic ในการพัฒนา Software เลยคือ 3 อย่างนี้เนี่ย เราจะเลือกอะไร ?
โดยปกติการสร้างเรา Software อะไรก็ตามไม่รู้แหละ แต่มันต้อง Make it work ก่อน แล้วพอมัน work ปุ๊ป Business ก็น่าจะเป้นไปตามคาดว่าเราต้องการให้มัน Fast ในช่วงแรกเราก็จะทำให้ดีและทำให้ไว ให้ตอบโจทย์ Business แต่มันก็เหมือนเป็นการทำแล้วทิ้ง ใครมาดูต่อก็ซวยไปอย่างงั้นหรอ รับเคราะห์ไปนะ
ดังนั้นเมื่อเราพัฒนา Software ไปเรื่อยๆแน่ ต้องดูว่าเราได้กลับมา Maintenance รึป่าว ? เราควรจะกลับมาทำให้ Software มัน Make it right ด้วย แต่คำถามคือ พอเรา Deliver ของไปซักพักคุณมีเวลาเหลือพอมั้ยที่จะมาทำให้มัน Make it right ก็จะเป็นปัญหาสุด Classic อีกปัญหานึงว่า เราไม่มีเวลาเหลือมากพอที่จะทำ Make it right หรอกในโลกแห่งความจริงที่คนส่วนมากพบเจอ
เราก็เลยทำแต่ Make it work , Make it work , Make it work กันต่อสุดท้ายพอเกิดปัญหาขึ้นมา เราก็จะ เห้ย !!! แล้วถามขึ้นมาว่า
- ใครเขียนตรงนี้ขึ้นมานะ ?
- ใครเคยทำตรงนี้นะ ?
- ใครออกแบบตรงนี้นะ ?
แล้วเราจะทำยังไงดี ? ก็จะเข้าคำตอบและความคิดสุด Classic อีกชุดนึงว่า System อะไรที่เราไม่ได้เป็นคนทำเอง มันไม่ดี ดังนั้นต้องทำมันขึ้นมาใหม่ด้วยฝีมือเรานั่นแหละคือ System ที่ดี ซึ่งเป็นสิ่งที่เกิดขึ้นและเจอบ่อยมากกก
ดังนั้นแล้วเวลาเราทำ Make it work , Make it work , Make it work เวลาเราเจอปัญหา เราไม่ควรจะทำ ad-hoc หรือ work-around ในการแก้ปัญหา เพราะมันเหมือนการปะผุไปเรื่อยๆ เราควรจะหาไปยัง root cause ของมัน แล้วทำมันให้ Make it right จากนั้นเราจึงค่อยมาหาวิธีในการทำ Make it fast สำหรับ Team
ซึ่งที่กล่าวมาก็เป็นแนวทางปฎิบัติแนวทางหนึ่งในการการพัฒนา Software ซึ่งพี่ปุ๋ยแนะนำเพิ่มเติมว่าถ้าใครอยากหาความรู้เพิ่มเติมลองไปหาอ่านหนังสือ 2 เล่มนี้ดู
1. Improving Software Quality and Reducing Risk
2. Reliable Software Releases through Build, Test, and Deployment Automation
โดยหนังสือทั้ง 2 เล่มก็จะพูดถึงการลดเวลาในการพัฒนา Software ด้วย Proces ต่างๆ เพื่อลด Reach Time ในการ Deliver Software
✅ Technical Excellence
Technocal Excellence หรือความเป็นเลิศทางเทคนิคคอล เนี่ยเป็นหัวข้อที่ยังได้รับความสนใจไม่มากเท่าที่ควรในปัจจุบัน ก็คือถ้า Software Team ไม่เชี่ยวชาญทางด้านนี้แล้ว การทำ Software ก็อาจจะออกมาได้ดี ซึ่งเราก็หวังว่าจะมีผู้เชี่ยวชาญมา
สร้าง Software ที่ดีที่สุดเท่าที่จะทำได้ ซึ่งจากรูปภาพข้างบนก็จะเห็นว่ามีสกิลต่างๆ ดังนี้
- Specification by Example
- Test Automation
- Thinking about testing
- Continuous Integration
- Continuous Delivery
- Architecture and Design
- Acceptance Testing
- Clean Code
- Test-Driven Development
- Unit Testing
ซึ่งเป็น Skills ที่จำเป็นในการสร้าง Technical Excellent แต่ก็ไม่ได้หมายความทุกคนต้องเชี่ยวชาญแล้วมี Skills ทั้งหมดนี่กันทุกคน คนในทีมแต่ละคนเลยต้องมี Skills ที่เฉพาะทางตามแต่ละคน แล้วนำแต่ละคนนั้นมารวมกันเพื่อสร้าง Software แต่ Session นี้พี่ปุ๋ยจะพูดถึงหัวข้อ Clean Code เป็นหลัก
✅ Clean Code
Clean Code คำๆนี้เนี่ยมัน Abstacrion เกินไป มันจับต้องไม่ได้ เพราะถ้าเรายอมรับความจริงกันจริงๆเลยก็คือ Code ที่สะอาดสุดก็คือ Code ที่เราไม่ได้เขียนมันขึ้นมา นั่นก็คือไม่มี Code อยู่เลย แล้ว Clean Code คืออะไรกันแน่
Clean Code หรือ Code ที่ดีเนี่ย ไม่จำเป็นต้องสวย แต่ต้องเป็นสิ่งที่จับต้องได้ หรือเป็น Code ที่ Team สามารถจัดการกับ Code ตัวนี้อยู่ Team อ่านแล้วรู้เรื่อง
ไม่ใช่ Code ที่ทุกคนเห็นแล้วแบบว้าว มันเท่จังเลย ทำงานได้ดีมาก Performance ก็ดีมากๆ แต่ประเด็นคือ ทุกคนในทีมไม่มีใครรู้เรื่องกับ Code ชุดนี้เลย พอมองแล้วก็ได้แต่อ้าปากค้าง มีคนที่เขียนนั่นแหละรู้อยู่คนเดียว แล้วมันเป็น Code ที่ดีมั้ย ?
เราตอบได้เป็นปากเลยว่ามันเป็น Code ที่ดี !!! แต่มันดีกับ Team มั้ย ?
ยกตัวอย่างให้เห็นภาพง่ายๆ ว่าคนที่เขียน Code ชุดที่บอกมาเนี่ยเค้าดันลาพักร้อน 1 Sprint ในทีมมีความจำเป็นต้องเพิ่ม Feature เข้ามาใน Sprint นี้ คำถามก็คือใครต้องเพิ่ม Feature ส่วนนี้ คำตอบก็คงเป็นคนใน Team เนี่ยแหละ ที่ต้องเข้ามาจัดการ แต่ปัญหาคือกว่าเค้าจะทำความเข้าใจและแก้ Code ชุดนี้อาจจะหมด Sprint นั้นแล้วก็ได้ ทำไมไม่รอคนทำกลับมาละ ? แล้วงี้ Code ชุดนี้มันดีจริงๆใช่มั้ยนะ
ปัญหาที่พูดไปเนี่ยมันเกิดจาก Code มีความ Ownership เฉพาะบุคคลมากเกินไป Skills ของ Team ยังไม่สามารถเข้าถึงตรงนั้นได้ มันก็เลยกลายเป็น Code ที่ดี แต่ ไม่ได้ดีสำหรับ Team เนี่ยก็เลยทำให้ นักพัฒนาหรือ Developer เนี่ย กลายเป็น Debugger กันไปเสียหมด คำถามก็คือเจ้าสิ่งนี้เนี่ยมันสร้างปัญหาให้เรามั้ย ?
ถ้าสร้างปัญหา แล้วจริงๆ Code ตัวนี้มัน Clean หรือป่าว ? มันเป็นสิ่งที่ Team ต้องคุยและปรับแก้กัน
เพราะถ้าเราไม่ปรับแก้กัน ทุกๆครั้งที่มี Change เกิดขึ้น เราจะจ่าย Cost per change และ Time taken กับ Change มากขึ้นเสมอ เช่น จาก 1 อาทิตย์ กลายเป็น 2 อาทิตย์ เพราะเกิดจากสิ่งที่เราไม่ได้ Argreement Clean Code ของ Team ร่วมกัน แล้วถ้าหากเรายิ่ง Monitor เราก็จะพบว่าเราใช้ทุกอย่างมากขึ้นจริงๆนะ ตัวเลขมันไม่เคยโกหก
จากทำงานปกติก็จะเริ่มมี OT เกิดขึ้น จากที่มี OT ก็จะเริ่มเพิ่มคน ทั้งๆที่ Sizing ของงานมันเท่าเดิม กลายเป็นว่า Time เท่าเดิม แต่ Effort มากขึ้น เนี่ยแหละคือปัญหาที่คอยสะท้อนใน Software ที่เรากำลังสร้าง แล้วเราจะมาเริ่มแก้เจ้าพวกนี้กันยังไงดีนะ
Code Review
การ Review Code ก็เป็นทางนึงที่จะช่วยแก้ปัญหา และช่วยสร้าง Clean Code ให้เกิดขึ้นมาใน Team
Code Review ยังเป็นสิ่งที่น่ากลัวสำหรับหลาย Team อยู่ จนบาง Team คนใน Team ถึงกับมี Mindset ที่ว่าไม่ต้องรีบทำหรอก ทำเสร็จไวก็ Review บ่อย ทำเสร็จตรงเวลาทีเดียวเลยดีกว่า ซึ่งก็แน่นอนว่าเป็นแนวคิดที่ผิดพอสมควร แล้วเราจะทำยังไงให้การทำ Code Review เนี่ยมันไม่น่ากลัวกันนะ ?
เราต้องสร้าง Environment ในการ Review Code ว่าคนที่มาช่วยดูเนี่ย เค้ามาช่วยคุณนะ มีการ Share กันกันว่าอันนี้ดี ไม่ดี ไม่ใช่จ้องจะใส่ว่าไม่ดีอย่างเดียวอันนี้ก็ไม่ถูก เพราะการ Review ไม่ใช่การด่า แต่เป็นการแสดงความคิดเห็น
โดยหลักๆก็ควรจะมี 3 ข้อหลักๆ ตามนี้
1.Easy to understnad
ข้อนี้ก็ดูเป็นอะไรที่เข้าใจยากอีกแล้ว Easy to understand ก็ความเก่งของแต่ละคนไม่เท่ากัน บางคนเข้าใจง่าย บางคนเข้าใจยาก แล้วเราควรจะทำยังไง จริงๆแล้วเราควรจะ Tradeoff สิ่งนี้แล้วหาจุด Balance ระหว่างคน 2 ประเภทนี้ เพื่อให้ได้ Code ที่ดี
2.Easy to change
เวลามีการเปลี่ยนแปลงหรือการ Change เนี่ยมัน Chang ได้ง่ายมั้ย ? อันนี้สำคัญ เพราะเราจะต้องเจอกับ Business ที่ขอเปลี่ยนตรงนี้นิดเดียวนะ อยู่แล้ว แต่หลังบ้านเราต้อง Change 10 จุดเลยนะ คำถามคือ แล้วใครเป็นคนทำแบบนี้ตั้งแต่แรก ?
ทีม Business ไม่ได้เป็นคนเลือก Technical Solution นะ แต่ Delivery Team เป็นคำทำให้มัน Change ยากเองไม่ใช่หรอ ? แบบนี้ก็จะสะท้อนแล้วว่าเป็นปัญหาทาง Technical
3.Make code testable and test it properly
Testable คือการ Test ระบบได้โดยง่าย ไม่ยุ่งยาก ซับซ้อน คนละเรื่องกับการ Test เราต้องทำให้ระบบเรา Test ได้ง่ายนั่นเอง ซึ่งการทำ Software ส่วนมากยังทำก่อนแล้วค่อยคิดว่าเราจะ Test อะไร Test ยังไง ซึ่งเราควรจะเริ่มจากคิดก่อนว่าเราจะ Test ยังไง แล้วค่อยเริ่มทำ Software (คิดก่อนแล้วค่อยทำ)
Avoid Surprise
Bug นี้เคยเกิดแล้ว แล้วทำไมถึงเกิดขึ้นมาอีก นี่ก็คือตัวอย่างการ Surprise รูปแบบนึง ซึ่งเราควรจะหลีกเลี่ยง เช่นการใช้ Flag หรือการแทน Status ต่างๆด้วยตัวเลข 1,2,3,4 คนมาตามอ่านก็จะสงสัยว่า เอ๊ะ มันคืออะไร ใช้ทำไม อยากรู้ตัวไหนก็ต้องไป Query เอาจาก Database แล้วทำไมเราต้องทำ Code เราให้มันยากขนาดนั้นกันนะ ?
หรือแม้กระทั่งมีการเขียน Service 1 เส้น แต่ด้านในไปเรียก services อื่นอีกเป็น 10 20 ตัว อันนี้ก็น่ากลัว วันดีคืนดี dependency service เหล่านั้นตายเราจะเอาอยู่มั้ย ?
หรือคำถามสุด Classic เช่น System มี Feature ทั้งหมดเท่าไหร่ พอตอบได้ก็จะตามมาด้วยคำถามว่า ปัจจุบันมี Feature ที่ไม่ใช้ในช่วง n เดือน เยอะมั้ย ?
คำถามต่อมาก็คือแล้วทำไมเราถึงไม่ลบ Feature ที่ไม่ถูกใช้กันนะ เราจะ Maintance ไปเพื่ออะไร ? คำตอบสุด Classic ก็คือ System มันดีอยู่แล้วอย่าไปยุ่งกับมัน เดี้ยวพังมาจะซวย
คำถามพวกนี้เกิดจากการที่เราไม่ Maintance ของเก่า เราสร้างสิ่งใหม่ๆขึ้นมาเรื่อยๆ
Make Code Hard to Misuse
Code ที่ดีไม่ควรจะใช้แบบ X ก็ได้ แบบ Y ก็ได้ แบบ Z ก็ได้ คุณใช้แล้ว คุณไม่มีทางผิดพลาดหรอก ใช้แบบนี้เลย เช่นการออกแบบ Service ให้ยิงมาที่ 1 Endpoint แต่ใน Request ดันมีส่งมาว่า Call function อะไร แล้วก็จะมี Parameter ตามมาอีกของ Function นั้น แล้วถ้าเราส่งไม่ครบแน่นอน Classic สุดก็คือ Request Invalid
คำถามก็คือแล้วเราจะรู้ได้ยังไงว่า Invalid ตัวไหน Function ไหน แล้วทุกคนที่ต้องการจะใช้ Service นี้ก็ต่างคนต่างยิงเข้ามาจากหลายๆที่ วันดีคืนนี้จากคนใช้ Service กลายมาเป็นคน Maintance service นี้แทน เราก็จะสัมผัสได้ถึงการเขียน Code แบบ Single point ประเด็นก็คือ มันพร้อมที่จะผิดได้ง่าย คนใช้งานก็ยาก
จริงๆแล้ว Session นี้ยังมียาวไปอีกมากมายหลายเลยแต่ผู้เขียนสรุปมาให้แค่ส่วนที่พูดถึง Clean Code เท่านั้น หากอยากได้เข้าฟัง Live Session คูลๆ แบบนี้ เชิญพบกับช่วงขายของงงงง !!!
SCB TechX มองหาผู้ร่วมงานจำนวนมาก หากใครสนใจอยากจะร่วมงานกับ Tech Company ที่มี Culture คูลๆ แบบนี้ ก็สามารถตามไปดูก็ได้ที่ด้านล่างนี้เลยยยย
