代碼的持續可用性

代碼的可維護性這個話題已經提了很多年了，但從最好的方案其實隻是最适合自己的方案的角度思考，代碼的可維護性說成代碼的持續可用性更現實，更适合我們的目标。

代碼的持續可用性說的是今天寫的代碼可以适用未來的需求，相同的工作不需要重複做。

但是，明眼人看到這裡肯定會笑了，這是一個看起來不能實作的目标，在軟體這個行業摸爬滾打過的人，誰不是在重複寫東西，實際細節中各種猥瑣的問題，怎麼可能用去年寫的代碼來應付。

好吧，為了實作代碼的持續可用性，需要從兩個方面着手：元件和架構。

oo是個不錯的東西，多态是個強大的工具，但是，建築工程的經驗告訴我們，拼裝積木更适合人類的原生思維，在工程中組裝是件較容易完成工作。好吧，這就是泛型，值得深入研究的一個具體模型是C++的template。核心元件開發完成，後期使用就是對核心元件的拼裝。

但工程之是以為工程，是因為它的規模比較大，遠遠超出了練習題的範圍，一個直覺的說法是代碼量，面對海量的代碼，拼裝積木的方式真的見效嗎？這個時候需要架構，一個架構定下來需要堅持，而且不應該因為patch而被修改，這要求架構的設計比較完美或者持續的漸進完善，這種對架構的漸進開發是值得的，因為這樣可以使得代碼持續可用。

一個欲從事軟體工程的學生，需要有一些基本功，譬如元件。也許元件做不了大事兒，但萬丈高樓都是由元件堆積而成的。

一個膨大的項目，應該有一張合理的設計圖，譬如架構，對架構的堅持使得元件的拼裝思想清晰。

代碼的持續可用的收益有很多，譬如有效回避出了問題牽一發而動全身的弊端等。