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

本文章主要聚焦在項目流程管理，彙總記錄一些工做中心得體會。

項目流程

流程體系旨在提升工做效率，明確流程接口和步驟，肯定相關崗位和相關事務要求、原則和規則。流程管理，簡而言之，就是各司其職，節奏合適。產品的需求和開發的Bug有工具跟蹤，軟件發佈按照節奏來，需求提交給具體開發前，須要和開發主管討論可行性，有專門的測試反饋和每日進度規劃。知道今天要作什麼，也知道明天要作什麼。

我的在開發過程當中，要提早計劃好要作的事情，在本身目前能力範圍內，作到目前的最好水平，保值保量。

開發流程

提出問題

當咱們發現別人代碼裏面很差的地方時，如何既能提醒別人，又不讓他人尷尬。做爲代碼當事人，面對對方挑錯時，正常的第一反應是：你在挑我毛病，我不接受。而受過良好訓練的人，會作到「君子聞過則喜,小人聞過則怒」.
我本身的心得時，經過qq或者其餘溝通方式，非實時的告知別人作的很差的地方，同時，給出改進的方向。

在與跨部門、跨地區同事進行溝通時，在正式開始溝通前，本身須要作一些準備工做，將問題域有關的背景狀況整理出來，發送給其餘同事，讓你們在後續的討論中有一個相同的上下文環境，在正式溝通中，按條理提出具體問題，對每個回覆的答案，本身內心要問本身，針對這個問題，我獲得滿意的答覆了嗎？如不滿意，及時提出反饋。

具體在給別人描述問題時，發現文字的表達力度不夠，通過一段時間的時間，發現將問題發生的現狀截圖下來，在一旁備註上必要的描述信息，圖文並茂，關聯信息聚合在一塊兒，便於對方迅速瞭解問題。

討論大問題時，要先對大問題進行分解，分解爲若干互相關聯的子問題，在提出討論以前，本身須要在腦子裏面過一片，哪些是這些問題鏈條的頭，先討論哪一個，哪一個有結論後能夠繼續下一個問題，直到全部問題，按照順序依次獲得確認。

對於一些更復雜的流程性問題，建議繪製流程圖來提出問題，根據流程圖的定位，能夠分爲概要設計流程圖和詳細設計流程圖，就溝通對象負責的層級，選擇不一樣層次的流程圖予以溝通應對。
下面經過一個例子來給出概要和詳細流程的區別。
例如，某種物品要進行賣出，賣出前要根據相關信息判斷是否有賣出的權限，若是可以賣出，接下來要作什麼提示和操做。

從概要流程出發，該問題就一個分支，「物品是否容許賣出」，從詳細流程觸發，物品在條件1或條件2，成立時是不容許賣出時，不一樣狀況的錯誤提示語是不一樣的，而其餘狀況是容許賣出的。

小結一下：概要設計、詳細設計是針對開發實踐來講兩個不一樣層面的流程抽象，咱們在一個層面上考慮時，不要過多考慮另一個層面的細節，不然，整個流程就會抓不住重點，既有概要過程、又有詳細處理，顯得冗餘繁雜。

討論問題

在同別人討論問題時，發現本身容易激動，很容易討論着，就把問題給帶偏了，原本剛開始在討論A問題，討論討論着，就跑向B問題，再討論一段時間，就忘記剛開始要討論的問題了。這個過程當中有須要改進的地方：

• 在討論的時候，要尊重別人的意見和見解，等別人把話說完，若是能夠的話，先複述一片問題，提出對別人的見解後，再就討論的問題給出本身的見解。若是中途本身嘗試打斷別人，必定要忍住這個衝動。

正確理解別人的前提是可以完整接收別人的信息，對於同一個問題或者說是概念，不一樣人有不一樣人的斷定是很正常的事情，同別人討論會多一些思考的角度，更加完善的看待事物。同時，要對本身有明確的認知，認知到本身在哪些地方存在不足，下一步往哪裏去提升。

記錄問題

