完美世界辰东,穿越小说排行榜,魔天记忘语小说

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

多些時(shí)間能少寫些代碼

我在我的微博上說過這樣一段話，我想在這里把我的這個(gè)觀點(diǎn)闡述地更完整一些。

創(chuàng)新互聯(lián)建站-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價(jià)比薊州網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式薊州網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋薊州地區(qū)。費(fèi)用合理售后完善，十年實(shí)體公司更值得信賴。

@左耳朵耗子：聰明的程序員使用50%-70%的時(shí)間用來思考，嘗試和權(quán)衡各種設(shè)計(jì)和實(shí)現(xiàn)，而用30% – 50%的時(shí)間是在忙碌著編碼，調(diào)試和測試。聰明的老板也會讓團(tuán)隊(duì)這樣做。而傻逼的老板，苦逼的程序員會拿出來100%-150%的時(shí)間來忙著趕進(jìn)度，返工，重構(gòu)，fix 大量的bug… 所以，越差的團(tuán)隊(duì)一般會越忙，而且還忙不完。

在現(xiàn)在這個(gè)浮躁的時(shí)期，再加上敏捷咨詢師們念的歪經(jīng)，他們讓人感覺上就像是軟件產(chǎn)品是可以在很短的時(shí)間內(nèi)高質(zhì)量的完成的，這令那些管理者們很興奮，就像巴甫洛夫的條件反射實(shí)驗(yàn)中的狗看到了肉就會流口水那樣興奮。他們使用TDD，快速迭代，不斷重構(gòu)，持續(xù)集成直至持續(xù)部署的方法在進(jìn)行軟件開發(fā)。

軟件開發(fā)真是這樣的嗎？難道不需要花時(shí)間去思考嗎？對此，有些觀點(diǎn)在Todd的《“品質(zhì)在于構(gòu)建過程”嗎？》以及《Bob大叔和Jim Coplien對TDD的論戰(zhàn)》中談到過了。我只想想表達(dá)下面的觀點(diǎn)：

軟件的精髓在于設(shè)計(jì)，設(shè)計(jì)是一件很費(fèi)大腦的事件。對于軟件來說，設(shè)計(jì)沒有完美的，它總是一件需要取舍需要權(quán)衡的事，比如：時(shí)間換空間，空間換時(shí)間，TCP或UDP，同步還是異步，數(shù)據(jù)冗余還不冗余等等。那怕是一個(gè)小小的observers模式是pull方式還是 push方式都需要仔細(xì)討論。這些的東西需要時(shí)間和做前期嘗試。
TDD、快速原型和迭代可能會對軟件和團(tuán)隊(duì)產(chǎn)生負(fù)面影響。在一開始，你需要花很大的精力來讓你的軟件從無到有（做過軟件的人都知道，從零開始寫代碼是很痛苦的事），但是因?yàn)槟銢]有想好，先做再說，所以，后期你會面臨更多的質(zhì)量問題而讓你需要花更多的時(shí)間精力。當(dāng)然，那些咨詢師會讓你用持續(xù)集成和持續(xù)部署這樣的方法。但我想告訴你，這并不解決你軟件設(shè)計(jì)的缺陷。舉個(gè)例子—— TDD、迭代、原型只關(guān)注功能性需求，其不會關(guān)注非功能性需求，比如性能問題，高可用性問題，系統(tǒng)維護(hù)問題（模塊的耦合問題），等等。而這些問題往往都可以讓你的軟件設(shè)計(jì)重新來過。
重構(gòu)是惡夢，重構(gòu)應(yīng)該越少越好。當(dāng)你維護(hù)一個(gè)復(fù)雜的系統(tǒng)時(shí)你會知道重構(gòu)是一件多么恐怖的事情（參看《重構(gòu)代碼的7個(gè)階段》）。如果一開始沒有想好，你要面臨的不單單是re-design, re-architect，還要面對時(shí)間和人力成本的增加，最難的是你還要面對的是團(tuán)隊(duì)士氣因?yàn)椴粩嗟膔ework而逐漸低落并產(chǎn)生厭倦和懈怠情緒。

所以，如果你能有多一些時(shí)間去和客戶討論一下需求和未來可能的變化，去調(diào)查一下實(shí)現(xiàn)的技術(shù)難點(diǎn)和細(xì)節(jié)，去和其他有經(jīng)驗(yàn)的人討論并推敲一下架構(gòu)和設(shè) 計(jì)，去思考設(shè)計(jì)上的缺陷，那么，你的coding會變得非常地直，直到你一眼就看到盡頭，你的測試案例也會寫得非常地好，你會幾乎不需要重構(gòu)，于是，你會在未來少寫很多代碼，從而你的軟件開發(fā)會越來越輕松，直到技術(shù)開始換代。

