Pages

วันพุธ, พฤศจิกายน 03, 2553

Renew Vs Renovation

**คำเตือน : บทความนี้ เหมาะสำหรับ Geek


หลายๆ ครั้ง การพัฒนาโปรแกรม ก็มีความยากในการพัฒนา ...
เหตุผลหลักๆ ของการพัฒนาที่ยากนั้น ไม่ใช่เพราะความยากของงาน
แต่เป็นเพราะ solution ที่จะใช้สำหรับงานนั้นๆ มันยากที่จะตัดสินใจ ....
ด้วยโครงสร้าง ของโปรแกรม ที่เป็นลักษณะ Product 
โดยไม่ใช้ 3rd party software มาช่วยทุ่นแรง นั้น ...
สิ่งที่ challenge มากที่สุด คือ การสร้าง compatibility ให้กับตัว Product นั้นๆ 
เพราะเมื่อการที่พัฒนา application ในรูปแบบ Product จะมีข้อจำกัดมากมายที่
Developer ไม่สามารถ control ให้ลูกค้่า(เก่า)ให้ปฎิบัติตามได้ ... 
การเลือก technology  จึงจำเป็นที่จะต้อง คำนึงถึงจุดนี้เช่นกัน ...


การที่ โปรแกรม มีอายุการใช้งานมามากกว่า 3-4 ปี 
โดยพัฒนาตาม Requirement ของ ลูกค้า
จะเป็นสิ่งที่ค่อนข้างขาด Innovation มากพอสมควร ... 
User Interface เป็นอีกจุดนึง ที่มีความคล้างคลึงเช่นเดียวกับ technology .. 
วันนี้ ใ้ช้ง่าย ... พรุ่งนี้อาจจะมี Interface แบบใหม่ที่ใช้งานได้ง่ายกว่าแล้วก็ได้ ...  
ความ challenge จึงอยู่ที่ว่า ผู้พัฒนา จะทำอย่างไรให้ โปรแกรมของตัวเองนั้น 
มี UI ที่ UP-TO-DATE อยู่เสมอ ?? 


การเขียนใหม่ทั้งหมด ( re-new ) เป็นทางออกแบบนึงแต่ไม่สามารถ การันตีได้ว่า 
ของที่ทำใหม่ จะดี / เทียบเท่าของที่มีอยู่เดิม ....

ทางออกที่เลือกสำหรับงานในบางครั้ง จึงจำเป็นที่จะต้องเปลี่ยนจากการคิด
ที่จะ re-new เป็น renovation แทน ดังนั้นด้วย legacy code ต่างๆ 
ยกตัวอย่างเช่น Java AWT ก็ค่อนข้างเป็น Challenge ที่จะคิดว่า 
เราจะเอาอะไรมาเป็น replacement แต่ต้องได้ productivity เท่าเดิม ???


ไม่ว่าจะทำอะไรก็ควรที่จะศึกษาความเป็นไปได้ ก่อนที่จะทำเสมอ ...
เลยไปแอบอ่านเจอ บทความ เกี่ยวกับ Swing ขึ้นมา


 http://www.jroller.com/phidias/entry/is_swing_dead

เค้าก็เขียนได้ดีอะนะ ๕๕
โดยสรุปก็คือ ... ถ้า technology มันยังพอไปต่อได้ 
ถ้าเสีย effort ในการ renovate อย่างน้อย ก็ยังใช้น้อยกว่า renew อยู่ดี ...