在作了一個月需求後的覆盤

前言

畢業入職後第二週，開始正式作需求，寫代碼，我有點坐臥不安的感受，由於真的要往一個真正的項目里加上本身的代碼，生怕本身搞砸了，寫的代碼上線後形成嚴重問題怎麼辦。

如今過了一個多月，需求也作了幾個了。有的很順利；有的延期；有的在測試階段 Bug 頻出，反覆修改；有的在灰度期間形成 Crash。如今回過頭來複盤一下，吸收其中的教訓，之後注意儘可能避免失誤。

腦圖大綱

注意事項

1. 擺正心態

首先明確一點是必須重視每個需求，不管大小，這是一個開發者素質的體現。可是一開始提到的緊張確實沒有必要，畢竟這是一個按部就班的過程，剛開始接觸的都是一些小需求，只是幾行代碼的修修補補，難度上不會很大。以後隨着對業務的熟悉，本身也能夠逐漸 cover 一些複雜的業務，這是一步步成長的，若是一直作小需求，反而本身也會以爲本身很不堪大用吧。把握好每一個需求，將其看成本身進步的途徑。

2. 仔細研究需求文檔

需求文檔是最重要的材料，一切的實現都要從需求文檔出發，不然就算的作的再牛逼，和文檔對不上，也是在作無用功。（至於以爲需求設計不夠好，想提供更好的參考意見，這實際上是應該在需求評審階段就提出來，和 PM 共同完善需求，在肯定以後，就必須嚴格按照文檔來實現）

在以前作需求的時候就出現過對文檔解讀不到位，在實現時本身想固然進行實現，好比埋點參數的值本身指定而沒有找數據分析師進行確認；在明知當前的設計沒有徹底符合文檔，可能會出現不一致的狀況時，沒有和 PM 確認，將風險移到了測試階段，增長本身需求的 Bug 數量。

因此說千萬不要想固然。在調研或者開發期間若是發現有和文檔不一致的狀況，不論是不是由於本身的因素致使（多是歷史因素），都須要及時和相關方進行溝通，明確最終方案。

3. 充分調研

需求到手後，在開發前會有一個調研估時的階段，剛開始的時候不太瞭解，接到需求就開始拉分支寫代碼。其實這是很沒有效率的作法，遇到複雜需求的時候最後也確定會出現不少狀況。好比發現估時太短，不可能作完，那可能就要加不少班來補充，甚至嚴重的會形成不能及時上車，需求 delay。充分的調研是很重要的一點。估時會反映出一個需求的複雜程度，以前接到一個需求，雖然需求不大，可是複雜度挺高，若是僅僅由於看上去的狀況估一個比較短的時間，那可能就會給本身形成不少麻煩。同時，估時要綜合考慮各類狀況，好比給埋點、自測留出必定的時間，提升本身的交付質量。

另外很重要的一點，在調研階段，必定要多查找資料，充分研究這個問題，將可能的坑都提早踩過去，將風險提早，不要把坑都留到開發的階段，否則可能會形成代碼編寫時很不順利，寫出不少 Bug。技術方案也要在調研階段就肯定好，編碼時有明確的方案，作到胸有成竹，總體質量就會好不少。

4. 開發：要有 Plan B 意識

在開發階段除了要遵循代碼規範，同時儘可能寫高質量的代碼，不要寫出來的代碼很難以理解，過陣子連本身也看不懂了。

另外，以前的開發給我最大的教訓是必定要考慮到 PlanB，分的細一點就是兜底策略和可降級方案。兜底策略針對小一點的場景，好比非空判斷等等，保證代碼的健壯性；可降級方案針對較大的場景，好比應用中引入了某一個第三方框架，不能一會兒就所有遷移，要有預防這個框架很差用時降級到一個保底的備用方案上來。AB 實驗中其實也有這種思想的影子，在出問題時能夠經過切換 AB 實驗，返回對照組，進行降級。前陣子有一個需求，顯示的文案是服務端下發的，在開發階段就沒有考慮到異常狀況，過度相信服務端的數據正確性，這樣是確定不行的，要保證本身代碼的健壯性，不能說服務器的數據不符合正確格式，應用就整個崩潰了。因此 PlanB 的意識是很是重要的，要時刻提醒本身，是否作好了兜底和降級。

5. 充分自測

開發過程當中自測也是很是重要的一個環節。若是自測不充分，就會致使交付質量不高，這樣一來本身在測試階段須要頻繁修改代碼、編譯、打包，過程很麻煩，作了不少額外工做，若是手上還有其餘需求也在進行的話，也可能對耽誤另外的需求開發。而且，若是交付質量太低，也會影響到 QA、Leader 對本身的一些見解，對本身的能力產生質疑，進而可能會影響績效等其餘東西。總之，咱們做爲一個合格的工程師，仍是要對本身有更高的要求，努力將交付質量提升，作一個靠譜的開發者。

所以充分自測就頗有必要了。首先，也須要以前的幾點注意事項來提供支持，在仔細研究需求文檔和進行充分調研後，在測試用例討論上，須要和 QA 一塊兒完善各類可能的邊界狀況和異常狀況，這樣在以後的開發中，也會更加註意這些 case，提升代碼的質量。而後在開發過程當中若是另外發現了一些異常 case 的話，須要及時知會各方，和 QA 同窗進行確認。以前也提到在估時階段須要給自測留出必定時間，保證本身可以充分測試各類正常和異常的 case，而且要重點關注各類邊界 case。

結語

以上五點就是我對這一個多月以來，所作需求的覆盤。但願本身在接下來作需求的時候，可以用這幾點來好好要求本身，努力提升交付質量，同時也不斷從各個需求中吸取，總結，提高本身的業務能力和編程能力。