開發小結-流程管理類-下篇
改Bug和優化要不要同時進行
個人覺的，改Bug和優化，當優點的點和改Bug的點緊密相關聯時時，改Bug和優化可以一同進行。而對於那些不怎麽緊密的代碼，優化可有可無時，那堅決不要優化。比方說，最開始進行釋放內存，使用delete p; p = NULL;後來發現項目中已經有封裝好宏，只需要一句話就可搞定。不過在使用該宏時，需要引入頭文件。那麽，這種情況下，就可以不進行優化，原來怎麽寫，現在就這麽寫。保持在同一個模塊(.cpp)中，相關操作的一致性即可。
從冗余的實現到既可以滿足業務功能，又保證每行代碼最優，在下手前，需要反思思考斟酌，這是新手邁向高手的必經之路。
找Bug經驗
解決Bug，很多時候，不存在既能夠減少改動範圍和影響範圍，又能很好解決問題的方案，為了平和開發成本和測試成本，很多時候，為了控制改動影響，會傾向於選擇“消除現象”，而不是找出根源來解決問題。
屏幕錄像找Bug
測試一些不容易重現的Bug時，可以借用FastStone的屏幕錄像功能，來找到Bug觸發的最短路徑，具體操作方法如下：
通過屏幕錄像，把在相關操作都記錄下來，直到出現崩潰提示為止。反復觀看，梳理一些不必要的動作，直到找出觸發Bug的必要路徑，不斷精簡路徑，直到找到最短路徑為止。
使用此種方法時，需要有以下前提：
- 測試反饋此Bug是進行了若幹操作後，會有很大幾率會出現，但不知是什麽操作觸發的，只有最後出現崩潰的畫面。
- 需要使用測試人員發生崩潰的版本來測試
二分法找Bug
在開發過程中發現，A模塊出現問題，而在幾天前，這個模塊是沒有問題的。通過代碼回滾，可以明確若幹天前的A模塊沒有問題，而今天的A模塊有問題，通過二分回滾查找，可以逐漸把範圍縮小，最終定位到是哪一次提交造成A模塊出問題，常見都是某一次不相關的提交，間接又間接的造成A模塊出問題。
接口變更造成的Bug
有些Bug是因為調用其他方提供的接口，如果因為接口提供方的重構，導致接口參數改變，而調用方沒有做針對性的改變，就會出現Bug。
此類Bug的修復，建議自己先排查出來，然後交由接口提供方去修改，因為這是它修改接口導致的問題，在調用方這裏，只知道調用方這裏的實現，而不會註意到其他開發人員調用該接口是否也會有問題出現。
有些因為接口導致的錯誤，由接口方來修改或者界面方來修改都可以的情況下，接口方修改，不僅僅可以針對當前這個界面，對以後其他新增界面也可以適用。如果有界面方來修改，那僅僅只能針對當前界面，如果有新增界面的話，則很有可能會遺漏. 針對這種情況，建議接口方做修改比較好。
提優化的Bug
開發事先的和需求要求的一樣，不算Bug。如果測試認為需求文檔上面實現的不美觀提Bug修改，那這種Bug不算是我的Bug，算是需求的Bug。這種Bug的產生是需求裏面沒有定義的細節，而測試認為默認實現和它心裏的不一樣而產生的。
因此，我自身的建議是：優化類的建議和Bug需要區分開.
一是，兩者判斷的依據不一致，
二是，兩者發起人可能不一致，優化類可能是開發人員自己發起的，也可以是測試人員主動發起的。可能某些優化，在界面的功能上是體現不出來的，需要和後臺一起來做判斷。可能有些優化，是各個界面上因為操作的不一致性而提出來的，這種問題的出現，是因為之前就沒有統一的標準，新界面走新標準，舊界面保持不變，那麽，在遇到這樣的情況時，需要限定修改和測試的範圍，以防止無止境的類似的優化建議提出。
進度評估
一個項目的完整流程，基本包括需求設計，視覺和交互設計，開發編碼，測試，上線，運維，發布新版本等幾個環節。
從用戶的角度來看，如果上線後功能無法正常運行或者運行經常崩潰，那就是沒正確的完成。
從開發的角度來看，自己負責的模塊完成並且自測通過，後續交付給測試測試，是不是可以認為自己這部分功能已經完成了呢? 這要看完成的評估標準了，如果是以軟件發布為標準，那個人模塊的提交還算不上完成，得集成測試通過後正式發布，才算完成。那個人自測通過交付測試後，這個進度怎麽去描述呢？量化的描述方法是不合適的，只能這樣說，進度到，已完成功能的開發，並且交付測試測試階段。
從整理角度來看待，項目進度可以從兩個層面去看待，整體進度（需求設計，視覺和交互設計，開發編碼，測試，上線），具體到每一個子流程中，每個人負責各自的進度（未開始、已完成A，B功能，已完成A，B，C功能，還剩D功能，已完成，這幾個階段），作為開發人員，考慮的著重點落在已分配的任務，已提交測試的任務兩個點上。
無論是開發新功能，還是重構已有功能，工期估計是很重要的。雖然都說，計劃趕不上變化，如果仍由變化任意發展，自己就是在進行毫無章法的工作，從時間安排上來看，就是用戰術上的勤奮掩蓋戰略上的懶惰。下面分別談談新功能開發和重構的工期估算：
- 新功能開發，如果該功能是之前類似的模塊，可以從項目管理工具和SVN提交記錄上查看，從自己接收到此任務到完成所有功能後提測，並且最終通過測試的時間段，以該時間段作為參考因素。另外，從該功能涉及到的業務流程、依賴的第三方數據等進行綜合考量，按照每天6個小時的有效工作時間來算，將得到的最終小時數再乘以1.5的系數後折算回天數，乘以系數是因為項目過程中總會有那麽些意外情況發生,可能用到了自己不熟悉的庫或者接口之類的。
註意：如果開發功能涉及到與其他同事合作對接，若不清楚相關業務，最好將此功能交給熟悉的同事來確認完成對接所需的時間，不能貿然代表同事回答對接時間，不能因為看起來很簡單就直接確認期限。對於同事來說，也一樣，大家都是為同一個目的而工作，不要因為自己的緣故耽誤別人以及整個項目的進度安排。
- 重構開發，根據需要重構的功能點，每一個功能點評估下所需時間，將各個功能點的時間匯總起來，構成總共需要的時間。
影響評估
對修改要心生敬畏。評估改動影響時，可以按照如下框架來思考:
- 應用場景分析：
1.1 是否高頻（例如每天5次）
1.2 是否高危（影響範圍較大）
完整的場景是如何的，本次變更屬於哪個環節，需要滿足什麽樣的條件？上線後如何確認功能是否正常
- 影響範圍分析：
2.1 影響哪些系統
2.2 影響哪些功能
2.3 影響哪些部門
越是臨近發布時點的修改，越是嚴格控制修改影響範圍，想清楚了再去做。
假如不能評估修改的影響，寧可不改，也不要亂改。與此同理，假如基於目前的開發進度，不能去評估完成一個新功能的工期，或者說很難去評估的準確，那麽在自己的心理預期上乘以2倍或者3倍。當碰到解決不了的問題時，在自己在嘗試了多種解決方法後，及時反饋上級，請求更多資源協助。
開發回顧
每做完一個功能模塊，要進行復盤，梳理回顧在實施過程中，有哪些做的好的地方，哪些做的不好的地方。
對於剛開始著手做這個模塊時的一些工時預估，難度的預估，溝通的預估，和真正完成這個模塊後的實際估計，看看自己哪些預估是正確的，哪些預估是偏差較大的，如果偏差較大，回顧自己在開發時的工作狀態，看是哪一個節點上卡殼，導致工期延長，仔細分析原因，有可能是其他人員的接口配合，後臺的數據配合，也可能是自己預估的太樂觀等等，開發是在不斷叠代進化的，及時的復盤，對完善自身，提高自我的項目管理能力大有裨益，切記，切記。
- 對工作崗位負責
- 當在工作時，就要在規定的時間內，全神貫註的工作,哪怕事情再多，也要一件一件地進行，做完一件事情再做另外一件事情。當在休息時，就必須完全休息.
- 及時做好自我反省,記錄在開發過程中的心得體會，以便在下一次任務來臨時，能夠精益求精，不斷進步。
- 留給自己一定的思考時間，在真正著手開始幹活之前，在腦海裏面梳理一片 要解決的問題是什麽，該如何做，怎麽做才能更好，想清楚，畫出來再動手。
- 失敗後不要找借口,失敗就是失敗，沒什麽好推脫的，哪怕原定計劃因為不可抗因素破壞而失敗，不要說因為這個那個，找原因比抱怨更好。從失敗中去找原因，記錄這個原因，在下次做類似決定之前，回顧下自己失敗的原因。因為一旦你為自己的失敗找了借口，那麽下次失敗還會再找借口，到最後，整個項目都會失敗的。
心態管理
公司不是學校，公司支付你的薪水，不是讓你深造技術，而是希望你替老板解決問題。在業余時間，你可以探究喜歡的技術，但一旦到了工作場合，你就應該思考如何高效、準確、敏捷完成產品提出的需求，無論這個需求有沒有技術含量，若該需求的實現會破壞現有的架構，那麽從實施成本和收益上做出自己專業性的判斷。
除了專業技術的進步，業務規則和業務流程也需要關註，多思考新技術與既有業務的結合點，通過代碼評審、技術分享等提高其他成員的技術能力。如果能做到這一點，相信你會迅速成長為團隊骨幹。
分支管理
現有的開發實踐中，采取開發分支和發布分支雙線並行的模式。平時，大家都是在一個開發分支上工作，當項目需要對外發布版本時，從開發分支中拉取一個分支當做發布分支（例如V1.0），後續發布版本的需求和Bug修改均在V1.0分支上完成，測試同事也在發布分支上工作。
越是臨近發布節點時，對發布分支上的改動越是要謹慎，改動範圍能小則小，不是萬不得已的修改，盡量不要提交。如有一些牽一發而動全身的修改，會造成回歸測試壓力過大，延誤發布時機。待到發布分支逐漸穩定後，達到可以發布的狀態，等發布上線後，再由各個開發人員將各自在開發分支上的提交逐次合並到主線分支上，大家繼續開發下一個版本。
對於已經發布出去的版本，對應的代碼庫應該設置為禁止提交，要完整保留發布時的代碼庫以及相關的調試信息，這有助於分析已發布版本的問題。
針對開發和發布分支雙線模式，我的習慣是，在本地建開發分支，重構分支和發布分子。新功能開發在開發分支上做，改Bug在發布分支上做，及時合並會開發分支。在重構分支上，做一些重構性的工作。三個分支各司其職。
每次提交作為一個最小完備的功能集合，目的唯一性。如果有些功能的實現涉及到多處改動，那麽需要有計劃、有意識地去劃分一個大功能的各個子功能，每次提交一個明確的子功能，由此逐步構建一個大功能。
在平時的工作任務安排中，需分清輕重緩急，一定要把自己手上現有的Bug都處理完後，才去做自己任何合適的優化和重構工作，千萬不要自以為是的做一些感動自己的事情。完成公司的任務是第一要緊的事情，是首要要解決的事情。
時間管理
在新接收到一個需求時，分配到 需求分析、設計、實現和自測上面的時間安排，推薦為4:3:2:1
為什麽這麽分配時間呢？經過多次工作實踐得來的。當需求不明確，那麽關於這個不明確的地方，怎麽開發都是不合適的，為了解決因需求不明確導致的後續設計和實現階段的返工，在需求分析階段，需要根據需求畫出自己理解的 用例圖、狀態圖和主要流程圖等。這些圖是需求本身所涉及到的，在一個系統中，這個需求實現的功能和其他功能是有關聯關系的，比如說彈出非模態框，如果程序中已有一些彈出非模態框的部分，新增的功能也要彈出非模態框，那麽這兩個功能就有前後的關聯了，是同一時間只出現
一個，還是前後依次出現，後出現的覆蓋前面出現的，還是新增功能的框始終在頂部，其他框在後面，等等涉及到與已有實現的關聯關系，這些都需要進行額外的確認。
產品人員給出的需求，很大程度上，不可能考慮所有與之相關的其他對象的交互，而在整體行為上，該框的出現，影響了什麽，只有到開發階段才能發現。
引入第三方庫
對於引入的第三方代碼，一定要全部吃透，或者說是對可能的異常進行捕獲處理（緩沖區溢出無法捕獲）。
要不要引入一些 難以維護的第三方代碼？或者說，在引入第三方代碼時，需要註意些什麽？
- 看應用場景。
如果是關鍵路徑上的關鍵應用，對於引入的第三方，務必要完全吃透。這裏吃透的意思指的是，不光是看它能夠實現什麽，更重要的是看它沒能實現什麽,後者往往在業務中是很重要的。它不能做什麽比它能夠做什麽更重要。
如果是非關鍵路徑上的應用，對於第三方要進行自己的封裝，並且盡量少用第三方的高級功能，而是自己通過簡單功能來組合實現。
- 考慮引用第三方庫的一些負面效應
比如，第三方庫使用的 運行庫配置 需要和調用方保持一致，這可能會影響主工程的相關配置。
商業提供的第三方庫支持，如有必要引入，則可以引入。
對於開源的第三方庫，有幾點需要考慮的地方： - 是否一直有技術支持
- 文檔是否齊全
- 使用以後，組內是否有人能夠hold主，如果hold不住，果斷放棄，找一個能hold主的
- 該第三方庫是否有其他公司在使用，是否有經驗可以借鑒
- 社區是否活躍
在調用第三方服務時，要時刻保持懷疑態度，不能因為第三方的原因，而拖垮自己的服務，做好超時機制以及重試機制的處理。重試機制要合理設置，若是因為是業務導致出錯的，在UI上面要做好控制，防止用戶重復操作。若是因為網絡原因導致的，則需要選擇合適的超時策略和提示機制。
任務管理
一個大的任務往往可以細化為幾個子任務，設定規劃好子任務的目標和時間安排，分派子任務給其他人員去做。
自己在工作時，討厭別人在旁邊指指點點。這一點，作為幹活的人和指導的人，都是一樣的。幹活的時候，不喜歡別人對自己的工作方法和工作流程的指點，而人人都有一種好為人師的心態，在看到別人低效的工作方式，往往會忍不住去說兩句，起到興頭上面，還會主動出手去幹預，糾正。
對於指導者來說，這好像是一種經驗上的優勢帶來的心理愉悅感，而對於被指導者來說，這像是在被打臉，內心深處有一種壓迫感和強制打斷感，往往會引起厭惡
即使這個時候給出的建議的確是有效的，但是也往往帶來不了切實的效果，別人還是用他一套舊的方法。
提意見的方式很重要，基於上述的考慮，結合自己看的書籍，得出了幾點心得：
- 在自己工作或者幫別人幹活時，先聽清楚別人的需求，然後說，我在幹活途中，請不要打擾我！每一個小的階段，我幹好了，會主動給你看階段性的成果。
- 在別人正在幹活時，即使別人的工作方式不切當，千萬不要當場指出，而是在心裏或者找個東西記錄一下低效工作的步驟，
重點分析在哪幾步耽擱了時間，就像profile一個程序一樣，找出花費時間最長的函數，然後專門優化此函數。針對最影響效率
的操作，提出有可操作性的改進方法。如果可以的話，可以主動演示操作，讓別人體會到使用新方法而帶來的好處。
作為管理者，面對手下員工的工作，自認為想到的第一件事不是優秀，而是可控。可控的意思是，他們在做自己安排給他們的事情，
一旦他們做完了，能夠得到及時的反饋和通知，當他們遇到問題時，他們能夠主動的去向我尋求幫助，而我也可以適時的給出專業性
的方向. 作為下屬，如果做完了上司交代的工作，需要主動告知，還需要做什麽？如果有新的任務安排，就取做新的任務，如果沒有，
那就做自己的。
表達管理
要講清楚一件事情，首先自己要深入、細致地了解這件事情，其次在自己的大腦裏面要梳理總結關於這件事的重點信息，條理清晰的列出來，劃分主次，分清重點，考慮到講解對象的理解程度。
在一件事情尚未能明確拿下之前，不要貿然對外宣布，一旦答應客戶的事情，就一定要盡全力去做到，定期跟蹤客戶反饋的事情，及時作出回復。面對他人的請求，拒絕是常態，坦然面對拒絕，理解拒絕，正確處理拒絕，抓住需求點，持續提供服務。
思維模式和心態比才華更為重要，註重自我內驅力的培養，自我激勵，敢於承擔責任。
刻意培養對外的表達能力,一個公司是各種角色的集合，像老板、設計、HR、外包乃至前臺測試，仍然要通過自然語言而不是機器語言的實現，能夠適時把肚子裏的聰明才智繡出來，能夠恰當的把功勞業績拿出，自然而然會成為受歡迎的人。隨著平臺的擴大，表達也不限於一對一的溝通，向上匯報、規劃腦圖、總結郵件、技術指南、PPT演示等等，是專業職場人士必須要精通的技藝。
將復雜問題深入淺出，說的清楚生動，是一門很重要的能力。
開發的品味
實現一種功能可能有多種實現形式，有簡單的，也有繁雜的。在開發過程中，可能是基於現有代碼進行二次開發，也可能是另起爐竈開發，不管如何，在保證正確性的前提下，爭取寫出簡單直接，邏輯清晰明了的代碼。在閱讀代碼時，看到已有代碼是如何實現業務目標時，要有自己的品味，在實現類似功能時，不能一味照搬借鑒，而是選擇性的吸收改進。
可在團隊中，定期選擇一個工作認真的人，每周選取一個時間段，專門做代碼規範和最佳實踐檢查，堅持一段時間後，整個團隊的代碼規範執行力度將會得到明顯提升。
團隊的每日構建，規定，無論是誰提交的代碼導致無法編譯通過，第一次口頭警告，第二次請整個項目組喝咖啡，目的是不是為了請喝咖啡，而是真正做到令行禁止，讓所有人在提交代碼時，對自己提交的代碼有顧忌，慎重，從整個團隊上來看，可以較好的實時規章制度。
我今天寫的代碼，如果遇到功能改動，會不會修改起來很困難？如果可維護性差，那麽該如何改進？然後再進一步考慮下，當前面臨的問題場景是否能夠與設計模式中的一種或多種匹配上？如果能的話，該怎麽用設計模式的思路來改進？
不能僅僅只是做好當前任期的事情，每個人在公司內都有一個定位，做好自己職責範圍內的事情是理所當然的，但這僅僅只能保證你不失業，想往前走，還遠遠不夠。所以我們平常做事，要從這你的下一個職業去做，機會永遠只留給有準備的人。
帶著問題去學習：學習東西不能為了學而學，必須要有自己的目的，不然你都不知道你學習的邊界在哪裏了。從邊界這個角度出發，改Bug的邊界和重構的邊界，他們需要清晰的確定嗎？我的回答是，需要，特別需要。
每過一段時間，回過頭來看之前寫的代碼，一定會有想要修改的沖動，此時，絕對不能修改已經過測試的代碼，在既是優化改進不會影響到關鍵業務，也不要修改。取而代之的是，在收到新需求時，吸收舊代碼的經驗教訓，每次寫的比上次更好一些。
在同一個項目中，保持簡單一致性，如果使用printf+read/write，那為了規整，在該項目的其他地方保持一致。如果使用了c++的ios流，那麽也保持一致。
版本號管理小結
Windows風格的版本號一般形如A.B[.C[.D]]，其中，A為主版本號，B為子版本號，C為修正版本號，D為編譯版本號。
- 當項目進行了局部修改或者Bug修正時，修正版本號可加1；
- 當項目在原有基礎上增加了部分功能時，子版本號可加1，修正版本號歸0；
- 當項目進行了重大修改或者局部修正積累較多，導致項目整體發生全局變化，主版本號加1.
- 編譯版本號一般是跟隨編譯過程自動生成的，常見的有取當前svn的提交編號或則git的提交編號，便於跟蹤定位發布版本。
如果是較小的工具程序，可以只保留一份最新程序即可。
如果是跟隨主程序一同對外發布的小程序（比如升級程序、卸載程序、註冊程序等），則需保存歷史發布版本，以備查問題，自己的工程實踐目錄結構如下，可供參考：
---tools
------history
------------1.0.0.123(123為SVN提交編號)
-------------------a.exe
-------------------b.dll
-------------------c.pdb
------------1.0.0.124
------release
------------a.exe
------------b.dll
------ReadMe.txt對於對外提供的小工具，需要給出相關的使用說明，具體提供方式，可以是截圖+說明文字的方式，也可以是簡要的幫助文檔等，便於他人使用。
針對工具類小程序，每發布一次程序，都要寫好ReadMe.txt，作為版本發布記錄，該文件中大概有如下內容：
- 使用方法
- 程序維護人以及聯系方式（郵箱、電話等）
- 源代碼的SVN庫路徑、最新發布程序路徑
- 各個版本的更新記錄
開發小結-流程管理類-下篇