我現(xiàn)在在做的項(xiàng)目，花了幾乎4個(gè)月的時(shí)間來做設(shè)計(jì)，在這個(gè)過程中，我們反復(fù)思考、討論和權(quán)衡若干種實(shí)現(xiàn)方法，并盡可能地窮舉所有的場景和細(xì)節(jié)以及未來可能的變化（那怕是那些簡單的模塊），有個(gè)模塊被重寫了至少三次，每次都是寫到一半就被推翻重寫，我們整個(gè)團(tuán)隊(duì)不斷地在和其它團(tuán)隊(duì)討論，并在對系統(tǒng)不斷地認(rèn)識中對系統(tǒng)進(jìn)行簡化和優(yōu)化，并力求達(dá)到完美?，F(xiàn)在看來，沒有貿(mào)然使用Scrum是明智的。

這就好像我們修路造橋一樣，我們需要花大量的時(shí)間勘測地形地質(zhì)，分析數(shù)據(jù)，思考可能出現(xiàn)的各種問題（各種自然災(zāi)害），評估不同的設(shè)計(jì)方案，而不是先盡快建好再說。

所以，多一些時(shí)間，不是讓你多做幾次迭代，多完成幾個(gè)模塊，而是可以讓你少寫一些代碼，更快的交付一個(gè)更好的產(chǎn)品。

我相信你會有很多疑問，下面是我覺得你可能會有下面的一些觀點(diǎn)，讓我一條一條來回復(fù)：

首當(dāng)其沖的一定會是項(xiàng)目的deadline，或是那種你沒有活語權(quán)的項(xiàng)目。比如做那種“甲乙方合同式的項(xiàng)目”，我把這種項(xiàng)目統(tǒng)一認(rèn)為是“外包項(xiàng)目”，在這種項(xiàng)目性質(zhì)下，你很難有話語權(quán)。對此，我覺得，1）作為乙方的你還是應(yīng)該和甲方在項(xiàng)目計(jì)劃上爭取一下，曉之以情，動之以理。2）如果不行，只能在時(shí)間、需求范圍和質(zhì)量上做一個(gè)權(quán)衡。另外，在這種情況下你要找一個(gè)方法，把你的壓力和痛苦分擔(dān)給用戶和領(lǐng)導(dǎo)。（找到這個(gè)方法的前提需要你找到用戶和領(lǐng)導(dǎo)他們害怕什么，嘿嘿）
過度設(shè)計(jì)和紙上談兵。有人說會不會設(shè)計(jì)太多，造成過度設(shè)計(jì)，或是在設(shè)計(jì)上花太多的時(shí)間。這有可能。我上一家公司的一個(gè)項(xiàng)目團(tuán)隊(duì)就花了1年多的時(shí)間來不停不停的開會和做設(shè)計(jì)，結(jié)果release的時(shí)候還有1000多個(gè)bug。這個(gè)問題的原因是，這個(gè)團(tuán)隊(duì)的設(shè)計(jì)是在紙上談兵，開會是開神仙會，討論的設(shè)計(jì)都是浮云。所以，設(shè)計(jì)并不是討論和思考，還需要去嘗試，我認(rèn)為當(dāng)你的設(shè)計(jì)完成的時(shí)候，你的骨干核心代碼都基本完成了。
我的團(tuán)隊(duì)成員水平太差，不會思考。首先，先恭喜你找到一堆碼農(nóng)，當(dāng)然，這不怪你，這是中國教育和大環(huán)境的問題，讓人不會思考。對于這樣的情況，我有兩個(gè)建議，1）量力而行，使多大的碗就吃多少飯。2）鼓勵思考，那怕那些想法很不靠譜，因?yàn)槿绻婚_始，那么將永遠(yuǎn)不會思考。
必需使用快速迭代。很多公司都在強(qiáng)行上敏捷，他們希望產(chǎn)品越快release越好，而沒有充分的時(shí)間思考和討論。對于這種項(xiàng)目，我的建議是，1）找有豐富經(jīng)驗(yàn)的人來做。2）迭代過程中力求架構(gòu)和程序邏輯的簡單，簡單，再簡單，力求代碼間的高內(nèi)聚，低耦合。不然，重構(gòu)的時(shí)候你就好玩了。
創(chuàng)業(yè)團(tuán)隊(duì)必需要快。做得快就是做得好嗎？很多時(shí)候，不是誰快誰就能笑到最后的。這樣的例子太多了。第一個(gè)做出來的人并不一定就會占領(lǐng)市場，其很有可能會成為先驅(qū)。
有錢的公司才會讓團(tuán)隊(duì)用更多的時(shí)間去思考。錯(cuò)了，你們沒有見過有錢的公司，有錢的公司可以招一堆干不成活的人，可以把事搞亂了再新來過，甚至可以把做失敗的項(xiàng)目換個(gè)名字再重新立項(xiàng)。這些真正的有錢的公司只求快，只求人多，不怕做錯(cuò)決定。像我們這些沒錢的人，干什么事都是小心翼翼地，生怕做錯(cuò)決定。

網(wǎng)頁名稱：多些時(shí)間能少寫些代碼
分享URL：http://fisionsoft.com.cn/article/djoeocp.html

新聞中心

其他資訊