三、編碼中
四、編碼完成及自測
五、提測
六、覆盤
經常性重複一些流程，時間久了就容易越過一些步驟。eg:
這些問題看起來都很「幼稚」，其實暴露的問題就是開發流程不規範；沒有良好的程式設計習慣。雖然不至於每次都按照list羅列的步驟去執行，但是很有必要把一些基本的操作內化成一種習慣，一種優秀的習慣。
誰最了解這個需求？我覺得未開發前是產品；開發完成後就應該是開發人員，而不是測試。
開發人員要理解需求文件，最好的方式就是多看幾遍，從技術角度思考能否實現？如何實現？
不侷限於只了解自己開發的部分，而是要了解自己做的功能的上下文；
理解的越透徹，提出的疑問就越多，越能盡快、盡早的暴露問題。我就經歷過幾次需求理解不透徹，立馬開幹，做到一半發現做不下去了的情況，然後改方案、返工…
是否能夠順利編碼的最重要、最核心的環節。
不要覺得寫文件是浪費時間，兵馬未動，糧草先行。想清楚了再做，想清楚了，寫**時間其實是很短的，前提是一定要多想。
我們開發前，一般都有對應的技術文件，維護再wiki中。這麼做好處多多：
1）梳理技術設計思路；
2）組織的知識資產；
3）把iso、cmmi等認證所需資料融入到日常開發中。
需要做到：
1、考慮每個技術細節和技術實現難易點、寫清楚實現流程；
2、別人根據文件即可順利開發；
3、這個過程盡可能多的提出所有疑問：針對產品的？開發的？測試的？ui的？
4、快速、高效的出設計文件。
原則上乙個設計文件再過完需求的2-3h之內出來。
leader分配任務的時候都要考慮開發時間。自己寫完設計文件之後，對開發時間應該做到心裡有數。如果leader評估的開發時間和自己心裡評估的開發時間有出入，要及時提出來。
基於哪個分支來拉分支，不要基於「髒分支」拉**。
多人一起合作完成功能時候，為了減少**衝突，及時commit，及時提醒隊友git pull，會減少不必要的merge。
當手頭要做的東西很多，要記住：拆！
拆成乙個乙個功能點，每做完乙個功能點，及時commit。每個commit都是乙個完整的、小的點。不要在乙個commit中包含多個功能，好處是：一步一步紮實的向前走，確保每個開發完成的就沒有大問題，這樣避免開發節奏混亂。
eg:
git commit -m "feat:首頁配置-區域化logo"
;git commit -m "feat:首頁配置-區域化標題"
;而不要一次性把這2個功能都開發完了一併提交。
~~git commit -m "feat:首頁配置-區域化logo、區域化標題"（不推薦！）~
~
這個時候及時反饋，尤其涉及到影響開發進度、開發思路的問題，及時組織相關人員討論。
個人習慣是，開發對應的功能時候就順手維護sql指令碼，而不是開發完畢一次性維護。
好處是：避免遺漏。
1）如果有精力，寫單元測試最好。因為可重複執行；
自測的質量直接決定提測的質量。這是對自己**的負責，也是節省測試人員的時間。節省別人時間就是對別人工作的尊重。
確保本次開發涉及到的相關指令碼都已跑；
確保**都入測試分支，jenkin部署不遺漏。
部署完畢，不要覺得萬事大吉，要去看看對應的功能是否如期出現，然後通知相關人員對接。
開發流程是否順暢？
下次開發同樣的功能？開發速度能否提公升？實現方法能有哪些改進與優化？
技術難點在**？
跟產品、前端、測試、開發人員溝通是否順暢？
良好的編碼習慣
1 以簡潔明瞭的方式編寫c程式。通常把這種程式編寫方法稱為kis 保持簡潔 不要用古怪的方式編寫程式。3 計算機和編譯器是很好的教員。如果對c的某個特點沒有把握，編寫乙個簡單的程式，然後編譯並執行它，看看會發生什麼結果。4 在每乙個函式的前面加上描述函式用途的注釋。5 執行列印操作的函式所列印的最後...
養成良好的軟體編碼習慣
最近在看 軟體開發沉思錄 這本書，感覺第六章物件健身操這篇文章總結的不錯。主要描述了在oo設計模式下的一些軟體編碼規範。在此我將這些軟體編碼規範分享給大家，希望在軟體編碼規範上能給大家起到一定的幫助。編碼規範內容如下 1 方法只使用一級縮排。2 拒絕使用else關鍵字。3 封裝所有的原生型別和字串。...
C 編碼規範2 良好的程式設計習慣
詞語選擇 避免使用由經常使用的命名空間複製的型別名。型別名不能使用下列詞語。system collections forms ui 識別符號 包括引數名 中不要使用縮寫。如果必須使用縮寫 任何超過兩個字元以上的縮寫都使用camel大寫格式，即使這不是標準縮寫。命名空間 命名命名空間的一般規則如下 c...