互聯網公司做好需求的幾點總結

這些內容很早就寫在我的記事本上了,今天趁寫博客的機會總結一下。

互聯網公司後端開發的特點就是開發快、迭代快、上線快,以我來說一週平均有2~3個需求要上線,遇到大的活動期間還有大的需求。頻繁的迭代早期對我來說不是一件輕鬆的事情,稍不留神就會製造bug。有bug就要隨時隨地快速響應修復,有時甚至在跑步也要去修改bug。

如何寫出沒有bug的代碼成爲至關重要的事情,以更長遠的眼光來說如何能通過這種鍛鍊讓自己的編程思想和技術更加高效成熟,直至獨當一面。下面是我在近一年的時間裏思考和總結的相關經驗。

核心思想

痛苦 + 反思 + 執行 = 進步
快樂 + 反思 + 執行 = 進步

這兩句話是核心思想,製造出bug是一件讓人痛苦的事情,因此需要反思bug產生的原因,可能是需求不理解、業務不熟悉、測試不充分等。反思找到原因指定改進方法就是執行,形成一個閉環,逐步提高。
快樂也是如此,順利的原因是什麼,有什麼值得借鑑的經驗,利用好這些經驗能將事情做的更高效。

這兩句話不僅僅適用於做需求,也適用於生活中很多方面,生活更需要智慧。

工作中的案例

痛苦+反思+執行=進步
教資開營
痛苦:教資開營雖然寫了技術文檔,但是仍然有沒想到的bug產生,並且在早上被電話連環call,給我的心理留下了陰影。在這個需求中做的好的地方和不好的地方都羅列出來:
好的地方:寫了技術文檔,接口和定時任務都詳細羅列出來,避免了遺漏
不好的地方:沒有對整個需求的流程做一個流程設計。需求中涉及到開營狀態判斷,user_plan狀態修改的定時任務等沒有搞清楚,也就是對整體流程不清晰。這其實是一個非常忌諱的事情。做任何需求都是要先有一個全局視角的設計,然後再細節設計。先設計細節後全局往往會陷入細節陷阱。
執行:大需求一定要有流程設計圖,有全局視角

快樂+反思+執行=進步
14天打卡挑戰
快樂:14天打卡挑戰是對21天打卡挑戰代碼的重構,重構很成功,沒有出問題。
反思:吸取之前的經驗,從四個方面來做需求:1. 全局流程清晰;2. 拆解需求細緻,將需要替換的代碼都羅列出來 3.方便測試 4.多個定時任務不方便測試,多次自審代碼
執行:這次需求,定時任務和流程基本對半分。對於不方便測試的定時任務,都手動執行了代碼,也發現了數據類型的問題和code不對的問題。所以不方便測試的功能一定要手動執行驗證。

做需求的兩種層次

對於一個需求基本要求是準確無誤的實現,能做到這一點就不錯了。如果對自己要求更高就需要跳出程序員的身份,以技術負責人的角度去看待需求。

做好需求基本四點

  1. 全局流程技術方案,狀態隨操作變換,隨時間變化
  2. 將大需求拆解成小步驟,每一步都保證是正確的
  3. 技術設計上儘可能方便測試。測試做的好,壓力就減小
  4. 不方便自測的功能一定要自審代碼

出色完成需求四點

  1. 以技術負責人的態度去對待需求
  2. 從技術角度做到高質量,無bug
  3. 從技術角度可以快速迭代,兼容性和擴展性
  4. 從產品角度思考設計缺陷,能夠給產品提供建議

工作態度

  1. 對於別人交接確定無誤的代碼一定要自己確認一遍沒有問題。別人去年使用沒有問題,不代表今年使用沒有問題。對於別人交接的代碼永遠保持懷疑態度,並且不要偷懶不驗證。
  2. 對於發現異常的數據和異常邏輯一定一定要拋出異常,去檢驗異常,不能心存僥倖,心存僥倖的事情最終都會發生
  3. 任何沒有實現的需求都要告知需求方,心存僥倖的事情最終都會發生

對於工作態度,最重要的就是不偷懶。發現任何異常的情況都要及時搞明白,一個個小小的bug都潛藏在暗處,需要勤奮且細緻的coder找出來。這一點很重要,我製造的bug裏面,大部分都是完成需求時發現了異常且選擇忽視,最終都會被用戶反饋出來。

技術修煉

  1. 學習技術不要華而不實。先熟練使用,再探究原理,不能操作都不熟練就開始搞原理。不懂linux命令就開始看內核源碼基本上做無用功。
  2. 不要做伸手黨,不主動思考
  3. 代碼要自我review。review邏輯、review代碼規範、review代碼效率
  4. 定時覆盤總結,整理自己的核心規律 如何構建知識體系
  5. 擴大核心規律。從核心規律出發去連通周圍的知識,解決知識阻塞,融匯貫通。由點連成片,直到掌握整個項目,將認知提高一層

工作相關閱讀記錄

平時的工作如何體現一個人的技術深度?

  1. 從需求角度有沒有思考產品設計當中的缺陷,能不能反向爲產品設計提供建議
  2. 從技術角度能不能做到高質量高兼容性無bug,以及下次再有類似的需求能不能快速高效率的迭代

反思

當你自認爲已經做好整個流程的每一件小事之後,接下來可以通過深入細節,思考整個流程是否存在問題:

  1. 做需求過程中溝通協作的有沒有問題
  2. 流程規範的有沒有問題
  3. 機制環節哪方面問題
  4. 代碼公共基礎能力的是否有缺失
  5. 開發過程中你所遇到的問題是不是一個通用問題,能不能抽象出一個公共庫解決大家的問題
  6. 能不能制定一個SOP的解決方案流程,亦或是提煉出一個最佳實踐在組內外分享經驗

總結

故不積跬步無以至千里,不積小流無以成江海。先從做好每一件小事開始,把每個業務需求做到120分,深度思考,發現問題,解決問題,逐步建立起靠譜有責任心技術牛的人設,逐步負責有技術難度的事情。跟隨公司業務發展積累自己的業務領域經驗與技術深度,從而獲得雙贏的回報。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章