我早在N年前就發現自己寫程序速度慢，我當時對STL遠比周圍人熟悉，照例說長纓在手，應該效率很高才對。結果發現不是，寫程序的時候特別沒自信，總在想：“這樣固然是可以work了，但恐怕有更好的方案吧，會是什么呢?加個模板參數試試?要么抽象出一個基類?做一個bridge模式?那么Ownership的問題怎么解決?誰來負責回收內存呢?移植一個boost::shared_ptr過來吧!可多線程情況下會不會拖慢速度呢?應該不會，可是會碰到循環引用的情況。要么在中間搞一個weak_ptr把循環鏈斷開?哎呀不行不行，太復雜，別人也理解不了。還是先這樣吧，能work就行�！� 就這樣，兜了一個圈子回來。有的時候，這個圈子不是純柏拉圖式的，我會真的實現不少 “優化” 設計來比對，那個時間啊，花花的就耗在里面了。
另一位資深的C++程序員劉未鵬則這樣感嘆：
群眾是容易被誤導的，我也曾經是。以為掌握了更多的語言細節就更牛，但實際卻是那些語言細節十有八九是平時編程用都用不到的。C++中眾多的細節雖然在庫設計者手里面有其用武之地，但普通程序員則根本無需過多關注，尤其是沒有實際動機的關注。一般性的編碼實踐準則，以及基本的編程能力和基本功，乃至基本的程序設計理論以及算法設計。才是真正需要花時間掌握的東西。
顯而易見，在C++這種語言上，人們投入了大量精力、撰寫了大量圖書和文章來關注它的語言細節，卻對在真實環境下使用它解決問題的最佳實踐重視不足。如果這還不夠糟糕的話，不妨再看看C++在項目層面上的最佳實踐——幾乎沒有任何成文的資料存在。當敏捷實踐對于Java、.NET、Ruby等等社區的開發者逐漸成為常識時，C++程序員們還要花大把時間去學習摸索如何寫一個好的makefile、如何組織自己的項目目錄結構，更不用說持續集成和測試驅動開發了。
但C++團隊仍然需要敏捷實踐。據記者的了解，國內有多家從事電信、鐵道等行業應用開發的IT企業已經痛感缺乏項目組織手段和質量保證手段帶來的問題，并希望通過引入敏捷實踐來改善項目質量，提高工作效率。在C++項目中引入敏捷方法，至少需要以下幾方面的最佳實踐作為支撐：
·項目自動化：如何在make等現有工具的基礎上，通過合理的項目組織，實現項目構建、集成、測試的完全自動化。
·測試驅動開發：如何引入以CppUnit、CxxTest為代表的單元測試工具，并以測試驅動功能代碼的開發。這個話題又可以引申出兩個方面：
·面向對象設計：針對某一特定領域的軟件應用，如何進行合理有效的面向對象設計，使之有可能進行單元測試;
·mock：如何為C++應用引入mock技術(甚至是IoC容器)，從而簡化單元測試。
·持續集成：如何加快集成的頻率，將C++項目與現有的持續集成工具(例如CruiseControl)結合起來，使集成狀態成為項目健康情況的重要標示信息。
·重構：如何有效利用現有工具，對規模較大的C++程序進行重構;如何避免使用對重構構成障礙的語言特性。
正如記者所指出的，C++的敏捷實踐正在日益受到相關IT企業和開發團隊的重視，但這方面的系統研究和資料仍然非常欠缺，給希望引入敏捷實踐的C++團隊造成了巨大的障礙。經驗豐富的C++程序員們如果投入更多的精力來討論和總結“如何用C++做好一個項目”，會給整個行業帶來更大的價值。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
