個人開發「五步曲」

　　開發過程當中，不免會遇到各種問題，現將我在工做中的開發流程整理成文分享給你們，拋磚引玉，但願能對你們有所幫助。

　　總體來說，個人流程爲五個部分，開發->自測->提交->上線->覆盤->...以此循環往復。

 

　　開發

　　當收到一個需求時，先充分理解需求，同時要對需求可能帶來的影響點有個大概的認知。與產品及相關測試進行溝通，羅列出功能點清單，有不肯定的點及時提出，並把最終理解好的需求與產品、測試複述溝通一遍，達成最終共識。

　　理解了需求後，可在草紙上畫出大體草圖或相關流程設計圖，原功能點是怎樣的，現需求如何，二者之間的異同點，調整後所影響的範圍；或者大體列列實現步驟，先XXX，再XXX，接着XXX，最後XXX，藉此把需求進一步理清楚。

　　實現同一需求，可能有多種實現方案。對於影響比較大或使用頻率比較高或改動範圍廣的需求動做，先找相關同事花幾分鐘討論並確立下技術實現方案，避免方向的失誤或在選擇那種實現方案上糾結過長。

　　肯定了技術方案，在時間緊迫的狀況下，可按照先正確快速實現，後調優效率的原則進行開發。

　　從線上（或已指定）分支最新代碼拉取一個分支，並通知相關協做開發夥伴及測試，你們在此基礎上進行相應的代碼開發。

　　開發過程當中，可善用IDE工具，譬如錯誤提示、代碼自動補全、查找替換、統一編碼格式等功能，減小初級問題的出現。

　　儘量按照通用的，你們廣泛承認的編碼規範進行代碼的書寫。能夠多借鑑下文檔或大廠寫的開源代碼； PHP 可參考看下 PSR 規範（https://www.php-fig.org/psr/），JAVA 可參考看下阿里新版java開發手冊-華山版；良好的編碼習慣須要不斷的自我訓練，屢次重複，慢慢造成習慣。

　　寫好註釋，重要邏輯或方法可寫下實現思路，並在適當的出入參節點或其餘重要節點，輸出日誌，方便往後定位排查問題。

 

　　自測

　　代碼完成後，對照需求文檔，進行自測。是否如實還原實現了需求？有沒有遺漏點？省得遺漏開發項。

　　對各個實現的功能模塊進行單元測試，查看常規參數、臨界參數的影響？正常流程化操做、跳躍性操做的影響？

　　先後端頁面配合，F12打開控制欄，進行相應的查看、修改、提交等操做，看看接口的傳參，請求方式，響應，展現，日誌的輸出等是否有異常？

　　切換不一樣的帳戶，查看是否有異常？

　　按照測試（功能）用例，測試一遍，查看是否有異常。

 

　　提交

　　對於本身目前所處的開發分支，多是多人協同，每次提交以前，先拉取最新代碼，再進行提交以免衝突。提交時，可藉助TortoiseGit軟件花幾分鐘進行提交文件的比對和校驗，避免少提交代碼或把不須要的代碼提交至遠程分支。本次不須要提交的，可暫時放在暫存區。

　　與相關開發及測試人員溝通能夠合併的代碼功能、時機和具體分支。譬如這個功能是本次上線嗎？何時能夠合併？能夠合併到那個分支進行測試環境的測試？提早把事情溝通清楚，避免把本次不須要的代碼合併錯，同時只需將本次須要的代碼合併到相應分支便可。

　　將代碼合併至測試分支時，先拉取最新的開發分支代碼，拉取最新的測試分支代碼，先將測試分支代碼合併至開發分支，若有衝突，解決衝突，合併完畢，本地進行預編譯，預編譯無誤，進行提交至遠程開發分支。切換至測試分支，拉取最新代碼（避免最近幾分鐘有人提交代碼），將開發分支合併至測試分支，（若有衝突，解決衝突，預編譯無誤）提交至遠程測試分支。

　　通知測試人員及協做夥伴，已將代碼合併並放在測試環境運行。

　　登錄測試環境，觀察頁面功能是否正常，查看相應功能點是否實現，非流程化操做的影響，切換不一樣帳戶，查看是否有異同。觀察相應的數據表數據變化及相應日誌輸出，對照是否達到預期。

 

　　上線

　　上線前：

　　根據前期功能的實現，概括整理，提早作好的相應調整。

　　數據庫、數據表的備份。

　　數據庫、數據表的結構調整，新增表，或者調整表。

　　數據表的數據調整。默認字段填充調整等

　　定時腳本的觸發，一次性腳本仍是循環腳本，觸發的機制（條件，異常補救措施）。

　　通知合做的相關業務部門或人員。

　　其餘須要作的操做等。

　　上線後：

　　線上環境的複查，頁面的展現，相關的功能點實現，log日誌的輸出及後期的用戶和數據反饋。

 

　　覆盤

　　對於本次開發過程當中遇到的問題進行分類記錄和總結，以便不斷的學習和成長。可根據本身的實際須要進行分類，個人分類是：

　　需求理解類

　　這個需求，和產品溝通了四個小時，依然沒有徹底理解產品的切實需求。

　　問題剖析爲溝通方向不對，不在同一頻道上。須要我不斷增強與產品的溝通，錘鍊溝通的技巧，提問的方式，回答的方式，明確要點，避免無方向的討論，儘早儘快達成共識，縮短溝通時長。

　　開發實現類

　　方案設計時的邏輯錯誤，流程錯誤，業務不熟悉，應用場景未明確，業務數據增量的影響，更新數據的前後方式等。

　　解決方法爲增強業務流程的學習，多多使用開發的軟件功能或產品，多與產品測試及業務合做部門進行溝通，加深對業務內容的理解和認識。同時不斷學習編程語言的設計及原理，提高業務水平和開發水平。

　　代碼規範類

　　沒有創建正確的索引方式，致使數據重複，或者查詢緩慢。

　　對於異常沒有捕獲，致使正常流程掛掉。

　　變量類型的定義不規範，異常參數引起異常數據。

　　一些方法函數的默認值。

　　方法的調用方式和時機條件。

　　查詢時的where條件及limit限制。

　　運行環境的差別。

　　...等。

　　解決方法爲能夠多多看看相應的代碼規範，模仿加練習，逐步養成規範，避免出現相似的問題。

　　其餘問題類

　　譬如難以預料的用戶操做習慣、環境、網絡，服務器供應商的限制等因素。開發實際遇到的問題千奇百怪，難以歸類的，都暫屬其餘。

 

　　雖然在開發過程種各類考慮周全、當心謹慎，依舊不免會出現其餘難以預料的問題；以上措施不是爲了杜絕問題發生，只是爲了減小問題發生。遇到bug，不要慌張，保持良好心態，分析解決加總結，找到本身能夠實施的模型，不斷完善及反覆訓練，以期達到最優效果。