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

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

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

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

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

??? 我覺得如果出于練兵的目的，重新搗騰一個輪子出來當然是個好方法，就好像比賽開始前反復練習投籃一樣正常。可如果你已經上戰場了，已經開始比賽了，已經去幫客戶做項目了，這時候才來練習是非常不合適的。因為你很可能會因此而輸掉比賽、丟掉客戶，而且因為你極其不專業的表現，會影響你的職業生涯。所以在公司里面，應該明確區分什么時候是練兵，什么時候是上陣，一定要杜絕上陣后才練兵的不專業表現。換句話說，工作中不要重復發明輪子，要練習投籃下場后自己慢慢練去，不要輕易浪費在賽場上的出手機會，just beprofessional.

諾懷博客標簽:

從某軟件開發項目一期工作中學到的經驗

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

1. 明確范圍

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

2. 范圍變更

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

3. 提交版本

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

4. 質量

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