โลกของการพัฒนา software นั้น
บริษัทส่วนใหญ่จะอยู่กับ Legacy system
และพบว่ามักจะชอบโยนระบบเหล่านี้ทิ้งไป
แล้วทำการเขียนใหม่ (rewrite) ทั้งหมด !!
เนื่องจากเชื่อว่า ถ้าเขียนใหม่แล้ว
ระบบมันจะดีกว่าเดิม
เราจะได้ใช้เทคโนโลยีใหม่กว่าเดิม
เราจะได้ไม่ต้องใช้ชีวิตอยู่กับ Legacy system ที่มันแย่ๆ
แต่การสร้างใหม่ทั้งหมดมันน่ากลัวเช่นกันนะ !!
ปัญหาที่มักจะพบเจอเมื่อต้องสร้างระบบใหม่ขึ้นมา
- Feature ต่างๆ มันต้องครบ 100% นะ ซึ่งเป็นเรื่องที่ยากมากๆ
- มีความเสี่ยงมากที่ระบบใหม่นั้น มันจะแย่เหมือนระบบเดิม
- มักจะประเมินเวลามาก หรือ น้อย จนเกินไป
- ปัญหาในขณะการสร้าง ระหว่าง ทีมพัฒนาระบบใหม่ กับ ทีม support
- และอื่นๆ อีกมากมาย
แต่ปัญหาหลักๆ ที่ทำให้เจ็บปวดรวดร้าวสุดๆ คือ
Feature มันต้องครบ หรือ ทำงานเหมือนเดิม หรือ 100% นะ !!
ลองคิดดูสิว่า
ถ้าคุณไม่มี feature ที่ถูกใช้งานบ่อยๆในระบบใหม่
มันจะเกิดอะไรขึ้นบ้าง ?
ลองคิดดูสิว่า
คุณจะต้องสร้าง feature ที่มันซ้ำกันทั้งสองระบบ ไปพร้อมๆ กัน
มันจะต้องใช้เวลาในการพัฒนามากเท่าไรกัน
ลองคิดดูสิว่า
ทั้งดูแลระบบเก่าให้ใช้งานได้
ทั้งสร้างระบบใหม่เพื่อมาแทนที่ และ ทำงานได้เทียบเท่ากัน
มันน่าสนุกมากเลยนะ !!!
เป้าหมายหลักที่แท้จริงๆ สำหรับการ rewrite คืออะไร
ต้องการสร้างระบบที่มัน clean กว่าระบบเดิม หรือ clean code
แต่ว่าเหตุผลหลักที่ใช้กันทั่วไปก็คือ
เราต้องการ rewrite เนื่องจาก ระบบเก่ามันแย่มากๆ
ดังนั้น จึงคิดว่า การ rewrite มันจะถูกกว่า การมานั่งซ่อมและแก้ไข !!
ซึ่งบ่อยครั้งพบว่า ความคิดนี้มัน ผิด
แถมยังสร้างระบบใหม่ที่แย่กว่าเดิมขึ้นมาอีกนะ
บ่อยครั้งมักพบว่า
ถ้าต้องการให้ระบบใหม่ feature เหมือนกับระบบเดิมทั้งหมด
จะทำการ copy&paste code จากระบบเดิมมายังระบบใหม่อีกด้วย
หรือแม้ว่าจะพัฒนาด้วยภาษาโปรแกรมที่แตกต่างกันก็ตาม
สิ่งที่น่าสนใจก็คือ เรากำลังสร้างระบบใหม่ที่เหมือนเดิมขึ้นมา !!
ดังนั้น ถ้าระบบเดิมมันแย่อย่างไร
ระบบใหม่ก็แย่อย่างนั้น
… ซึ่งมันคือเป้าหมายของการ rewrite หรือ ?
คำถาม
ในการ estimate เวลาและค่าใช้จ่ายสำหรับการ rewrite ควรจะเป็นเท่าไรดีล่ะ ?
คำตอบที่มักจะได้รับกลับมาคือ
ถ้าปลอดภัยสุดๆ ก็คือ เท่ากับเวลาที่ใช้พัฒนาระบบเดิมนะ
มันน่ากลัวจริงๆ นะเออ
คำถาม
ดังนั้นการ rewrite ระบบมันไม่ดีใช่ไหม ?
คำตอบ
ควรที่จะ rewrite เฉพาะส่วนที่มันมีปัญหาจริงๆ เท่านั้น
ซึ่งผลที่ได้กลับมามันจะคุ้มกว่า rewrite ทั้งหมดนะ
โดยในการพัฒนา software มักจะใช้กฎ 80:20 เสมอ
นั่นคือ ผู้ใช้งานจะใช้เวลาประมาณ 80%
ใช้งาน feature ของระบบเพียง 20%
ดังนั้น ถ้าคุณตอบได้ว่า feature ไหนที่มีผู้ใช้งานเยอะสุดๆ
และมันมีปัญหาสุดๆด้วยแล้ว
นั่นคือ สิ่งที่คุณจะตอบได้ว่า feature ไหนควรที่จะต้อง rewrite
มันช่วยทำให้คุณมีชีวิตที่ปลอดภัยขึ้นนะ
แต่สิ่งที่พบเจอมานั้นกลับตรงข้ามกัน คือ
แม้แต่ระบบเดิมยังไม่รู้เลยว่ามี feature อะไรบ้าง ?
แม้แต่ระบบเดิมยังไม่รู้เลยว่าแต่ละ feature มีผู้ใช้งานเท่าไร ?
หรือบางครั้งก็บอกว่า เรารู้นะ แต่ขอเวลาไป query ข้อมูลจากฐานข้อมูล
หรือขอไปไล่ code ก่อนนะ !!
มันเป็นเรื่องตลกร้าย แต่เกิดขึ้นจริง !!
จากปัญหาเหล่านี้นี่เอง
ทำให้คำว่า rewrite มันน่ากลัว อันตราย
รวมทั้ง ผิดวัตถุประสงค์ของการ rewrite อีกด้วย
ดังนั้น
ถ้าคุณยังไม่รู้สถิติการใช้งานของระบบเก่าเลย
แนะนำให้เริ่มทำและเก็บข้อมูลเสียแต่วันนี้
และนำข้อมูลเหล่านั้นมาวิเคราะห์
เพื่อกำหนดทิศทางการพัฒนาต่อไป …
อีกอย่าง สิ่งที่เข้าใจผิดอย่างมากสำหรับการ rewrite ก็คือ
เราจะทำการ rewrite ให้ครบทุก feature ก่อน
จึงจะเริ่มทำการ deploy เพื่อแทนที่ระบบเก่า
หรือให้ทำงานแบบขนานกันไป !!
เรามักเรียกการdeploy แบบนี้ว่า Big Bang
ซึ่ง fail มานักต่อนัก แต่ก็ยังทำกันแบบนั้นเสมอมา !!
สิ่งที่ขอแนะนำก็คือ Deploy early and often
ทำการ deploy บ่อยๆ รวมทั้งมีชุดของ automated test ด้วย
เพื่อทำให้คุณมั่นใจว่า
แต่ละบรรทัดของ code
แต่ละ feature ที่เพิ่มเข้าไป หรือ แก้ไข หรือ ลบออกไปนั้น
ทุกๆ feature ของระบบยังคงทำงานถูกต้องเช่นเดิม
สิ่งที่ขาดไม่ได้เลย สำหรับการ rewrite feature คือ automated test
หยุดการเขียนเอกสาร และ การ track งานแบบเดิมๆ
ซึ่งคุณก็รู้อยู่แก่ใจว่า มันไม่ได้ผลที่ดีเลย !!
ดังนั้น มาเขียน automated test กันดีกว่า
คำถาม
แล้วทำอย่างไรล่ะ ?
คำตอบ
ก่อนที่เริ่มทำการ rewrite feature ใดๆ นั้น
ให้เริ่มด้วยการเขียน automated test ทดสอบระบบเดิมก่อน
เพื่อทำให้รู้ และ เข้าใจการทำงานของ feature นั้นๆ
จากนั้นจึงเริ่มการ rewrite feature นั้น
โดยใช้ automated test ชุดเดิม มาทดสอบที่ระบบใหม่
ซึ่งถ้าผลการทดสอบผ่านทั้งหมด เราจึงจะทำการ deploy ขึ้นระบบ production ต่อไป
จะเห็นได้ว่า automated test มันคือ สิ่งที่บอกเราว่า feature นั้นๆ
ทำการ rewrite เสร็จหรือไม่นั้นเอง
เพียงทำตามทั้งหมดนี้
การ rewrite ก็จะไม่น่ากลัวอีกต่อไป
ปัจจุบันคุณทำการ rewrite ระบบกันอย่างไร ?
