你告訴我你有單元測試，你有**提交自動構建，還有你說的構建後自動整合測試。好的，專案在貌似平穩的執行。可我已經感覺到缺陷的修復越來越困難，**不斷的、不聲不響的退化，燃盡圖越來越平緩。問題很簡單也顯而易見：開發人員的投入產出比在不斷下降。
當我真正要著手重構現有**時，吃驚的發現乙個大問題。這個專案大致有60多個核心應用，卻有上千個編譯警告。這明顯是對於c++的編譯警告的態度問題。編譯警告有用嗎？就這麼忽略嗎？這個先要說清楚。
不管是專案中的敏捷方法，還是個人開發使的測試驅動，我們都有乙個共同的目標：盡早盡快的發現問題。越早、越快，成本就越低，代價就越小。細數起來，無論如何，編完**的第乙個工作就是編譯，**功能以及質量也同樣的反應在編譯輸出上。從這個角度講，編譯的錯誤資訊、警告資訊對我們是非常有用的。問題就出來了，錯誤無法迴避，可警告資訊，出於各種原因（比如時間壓力、人為忽略），就有可能被忽略了。而這樣的影響，恰恰會把一些前期錯誤推遲到單元測試階段。
如果足夠幸運的話，你可能在單元測試時發現了問題。事實卻總不盡如此，更為嚴重的，潛在問題，在單元測試時，悄悄的漏掉了。是的，現實中，測試總不能夠發現所有的問題。而這，可能是以後問題的炸彈，或許是顆啞彈，或許在程式設計師的腳下**，或許在客戶的面前**。
好吧，如果你認為我足夠囉嗦，而你又看到這裡的話，也許會問，如果不關心這些幕後的話，程式設計師如何認識編譯警告的價值呢？簡而言之，尊重編譯器，從尊重編譯器誠實可靠的警告資訊開始。
基於以上原因，我決定拿出一部分時間，細查專案中的警告資訊，甚至不惜抬出-werror引數，逐步修正專案中的問題，強制加入**規範裡。 隨後，我會借助**、用有代表性的警告詳細分析問題、以及其可能帶來的後果。
如何正確看待需求文件
今天中午吃飯，老師主動講了一下對於需求的看法。首先，最好是在迭代啟動會之前，就把需求看清楚，對於其中的問題有自己的看法，並在啟動會上提出自己的問題 可能多數人並沒有看需求，因此在迭代會上問題不多，甚至並沒有發問 其次，對於需求，老師認為，應該是我們引導業務部門，而不是業務完全引導我們。換言之，我們需...
如何正確看待手機的續航
這些年在智慧型手機的續航問題應該是飽受爭議的，或者說不是爭議，是詬病。一台號稱智慧型手機能正常使用上2天已經算的上是牛逼，完完全全的大賣點了吧。就算是蘋果也沒有在這個方面有任何的重大突破，只是在平衡了效能和續航的方向上做著努力。而android的那就像乙個戰國時期，亂的不行。在解決續航的問題上，目前...
歐美軟體外包系列 一 正確看待外包
做歐美外包8年了，積累了很多對歐美外包的一些經驗和認識。由於看到很多人對外包產生了很多誤解，有很多發包方也在大家的誤解中錯誤的看待外包團隊，所以想讓大家對外包有乙個正確的認識。由於我一直做的都是歐美外包，所以主要是在談歐美外包。歐美外包其實就是歐洲和美國的軟體外包，主要是歐美發達國家和離岸顧團隊的一...