在實際的工作中，一般來說，產品在召開需求評審會時，會邀請開發來參與評審，如果開發人數很多，往往只會邀請開發經理來參與評審，參與評審完後，由開發經理來分解模組，分配給相關的開發人員。這從產品需求到真正開發人員中間多了一道，會有需求資訊傳遞的損失，這是不可避免的。
產品在需求規格說明書上面進行的需求描述，是從產品的視角出發，通常專注於正常的業務流程，描述方式是從正常的使用者視角在正常環境下執行一趟業務流程，很有可能沒考慮錯誤情況和異常情況。如果涉及到的業務流程較為複雜，會附加上 程式流程圖 來幫助梳理理解，這沒問題。
小結：產品提出的需求是從正常執行的業務角度、使用者角度來提出需求。
在召開需求評審會時，要求開發經理和具體開發人員一起來參與，這樣可以減少資訊傳遞中的損失，提高溝通效率。
個人看法，程式設計師在開發的需求包含了產品提出來的需求，其範圍比產品提出來的需求要大。如果是不會思考的開發，只會一板一眼的按照產品提出的需求來做，那最後很有可能把自己給繞到坑裡面去。對於業務邏輯的 走向，誰有最全面的視角和理解能力呢？我覺的，應該是乙個追求卓越的開發。產品和測試都是從黑盒子的角度來看待程式執行，只有開發知道業務的每一步做了什麼，它的下一步做了什麼，最終表現的又是什麼。
產品對於異常和錯誤的處理，往往沒想那麼細，而開發實際上大部分在和錯誤和異常打交道，這個地方，個人覺得借用unix文化中的「提供機制而不是策略」這個角度來進行界定。產品人員需要提供業務流程正常或異常的機制，具體實現的策略由開發來決定，如果產品有相關的思考，可一起納入思考，如果沒有，則開發決定後將錯誤異常處理反饋給產品即可。
因此，程式設計師開發的需求，可以具體分為以下兩點：
經過具體開發人員過濾後的產品需求。具體開發人員在動手設計前，需要在心中走一片產品需求，發現有哪些不妥的地方，要及時和產品反饋，從專業的角度給出修改意見，反覆溝通數次，才完成過濾業務需求的這個步驟，這是在進行具體方案設計前必須做的，具體方案針對的一定要是經過過濾後的需求，而不能是原始的裸需求。
非業務需求：
2.1 復用性：當需要特定功能來實現需求時，一定要檢視當前工程中是否已有提供相關的工具類以及現有框架中業務流程。如果已有工具類，那就不要自己再造輪子。如果現有框架中已有通用的業務流程處理，而自己的需求是在通用的基礎上，增加自己獨特的部分，一般情況下，有三種處理方法：
上述三種方式，推薦第三種方式，通過訊息來解耦合。
2.2 內聚性以及可維護性
新功能的新增，要以不修改、不影響原有功能為前提條件（如果一定要修改，則要和上級一起來評估影響），在此前提條件下，相關類似的操作，一定要放到同乙個地方聚合起來，不要處理正確情況的**在a除，處理錯誤情況的**在b處，這樣不利於後期維護。
2.3 可讀性
團隊作戰，每個人都會遇到不好的**，或者是別人寫的，或者是以前自己寫的。在新增新功能時，如果是新建檔案，那麼一定要按照團隊最高標準來寫，如果是在已有檔案上修改，那麼只需修改與本次任務緊密相關的**可讀性，不要想著來個大招。藉著新需求或者改bug的機會，小步慢跑地來重構。如果在此過程中，發現別人寫的不好的地方，可以將相關的修改以patch的方式通知他人，而不是擅自修改。
2.4 效能
在一些重試場景下，要注意新增功能對系統整體效能的影響，不能因為新增功能的加入，給整個系統埋下了潛在的效能異常點。這裡舉以 「關聯賬號登陸重試」 例子介紹下：
應用背景：a賬號登陸成功後，底層會發起其關聯賬號a1的登陸操作，a1登陸狀態決定a賬號中某個子模組的可用性。在生產環境上發現，關聯賬號有一定機率會登陸失敗，會影響子模組可用性。
需求方提出：當a1賬號登陸失敗時，發起重試登陸，直到登陸成功。
開發分析：登陸失敗的原因有多種，比如超時，後台不穩定，後台處於不可用狀態等等，如果是因為非超時而重試，從業務穩定性上來分析，會給已處於不正常的後台增加增大的負擔。
最終流程：
登陸過程本身有乙個定時器來界定超時，當登陸超時發生，立即重發登陸請求。
如果是登陸失敗，則不再重試。
經過前面的分析後，那麼可以得知，開發實現的是兩方面的需求：
對於第一種測試，測試人員可以根據產品提供的需求檔案來提前編寫一些測試案例，然後在測試階段，按照案例來進行測試。
對於第二種測試，開發只有開發完成後，才能明確可測試點，需要對外提供該業務的業務流程圖，並標註一些可供測試的錨點。給出的錨點不會覆蓋所有的業務流程點，對於那些測試無法覆蓋的點，開發要自己保證這些中間狀態的流程正確性。
乙個需求的反思
在實際的工作中，一般來說，產品在召開需求評審會時，會邀請開發來參與評審，如果開發人數很多，往往只會邀請開發經理來參與評審，參與評審完後，由開發經理來分解模組，分配給相關的開發人員。這從產品需求到真正開發人員中間多了一道，會有需求資訊傳遞的損失，這是不可避免的。產品在需求規格說明書上面進行的需求描述，...
乙個奇葩的需求
今天和朋友聊天突然給我說拍一下錄取通知書封面，一解釋原因原來是小夥伴碰到了乙個奇葩需求。拍攝內容 錄取通知書封面 拍攝要求 1 拍攝角度在通知書正上方，通知書要是原來的形狀，不要產生形變。主要內容為通知書，通知書邊上留一部分空白 2 最好用相機，用手機拍的話發原圖 3 拍攝時在明亮處拍攝，同時通知書...
乙個MySQL死鎖問題的反思
很早之前我寫過幾篇關於mysql死鎖的分析，比如 但是感覺不過癮，而且分析的都是一些特定的場景，好像還缺少一些舉一反三的感覺，所以今天就補上這一波。mysql裡的鎖相容列表大體是這樣的關係，如果第一次看會有些暈，感覺抓不住重點，其實有一點小技巧。首先innodb實現了兩種類似的行鎖，即s 共享鎖 和...