軟件開發(fā)金科玉律之-不要重復(fù)發(fā)明輪子!

Caven — Thu, 17 Apr 2014 08:29:05 +0000

?? ? 以前有個(gè)小朋友，特別有好奇心，也喜歡動(dòng)手搗騰。有一天，他做出來了一個(gè)圓圓的，會(huì)滾動(dòng)的東西，感到特別興奮，到處去向別人展示自己的"新發(fā)明"。結(jié)果他發(fā)現(xiàn)別人一點(diǎn)都不稀奇，原來這個(gè)東西叫做“輪子”，早在幾千年前就有了，現(xiàn)在已經(jīng)發(fā)展出了上百種的不同規(guī)格、材質(zhì)、樣式，自己的這個(gè)相比之下太不完善了，根本不能算是什么發(fā)明。這個(gè)小朋友，現(xiàn)在就藏在我們的心里，尤其是經(jīng)驗(yàn)不夠豐富的程序員身上。

??? 幾年前我曾經(jīng)做過一個(gè)項(xiàng)目，經(jīng)過長時(shí)間的掙扎之后，項(xiàng)目依然失敗了。主要的原因之一，就是我們重復(fù)發(fā)明了太多的輪子。事情是這樣的，時(shí)任項(xiàng)目核心開發(fā)人員的同事很有鉆研精神，也相當(dāng)自信，當(dāng)時(shí)客戶提出的一些基本功能，譬如用戶管理、輸入驗(yàn)證、內(nèi)容管理等，雖然市面上隨處可見現(xiàn)成的模塊和控件，可他總是覺得那些做得不夠好，說不如自己重新做一個(gè)方便，而且重新做更能符合客戶的特殊需求。我當(dāng)時(shí)作為PM，雖然對此略有質(zhì)疑，但看他自信滿滿很有激情，而項(xiàng)目時(shí)間也很寬松，就同意了。后來僅僅輸入驗(yàn)證這個(gè)功能就推翻重來了三次，最終還是選用了一個(gè)現(xiàn)成的控件直接用，因?yàn)樗龀鰜淼奶痪邆渫ㄓ眯裕蛛y以維護(hù)；同時(shí)，用戶管理模塊也做得千瘡百孔，極不穩(wěn)定，出現(xiàn)了很多Bug和考慮不周全的地方，最后也不得不去找現(xiàn)有的成熟的組件替換。結(jié)果，這些“重復(fù)發(fā)明輪子”的開發(fā)工作，不但耗費(fèi)了大量的時(shí)間、金錢和精力，而且也沒能發(fā)揮預(yù) 期的效用。事實(shí)證明，現(xiàn)成的控件“輪子”（開源的或收費(fèi)的），經(jīng)歷過時(shí)間的檢測和眾人的改進(jìn)，總比自己重新?lián)v騰出來的要更成熟、更穩(wěn)定，同時(shí)也更加省事、好用。我們在這個(gè)項(xiàng)目中花費(fèi)了這么多時(shí)間、金錢、心血，終于證明了“不要重復(fù)發(fā)明輪子”這句話是很有道理的，這個(gè)慘痛的教訓(xùn)讓我迄今記憶猶新。

??? 雖然此事已經(jīng)時(shí)過境遷，但近些年來我發(fā)現(xiàn)有很多人都在“重復(fù)發(fā)明輪子”，尤其是在我們軟件開發(fā)這個(gè)圈子里面，年輕的小伙伴們充滿了發(fā)明輪子的欲望和激情，就好像那個(gè)可愛的小朋友一樣。因?yàn)樗麄冇X得這樣做會(huì)讓自己學(xué)到很多東西，如果做出來了也會(huì)很有成就感。確實(shí)，成長和成就的確是他們所需要的東西。可如果你是客戶，你會(huì)愿意為此承擔(dān)更高的費(fèi)用和風(fēng)險(xiǎn)么？如果你是項(xiàng)目經(jīng)理呢，在成員練手跟項(xiàng)目成功交付之間，哪個(gè)更重要？

