項目中開發團隊切忌使用的七種操做

最近在看《人人都是產品經理》這本書，書中提到了「開發的Secret Toolbox」概念，做爲項目管理人員，也是深有同感，在這裏作一個簡單記錄，做爲技術開發人員，應該嚴格杜絕如下七種操做的出現：

一、 Copy&Paste
不假思索的「複用」，知足當前需求就好，不考慮邏輯的可擴展，好比A和B如今1對1，不考慮未來有可能1對N，即便是業務上已經作出提示的時候。

PS： 另外一個重要緣由是：拷貝粘貼是BUG擴散的重要途徑，在不少專業的團隊內部，是不容許互相之間拷貝代碼的，也有這方面的考慮。

二、 Hardcode
寫死代碼，不用配置文件、變量，當你發現某個參數不妥，想要多改幾回試試的時候，發現工做量超乎想象，並且怎麼都改不乾淨。

PS：在實際項目中，全部須要作選擇和分支的時候，都儘可能應該使用配置代碼，即便已經明確只有固定的幾種狀況，也應該考慮將來的擴容，不少項目都是有二期甚至多期的，要爲本身留後路！不少人會說，寫成可配置的代碼會比較費時間，有一種簡單的辦法就是，可配置的內容能夠不與配置文件或數據庫聯動，而是經過靜態類、靜態變量、常量的方式實現，這也是符合OOP思想的一種實現。

三、Less Testing
聽來一個很搞笑的故事，某位技術同窗寫完代碼作單元測試，第一次沒過，百思不得其解，因而再跑一次看看，結果過了，再跑，又過了，因而，就認爲第一次是幻覺。

PS：上述這種很難復現的BUG，纔是程序中最可怕的BUG，由於開發人員不知道復現步驟，也就意味着不知道問題是什麼，若是一個問題連問題自己是什麼，就更別提如何解決問題了。因此對於這種「見鬼的問題」，開發、測試、項目管理團隊都應該引發足夠的重視，以避免項目上線後，由於這種問題而引發不可挽回的損失，試想一下若是在一個資金或帳目相關的功能模塊出現這種問題，面對上線後，真實用戶千奇百怪的操做方式，誰又能確保這個問題不會在關鍵路徑上出現？！

四、Skip Error Handling
不考慮異常狀況，假設用戶都是正常使用（固然，在某些狀況下，業務方承認的時候確實能夠這樣作），舉個最簡單的例子，輸入框沒有作安全上限的長度控制，用戶能夠直接把程序搞掛。

PS：除非你作的是專用系統，而且用戶都是願意學習的、接受太高等教育的、具備極深專業背景的人，不然，你仍是在程序中作好邊界控制，不要對用戶抱有任何幻想，試想一下，若是汽車自動變速箱製造商沒有在R檔和P檔作「防呆」措施的話，你正在高速公路上行駛，卻不當心將檔位掛進了P檔或R檔，那你還能看到次日的太陽嗎？！（自動擋汽車通常在有必定正向速度的時候，是沒法掛進P檔和R檔的，即便你輕踩着剎車）

五、Descope
偷摸減需求，不舉例了，真的會有，驗收的時候產品經理負責，發現了還好，但有時候只驗收主要場景是發現不了的。

PS：出來混，早晚是要還的，一方面這是程序猿的職業素養，是道德問題，另外一方面，也是項目管理和測試人員沒有盡到工做職責的表現。

六、Less Review
減小設計評審、代碼Review等，咱們認爲強技術能夠少評審，但會動用secret toolbox的同窗每每並非很厲害的人物。

PS：在項目管理中，每每是前期工做越紮實，後期越少走彎路，若是團隊對設計、評審、分析、代碼重構的重視度不夠，短時間內，可能看不到什麼影響，可是長遠來講，一是不利於我的專業水平提高，二是後期糾正錯誤成本巨大，每每會伴隨着加班、大面積代碼重構，甚至會總體推翻重作，最嚴重的將是項目以失敗了結，這可能不會再一期項目中提現出來，但只要項目後續有變更或者調整，不管這個變更是否合理，對於項目團隊來講，都如鯁在喉，痛苦異常。

七、No Autotest
無測試自動化，工欲善其事必先利其器，磨刀不誤砍柴工，一直不磨刀，總體效率就一直上不去。

PS：一方面，對於測試人員來講，剛入行時，須要掌握和鍛鍊的技能多是對需求的理解能力、測試用例的設計能力，主要看測試用例是否可以儘量多的覆蓋程序的全部邏輯節點、分支、路徑等，可是當基礎概念和能力掌握的差很少時，就須要更加深刻一步，畢竟一我的就算一天24小時不睡覺又能執行幾個用例呢？而自動化測試，從功能、性能、安全性等方面能夠全面逼近真實環境，要相信現代科學永遠都是向着人類愈來愈輕鬆的方式進化的。另外一方面，不少測試人員是由於不想寫代碼或者寫不了代碼纔去作測試的，可是要知道，只要作測試這行，你一定是繞不過這關的，除非你永遠只想作一顆無足輕重的螺絲釘，而且期盼技術的發展在你退休以前尚未達到能用機器代替你的程度。

     若是對技術缺乏敬畏，就會在不知不覺中背上沉重的技術債務！仍是那句話，出來混早晚是要還的！最終整個項目組（包括技術、測試、產品、設計等部門）都將爲這些技術債務埋單！

    原連接：         http://www.softeng.cn/?p=227