開發小結-流程管理類-下篇

改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.1 是否高頻（例如天天5次）
   1.2 是否高危（影響範圍較大）

完整的場景是如何的，本次變動屬於哪一個環節，須要知足什麼樣的條件？上線後如何確認功能是否正常

1. 影響範圍分析：
   2.1 影響哪些系統
   2.2 影響哪些功能
   2.3 影響哪些部門

越是臨近發佈時點的修改，越是嚴格控制修改影響範圍，想清楚了再去作。

假如不能評估修改的影響，寧肯不改，也不要亂改。與此同理，假如基於目前的開發進度，不能去評估完成一個新功能的工期，或者說很難去評估的準確，那麼在本身的心理預期上乘以2倍或者3倍。當碰到解決不了的問題時，在本身在嘗試了多種解決方法後，及時反饋上級，請求更多資源協助。

開發回顧

每作完一個功能模塊，要進行復盤，梳理回顧在實施過程當中，有哪些作的好的地方，哪些作的很差的地方。
對於剛開始着手作這個模塊時的一些工時預估，難度的預估，溝通的預估，和真正完成這個模塊後的實際估計，看看本身哪些預估是正確的，哪些預估是誤差較大的，若是誤差較大，回顧本身在開發時的工做狀態，看是哪個節點上卡殼，致使工期延長，仔細分析緣由，有多是其餘人員的接口配合，後臺的數據配合，也多是本身預估的太樂觀等等，開發是在不斷迭代進化的，及時的覆盤，對完善自身，提升自個人項目管理能力大有裨益，切記，切記。

1. 對工做崗位負責
2. 當在工做時，就要在規定的時間內，全神貫注的工做,哪怕事情再多，也要一件一件地進行，作完一件事情再作另一件事情。當在休息時，就必須徹底休息.
3. 及時作好自我檢討,記錄在開發過程當中的心得體會，以便在下一次任務來臨時，可以精益求精，不斷進步。
4. 留給本身必定的思考時間，在真正着手開始幹活以前，在腦海裏面梳理一片 要解決的問題是什麼，該如何作，怎麼作才能更好，想清楚，畫出來再動手。
5. 失敗後不要找藉口,失敗就是失敗，沒什麼好推脫的，哪怕原定計劃由於不可抗因素破壞而失敗，不要說由於這個那個，找緣由比抱怨更好。從失敗中去找緣由，記錄這個緣由，在下次作相似決定以前，回顧下本身失敗的緣由。由於一旦你爲本身的失敗找了藉口，那麼下次失敗還會再找藉口，到最後，整個項目都會失敗的。

心態管理

公司不是學校，公司支付你的薪水，不是讓你深造技術，而是但願你替老闆解決問題。在業餘時間，你能夠探究喜歡的技術，但一旦到了工做場合，你就應該思考如何高效、準確、敏捷完成產品提出的需求，不管這個需求有沒有技術含量，若該需求的實現會破壞現有的架構，那麼從實施成本和收益上作出本身專業性的判斷。

除了專業技術的進步，業務規則和業務流程也須要關注，多思考新技術與既有業務的結合點，經過代碼評審、技術分享等提升其餘成員的技術能力。若是能作到這一點，相信你會迅速成長爲團隊骨幹。

分支管理

現有的開發實踐中，採起開發分支和發佈分支雙線並行的模式。平時，你們都是在一個開發分支上工做，當項目須要對外發布版本時，從開發分支中拉取一個分支當作發佈分支（例如V1.0），後續發佈版本的需求和Bug修改均在V1.0分支上完成，測試同事也在發佈分支上工做。
越是臨近發佈節點時，對發佈分支上的改動越是要謹慎，改動範圍能小則小，不是萬不得已的修改，儘可能不要提交。若有一些牽一髮而動全身的修改，會形成迴歸測試壓力過大，延誤發佈時機。待到發佈分支逐漸穩定後，達到能夠發佈的狀態，等發佈上線後，再由各個開發人員將各自在開發分支上的提交逐次合併到主線分支上，你們繼續開發下一個版本。

對於已經發布出去的版本，對應的代碼庫應該設置爲禁止提交，要完整保留髮布時的代碼庫以及相關的調試信息，這有助於分析已發佈版本的問題。

針對開發和發佈分支雙線模式，個人習慣是，在本地建開發分支，重構分支和發佈分子。新功能開發在開發分支上作，改Bug在發佈分支上作，及時合併會開發分支。在重構分支上，作一些重構性的工做。三個分支各司其職。

每次提交做爲一個最小完備的功能集合，目的惟一性。若是有些功能的實現涉及到多處改動，那麼須要有計劃、有意識地去劃分一個大功能的各個子功能，每次提交一個明確的子功能，由此逐步構建一個大功能。

