1.對專案延期的處理方式：
有些專案開始時非常樂觀，但是到最後因為各種原因延期，主要的原因如下：
（1） 有些灰色地帶沒有考慮清楚，或者沒有引起重視。
（2） 專案開始時大家非常輕鬆，工作不緊不慢的。到專案的後期發現要延期了，就加班加點。
（3） 測試時發現嚴重的bug，一時三刻解決不了。
（4） 設計時沒有考慮效能問題，導致效能很差。
解決專案延期有如下方式：
（1） 在專案開始時盡量往前趕，超出計畫時間，多給專案後期留更多時間，這樣在專案後期遇到問題時由於有充足時間，導致專案延期的可能性大大減少。
（2） 大家在從事專案的過程中，在設計階段往往比較空，討論討論問題，寫寫文件。其實可以把這些比較空餘的時間也利用起來，可以在設計階段完成一些關鍵模組的原形，驗證一下技術上是否可行。
（3） 在**開發階段，每完成乙個函式就可以上別人review你的**，而不是在所有**都完成後再review**。這樣把**review的時間分散到開發階段。
2.測試驅動
最近部門在強力推行測試驅動開發，我最初有點反感，到現在完全、徹底支援。
測試驅動要求你在編寫**前，先寫測試**，開始時測試**肯定通不過，因為你的**還沒有寫，當你的測試**寫好後（把所有情況都考慮到了），你寫**的唯一目的就是把測試用例通過。
我覺得測試驅動有如下優點：
(1). 在寫某模組**前，你先寫測試**，可以對你的**的輸入輸出有乙個全面的認識，對邊界條件你也會心理有數。
(2). 事後確保機制： 在你寫完所有**後，如果過一段時間後發現某bug,你fix呼叫這個bug後，你需要執行一下這個系統的所有testcase,如果有失敗，則表示你的修改有問題，需要找原因，把失敗的testcase通過，或修改testcase,或者修改**。
(3) .測試用例一般在設計階段完成，所以在設計階段就需要考慮可測試性。
記得老大描述測試驅動時，舉了乙個比較貼切例子來解釋測試驅動，開始時我沒有明白，現在明白了。 把我們從事專案設計，開發比喻成以前從井裡打水，古代井裡打水是這樣的，在井口有一根木頭，木頭上纏繞繩子，繩子的一端系上水桶，當需要打水時，慢慢轉動木頭，把水桶放到井裡，然後打水，水桶裡打滿水後，再轉動繩子，把水桶從井裡慢慢往上拉。直到水桶拉出井口。
老大說測試用例就是繩子上乙個鍥子，當你慢慢把水從井底拉上來時，每隔一短距離（比喻你的一段**）你就要打乙個鍥子（你對這段**寫的測試用例），這樣當你把水桶拉到一半，你想休息一下時，由於有鍥子，所以最多隻會掉下一點點，不會重新掉到井底。暗喻你的**質量***，不會把所有**都推倒從來，或者你不知道這一堆**裡，哪些**是好的，哪些**是不好的。
在實際的測試驅動開發過程中,我有如**會:
(1) 你在設計過程中寫的測試驅動有可能要往往不夠,在開發過程可能要新增測試用例,因為你在設計過程中考慮的往往非常粗,只考慮某個類的介面.在實際實現這些介面過程中,會新增函式,而這些函式可能非常重要,你必須寫乙個單獨的測試用例來測試它.
(2) 測試用例一定要認真寫,考慮全面,把各種情況要考慮一邊,各種邊界條件也要測試到,否則你會把測試驅動開發形式化,你在按照測試驅動開發在運作,但實際上沒有發揮作用. 有時候可能考慮不全面,但事後發現bug時一定要把相應的測試用例補上。
(3) 有時候你為了測試某個函式，這個函式對這個類非常關鍵，而這個函式是private的，因為只會給這個類的介面呼叫到，所以private,但是為了測試這個函式，你又不得不把它public,因為測試驅動開發你要求你的測試方法必須是public的，後來老大說這樣做不好，把不該暴露的函式暴露給外面，那個時候討論的結果是，你要麼不測試它，你要測試它，就或者public這個函式，或者新增乙個介面testaaa,這個函式只給測試用例用，我覺得這也不太好。後來我想了乙個辦法，我覺得可行，這個類把測試用例的類作為友元類或許可以解決這個問題。
一些專案管理心得
最近負責的市政數字報建專案快結束了，記下一些心得 對於中小型專案，最好不要使用常規的軟體工程方法進行開發。建議前期採用迭代開發，後期採用測試驅動開發。專案一開始，就要搭好以下文件的框架，隨專案進行中，不斷修改 補充和完善。1 需求規格說明書 甲方負責。詳細記錄整個專案的需求。特別是專案過程中，一些需...
git專案管理方面的一些心得
git clone ssh git add git commit m test.txt created by zyu git log oneline graphoneline 一條展示為一行 graph 圖形化展示 git remote 檢視配置的遠端提交資訊 只有名稱 git remote v 檢...
效能測試的一些心得
效能測試三階段 一 單個介面的壓測 基準容量測試 目的 驗證被測試介面的最高tps 基於一定的響應時間ms tps是從服務端角度驗證介面效能 方法 採用梯度壓測方法，按照設定的梯度逐步遞增壓力，觀察tps曲線變化 測試時注意遞增的粒度，粒度需要細化到tps曲線跟隨梯度壓力曲線呈梯度變化 最大tps ...