可持續發展的程式設計

        為什麼很多程式被使用者用了一次就扔掉？一方面在中國，軟體基本上是不花錢的；另一個方面，使用者往往只有單次的功能需求。不過，本文並非討論如何避免這種事情發生，而是要站在程式員的角度去考慮另外一個類似的問題：很多我們曾經寫過的代碼被自己用了一次就扔掉。

       代碼“即用即拋”的習慣使我們開始一個新的項目就意味著白手起家，重頭再來。實際上我們是希望自己的代碼高度可重用的。寫過的代碼如果都能在此後的項目中加以利用，那將是一件非常美妙的事。想要真正實現這個願望其實並不難，只要你學會可持續發展地設計程式即可。

       代碼重用實際上是軟體工程中已被充分考慮過的問題。組件技術以及我們樂於使用的第三方類庫都是代碼重用的體現。但是我們就不能考慮自己的代碼重用嗎？我的一位朋友，在某家企業的營運部工作，他時常抱怨部門裡可用的自動化指令碼奇缺，以至於自己每天都淹沒在“人肉”的維護工作之中。這意味著大量的索然無味的重複性工作。我的那位朋友並不準備“坐以待斃”，他現在(今天周六)正在加班，埋頭寫著各種自動化指令碼。我認為這與程式員的代碼重用有十足的類似性。程式員應當讓自己的代碼更具重用性，以避免毫無意義的重複性工作。

       如何去做？Scott Meyers在《More Effective C++》條款32中給我們提供了非常精彩的參考。條款32鼓勵程式員在未來時態下進行程式開發，力求使自己的代碼更有彈性、健壯性和高可信賴度。所謂“在未來時態下”即開發程式的過程中充分考慮可能的變化，他總結了一些與此相關的忠告：

(1) 軟體的維護人員往往不是那款軟體的開發人員，因此一位優秀的開發人員應該留意這個問題，讓自己編寫的代碼適合閱讀、易於理解、便於維護；

(2) 如果你想明確禁止Class的某些行為，不要單單依靠文檔或注釋，利用C++的語言特性去實現吧。比如你要禁用某個Class的拷貝構造和賦值操作，就應該明確設定它們為private，這比你在原始碼中添加大篇幅的警告更有現實意義；

(3) 不要突發奇想，而要謹慎地去設計。軟體開發不僅是編碼，若如此程式員真的就只是“碼農”而已了。軟體開發至少包括軟體設計和軟體實現兩個過程。請重視軟體的設計，你需要更謹慎地對待它。多考慮你的設計是否完備，是否還有漏洞，某種新功能的實現是否帶來副作用等；

(4) 別存僥倖心理，凡是使用者能夠做的，使用者肯定會做。只要編譯器允許，即使邏輯上有錯誤的事，使用者也會去做。要接受“使用者會犯錯”這個現實，因此不要僥倖地認為使用者不會走入雷區而讓自己輕鬆悠然，多花時間和精力去完善自己的設計吧；

(5) 偶爾也要考慮一下軟體的平台移植性，如果你在作業系統上押錯了寶，可能等待你的將是徹頭徹尾的失敗。

       上面的這些忠告的確出於理性地經驗總結，但是它並不是讓你在未來時態下思考問題。從實際出發仍然很重要！不要等著編譯器廠商實現了某種你期待的C++標準特性之後才動手實現你的設計，你的等待可能很漫長，黃花菜都涼了；不要脫離了目前使用者的實際，不要強迫使用者更改自己的作業系統或者升級自己的硬體，你應該做的是在當前的條件下實現使用者需要的功能；不要對使用者承諾多久之後你的軟體有多麼巨大的效能提升，那並不會給使用者帶來任何溫暖，你要想著如何讓自己美妙的想法儘快實現，儘快推向市場，儘早轉化為財富。

       當你被拉回到現實中來，你可能會覺得很操蛋。是不是上面的忠告都是站著說話不腰疼。或許是吧，不過即便你非常注重使用者當前的需要，也不要忘記留意一下自己的需要。重用代碼會給你省下不少的時間和精力，讓你周末不用加班寫著重複的代碼。留意自己的需要，讓自己的代碼具有可重用性，記得以下3點：

  (I) 完整地實現Class，哪怕有些功能你現在還用不到呢，完備的Class才具有通用性；

 (II) 設計好Class的介面，你想要對外禁用的介面就設定為private吧；

(III) 儘可能讓你的代碼更具通用性，必要時使用C++模板編程。