以Linus Torvalds的一番言論為導火索，國內的技術博客們掀起了一場不大不小的“語言大戰”。是否真如Linux之父所說的那樣，“C++是一種糟糕的(horrible)語言。而且因為有大量不夠標准的程序員在使用而使情況更糟，以至於極輕易產生徹頭徹尾的垃圾(total and utter crap)。”孟巖的切身經驗頗值得玩味：
我早在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++做好一個項目”，會給整個行業帶來更大的價值。