在平時的工做任務安排中，需分清輕重緩急，必定要把本身手上現有的Bug都處理完後，纔去作本身任何合適的優化和重構工做，千萬不要自覺得是的作一些感動本身的事情。完成公司的任務是第一要緊的事情，是首要要解決的事情。

時間管理

在新接收到一個需求時，分配到 需求分析、設計、實現和自測上面的時間安排，推薦爲4:3:2:1

爲何這麼分配時間呢？通過屢次工做實踐得來的。當需求不明確，那麼關於這個不明確的地方，怎麼開發都是不合適的，爲了解決因需求不明確致使的後續設計和實現階段的返工，在需求分析階段，須要根據需求畫出本身理解的 用例圖、狀態圖和主要流程圖等。這些圖是需求自己所涉及到的，在一個系統中，這個需求實現的功能和其餘功能是有關聯關係的，好比說彈出非模態框，若是程序中已有一些彈出非模態框的部分，新增的功能也要彈出非模態框，那麼這兩個功能就有先後的關聯了，是同一時間只出現
一個，仍是先後依次出現，後出現的覆蓋前面出現的，仍是新增功能的框始終在頂部，其餘框在後面，等等涉及到與已有實現的關聯關係，這些都須要進行額外的確認。
產品人員給出的需求，很大程度上，不可能考慮全部與之相關的其餘對象的交互，而在總體行爲上，該框的出現，影響了什麼，只有到開發階段才能發現。

引入第三方庫

對於引入的第三方代碼，必定要所有吃透，或者說是對可能的異常進行捕獲處理（緩衝區溢出沒法捕獲）。

要不要引入一些 難以維護的第三方代碼？或者說，在引入第三方代碼時，須要注意些什麼？

1. 看應用場景。
   若是是關鍵路徑上的關鍵應用，對於引入的第三方，務必要徹底吃透。這裏吃透的意思指的是，不光是看它可以實現什麼，更重要的是看它沒能實現什麼,後者每每在業務中是很重要的。它不能作什麼比它可以作什麼更重要。

若是是非關鍵路徑上的應用，對於第三方要進行本身的封裝，而且儘可能少用第三方的高級功能，而是本身經過簡單功能來組合實現。

1. 考慮引用第三方庫的一些負面效應
   好比，第三方庫使用的 運行庫配置 須要和調用方保持一致，這可能會影響主工程的相關配置。
   商業提供的第三方庫支持，若有必要引入，則能夠引入。
   對於開源的第三方庫，有幾點須要考慮的地方：
2. 是否一直有技術支持
3. 文檔是否齊全
4. 使用之後，組內是否有人可以hold主，若是hold不住，果斷放棄，找一個能hold主的
5. 該第三方庫是否有其餘公司在使用，是否有經驗能夠借鑑
6. 社區是否活躍

在調用第三方服務時，要時刻保持懷疑態度，不能由於第三方的緣由，而拖垮本身的服務，作好超時機制以及重試機制的處理。重試機制要合理設置，如果由於是業務致使出錯的，在UI上面要作好控制，防止用戶重複操做。如果由於網絡緣由致使的，則須要選擇合適的超時策略和提示機制。

任務管理

一個大的任務每每能夠細化爲幾個子任務，設定規劃好子任務的目標和時間安排，分派子任務給其餘人員去作。

本身在工做時，討厭別人在旁邊指指點點。這一點，做爲幹活的人和指導的人，都是同樣的。幹活的時候，不喜歡別人對本身的工做方法和工做流程的指點，而人人都有一種好爲人師的心態，在看到別人低效的工做方式，每每會忍不住去說兩句，起到興頭上面，還會主動出手去幹預，糾正。

對於指導者來講，這好像是一種經驗上的優點帶來的心理愉悅感，而對於被指導者來講，這像是在被打臉，心裏深處有一種壓迫感和強制打斷感，每每會引發厭惡
即便這個時候給出的建議的確是有效的，可是也每每帶來不了切實的效果，別人仍是用他一套舊的方法。

提意見的方式很重要，基於上述的考慮，結合本身看的書籍，得出了幾點心得：

1. 在本身工做或者幫別人幹活時，先聽清楚別人的需求，而後說，我在幹活途中，請不要打擾我！每個小的階段，我幹好了，會主動給你看階段性的成果。
2. 在別人正在幹活時，即便別人的工做方式不切當，千萬不要當場指出，而是在內心或者找個東西記錄一下低效工做的步驟，
   重點分析在哪幾步耽擱了時間，就像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，做爲版本發佈記錄，該文件中大概有以下內容：

1. 使用方法
2. 程序維護人以及聯繫方式（郵箱、電話等）
3. 源代碼的SVN庫路徑、最新發布程序路徑
4. 各個版本的更新記錄