在工做過程當中，有一些問題在qq羣裏面討論的，一位同事拋出一個問題，你們東一句、西一句的討論，不少時候，討論到最後，沒有一個最終排版確認的人，形成討論的不少，實際能落地執行的不多。當遇到這種狀況時，開發人員須要就問題域以及各方提出的意見方案，梳理彙總成郵件方式，召集有關各方一塊兒討論肯定，達成一致後，由產品人員在JIRA單記錄關於此問題的已確認的解決方案，而後再轉交給開發進行開發修改。這裏應該是有開發來主導的，秉承着誰開發、誰負責的原則，來主動推進。無論前期是如何討論的，一旦方案肯定下來，你們就要堅決不移的去執行。

若是是開發人員本身覺的有一些重構優化方面的需求，在動手以前，須要在JIRA上建一個優化需求單，限定好邊界，規定好內容，先交由上級審覈，審覈經過後再進行開發，這是事前告知流程。若是嫌每次重構都建單麻煩，能夠以先將本身每次待重構的修改整理爲補丁形式，和其餘同事一塊兒，選取一個集中時間，你們一塊兒過一片這些重構類的補丁，一致審閱經過後，再建JIRA單和提交到代碼庫中。

召開會議後，通常須要會議記錄人員作一個會議紀要，會後要求會議記錄人員將會議紀要已肯定達成共識的事項經過郵件羣發給參會人員，明確後一步的工做方向。

接到新需求

接收到新需求時的工做流程

在接收到產品人員的需求或者級要求時，在時間容許的狀況下，要主動詢問該項任務須要要作什麼，指望達到什麼樣的目標？對於一些尚不明確的地方，預備是如何處理的？要商量好總體業務流程和功能界限，討論清楚而且有合適的文檔指導狀況下，在進行後續的概要設計和具體編碼。

詳細閱讀需求文檔和原型設計圖，這些文檔每每混雜着業務背景、需求說明，與需求無關的一些信息，須要在開發前，將文檔中與開發、測試相關的功能要求抽取出來，彙總在獨立的文件中，以此文件做爲後續開發的參考文檔，當發現有不肯定的地方時，先分類彙總起來，獲得所有了解後，將這些不肯定的地方一一同產品人員確認.

做爲開發人員來講，不能生搬硬套產品提供的需求，要從本身的專業角度出發，對一些不合理的地方或者冗餘的流程處理給出本身的意見，對於一些有悖於通用性的流程和交互的地方，須要產品給出信服的理由來講服開發人員實施，產品是着眼於這個需求，而開發考慮的是總體交互的一致性，能統一處理的，最好統一處理。

簡化合並某些業務流程，甚至在產品需求的基礎上，提出更好的業務流程，也是一個專業開發人員應該要作到的。

當產品提出了看似很簡單，但確須要修改框架才能實現的功能時，開發要第一時間站出來提出質疑，儘可能引導產品提出在現有框架內可以實現的功能。在一個已經成熟的軟件產品上，進行框架級別的改動來知足某個蹩腳的需求，是具備極大風險的。有時候，寧肯不作，也不要作錯。

• 待實現功能的先後邏輯關係和一些限制性的要求等。
• 非功能性需求，好比UI、交互的一致性，錯誤處理等要一一確認。這些需求文檔通常不會給出來，須要在開發過程當中去產品人員討論後決定。
• 當前遇到的問題，以及對應的各類解決方法和對應的輸出結果。
• 異常狀況的處理
• 自測流程

在一個已有實現的基礎上進行新界面的繪製，修改的原則是：保留原有實現不變，不要在原有實現上面去修改，而是用一個新的實現來代替原有的實現。

在一些必需要公用修改的地方，好比顏色的取值之類的，若是新的修改會影響到舊的實現，那就要討論下，是用新的顏色段仍是修改公用的顏色段。

進度報告

對於開發量比較大的開發任務，須要較長時間才能所有，在向上彙報時，須要注意技巧，不要說還剩多少工做沒作，改成已經完成了多少工做。至於量化的進度，好比完成了50%、80%之類的，本身說出來都覺的不可信。本身接收前，要進行任務分解，有大至小，逐步細化，一直細化到可落地實踐的程度，以1，2，3，4，5這樣羅列出來，天天完成了什麼，就打上一個勾，讓上級知道工做進度，

