作者：曉風(fēng)輕原文：https://zhuanlan.zhihu.com/p/28719726
我之前的文章 程序員你為什么這么累？ 中，我個(gè)人觀(guān)點(diǎn)是加班原因是編碼質(zhì)量占了大部分因素，但是不少同學(xué)都不認為是代碼質(zhì)量導致的加班，都認為是不斷的需求改動(dòng)導致的加班。這位同學(xué)，說(shuō)的好像別人的需求就不會(huì )變動(dòng)似的！誰(shuí)的需求不改動(dòng)??？不改動(dòng)的能叫需求嗎？哈哈。
先看幾個(gè)程序員的段子娛樂(lè )一下
殺一個(gè)程序員不需要用槍?zhuān)娜涡枨缶涂梢粤恕?/p>
看一個(gè)宮保雞丁的段子娛樂(lè )一下：這TM就是設計師不想改圖的真正原因?。?！
客戶(hù)被綁，蒙眼，驚問(wèn)：“想干什么?”對方不語(yǔ)，鞭笞之，客戶(hù)求饒：“別打，要錢(qián)?”又一鞭，“十萬(wàn)夠不?”又一鞭，“一百萬(wàn)?”又一鞭?？蛻?hù)崩潰：“你們TMD到底要啥?”“要什么?我幫你做項目，寫(xiě)代碼的時(shí)候也很想知道你TMD到底想要啥!”
有沒(méi)有可能存在明確的、不再改動(dòng)的需求呢？其實(shí)很難的。以前我們公司是瀑布開(kāi)發(fā)模式，需求階段時(shí)間較長(cháng)，需要輸出完整的需求規范，還要評審幾次然后才進(jìn)入開(kāi)發(fā)，這個(gè)時(shí)候，需求變更就比較少，但還是有；后來(lái)公司趕時(shí)髦改成了敏捷開(kāi)發(fā)模式，文檔大量簡(jiǎn)化，于是需求沒(méi)有考慮清楚就開(kāi)始開(kāi)發(fā)，需求是邊開(kāi)發(fā)邊變動(dòng)。敏捷開(kāi)發(fā)模式間接變成了加班開(kāi)發(fā)模式。
關(guān)于需求變動(dòng)，不同的角色定義很不一樣。BA覺(jué)得這個(gè)改動(dòng)很正常，開(kāi)發(fā)人員覺(jué)得就是個(gè)需求變更，兩邊各執一詞，這種矛盾長(cháng)期存在。
我列舉幾種場(chǎng)景，大家覺(jué)得算不算需求變更？
刪除對象功能，一開(kāi)始只能創(chuàng )建者刪除，后面變更為管理員也可以刪除，再后面變更了某個(gè)角色也可以刪除。
配置功能，一開(kāi)始使用xml配置，后面修改為使用數據庫配置。
導出功能，一開(kāi)始導出為excel格式，后面變更為導出json格式或者pdf格式?；蛘咭婚_(kāi)始導出20個(gè)字段，后面變更為導出30個(gè)字段。
這些當然都是變更了，但這些真的就是我們加班加點(diǎn)的原因嗎？！我們就沒(méi)有辦法只能任人宰割嗎？！而我的觀(guān)點(diǎn)剛好是，正是因為需求變更不可避免，所以我們才更應該把代碼寫(xiě)簡(jiǎn)單，以對付各種各樣的需求變化。有以下幾點(diǎn)心得建議：
最起碼的要求，我之前一系列的文章說(shuō)的就是這個(gè)。重要程度不需要再講了。改1行簡(jiǎn)單代碼和改10行復雜代碼，工作量能一樣嗎？！測試一個(gè)20行的函數和測試一個(gè)2行的函數工作量能一樣嗎？！
好比一個(gè)房子，你打掃的干干凈凈收拾得井井有條，將來(lái)房子里面的東西搬來(lái)搬去都比較簡(jiǎn)單；但如果你的房子垃圾堆一樣，走進(jìn)去都難（代碼無(wú)法看），就更加不用說(shuō)把東西搬動(dòng)了（改代碼）。
請閱讀：函數編寫(xiě)建議。很重要的習慣，多思考多抽象和封裝，小變更將無(wú)法傷害到你。主動(dòng)思考，主動(dòng)思考將來(lái)可能的各種場(chǎng)景。其實(shí)這個(gè)不難，你只要有這個(gè)意識就成功了一大步！
兵法中叫攻其必救之地。你要知道哪些需求是所有人都明白看上去就很合理的需求，就先開(kāi)始做，你覺(jué)得有爭議的需求你可以放后面一點(diǎn)。同樣，一個(gè)功能中你要知道哪些會(huì )變的，哪些是不會(huì )變的，不變的先做。
舉例：每個(gè)系統都有導出功能，導出功能里面，從數據庫庫查詢(xún)出來(lái)然后處理包裝數據這是肯定要做的而且不會(huì )變的，這個(gè)應該先做；而導出為什么格式（xls還是pdf），導出的具體完整字段，字段的格式如何展示這些是會(huì )變的，這些你開(kāi)始甚至都不需要仔細看需求，等要做的時(shí)候在確認可能需求都有不同的變化。你完全可以邊做前面確定的導出功能邊確認其他的細節，確認需求的時(shí)間越多，需求就越清晰，變更的概率就越小。
多個(gè)功能中，我的習慣是先做最難的功能，最少要開(kāi)始設計和思考，拉長(cháng)功能開(kāi)發(fā)周期。有些同學(xué)喜歡先做簡(jiǎn)單的，導致難的問(wèn)題開(kāi)發(fā)周期不夠，后面加班加點(diǎn)也解決不了。加班其實(shí)是解決不了太多問(wèn)題的。
拖延癥的一個(gè)好處就是，很多需求拖著(zhù)拖著(zhù)就不用做了，因為提出人發(fā)現了這個(gè)需求的不合理。所以先做合理確定的需求。
個(gè)人認為，解耦是編程里面重要的思想。spring的ioc最重要的價(jià)值不就是解耦嗎？就像mvc一樣，數據和視圖要徹底的分離，否則業(yè)務(wù)代碼里面有視圖代碼改起來(lái)是很痛苦的。
我的編碼習慣 - 配置規范里面的舉例，bean的定義就是第三者，就是為了解耦。如導出功能里面，也要有中介。不要把查詢(xún)數據，處理數據和導出數據都在一個(gè)函數一個(gè)循環(huán)里面做了。否則導出格式由xls改成pdf的時(shí)候，你相當于重寫(xiě)做了一遍功能。jms這些基于消息的都是解耦的思想，架構設計上要多用這些松耦合的設計。
很多時(shí)候，由于時(shí)間關(guān)系，一開(kāi)始只做簡(jiǎn)單的功能，后面會(huì )慢慢豐富功能。這雖然不是變更，但是如果你一開(kāi)始的時(shí)候不設計好，很可能后面版本需要大改動(dòng)，數據庫表都要推倒重來(lái)，比全新做還痛苦，相信大家會(huì )有體會(huì )。所以，作為開(kāi)發(fā)組長(cháng)，做任何一個(gè)功能都要想到將來(lái)的發(fā)展，我舉幾個(gè)例子。
下載功能，工作量問(wèn)題當前版本只需要顯示總下載量。你要考慮將來(lái)會(huì )不會(huì )要列出所有的下載過(guò)的用戶(hù)？如果不需要，可能用一個(gè)字段記錄總數就可以；如果需要，那么就要用新表，就算現在做起來(lái)麻煩一點(diǎn)也不要后面來(lái)推翻數據庫表設計。
牽涉到link的，現在是1對1，要考慮將來(lái)有沒(méi)有可能1對n或者n對n。1對1用個(gè)外鍵就可以了，否則一開(kāi)始就單獨用一張link表。
系統集成的，現在只對口一個(gè)系統，要考慮將來(lái)會(huì )不會(huì )相同的業(yè)務(wù)對接多個(gè)系統？如果會(huì )，你應該直接上jms這種（雖然工作量加大了），不上jms這種的話(huà)，也要設計成被動(dòng)接受的集成方式，那么在增加新系統你都不需要怎么樣改。（如果你主動(dòng)請求的交互方式，多一個(gè)系統你就要多一個(gè)配置，多測試一遍，如果設計成被動(dòng)接受的，就不需要什么配置和測試了。而很多時(shí)候，2個(gè)系統集成設計成主動(dòng)被動(dòng)都可以實(shí)現需求）
其實(shí)，我上面說(shuō)的這些，概括起來(lái)，就是要主動(dòng)思考，多走一步，不要被動(dòng)接受看到的需求，要對需求的將來(lái)變化做好心中有數。當然，你可以說(shuō)這些變更都是小變，大變怎么辦？大變還不給你加工作量，你就走人不干了吧，哪里有這么無(wú)良的老板！
希望每一個(gè)開(kāi)發(fā)人員都認真思考，需求變動(dòng)真的是我加班的最重要原因嗎？我的代碼是否寫(xiě)得足夠好？需求變更里面，我能控制是啥，我不能控制的是啥？我應該做好什么的準備來(lái)?yè)肀枨蟮淖兏?？愿天下有永恒不變的需求~~
聯(lián)系客服
