上一篇博文寫到了要編寫適合測試的代碼，后來幾天又深入地思考，重新梳理下一些不清晰的概念點。

產品提出的需求是什么

在實際的工作中，一般來說，產品在召開需求評審會時，會邀請開發來參與評審，如果開發人數很多，往往只會邀請開發經理來參與評審，參與評審完后，由開發經理來分解模塊，分配給相關的開發人員。這從產品需求到真正開發人員中間多了一道，會有需求信息傳遞的損失，這是不可避免的。

產品在需求規格說明書上面進行的需求描述，是從產品的視角出發，通常專注于正常的業務流程，描述方式是從正常的用戶視角在正常環境下執行一趟業務流程，很有可能沒考慮錯誤情況和異常情況。如果涉及到的業務流程較為復雜，會附加上 程序流程圖 來幫助梳理理解，這沒問題。

小結：產品提出的需求是從正常運行的業務角度、用戶角度來提出需求。
在召開需求評審會時，要求開發經理和具體開發人員一起來參與，這樣可以減少信息傳遞中的損失，提高溝通效率。

開發開發的需求是什么

個人看法，程序員在開發的需求包含了產品提出來的需求，其范圍比產品提出來的需求要大。如果是不會思考的開發，只會一板一眼的按照產品提出的需求來做，那最后很有可能把自己給繞到坑里面去。對于業務邏輯的 走向，誰有最全面的視角和理解能力呢？我覺的，應該是一個追求卓越的開發。產品和測試都是從黑盒子的角度來看待程序運行，只有開發知道業務的每一步做了什么，它的下一步做了什么，最終表現的又是什么。

產品對于異常和錯誤的處理，往往沒想那么細，而開發實際上大部分在和錯誤和異常打交道，這個地方，個人覺得借用Unix文化中的“提供機制而不是策略”這個角度來進行界定。產品人員需要提供業務流程正常或異常的機制，具體實現的策略由開發來決定，如果產品有相關的思考，可一起納入思考，如果沒有，則開發決定后將錯誤異常處理反饋給產品即可。

因此，程序員開發的需求，可以具體分為以下兩點：

經過具體開發人員過濾后的產品需求。具體開發人員在動手設計前，需要在心中走一片產品需求，發現有哪些不妥的地方，要及時和產品反饋，從專業的角度給出修改意見，反復溝通數次，才完成過濾業務需求的這個步驟，這是在進行具體方案設計前必須做的，具體方案針對的一定要是經過過濾后的需求，而不能是原始的裸需求。

非業務需求：
2.1 復用性：當需要特定功能來實現需求時，一定要查看當前工程中是否已有提供相關的工具類以及現有框架中業務流程。如果已有工具類，那就不要自己再造輪子。如果現有框架中已有通用的業務流程處理，而自己的需求是在通用的基礎上，增加自己獨特的部分，一般情況下，有三種處理方法：

• 自己的業務類重載基類通用處理虛函數，先調用基類通用處理流程，再進行特有業務的處理。
• 在基類通用處理中加上一個虛函數鉤子，默認實現為空，在派生類中的虛函數中實現特有業務處理。
• 如果基類在通用流程處理完有對外發通知的動作，那么派生類可以訂閱該通知，在相應的響應中做處理。

上述三種方式，推薦第三種方式，通過消息來解耦合。

2.2 內聚性以及可維護性

新功能的添加，要以不修改、不影響原有功能為前提條件（如果一定要修改，則要和上級一起來評估影響），在此前提條件下，相關類似的操作，一定要放到同一個地方聚合起來，不要處理正確情況的代碼在A除，處理錯誤情況的代碼在B處，這樣不利于后期維護。

2.3 可讀性

團隊作戰，每個人都會遇到不好的代碼，或者是別人寫的，或者是以前自己寫的。在添加新功能時，如果是新建文件，那么一定要按照團隊最高標準來寫，如果是在已有文件上修改，那么只需修改與本次任務緊密相關的代碼可讀性，不要想著來個大招。借著新需求或者改Bug的機會，小步慢跑地來重構。如果在此過程中，發現別人寫的不好的地方，可以將相關的修改以patch的方式通知他人，而不是擅自修改。

2.4 性能

在一些重試場景下，要注意新增功能對系統整體性能的影響，不能因為新增功能的加入，給整個系統埋下了潛在的性能異常點。這里舉以 “關聯賬號登陸重試” 例子介紹下：
應用背景：A賬號登陸成功后，底層會發起其關聯賬號A1的登陸操作，A1登陸狀態決定A賬號中某個子模塊的可用性。在生產環境上發現，關聯賬號有一定幾率會登陸失敗，會影響子模塊可用性。

需求方提出：當A1賬號登陸失敗時，發起重試登陸，直到登陸成功。

開發分析：登陸失敗的原因有多種，比如超時，后臺不穩定，后臺處于不可用狀態等等，如果是因為非超時而重試，從業務穩定性上來分析，會給已處于不正常的后臺增加增大的負擔。

最終流程：
登陸過程本身有一個定時器來界定超時，當登陸超時發生，立即重發登陸請求。
如果是登陸失敗，則不再重試。

測試測試的需求是什么

經過前面的分析后，那么可以得知，開發實現的是兩方面的需求：

• 經過開發過濾的業務需求
• 開發具體實現的流程

對于第一種測試，測試人員可以根據產品提供的需求文件來提前編寫一些測試案例，然后在測試階段，按照案例來進行測試。

對于第二種測試，開發只有開發完成后，才能明確可測試點，需要對外提供該業務的業務流程圖，并標注一些可供測試的錨點。給出的錨點不會覆蓋所有的業務流程點，對于那些測試無法覆蓋的點，開發要自己保證這些中間狀態的流程正確性。

轉載于:https://www.cnblogs.com/cherishui/p/9914144.html

總結

以上是生活随笔為你收集整理的一个需求的反思的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。