程式碼之道

第3部分 (第2/4頁)

程式碼重寫這種愚蠢的事情，它只會重新引入一大堆令人討厭的Bug，而且還對客戶價值沒有絲毫的貢獻。

作者注：我的上述觀點同樣適用於“重構”（Refactoring），儘管我很討厭提到它。哪怕重構是在你毫無察覺的情況下由電腦自動完成的。這並不是說你不應該進行定期的程式碼重構或複審，而是說，你不應該隨意地做這些事情。做不做都應該由團隊來做決定，並且要保證手頭有足夠的“單元測試”來防止引入大量的新Bug。如何正確地做這些事情才是關鍵。

？ 在編碼風格上爭論不休。談到最消耗開發團隊時間的事情，在空格、括號、匈牙利命名法等問題上的爭論必定在前5名之列。請記住：使用一種一致的編碼風格對你程式碼庫的質量和可維護性大有裨益，而你的團隊具體使用哪種風格一點都不重要。你是開發經理，你來選一個並堅持使用它。誰說這也需要民主？！

txt小說上傳分享

告訴我該做什麼

關於閒散時間的陰暗面我已經說得夠多的了。在這個清靜時期，你的開發團隊可以做些什麼有建設性的事情呢？

很自然，測試團隊會堅持說，在產品釋出給製造商之前的這段時間裡，開發人員應該幫著找Bug。而專案管理團隊會堅持說，在產品釋出給製造商之後，開發人員應該花時間去閱讀和複審規範書。不過，這些事情對開發團隊來說沒有太多實際的工作量、不具有吸引力、也無法讓他們開心。

那麼，開發人員在“工作淡季”到底可以做些什麼呢？下面是我的一些想法：

？ 分析Bug。分析團隊在過去的一個產品開發週期中修復過的所有Bug，找出其中的規律。哪些是個人常犯的錯誤？哪些是團隊犯的錯誤？團隊中的每個成員下次需要注意點什麼，才能開發出更好的產品？

？ 為部門開發一些工具。儘管開發人員通常不擅長髮現Bug，但他們在開發用於幫助發現Bug的工具方面的能力卻是超強的。他們還能開發一些工具用於使過程更加順暢，比如原始碼簽入、安裝、建造和支援。給原始碼插樁或者開發一個好的測試用具，能夠大大地促進開發與測試團隊之間的關係。當然，你應該先到工具箱網站上去查一查，看看滿足你需要的工具是否早已存在了。

？ 討好專案經理，把他們的設計思想變成原型程式。開發原型程式是個好主意，只是不要在常規程式碼庫上去做。嘗試用另一種語言來寫，或者至少要有獨立的建造。在常規程式碼庫上開發原型程式的最大問題是，專案經理和高層管理者會很自然地認為，程式碼已經到了差不多可以釋出的程度，而事實上，原型程式通常存在著本地化、平臺依賴、徽標、漫遊、效能、安全、相容性等各種各樣的問題。混淆原型程式和產品程式碼會把產品計劃和期望搞得一團糟。相反，用另一種語言來開發原型程式卻是一個極好的學習機會。再說還能……

作者注：雖然以前已經說過了，但我還要再強調一下，“不要把原型程式當作產品來發布。”這麼做不會節省時間，而只會花更多的時間。千萬不要這麼做！原型程式是用於學習和溝通的，它的用途就是這麼單純。除了用另一種語言開發原型程式外，我以前常常把Esc按鍵處理為異常結束。這樣的話，如果我的上司在觀看演示時表現得異常興奮，我會敲一下Esc鍵，讓程式崩潰，然後解釋說，“很顯然，我們的程式還沒到釋出的時候。”

？ 學習新技術或技能。人們總是抱怨他們沒有足夠的時間去學習新技術或技能，抱怨得不到培訓機會使他們自身得到提高。好吧，為什麼不好好利用專案的這個清靜時期呢？不要讓機會在你身邊溜過！

？ 跟研究人員交談。在零Bug反彈之後是跟研究團隊交談的最好時機。這時候你有足夠的時間去採用某個新技術，花時間去學習它，並且瞭解你能用到哪些東西。到你的產品釋出、並且開始計劃下一個版本的時候，你可能已經把原型程式準備好了，並且解決了所有的風險，著實讓你的團隊驚喜不已。另外，你和研究人員也可以為未來的產品策劃新的研究領域。這非常有價值，而且做起來很容易。

？ 撰寫專利申明或白皮書。其他還有更好的時間，用來反思和記錄你已經做過的事情嗎？如果你團隊中的一位開發人員在專案過程中想出了一個新穎的點子，產品因此增加了不錯甚至是重大的價值，那麼務必叫他撰寫一個專利申明。這做起來很容易，很快，還能極大地鼓舞士氣。請訪問專利組織的網站，以便了解更多的細節。如果你想