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