🏆 超過70萬名讀者已閱讀本站的內容，共同創造了105萬次總閱讀次數！
無論是需求變更，新功能，修正錯誤，軟體開發上時時刻刻都在面對變動。面對變動時大部份人考慮的是「怎麼做」？
但技術底子強的工程師面對變動時馬上會想到：
- 為什麼要改？或是為什麼要在這時間點改？
- 改了之後程式碼的代價是？風險是？
- 改了之後可以維護嗎？有要維護嗎？
軟體工程的概念不能馬上給你一個超炫的新功能，或是馬上解決眼前的 bug。但卻有機會把軟體的體質改善，獲得長期根本上的健康。
相關文章
-
My OGRE 3D working journal vol.5 -
Design Pattern 設計模式 (3): Facade, Flyweight, Proxy, Chain of Responsibility
-
Design Pattern 設計模式 (2): Adapter, Bridge, Composite, Decorator
-
Delegate (委託模式), and its difference in C++ and C# -
Multi-thread 多執行緒程式設計 -
Design Pattern 設計模式 (1): Abstract Factory, Factory Method, Singleton, Builder, Prototype -
Smart Pointer
-
Policy-based Design
💡相關文章
縮小
我是 Larry，經營 B2B 軟體公司超過 10 年，也持續寫作超過 15 年。
我會持續分享自己對商業、科技與生活的觀察。
如果你喜歡這篇文章，也歡迎追蹤我的社群：
📌 Threads｜日常觀察與商業思考
📌 FB｜文章與生活分享
📌 IG｜旅行、美食短影片
