程序員你為什么這么累【續(xù)】：如何應對需求變
來源：原創(chuàng) 時間：2017-12-09 瀏覽：0 次
小編之前的文章 程序員你為什么這么累？ 中，小編個人觀念是加班原因是編碼質量占了大部分要素，可是不少同學都不認為是代碼質量導致的加班，都認為是不斷的需求改動導致的加班。這位同學，說的如同他人的需求就不會改變似的！誰的需求不改動??？不改動的能叫需求嗎？哈哈。
先看幾個程序員的段子文娛一下
殺一個程序員不需求用槍，改三次需求就能夠了。
看一個宮保雞丁的段子文娛一下：這TM就是規(guī)劃師不想改圖的真實原因！??！
客戶被綁，蒙眼，驚問：“想干什么?” 對方不語，鞭撻之，客戶求饒：“別打，要錢?” 又一鞭，“十萬夠不?” 又一鞭，“一百萬?” 又一鞭?？蛻魸⑸ⅲ?ldquo;你們TMD究竟要啥?” “要什么?我?guī)湍阕鲰椖?，寫代碼的時分也很想知道你TMD究竟想要啥!”
有沒有可能存在明晰的、不再改動的需求呢？其實很難的。曾經我們公司是瀑布開發(fā)形式，需求階段時刻較長，需求輸出完好的需求標準，還要評定幾回然后才進入開發(fā)，這個時分，需求改變就比較少，但仍是有；后來公司趕時髦改成了靈敏開發(fā)形式，文檔許多簡化，所以需求沒有考慮清楚就開端開發(fā)，需求是邊開發(fā)邊改變。靈敏開發(fā)形式直接變成了加班開發(fā)形式。
關于需求改變，不同的人物界說很不一樣。BA覺得這個改動很正常，開發(fā)人員覺得就是個需求改變，兩頭各不相謀，這種對立長期存在。
小編羅列幾種場景，我們覺得是不是需求改變？
刪去目標功用，一開端只能創(chuàng)建者刪去，后邊改變?yōu)楣芾韱T也能夠刪去，再后邊改變了某個人物也能夠刪去。
裝備功用，一開端運用xml裝備，后邊修改為運用數(shù)據(jù)庫裝備。
導出功用，一開端導出為excel格局，后邊改變?yōu)閷С鰆son格局或許pdf格局?；蛟S一開端導出20個字段，后邊改變?yōu)閷С?0個字段。
這些當然都是改變了，但這些真的就是我們加班加點的原因嗎？！我們就沒有辦法只能任人宰割嗎？！而我的觀念剛好是，正是因為需求改變不可避免，所以我們才更應該把代碼寫簡略，以抵擋各式各樣的需求改變。有以下幾點心得主張：
1 把代碼寫到最簡略
最起碼的要求，我之前一系列的文章說的就是這個。重要程度不需求再講了。改1行簡略代碼和改10行雜亂代碼，作業(yè)量能一樣嗎？！測驗一個20行的函數(shù)和測驗一個2行的函數(shù)作業(yè)量能一樣嗎？！
比如一個房子，你清掃的干干凈凈收拾得有條不紊，將來房子里邊的東西搬來搬去都比較簡略；但如果你的房子垃圾堆一樣，走進去都難（代碼無法看），就愈加不用說把東西搬動了（改代碼）。
2 把可能改變的封裝成函數(shù)
請閱覽：函數(shù)編寫主張。很重要的習氣，多考慮多籠統(tǒng)和封裝，小改變將無法損傷到你。自動考慮，自動考慮將來可能的各種場景。其實這個不難，你只需有這個認識就成功了一大步！
3 多個功用中先做不會變的功用，一個功用中先做不會變的部分
兵書中叫攻其必救之地。你要知道哪些需求是一切人都理解看上去就很合理的需求，就先開端做，你覺得有爭議的需求你能夠放后邊一點。相同，一個功用中你要知道哪些會變的，哪些是不會變的，不變的先做。
舉例：每個體系都有導出功用，導出功用里邊，從數(shù)據(jù)庫庫查詢出來然后處理包裝數(shù)據(jù)這是必定要做的并且不會變的，這個應該先做；而導出為什么格局（xls仍是pdf），導出的詳細完好字段，字段的格局怎么展現(xiàn)這些是會變的，這些你開端甚至都不需求仔細看需求，等要做的時分在承認可能需求都有不同的改變。你完全能夠邊做前面斷定的導出功用邊承認其他的細節(jié)，承認需求的時刻越多，需求就越明晰，改變的概率就越小。
多個功用中，我的習氣是先做最難的功用，最少要開端規(guī)劃和考慮，拉長功用開發(fā)周期。有些同學喜愛先做簡略的，導致難的問題開發(fā)周期不行，后邊加班加點也解決不了。加班其實是解決不了太多問題的。
延遲癥的一個優(yōu)點就是，許多需求拖著拖著就不用做了，因為提出人發(fā)現(xiàn)了這個需求的不合理。所以先做合理斷定的需求。
4 規(guī)劃上多采納解耦的規(guī)劃，多引進“第三者”，不要直接發(fā)生聯(lián)系
個人認為，解耦是編程里邊重要的思維。spring的ioc最重要的價值不就是解耦嗎？就像mvc一樣，數(shù)據(jù)和視圖要完全的別離，不然事務代碼里邊有視圖代碼改起來是很苦楚的。
我的編碼習氣 - 裝備標準里邊的舉例，bean的界說就是第三者，就是為了解耦。如導出功用里邊，也要有中介。不要把查詢數(shù)據(jù)，處理數(shù)據(jù)和導出數(shù)據(jù)都在一個函數(shù)一個循環(huán)里邊做了。不然導出格局由xls改成pdf的時分，你相當于重寫做了一遍功用。jms這些根據(jù)音訊的都是解耦的思維，架構規(guī)劃上要多用這些松耦合的規(guī)劃。
5 數(shù)據(jù)結構上要考慮功用將來的擴展
許多時分，因為時刻聯(lián)系，一開端只做簡略的功用，后邊會漸漸豐厚功用。這盡管不是改變，可是如果你一開端的時分不規(guī)劃好，很可能后邊版別需求大改動，數(shù)據(jù)庫表都要推倒重來，比全新做還苦楚，信任我們會有領會。所以，作為開發(fā)組長，做任何一個功用都要想到將來的開展，我舉幾個比如。
下載功用，作業(yè)量問題當時版別只需求顯現(xiàn)總下載量。你要考慮將來會不會要列出一切的下載過的用戶？如果不需求，可能用一個字段記載總數(shù)就能夠；如果需求，那么就要用新表，就算現(xiàn)在做起來費事一點也不要后邊來推翻數(shù)據(jù)庫表規(guī)劃。
牽涉到link的，現(xiàn)在是1對1，要考慮將來有沒有可能1對n或許n對n。1對1用個外鍵就能夠了，不然一開端就單獨用一張link表。
體系集成的，現(xiàn)在只對口一個體系，要考慮將來會不會相同的事務對接多個體系？如果會，你應該直接上jms這種（盡管作業(yè)量加大了），不上jms這種的話，也要規(guī)劃成被迫承受的集成方法，那么在添加新體系你都不需求怎么樣改。（如果你自動懇求的交互方法，多一個體系你就要多一個裝備，多測驗一遍，如果規(guī)劃成被迫承受的，就不需求什么裝備和測驗了。而許多時分，2個體系集成規(guī)劃成自動被迫都能夠實現(xiàn)需求）
其實，我上面說的這些，歸納起來，就是要自動考慮，多走一步，不要被迫承受看到的需求，要對需求的將來改變做好心中有數(shù)。當然，你能夠說這些改變都是小變，大變怎么辦？大變還不給你加作業(yè)量，你就走人不干了吧，哪里有這么無良的老板！
