改进代码的 12 个步骤
|
如果你把這 12 件事做好了，你將擁有一支紀律嚴明的團隊，能夠始終如一地交付。
1. 你使用源代碼管理嗎？
我使用過商業(yè)源代碼管理包，也使用過免費的 CVS，讓我告訴你，CVS 很好。但是，如果你沒有源代碼管理，你就會在試圖讓程序員一起工作時感到壓力。程序員無法知道其他人做了什么。錯誤不能輕易回滾。源代碼管理系統(tǒng)的另一個巧妙之處在于，源代碼本身在每個程序員的硬盤上都簽出——我從未聽說過使用源代碼管理的項目會丟失大量代碼。
2. 你能一步到位地完成構(gòu)建嗎？
我的意思是：從最新的源快照進行交付構(gòu)建需要多少步驟？在優(yōu)秀的團隊中，你可以運行一個腳本，從頭開始進行完整的檢出，重新構(gòu)建每一行代碼，制作各種版本、語言和 #ifdef 組合的 EXE，創(chuàng)建安裝包，并創(chuàng)建最終媒體——CDROM 布局、下載網(wǎng)站等等。
如果該過程需要多個步驟，則容易出錯。當你接近發(fā)貨時，你希望有一個非?？斓闹芷趤硇迯?fù)“最后一個”錯誤，制作最終的EXE等。如果編譯代碼、運行安裝構(gòu)建器等需要 20 個步驟，你會發(fā)瘋，你會犯愚蠢的錯誤。
正是出于這個原因，我工作的最后一家公司從 WISE 切換到 InstallShield：我們要求安裝過程能夠使用 NT 調(diào)度程序從腳本自動運行，而 WISE 不能在一夜之間從調(diào)度程序運行，所以我們把它扔掉了。（WISE的好心人向我保證，他們的最新版本確實支持夜間構(gòu)建。
3. 你每天都會做構(gòu)建嗎？
使用源代碼管理時，有時一個程序員會意外簽入破壞生成的內(nèi)容。例如，他們添加了一個新的源文件，并且在他們的機器上一切都編譯良好，但他們忘記將源文件添加到代碼存儲庫中。于是他們鎖上機器，回家了，忘乎所以，高興不已。但是沒有其他人可以工作，所以他們也不得不回家，不開心。
破壞構(gòu)建是如此糟糕（而且如此普遍），以至于它有助于進行日常構(gòu)建，以確保不會忽視任何損壞。在大型團隊中，確保立即修復(fù)破損的一個好方法是每天下午在午餐時間進行每日構(gòu)建。每個人都在午餐前盡可能多地簽到。當他們回來時，構(gòu)建就完成了。如果它有效，那就太好了！每個人都檢查了最新版本的源代碼并繼續(xù)工作。如果構(gòu)建失敗，您可以修復(fù)它，但每個人都可以繼續(xù)使用預(yù)構(gòu)建的、完整的源代碼版本。
在 Excel 團隊中，我們有一個規(guī)則，即作為他們的“懲罰”，無論誰破壞了構(gòu)建，都有責任照看構(gòu)建，直到其他人破壞它。這是一個很好的激勵措施，可以不破壞構(gòu)建，也是一種在構(gòu)建過程中輪換每個人的好方法，這樣每個人都可以了解它是如何工作的。
在我的文章《每日構(gòu)建是你的朋友》中閱讀有關(guān)每日構(gòu)建的更多信息。
4. 你有錯誤數(shù)據(jù)庫嗎？
我不在乎你說什么。如果你正在開發(fā)代碼，即使是在一個團隊中，如果沒有一個有組織的數(shù)據(jù)庫列出代碼中所有已知的錯誤，你就會發(fā)布低質(zhì)量的代碼。許多程序員認為他們可以把錯誤列表記在腦子里。廢話。我一次記不住超過兩三個蟲子，第二天早上，或者在匆忙的運輸中，它們被遺忘了。您絕對必須正式跟蹤錯誤。
Bug 數(shù)據(jù)庫可以很復(fù)雜，也可以很簡單。對于每個 bug，最小、有用的 bug 數(shù)據(jù)庫必須包含以下數(shù)據(jù)：
- 完成重現(xiàn)錯誤的步驟
- 預(yù)期行為
- 觀察到的（錯誤）行為
- 分配給誰
- 是否已修復(fù)
如果錯誤跟蹤軟件的復(fù)雜性是唯一阻止您跟蹤錯誤的原因，只需使用這些關(guān)鍵字段制作一個簡單的 5 列表并開始使用它。
5. 在編寫新代碼之前，你會修復(fù)錯誤嗎？
Microsoft Word for Windows的第一個版本被認為是一個“死亡行軍”項目。它花了很長時間。它一直在滑落。整個團隊都在荒謬地工作，項目一次又一次地被推遲，壓力令人難以置信。當這個的東西終于發(fā)貨時，晚了好幾年，Microsoft把整個團隊送到坎昆度假，然后坐下來進行一些認真的反省。
他們意識到，項目經(jīng)理一直堅持遵守“時間表”，以至于程序員只是匆匆忙忙地完成編碼過程，編寫了極其糟糕的代碼，因為錯誤修復(fù)階段不是正式時間表的一部分。沒有試圖減少錯誤倒計時。恰恰相反。故事是這樣的，一個程序員，他必須編寫代碼來計算一行文本的高度，他只是寫了“return 12”，然后等待錯誤報告進來，說明他的函數(shù)并不總是正確的。時間表只是一個等待變成錯誤的功能清單。在事后分析中，這被稱為“無限缺陷方法”。
為了糾正這個問題，Microsoft普遍采用了一種叫做“零缺陷方法”的方法。公司里的許多程序員都咯咯地笑了起來，因為這聽起來像是管理層認為他們可以通過執(zhí)行命令來減少錯誤數(shù)量。實際上，“零缺陷”意味著在任何給定時間，最高優(yōu)先級是在編寫任何新代碼之前消除錯誤。原因如下。
一般來說，在修復(fù)錯誤之前等待的時間越長，修復(fù)成本（時間和金錢）就越高。
例如，當您犯了編譯器捕獲的拼寫錯誤或語法錯誤時，修復(fù)它基本上是微不足道的。
當你的代碼中有一個錯誤，當你第一次嘗試運行它時看到它，你將能夠立即修復(fù)它，因為所有的代碼在你的腦海中仍然記憶猶新。
如果你在幾天前編寫的某個代碼中發(fā)現(xiàn)了一個錯誤，你需要一段時間來尋找它，但是當你重新閱讀你寫的代碼時，你會記住所有內(nèi)容，并且你將能夠在合理的時間內(nèi)修復(fù)這個錯誤。
但是，如果你在幾個月前編寫的代碼中發(fā)現(xiàn)了一個錯誤，你可能已經(jīng)忘記了關(guān)于該代碼的很多事情，而且修復(fù)起來要困難得多。到那時，你可能正在修復(fù)別人的代碼，而他們可能正在阿魯巴島度假，在這種情況下，修復(fù)錯誤就像科學(xué)一樣：你必須緩慢、有條不紊、一絲不茍，而且你不能確定需要多長時間才能找到治療方法。
如果你在已經(jīng)發(fā)布的代碼中發(fā)現(xiàn)了一個錯誤，你將產(chǎn)生難以置信的費用來修復(fù)它。
這是立即修復(fù)錯誤的原因之一：因為它花費的時間更少。還有另一個原因，它與以下事實有關(guān)：預(yù)測編寫新代碼所需的時間比修復(fù)現(xiàn)有錯誤更容易。例如，如果我讓你預(yù)測編寫代碼對列表進行排序需要多長時間，你可以給我一個很好的估計。但是，如果我問你如何預(yù)測在安裝了 Internet Explorer 5.5 的情況下，修復(fù)代碼不起作用的錯誤需要多長時間，你甚至無法猜測，因為你不知道（根據(jù)定義）是什么導(dǎo)致了這個錯誤。可能需要 3 天才能找到它，或者可能需要 2 分鐘。
這意味著，如果你的日程安排中還有很多錯誤需要修復(fù)，那么這個日程安排是不可靠的。但是，如果您已經(jīng)修復(fù)了所有已知的錯誤，并且只剩下新代碼，那么您的日程安排將更加準確。
將錯誤計數(shù)保持在零的另一個好處是，您可以更快地響應(yīng)競爭。一些程序員認為這是讓產(chǎn)品隨時準備好發(fā)貨。然后，如果您的競爭對手推出了一項殺手級新功能，正在竊取您的客戶，您可以僅實現(xiàn)該功能并立即發(fā)布，而無需修復(fù)大量累積的錯誤。
6. 你有最新的時間表嗎？
這就把我們帶到了日程安排上。如果你的代碼對業(yè)務(wù)很重要，那么有很多原因可以解釋為什么知道代碼何時完成對業(yè)務(wù)很重要。程序員在制定時間表方面是出了名的蹩腳?！爱斔瓿蓵r，它就會完成！”他們對商人大喊大叫。
不幸的是，這并不能解決問題。在發(fā)布代碼之前，企業(yè)需要做出太多的規(guī)劃決策：演示、貿(mào)易展覽、廣告等。而做到這一點的唯一方法是制定一個時間表，并使其保持最新狀態(tài)。
制定時間表的另一個關(guān)鍵因素是，它迫使你決定要做什么功能，然后它迫使你選擇最不重要的功能并削減它們，而不是陷入特征性（又名范圍蔓延）。
7.你有規(guī)格嗎？
編寫規(guī)范就像使用牙線一樣：每個人都同意這是一件好事，但沒有人這樣做。
我不確定為什么會這樣，但這可能是因為大多數(shù)程序員討厭編寫文檔。因此，當僅由程序員組成的團隊處理問題時，他們更喜歡用代碼而不是文檔來表達他們的解決方案。他們寧愿潛心編寫代碼，也不愿先生成規(guī)范。
在設(shè)計階段，當您發(fā)現(xiàn)問題時，您可以通過編輯幾行文本輕松修復(fù)它們。一旦代碼被編寫出來，修復(fù)問題的成本就會大大增加，無論是在情感上（人們討厭扔掉代碼）還是在時間上，所以實際解決問題是有阻力的。不是根據(jù)規(guī)范構(gòu)建的軟件通常最終會設(shè)計得很糟糕，并且進度會失控。這似乎是 Netscape 的問題所在，前四個版本變得如此混亂，以至于管理層愚蠢地決定扔掉代碼并重新開始。然后他們在Mozilla上再次犯了這個錯誤，創(chuàng)造了一個失控的怪物，花了幾年時間才達到alpha階段。
我的理論是，這個問題可以通過教程序員不那么不情愿地成為作家來解決，方法是讓他們?nèi)⒓訉懽鞯膹娀n程。另一種解決方案是聘請聰明的項目經(jīng)理來制作書面規(guī)范。無論哪種情況，您都應(yīng)該強制執(zhí)行簡單的規(guī)則“沒有規(guī)范就沒有代碼”。
通過閱讀我的 4 部分系列，了解有關(guān)編寫規(guī)范的所有信息。
8. 程序員有安靜的工作條件嗎？
通過為知識工作者提供空間、安靜和隱私，可以提高生產(chǎn)力。經(jīng)典的軟件管理書籍《Peopleware》廣泛地記錄了這些生產(chǎn)力優(yōu)勢。
麻煩來了。我們都知道，知識工作者通過進入“心流”（也稱為“在區(qū)域”）中才能發(fā)揮最佳效果，在那里他們完全專注于自己的工作并完全脫離環(huán)境。他們忘記了時間，通過絕對的專注創(chuàng)造了偉大的東西。這是他們完成所有生產(chǎn)性工作的時候。作家、程序員、科學(xué)家，甚至籃球運動員都會告訴你關(guān)于在這個區(qū)域的信息。
麻煩的是，進入“區(qū)域”并不容易。當您嘗試測量它時，看起來平均需要 15 分鐘才能開始以最大生產(chǎn)力工作。有時，如果你累了，或者那天已經(jīng)做了很多創(chuàng)造性的工作，你就無法進入這個區(qū)域，你把剩下的工作時間都花在擺弄、閱讀網(wǎng)絡(luò)、玩俄羅斯方塊上。
另一個麻煩是很容易被淘汰出該區(qū)域。噪音、電話、外出吃午飯、不得不開車 5 分鐘去星巴克喝咖啡，以及同事的打擾——尤其是同事的打擾——都會讓你離開這個區(qū)域。如果同事問你一個問題，導(dǎo)致 1 分鐘的中斷，但這會嚴重影響你，以至于你需要半個小時才能再次提高工作效率，那么你的整體工作效率就會遇到嚴重的麻煩。如果你處于一個嘈雜的牛棚環(huán)境中，就像咖啡因的網(wǎng)絡(luò)公司喜歡創(chuàng)造的那種環(huán)境，營銷人員在程序員旁邊打電話尖叫，你的生產(chǎn)力就會直線下降，因為知識工作者一次又一次地被打斷，永遠不會進入這個區(qū)域。
對于程序員來說，這尤其困難。生產(chǎn)力取決于能否同時處理短期記憶中的許多小細節(jié)。任何形式的中斷都可能導(dǎo)致這些細節(jié)崩潰。當你恢復(fù)工作時，你不記得任何細節(jié)（比如你正在使用的局部變量名稱，或者你在實現(xiàn)該搜索算法時所處的位置），你必須不斷查找這些東西，這會減慢你的速度，直到你恢復(fù)速度。
這是簡單的代數(shù)。比方說（證據(jù)似乎表明），如果我們打斷一個程序員，哪怕是一分鐘，我們真的會浪費 15 分鐘的生產(chǎn)力。在這個例子中，讓我們把兩個程序員 Jeff 和 Mutt 放在一個標準的 Dilbert 小牛肉育肥場的開放式隔間里。Mutt 不記得 strcpy 函數(shù)的 Unicode 版本的名稱。他可以查一下，這需要 30 秒，或者他可以問 Jeff，這需要 15 秒。由于他就坐在杰夫旁邊，他問杰夫。Jeff 分心并失去了 15 分鐘的工作效率（為 Mutt 節(jié)省了 15 秒）。
現(xiàn)在讓我們把它們搬到有墻和門的獨立辦公室里?，F(xiàn)在，當 Mutt 不記得那個函數(shù)的名稱時，他可以查找它，這仍然需要 30 秒，或者他可以問 Jeff，現(xiàn)在需要 45 秒，并且需要站起來（考慮到程序員的平均身體素質(zhì)，這不是一件容易的事！于是他查了一下。所以現(xiàn)在 Mutt 損失了 30 秒的生產(chǎn)力，但我們?yōu)?Jeff 節(jié)省了 15 分鐘。?。?/p>
9. 你使用金錢能買到的最好的工具嗎？
用編譯語言編寫代碼是最后一件事，仍然無法在花園品種的家用計算機上立即完成。如果您的編譯過程需要幾秒鐘以上，那么獲得最新最好的計算機將節(jié)省您的時間。如果編譯只需要 15 秒，程序員就會在編譯器運行時感到無聊，這會讓他們陷入困境并扼殺數(shù)小時的生產(chǎn)力。
使用單個監(jiān)視器系統(tǒng)調(diào)試 GUI 代碼即使不是不可能，也是痛苦的。如果您正在編寫 GUI 代碼，兩個顯示器將使事情變得容易得多。
大多數(shù)程序員最終必須操作圖標或工具欄的位圖，而大多數(shù)程序員沒有可用的好位圖編輯器。嘗試使用 Microsoft Paint 來操作位圖是一個笑話，但這是大多數(shù)程序員必須做的。
一流的開發(fā)團隊不會折磨他們的程序員。即使是因使用功能不足的工具而引起的小挫折也會加起來，使程序員脾氣暴躁和不開心。一個脾氣暴躁的程序員是一個沒有生產(chǎn)力的程序員。
除此之外，還要補充...程序員很容易通過向他們提供最酷、最新的東西來賄賂他們。這是讓他們?yōu)槟ぷ鞅葘嶋H支付有競爭力的薪水便宜得多的方式！
10. 你們有測試人員嗎？
如果你的團隊沒有專門的測試人員，每兩三個程序員至少有一個，你要么在運送有缺陷的產(chǎn)品，要么你浪費了錢。吝嗇測試人員是一種令人發(fā)指的虛假經(jīng)濟，以至于我被更多的人不承認它所震撼。
11. 新應(yīng)聘者在面試時會寫代碼嗎？
你會聘請魔術(shù)師而不讓他們給你展示一些魔術(shù)嗎？當然不是。
你會在不品嘗他們的食物的情況下為您的婚禮聘請餐飲服務(wù)商嗎？我懷疑。（除非是瑪吉阿姨，如果你不讓她做她“有名”的切碎的肝蛋糕，她會永遠討厭你）。
然而，每天，程序員都是根據(jù)令人印象深刻的簡歷或面試官喜歡與他們聊天而被聘用的?；蛘咚麄儽粏柕浆嵤聠栴}（“CreateDialog（） 和 DialogBox（） 有什么區(qū)別？”），這些問題可以通過查看文檔來回答。你不在乎他們是否記住了數(shù)千個關(guān)于編程的瑣事，你關(guān)心他們是否能夠編寫代碼?；蛘撸愀獾氖?，他們被問到“啊哈！”問題：當你知道答案時，這些問題似乎很容易，但如果你不知道答案，它們就是不可能的。
12. 你們做走廊可用性測試嗎？
走廊可用性測試是你抓住走廊上下一個經(jīng)過的人，強迫他們嘗試使用你剛剛寫的代碼。如果你對五個人這樣做，你將學(xué)到 95% 的關(guān)于代碼中可用性問題的知識。
好的用戶界面設(shè)計并不像你想象的那么難，如果你想讓客戶喜歡和購買你的產(chǎn)品，這一點至關(guān)重要。你可以閱讀我關(guān)于UI設(shè)計的免費在線書籍，這是一本簡短的程序員入門書。