ปัจจุบัน developer ต้องทำงานกับ code แบบไหนกันนะ ?
ทำงานกับ legacy code, ugly code หรือ beautiful code กันอยู่นะ ?
จากที่ทำงานมานั้น มักจะอยู่กับ ugly code มากกว่านะ
ซึ่งมันไม่น่าจะใช่เรื่องปกติของการพัฒนา software หรือเปล่านะ ?
คำถามที่มักได้ยินมาตลอดคือ
แล้วเราควรที่จะ rewrite หรือ refactor มันดีล่ะ ?
มันเป็นคำถามที่ตอบยากมากๆ
แต่ส่วนใหญ่มักจะตอบว่า rewrite หรือเขียนใหม่ไปเลยสิ
เนื่องจากเราไม่เข้าใจการทำงานของ code เหล่านั้นไงล่ะ
แต่กลับลืมไปว่า
การ rewrite code นั้นก็ต้องการความเข้าใจในเรื่องนั้นๆ ด้วยสิ
ยิ่งระบบ หรือ code ส่วนนั้นมีผู้ใช้งานอยู่ด้วย
ก็จำเป็นต้องเขียน code หรือสร้างระบบ
ที่มีพฤติกรรม หรือ การทำงานในรูปแบบเดิมขึ้นมา
ดังนั้น จำเป็นต้องไปอ่าน และ ทำความเข้าใจ code ก่อน rewrite ด้วยใช่ไหม ?
ในองค์กร หน่วยงาน หรือ ทีม ที่ต้องดูแลระบบใหญ่ๆ มักจะพบว่า
ระบบเหล่านั้นมี code จำนวนมากมายมหาศาล
แน่นอนว่า code เหล่านั้น มันถูกเรียกว่า Legacy code หรือ ugly code
แต่สิ่งที่น่ากลัว หรือ แย่มากๆ ก็คือ
คนในองค์กร หน่วยงาน ทีม นั้น
เป็นกลุ่มคนที่ใกล้ชิดกับ code อย่างมาก
เป็นกลุ่มคนที่ใกล้ชิดกับปัญหา อย่างมาก
แต่ไม่สามารถแก้ไข หรือปรับปรุงได้เลย
เนื่องจาก code มันถูกแบ่งให้ดูแลกันหลายส่วน
ดังนั้น จึงไม่เคยเห็น code ทั้งหมด
ส่งผลทำให้
เมื่อทาง business ต้องการเพิ่ม feature หนึ่งๆ ขึ้นมา
ทางหน่วยงานที่พัฒนาจะบอกไปว่า มันใช้ค่าใช้จ่ายที่สูงมากๆ
เมื่อเป็นแบบนี้บ่อยๆ ทำให้ทาง business
ไม่สามารถที่จะสร้าง feature อะไรออกไป
และไม่สามารถสู้กับคู่แข่งในตลาดได้เลย
ตรงข้ามกับบริษัทใหม่ๆ หรือเหล่า Startup นั้น
ยังไม่มีระบบอะไรที่ซับซ้อน ซ่อนเงื่อน
เหมือนกับพวกบริษัท software ใหญ่ๆ จากข้างต้น
ทำให้สามารถพัฒนา feature ใหม่ๆ
เพื่อนำออกไปให้ลูกค้าใช้งานได้อย่างรวดเร็วกว่า
ทำให้บริษัทใหญ่ๆ ไม่สามารถสู้กับคู่แข่งในตลาดได้เลย !!
บางครั้งบริษัทใหญ่ๆ
อาจจะต้องยอมแพ้ หรือ ออกจากตลาดนั้นไปได้เลย
แต่แปลกนะ !!!
ที่คนกลุ่มนั้นไม่เคยพูดเรื่องเหล่านี้ออกมาเลย ..
เมื่อคำว่า Agile เข้ามา
มีการพูดถึงเรื่อง การลดค่าใช้จ่ายของการเปลี่ยนแปลง
รวมไปถึง code ด้วยเช่นกัน
ด้วยการนำแนวปฏิบัติต่างๆ มาใช้ เช่น
- Test-Driven Development
- Refactoring
- Continuous Integration
ซึ่งเป็นแนวทางที่ดีมากๆ
แต่ถ้าต้องไปทำงานกับ Legacy code หรือ ugly code นั้น
มันยากมากมายเลยนะเออ !!
ใน Lean Software Development นั้นบอกว่า
requirement นั้นคือ inventory
แต่ถ้าเราเสียเวลาไปมากๆ
กับการสร้าง requirement ให้ละเอียดให้ชัดเจนในทุกๆ feature แล้ว
นั่นแสดงว่า คุณไม่ได้ทำการสร้าง feature นั้นขึ้นมาเลยใช่ไหม ?
เราเสียเวลาไปมากมาย นั่นคือ waste ใช่ไหม ?
ดังนั้นเราควรปรับปรุงกระบวนการให้ดีขึ้นไหมนะ ?
ดังนั้นเราควรเริ่มสร้างระบบขึ้นมาให้เร็วที่สุด
นั่นคือต้องลงมือเขียน code ใช่ไหม ?
code มันสามารถจับต้องได้ดีกว่า requirement หรือเปล่านะ ?
ดังนั้น code มันก็คือ inventory อย่างหนึ่งใช่ไหมนะ ?
และเราก็ควรดูแลมันอย่างดีด้วยหรือเปล่านะ ?
ในโลกของการพัฒนา software
เรามักจะอยู่ หรือ สร้าง หรือ แก้ไขเปลี่ยนแปลงระบบอยู่อย่างยาวนาน และ ตลอดเวลา
ซึ่งต่างจากการสายการผลิตในอุตสาหกรรมอื่นๆ
ที่ทำงานเป็นชิ้นๆ ออกมา เช่น
การผลิตรถ
จะผลิตแต่ละชิ้นส่วน และ นำมาประกอบกันในท้ายที่สุด
สามารถกำหนดขั้นตอนการทำงานได้อย่างชัดเจนในสายการผลิต
แต่ในโลกของการพัฒนา software นั้น
เราต้องอยู่กับรถแต่ละคันไปอย่างยาวนาน
ต้องคอยดูแล แก้ไข เติมน้ำมัน เปลี่ยนอะไหล่
อาจจะเป็นเดือน เป็นปี หรือ นับสิบๆ ปีกันเลยทีเดียว
ดังนั้น คุณจำเป็นต้องอยู่กับ code เหล่านั้นไปอย่างยาวนาน
และแต่ละส่วนการทำงาน ที่ชอบเรียกว่า module นั้น
เราไม่สามารถมั่นใจได้เลยว่า
มันทำงานอย่างไร เกี่ยวข้องกับ module อะไรบ้าง
หรือทำงานด้วยตัวมันเองเลยหรือไม่
ดังนั้น สิ่งที่คุณทำได้คือ ความใส่ใจต่อ code ที่คุณอยู่ด้วย
อย่างสม่ำเสมอนะ !!
Attention please …. attention please ….
มาถึงตรงนี้ ลองคิดสิว่า Code มันคือ inventory จริงๆ หรือไม่ ?
code มันคือหนี้หรือเปล่านะ ?
code มันมีค่าใช้จ่ายที่สูงขึ้น ตามอายุของระบบหรือเปล่านะ ?
code มันมีค่าใช้จ่ายที่สูงขึ้น ตามความซับซ้อนของระบบหรือเปล่านะ ?
code มันมีค่าใช้จ่ายสูงขึ้นหลังจากการ deploy หรือไม่นะ ?
code มันมีค่าใช้จ่ายสูงเมื่อต้องทำการแก้ไข หรือ เพิ่ม feature ใหม่หรือเปล่านะ ?
ดังนั้น Code มันคือ cost
หรือ ค่าใช้จ่ายขององค์กร หน่วยงาน หรือ ทีม หรือเปล่านะ ?
จะสร้าง code ก็มีค่าใช้จ่าย
จะดูแล code ก็มีค่าใช้จ่าย
จะแก้ไข code ก็มีค่าใช้จ่าย
คำถาม
ดังนั้นสิ่งที่คุณทำได้คืออะไรล่ะ ?
คำตอบ
ต้องลด cost ต่างๆ เหล่านี้ลงไปนะสิ
นั่นคือ การทำให้ code มันเล็กลงใช่ไหมล่ะ ?
คุณต้องเรียนรู้การลบ code ที่ไม่จำเป็นออกไปบ้างนะ …
คำถาม
แล้วจะรู้ได้อย่างไรล่ะ ว่า code ส่วนไหนไม่ถูกใช้งาน ?
คำตอบ
แต่ละองค์กร หน่วยงาน ทีม จำเป็นจะต้องรู้ว่า
feature ไหนที่มันไม่ถูกใช้งาน หรือ เลิกใช้ไปแล้ว หรือ ที่มันไร้ค่า
หรือไม่ก็ให้เกิดประโยชน์ หรือ รายได้เข้ามาเลย
ถ้าไม่รู้ ก็ต้องทำให้รู้ให้ได้ …
จากนั้น จึงจะทำการลบ code ซึ่งคือที่กำเนิดของ feature นั้นต่อไป
จุดที่สำคัญมากๆ
คุณจะเห็นได้ว่า cost หรือ ค่าใช้จ่ายที่มาจาก code
มันมากกว่าที่คุณคิดไว้อย่างมากมาย …
ดังนั้นต้องลด cost นี้ลงให้ได้มากที่สุดเท่าที่จะทำได้ …
แต่คุณจะแข่งขันในตลาดได้
ถ้าคุณยอมรับว่า product ของคุณมีปัญหา และ นำมาปรับปรุง
ถ้าคุณยอมรับว่า code ของคุณมีปัญหา และ นำมาปรับปรุง
คำถามสุดท้าย
คุณกล้าลบ code ไหมล่ะ ?
[fb_embed_post href=”https://www.facebook.com/somkiatspns/posts/10153356588198588/” width=”550″/]
