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

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

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

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

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

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

諾懷博客標簽:

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

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

1. 明確范圍

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

2. 范圍變更

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

3. 提交版本

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

4. 質(zhì)量

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