換位思考，做爲領導，向下屬發出一個任務時，領導但願獲得什麼？我的認爲是但願獲得及時的反饋，不管是階段性的成果或者是遇到難題卡殼，及時，主動，條理清晰地向上級反饋工做，在實際工做中是很是重要的。

寫工做總結的時候，總體最好以總分總的形式排列，具體到各個分任務時，在內部也要遵循先總後分的原則，第一句話歸納提煉該段文字的中心思考。重點工做要重點描述，對於重點工做的斷定，起初我是這麼認爲的，本身在哪項任務上面花費了最多的時間，就認爲哪項任務是重要任務。通過同事的指點後，發現本身的這種認識是存在誤差的。重點的工做，不能僅僅從完成這項工做的時間長短上來判斷，而須要站在更高一層上上，從團隊職責、功能模塊層面去考慮。這種須要從具體功能點的編碼，上升到功能實現對外體現的價值上來。

在此以一個例子來講明：

好比，針對查詢頁面，完成的各頁面的拆分，列表支持穩定排序，表頭統一對齊，這些是很具體，很細節的工做，若是硬要從這幾項具體的工做中找出重要的工做進行描述，那每每會顧此失彼，抓不住重點。

解決方法是：站在更高一層上面去看待目前的工做，層級提升，就會缺乏對細節的描述，但會從一個更加高的視角去看待工做所在的意義。好比說，這些改動，從用戶的角度上來看，統一UI風格，優化用戶交互視覺體驗，具體包括查詢表的穩定排序、風格統1、刷新邏輯統一等。高層次的描述，須要具體層面的配合，才能更加有說服力，能夠配合一兩個具體的頁面來描述。另外一個視角是從開發上來看待，按業務拆分後，有效下降代碼耦合度，減小後期維護成本。

改Bug

整體原則

不要混合修改Bug和優化流程，這一次，又在這裏掉坑裏面去了，JIRA單分爲Bug單、新功能單和優化改進單。

每次提交代碼的範圍要最小化，一次提交解決一類問題，不要在提交中混雜其餘問題。

嚴格守好提交紀律，對於已經測試過的代碼，在沒有新需求或者新功能以前，必定不要去修改。

只有JIRA單流轉到我名下，我纔有須要去作，不然的話，別人口頭上一句話、或者QQ羣裏面的一切討論，無論有沒有最終定論，若是沒有反饋到JIRA單上面，就都不算數。白紙黑字寫下來的才行，口頭告知、或者羣聊天等，沒法明確留痕的討論，都不算數。不要別人一句話，本身哼次哼次的思索分析了大半天，結果別人又來一句，不用管了，那本身以前的心血就白費了。

當和別人共同修改一個問題時，JIRA單在別人名下，本身作的修改以及提交，要及時的更新到JIRA單上，以明確本身在此Bug解決過程當中所作的工做。

在改一個Bug時，不要僅僅侷限於當前這個模塊產生的Bug，想想相似的Bug，在工程中其餘地方會不會存在，若是存在的話，要一併修改，而且在JIRA單上註明修改影響範圍和測試建議。

具體到戰術層面上的，能夠分爲以下幾個方面去逐步思考，探究。

1. 分析以前寫的很差的地方，找出可能的隱患，總結出這個很差的地方全部可能的測試案例，有可能一些測試案例是測試那邊覆蓋不到的，或者說觸發此測試案例的組合條件很是隱蔽，難以觸發。

2. 分析如何修改，從這幾年的編碼經驗上來，對於最終的Bug表現來講，若從表現上逐漸深刻查找，每每會找到一系列觸發條件，最終有一個根條件，我稱之爲Bug觸發鏈,找到了該觸發鏈條，也就有了對應層級的修改方法，舉一個簡單的例子，好比說，因素A-->因素B-->因素C-->Bug現象，那麼解決方案能夠C層級上處理，也能夠在B上處理，也能夠在A上處理，具體在哪個節點處理，要看引入的處理會不會影響其餘正常業務邏輯，最好的狀態是，只修改了Bug，而對其餘業務沒有影響，這能夠稱爲改Bug的隔離性。若修改會對其餘業務流程有些許影響，那看該影響是好的影響仍是很差的影響。若是決定在這個層面上修改的話，無論是好的影響仍是很差的影響，都要分析清楚利弊，同產品和測試人員溝通好後，再行動手修改，同時在提交Bug的備註信息上面進行詳細的說明。

