爲什麼很多程序被用戶用了一次就扔掉？一方面在中國，軟件基本上是不花錢的；另一個方面，用戶往往只有單次的功能需求。不過，本文並非討論如何避免這種事情發生，而是要站在程序員的角度去考慮另外一個類似的問題：很多我們曾經寫過的代碼被自己用了一次就扔掉。
代碼“即用即拋”的習慣使我們開始一個新的項目就意味着白手起家，重頭再來。實際上我們是希望自己的代碼高度可重用的。寫過的代碼如果都能在此後的項目中加以利用，那將是一件非常美妙的事。想要真正實現這個願望其實並不難，只要你學會可持續發展地設計程序即可。
代碼重用實際上是軟件工程中已被充分考慮過的問題。組件技術以及我們樂於使用的第三方類庫都是代碼重用的體現。但是我們就不能考慮自己的代碼重用嗎？我的一位朋友，在某家企業的運維部工作，他時常抱怨部門裏可用的自動化腳本奇缺，以至於自己每天都淹沒在“人肉”的維護工作之中。這意味着大量的索然無味的重複性工作。我的那位朋友並不準備“坐以待斃”，他現在(今天週六)正在加班，埋頭寫着各種自動化腳本。我認爲這與程序員的代碼重用有十足的類似性。程序員應當讓自己的代碼更具重用性，以避免毫無意義的重複性工作。
如何去做？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++模板編程。