??? 我覺得如果出于練兵的目的，重新?lián)v騰一個(gè)輪子出來當(dāng)然是個(gè)好方法，就好像比賽開始前反復(fù)練習(xí)投籃一樣正常。可如果你已經(jīng)上戰(zhàn)場了，已經(jīng)開始比賽了，已經(jīng)去幫客戶做項(xiàng)目了，這時(shí)候才來練習(xí)是非常不合適的。因?yàn)槟愫芸赡軙?huì)因此而輸?shù)舯荣悺G掉客戶，而且因?yàn)槟銟O其不專業(yè)的表現(xiàn)，會(huì)影響你的職業(yè)生涯。所以在公司里面，應(yīng) 該明確區(qū)分什么時(shí)候是練兵，什么時(shí)候是上陣，一定要杜絕上陣后才練兵的不專業(yè)表現(xiàn)。換句話說，工作中不要重復(fù)發(fā)明輪子，要練習(xí)投籃下場后自己慢慢練去，不要輕易浪費(fèi)在賽場上的出手機(jī)會(huì)，just beprofessional.

諾懷博客標(biāo)簽:

從某軟件開發(fā)項(xiàng)目一期工作中學(xué)到的經(jīng)驗(yàn)

Caven — Fri, 21 Mar 2014 03:45:58 +0000

1. 明確范圍

如果說要把整個(gè)項(xiàng)目（假設(shè)持續(xù)2個(gè)月，分為4次迭代）的范圍，在一開始就明確下來，對我們、對客戶都很困難，因而這個(gè)期望不太現(xiàn)實(shí)；更可行的辦法是把范圍的明確，也拆分成更小的單位，譬如按照每個(gè)迭代（每兩周）來明確；我們雙方只要保證，對這兩周要提交的內(nèi)容，有明確的共同認(rèn)識(shí)即可；然后不斷循環(huán)；
明確下來的范圍，要有個(gè)Task List或者Plan來作為以后判斷是否發(fā)生范圍改變的依據(jù)；

2. 范圍變更

如上所述，如果每兩周一個(gè)迭代，每次迭代都有明確的Task List或Plan；那么在這個(gè)過程中，任何不在這個(gè)List和Plan中的任務(wù)，都可以視為需求變更、范圍變化；
這種變更，需要在客戶剛提出來時(shí)，就進(jìn)行評估，明確告訴客戶這個(gè)改變所需要的額外時(shí)間，必要時(shí)，要協(xié)商延后當(dāng)前版本的提交日期Timeline；
同時(shí)，在平時(shí)要注意把這類小變更記錄起來，免得以后說不清楚哪些是變更，哪些是初始的要求；

3. 提交版本

如果跟客戶約定在每個(gè)迭代結(jié)束時(shí)提交版本，那就相當(dāng)于每次提交都跟客戶商量了一個(gè)明確的提交日期；這樣就不會(huì)太被動(dòng)；當(dāng)然如果客戶覺得這個(gè)頻率有問題，也可以改為每周提交一次或者每周兩次提交；無論是哪種情況，都可以事先商量好，做好對應(yīng)的計(jì)劃和時(shí)間安排；這樣就可以避免倉促提交的現(xiàn)象；
提交版本之前，內(nèi)部一定要留些時(shí)間，譬如1天2天做為內(nèi)部測試和修改Bug的時(shí)間；必須內(nèi)部通過了才提交給客戶；這個(gè)是最基本的質(zhì)量保證流程；

4. 質(zhì)量

開發(fā)人員自測是最基礎(chǔ)的；如果測試人員得到的版本是不可測的，一看就有很多明顯的Bug；通常會(huì)要求測試人員直接打回給開發(fā)人員重測；只有過了自己這一關(guān)，下一個(gè)環(huán)節(jié)的工作才有意義；
如果開發(fā)人員的自測實(shí)在不知道如何才能改進(jìn)，那么可以讓測試人員跟其結(jié)對，一起測試；這樣就能學(xué)到一些測試人員的測試方法和技術(shù)；幫助開發(fā)人員提高自測水平，在后期也可以節(jié)省整個(gè)團(tuán)隊(duì)的時(shí)間；
對于經(jīng)常出現(xiàn)的Bug，開發(fā)人員一定要進(jìn)行分析總結(jié)，看看哪類Bug是自己最常犯的錯(cuò)誤，得到經(jīng)驗(yàn)以后采取措施避免；