3. 在具體動做編碼以前，要評估開發的時間。評估開發時間，是一個技術活，這不是說完成有多難，而是評估的準確度。
   就一個顯示用戶資產總覽的需求來講：通過前期任務分解，有以下子任務要完成：
4. 完成6條基礎數據指令的收發
5. 完成界面搭建
6. 在界面上測試基礎指令，封裝基礎數據
7. 同前端網頁聯合調試
8. 處理異常狀況，好比頁面重入、請求失敗、切換帳號請求、請求回來前關閉窗口等等

9. 優化代碼效率，好比增長緩存已減小請求次數，優化業務邏輯，合併錯誤處理等。

具體操做

接到Bug的，首要任務是重現它。在改 Bug 的過程當中，要定位是哪一行是形成該 Bug 的關鍵行或者關鍵塊？努力作到在不改變原有業務邏輯的基礎上改對Bug。

在進行分支Bug的修改時，通過生產實踐，討論的流程以下，你們一致在主線分支上開發，當開發到合適時候，拉出發佈分支，
好比V0.1，在此分支上面修改Bug，待到V0.1分支調整到一個較爲穩定的、可發佈的狀態，就能夠對外發布了。當V0.1分支正式發佈後，將在V0.1分支上作的修改，逐個merge到主線分支上，這種方法較繁瑣，但能夠保證提交到主線上面的修改能夠對應到每個Bug單。

在分支上，只作修改Bug，至於優化改進類的操做，建議在主幹分支上去作。

實現一樣一項功能，有的開發20行能解決問題，有的只須要10行，結果都是實現了功能，只不過一個效率不是那麼的好而已，項目組若有條件，可在開發和測試之間，若是條件容許的話，增長一個開發審覈的流程，由高級開發人員審閱檢查本次Bug提交狀況，而且提供思路和實現上的優化意見，有助於增強開發質量，下降Bug的打回率。

提交Bug規範

提交Bug的備註格式要統一科學的格式說明，目前工程中用到的格式以下：

Bug備註信息：

Bug單號：問題單號以及對應的標題描述，例如：JIRA-1000, 用戶在wifi狀況下登錄會失敗
修改版本：V1.0
問題緣由：描述問題產生的緣由，儘可能以精簡的語言描述
修改方法：用簡練的語言描述出來,文字要有先後的邏輯關係，好比，點擊刷新按鈕時，重置提示語、清空列表數據和緩存數據，滾動條復位。
影響範圍：以功能模塊或者頁面展現爲單位來描述，可以具體到特定業務模塊的，最好具體到特定業務模塊。好比一個功能模塊XXX，下面有子模塊A、子模塊B和子模塊C，這次                 
         修改影響到了子模塊C，那麼在這裏最好寫影響了功能模塊XXX中的子模塊C，而不能只寫影響了功能模塊XXX，給測試人員帶來了額外的測試負擔。
測試建議：若是Bug表現很簡單，那麼此處能夠寫略，若是Bug表現的背後業務邏輯不少，那麼有必要業務邏輯經過1，2，3，4的流程列舉完整，列出這次改動的影響到的執行
        路徑（即便是調整了下原有路徑的命令規範等也在影響範圍內），一方面，要寫修改點的影響，另外一方面要寫，該修改點所涉及到的界面的相關功能(包含修改點涉及到的功能以及未涉及到的功能)

Bug備註要簡潔精煉，想明白才能寫清楚。

寫Bug的問題緣由時，要儘量減小閱讀者的知識依賴，讓看到這個Bug的人員看一眼就能瞭解該Bug的來龍去脈，不要想固然的認爲測試人員已經知道本身明顯知道的上下文背景知
識。沒有上下文的Bug描述規範，不是一個好的描述。想清楚問題的起源，闡述清楚問題的表現以及解決方法，是一個很重要的能力。

在一次提交中的全部涉及到的文件修改的內容和現有的說明，都要在JIRA備註裏面寫清楚，讓測試人員和產品人員知道。
改一個Bug，若是是單單針對這個頁面的Bug，改正很容易，但若是想要改正通用的，讓全部人都滿意，那很難。
凡是改Bug，就要限定修改的範圍，同一類型的問題，在其餘界面每每都存在，限定修改和測試的範圍，讓各方人士統一目標。

