編碼規範 -- 如何應對需求變更
如何應對需求變更
現在的程式設計師為什麼這麼累，其實很大程度上來說是加班原因使編碼質量佔了大部分因素，但是不少同學都不認為是程式碼質量導致的加班，都認為是不斷的需求改動導致的加班。但是話又說回來，誰的需求不改動啊？不改動的能叫需求嗎？
先看個程式設計師的段子娛樂一下
客戶被綁，矇眼，驚問：“想幹什麼?” 對方不語，鞭笞之，客戶求饒：“別打，要錢?” 又一鞭，“十萬夠不?” 又一鞭，“一百萬?” 又一鞭。客戶崩潰：“你們TMD到底要啥?” “要什麼?我幫你做專案，寫程式碼的時候也很想知道你TMD到底想要啥!”
有沒有可能存在明確的、不再改動的需求呢？其實很難的。以前很多公司是採用瀑布開發模式，需求階段時間較長，需要輸出完整的需求規範，還要評審幾次然後才進入開發，這個時候，需求變更就比較少，但還是有；後來漸漸地公司都趕時髦改成了敏捷開發模式，文件大量簡化，於是需求沒有考慮清楚就開始開發，需求是邊開發邊變動。敏捷開發模式間接變成了坑爹的加班開發模式。
關於需求變動，不同的角色定義很不一樣。BA覺得這個改動很正常，開發人員覺得就是個需求變更，兩邊各執一詞，這種矛盾長期存在。
下面列舉幾種場景，大家覺得算不算需求變更？
- 刪除物件功能
一開始只能建立者刪除，後面變更為管理員也可以刪除，再後面變更了某個角色也可以刪除。
- 配置功能
一開始使用xml配置，後面修改為json格式，又或者修改為使用資料庫配置。
- 匯出功能
一開始匯出為excel格式，後面變更為匯出json格式或者pdf格式。或者一開始匯出20個欄位，後面變更為匯出30個欄位。
這些當然都是變更了，但這些真的就是我們加班加點的原因嗎？！我們就沒有辦法只能任人宰割嗎？！而我的觀點剛好是，正是因為需求變更不可避免，所以我們才更應該把程式碼寫簡單，以對付各種各樣的需求變化。有以下幾點心得建議：
把程式碼寫到最簡單
最起碼的要求，重要程度不言而喻。改1行簡單程式碼和改10行復雜程式碼，工作量能一樣嗎？！測試一個20行的函式和測試一個2行的函式工作量能一樣嗎？！ 好比一個房子，你打掃的乾乾淨淨收拾得井井有條，將來房子裡面的東西搬來搬去都比較簡單；但如果你的房子垃圾堆一樣，走進去都難（程式碼無法看），就更加不用說把東西搬動了（改程式碼）。
把可能變化的封裝成函式
請閱讀：函式編寫建議。很重要的習慣，多思考多抽象和封裝，小變更將無法傷害到你。主動思考，主動思考將來可能的各種場景。其實這個不難，你只要有這個意識就成功了一大步。
先做確定的需求
多個功能中先做不會變的功能，一個功能中先做不會變的部分，兵法中叫攻其必救之地。你要知道哪些需求是所有人都明白看上去就很合理的需求，就先開始做，你覺得有爭議的需求你可以放後面一點。同樣，一個功能中你要知道哪些會變的，哪些是不會變的，不變的先做。
需求實現先後順序應該難的/確定的先做。先做難的是需要把週期拉長，更多的時間設計；先做確定的是為了避免頻繁的改動。
舉例：每個系統都有匯出功能， 我們實現功能之前，先要考慮哪些功能是確定的，哪些功能是很可能變化的？簡單分析之後可以知道，從資料庫庫查詢出來然後處理包裝資料這是肯定要做的而且不會變的，這個應該先做；而匯出為什麼格式（xls還是pdf），匯出的具體完整欄位，欄位的格式如何展示這些是會變的，這些你開始甚至都不需要仔細看需求，等要做的時候在確認可能需求都有不同的變化。你完全可以邊做前面確定的匯出功能邊確認其他的細節，確認需求的時間越多，需求就越清晰，變更的概率就越小。
多個功能中，我的習慣是先做最難的功能，最少要開始設計和思考，拉長功能開發週期。有些同學喜歡先做簡單的，導致難的問題開發週期不夠，後面加班加點也解決不了。加班其實是解決不了太多問題的。
拖延症的一個好處就是，很多需求拖著拖著就不用做了，因為提出人發現了這個需求的不合理。所以先做合理確定的需求。
解耦！解耦！解耦！
個人認為， 解耦是程式設計裡面重要的思想， 解耦的關鍵在於：多引入“第三者”，不要直接發生關係 。spring的IoC最重要的價值不就是解耦嗎？spring的容器不就是“第三者”嗎？就像mvc一樣，資料和檢視要徹底的分離，否則業務程式碼裡面有檢視程式碼改起來是很痛苦的。
在上面的配置規範
裡面的舉例，bean的定義就是第三者，就是為了解耦。如匯出功能裡面，也要有中介。不要把查詢資料，處理資料和匯出資料都在一個函式一個迴圈裡面做了。否則匯出格式由xls改成pdf的時候，你相當於重寫做了一遍功能。jms這些基於訊息的都是解耦的思想，架構設計上要多用這些鬆耦合的設計。
資料結構上要考慮擴充套件
由於是牽涉到表設計的時候，大家都知道改表結構很痛苦。很多時候，由於時間關係，一開始只做簡單的功能，後面會慢慢豐富功能。這雖然不是變更，但是如果你一開始的時候不設計好，很可能後面版本需要大改動，資料庫表都要推倒重來，比全新做還痛苦，相信大家會有體會。所以， 作為開發組長，做任何一個功能都要想到將來的發展，功能現在可以不做，但必須對將來的變化做到了然於胸 。
我舉幾個例子。
下載功能
工作量問題當前版本只需要顯示總下載量。你要考慮將來會不會要列出所有的下載過的使用者？如果不需要，可能用一個欄位記錄總數就可以；如果需要，那麼就要用新表，就算現在做起來麻煩一點也不要後面來推翻資料庫表設計。
關係表相關功能
牽涉到link的，現在是1對1，要考慮將來有沒有可能1對n或者n對n。1對1用個外來鍵就可以了，否則一開始就單獨用一張link表。
系統整合
現在只對接一個系統，要考慮將來會不會相同的業務對接多個系統？如果會，你應該直接上jms這種（雖然工作量加大了），不上jms這種的話，也要設計成被動接受的整合方式，那麼在增加新系統你都不需要怎麼樣改。（如果你主動請求的互動方式，多一個系統你就要多一個配置，多測試一遍，如果設計成被動接受的，就不需要什麼配置和測試了。而很多時候，2個系統整合設計成主動被動都可以實現需求）
總結
其實，上面說的這些，概括起來，就是要 主動思考，多走一步，不要被動接受看到的需求，要對需求的將來變化做好心中有數 。當然，你可以說這些變更都是小變，大變怎麼辦？大變還不給你加工作量，你就走人不幹了吧，哪裡有這麼無良的老闆！
每一個開發人員都應該思考：需求變動真的是我加班的最重要原因嗎？我的程式碼是否寫得足夠好？需求變更裡面，我能控制是什麼，我不能控制的是什麼？我應該做好什麼的準備來擁抱需求的變更？
原文參考【https://www.javazhiyin.com/26179.html】