在寫Bug描述時，千萬不要使用程序中的代碼，而要使用和代碼相關聯的界面顯示元素，由於測試在看這些描述時，是不知道你寫的代碼是什麼意思，他們只能看到界面，使用於代碼相關聯的界面元素，方便測試理解改動給界面帶來的影響。

有時候的Bug修改，可能既改對了當前JIRA單上面描述的問題，又改對了以前測試沒有發現的問題，對於這樣的修改，在備註裏面要註明清楚，修改後，一併改正了一個還沒有被測試發現的問題。
若是你的修改涉及到其餘分支上的修改，無論涉不涉及到具體執行邏輯的修改，只要對其餘分支路徑形成影響的，都應該寫相關的分支的測試案例來進行覆蓋測試，已確保本次修改未影響其餘分支邏輯。

提測格式：

提測版本：X.XX.XXX
版本路徑：\\XX\\XX\\XXX
提測內容：
測試建議：
請安排測試！

通常來講，一個Bug可能會通過兩三次反覆修改後，才能算是完完整整的解決了，此處以提交2次代碼解決了一個Bug爲例子，在第二次提交時，提交的備註要緊跟第一次提交到備註後面，關聯上SVN提交編號和對應的Bug單號，有助於從代碼回溯找到對應的Bug單。

Bug思考

對待一個Bug的見解，能夠從Bug自己出發，哪裏有問題就改哪裏？這是第一種狀況。

第二種狀況是，不只僅着眼於Bug自己，圍繞着這個Bug的相關流程，是否是有問題？

這裏指的有問題，指的是含雜了無關的、說不清道不明的業務邏輯代碼。或者是原本須要自身來處理，卻交給外部來處理的地方。在這種狀況下，與其在已有基礎上修修補補，還不如總體重作，保持以前同樣的接口，內部實現邏輯徹底重寫，向着最優、最簡的路線走上去。

每一種正確的改Bug方式都是各有利弊，沒有最好，只有最適合。

修改代碼保持謹慎，對別人的代碼保持敬畏。

改Bug有一個驅動原則：無Bug單，不要提交代碼，能夠先在本地作一些簡單的修改測試，但直到有任務單，纔去提交代碼，凡事可能影響其餘路徑的，那麼必定會影響，要依賴完善的測試來覆蓋改動影響。。

修改的層級性，好比，來了一個Bug，通過初步分析後，發現只須要改動一處代碼便可解決此Bug，此時爲「Bug修改」，但改正這裏，可能和前面的已有代碼有重複，所以，可繼續進行相關的邏輯合併修改，造成第二份修改，造成「優化修改」。

在提交時，就有多種方式了，具體哪種方式更好，各有各的場景吧。

方式一：只提交「Bug修改」

方式二：將「Bug修改」和「優化修改」，做爲總體，一次提交到代碼庫，此處的優化修改，很容易，也能夠說是必定會有 超出範圍的修改，好比說，那個變量名看着不合適了，哪些重複的邏輯須要合併了之類的

方式三：區分提交「Bug修改」和「優化修改」，分兩次提交到代碼庫。

從開發目的來看，全部的開發工做，均可以彙總爲三點：改Bug，新功能和重構。

• 改Bug期間，測試提JIRA單或者本身發現Bug來驅動，目標是改Bug，因此你的修改着力點就是改Bug，即便看到了一些特別容易重構的地方，只要和當前Bug不是緊密相關的，不要貿然去重構，讓改Bug的改的純粹些。

• 增長新功能期間，又可細分爲兩種，一種在已有實現上增長新功能，另外一種是另起爐竈，開發新功能。第二種方式毋庸置疑，第一種方式，也不要想固然的擴大修改範圍，將當前的精力聚焦在增長新功能上，小的重構手法可使用，不要貿然實施大的重構手法。

• 重構開發，若是是單純的重構開發任務，那麼要聚焦優化範圍，一次只提交一種類型的重構改動，保證每次提交的功能一致性和可測試性。