你聽說過SEMA麼？ 它是一個用來測試一個軟件團隊有多好的相當深奧的系統。不，等等！不要手賤點開這個鏈接！它會花費你大概六年的時間來了解這個東西。所以我提出了我自己 的、跟它相比極不負責任的、草率的評價一個軟件團隊的質量的測試。這個測試最棒的方面是它只會花費你3分鐘的時間。你節省下來的所有時間，還可以去上個醫學院。
Joel 測試
The Joel Test
Joel測試的好處是很容易快速得出針對每一個問題的“是”或“不是”。你不必去翻出那些每日編程行數和每個拐點的平均bug數。如果你的團隊有一個“是”就得一分。關於Joel測試令人失望的是，你真的不應該用它來確保你的核電站軟件的安全。
獲得12分是完美的，11分也還可以容忍，但10分或更低的分數表明你有嚴重的問題。事實上，大多數軟件企業都以2分或3分的分數在運轉著，他們真的很需要幫助，因為像微軟這樣的公司一直以來都以12分的完美表現在運轉。
當 然，這些都不是決定成敗的唯一因素：特別是當你有一個正在開發沒人要的產品的偉大的軟件團隊的時候，那麼，人們是真的不會接受這個產品的。同時一個沒有這 麼做的“神槍手”仍然能產生出令人難以置信的改變世界的軟件也是可能存在的。但是，在其他條件相同的情況下，如果你把這12件事情都做好了，你就會擁有一 個能始終如一完成任務的團隊。
我 用過商業源代碼管理包，也用過CVS，它是免費的，讓我來告訴你，CVS很好用。但如果你沒有對源代碼進行管理，你就要應激嘗試把程序員都弄到一塊來工 作。程序員根本不會知道別人都做了什麼。犯過的錯誤不能輕易改過來。關於源代碼管理系統的另一個好處就是源代碼本身可以在每個程序員的硬盤上進行驗證 —我還從沒聽說過哪個使用源代碼管理的項目丟失了很多代碼。
通 過這條測試我想明白：從最新的源代碼的快速復制到進行能輸出的編譯需要多少步驟？再優秀的團隊裡，有一個單獨的腳本，它能從零開始對代碼做一個全面的檢 查，重新編譯每一行代碼，生成EXE文件，在他們各種各樣的版本、編程語言和#ifdef宏定義組合，創建安裝包和最終媒體–CDROM布局、下載網站 等等。
如果這個過程需要一個以上的步驟，就很容易出現誤差。當你接近完工的時候，你很想有很快的修復“最後一個”bug的周期，生成最後的EXE文件等。如果編譯代碼要用20步才能完成，運行安裝編譯器，……，等等，你會抓狂的，並且會導致你犯下愚蠢的錯誤。
正式由於這個原因，我曾工作過的上個公司就從“聰敏”模式切換到了“軟件安裝打包”模式：我們要求安裝過程中可以運行，使用NT調度從腳本整晚自動地運行，“聰明”模式做不到這些，所以我們就拋棄了這個模式。
當 你使用源代碼管理的時候，有時候程序員偶然會檢查出會停止編譯的東西。比如，他們添加了一個源文件，一切在他們的機器上編譯起來都很好，但他們忘記把源文 件添加到代碼庫裡了。所以他們鎖定了機器就回家去了，比較健忘也比較高興。但其他人都不能繼續工作了，所以他們也不得不很不愉快地卷鋪蓋回家了。
打 斷編譯是很糟糕的（也很常見的），但它能幫助程序員每天都編譯代碼，以確保不會出現沒有預兆的編譯中斷。在大型團隊裡面，一個很好的確保中斷能迅速修復的 方法是每天下午都對代碼進行編譯，比如可以在午飯時間做這個。每個人都盡可能多地在午飯前做代碼檢查。這樣當他們吃完午飯回來的時候，這個編譯就已經完成 了。如果它能用，就太好了！每個人都對最新的源代碼進行檢查，然後才繼續工作。如果編譯失敗了，你就修復它，但每個人還能在預編譯、沒有中斷版本的源代碼 上繼續工作。
在Excel項目組，我們有一條規則：誰中斷了編譯，作為對他的“懲罰”，他就要在其他人中斷編譯之前臨時照顧代碼編譯的工作。這是一個很好的不中斷編譯的激勵方式，也是一個讓每個人輪流參與編譯工作從而都能知道編譯原理的好方法。
我 不在乎你怎麼說。如果你在開發代碼，即使是在一個人的團隊，沒有一個組織的列出代碼裡所有已知bug的數據庫，你將會產生出低質量代碼。許多程序員都認為 他們能把眾多的bud存在腦子裡。真是胡說八道。我根本就不能再同一時間記住兩個或三個bug，第二天早上，或者在寫代碼的高峰時期，就記不起它們了。你 絕對要正式地跟蹤bug。
但數據庫可以是復雜或簡單的。一個最小限度的bug數據庫必須包含以下對每個bug的數據：
如果bug跟蹤軟件的復雜性是讓你不想跟蹤你的bug的唯一理由，只用上面包含簡單的5個元素的表格用在這些至關重要的領域，開始使用它吧。
第 一個版本的Windows系統上的微軟Word被認為是一個“死亡行軍”項目。不知道這項目要什麼時候才能完成，它不斷的延期。整個項目組在荒謬的時間裡 工作著，項目再次、再次、再次延期，這時候的壓力的令人難以置信的。當討厭的事情最終出貨，幾年以後，微軟把這整個團隊都送到坎昆去度假了，他們可以靜下 來做些嚴重的自我反省了。
他 們意識到，項目經理一直在堅持按照“日程安排”部署工作，而程序員們只是頭腦簡單的趕緊完成敲代碼的過程，又因為修復bug階段並沒有成為正式日程安排的 一部分，這導致他們寫出了及其惡劣的代碼。沒有能試圖保持住bug不發作的倒計時。恰恰相反，據說一個程序員寫了計算文本行高的代碼，僅僅寫了 “renturn 12;”然後就開始等待關於他的功能總是正確的bug報道。日程安排僅僅是即將變為bug的功能的檢查清單。事後，這個被稱為“無窮大缺陷的方法”。
為 了解決這個問題，微軟普遍地采取了一種叫做“零缺陷方法”的東西。公司的許多程序員都咯咯地笑，因為它聽起來是一種好像通過行政法令就能夠減少bug數量 的管理思想。其實，“零缺陷”意味著在任意給定的時間內，優先級最高的是消除bug，然後才是編寫新代碼。讓我來講講為什麼。
一般情況下，你等待修復bug的時間越長，這個bug就需要付出的代價就越大（在實踐和金錢上）。
比如，當你犯了一個編譯器能捕捉的拼寫或語法錯誤時，修復它的代價微不足道。當你第一時間看到你嘗試運行的代碼裡有bug的時候，你能夠很快的把它解決掉，因為所以的代碼在你腦子裡印象還很清楚。
如果你在幾天前的代碼裡發現了bug，你會花費一段時間來找到它，但當你重讀先前寫下的代碼後，你就會記起一切然後就能在一個合理的時間內修復這個bug。
但 如果你在幾個月前的代碼裡發現了bug，你很可能把關於這段代碼的大部分東西都忘了，要修復它就很難了。這個時候你可能正在修復別人代碼裡的bug，他們 可能會在阿魯巴島度假，這種情況下，修復bug就像科學一樣：你不得不放緩步調、有條不紊、細致地開始工作，並且你還不能確定需要多長時間才能找到問題的 治療方法。
如果你在已經售出的代碼中發現了bug，你會招致令人難以置信的代價修復它。
這 是要立刻修復bug的一個原因：因為這樣花費更少的時間。這關系到寫新代碼之前而不是修復bug之前還要等多長時間。比如，如果我要你預測寫一個給列表排 序的代買要多長時間，你可以給我一個很好的估計值。但如果我要你預測修復一個安裝Explorer 5.5版本後代碼就不能工作的bug需要多長時間，你猜都猜不出來，因為根本不知道到底什麼導致了這個bug。它可能需要3天時間才能跟蹤到，或者僅僅3 分鐘就足夠了。
這句話的意思是，如果你有一個很多bug有待修復的日程安排，這個日程是不靠譜的。但如果你修復了所有已知的bug，並且所有剩下的都是新代碼，這樣你的日程安排才會更加驚人的精確。
關於把bug控制到零還有另一件重要的事，那就是你可以對競爭響應更快。一些程序員認為這點能讓產品在任何時候為發售准備好。如果你的競爭對手從你的客戶那裡引入了一個殺手級的新功能，你就能在發售之前只實現這個功能，而不必去修復大量累計下來的bug。
這條測試把我們帶到了日程安排上來。如果你的代碼對生意是很重要的，會有很多知道代碼完成日期怎麼對生意很重要的原因。程序員在制定日程安排上是出了名的倔。“該完成的時候就完成了！”他們會這樣對商務人士尖叫。
不幸的是，這並沒有讓一切變得更好。在發售代碼之前，公司需要做太多的計劃好的決定：軟件演示，展會，廣告等。而要做到這一點的唯一方法就是擁有一個日程安排，並保證其為最新版本。
關於要有一個日程安排的另一個至關重要的原因是，它能強迫你決定要做哪些功能，然後迫使你挑選出最無關緊要的功能並砍掉它們，而不是陷入長期的猶豫中去。
同時，跟隨日程安排做事並不一定要很苛刻。
書寫規范就像牙線，每個人都同意這是一個很好的事情，但卻沒人做。
我不知道這是為什麼，但很可能是因為大多數程序員討厭寫文檔。結果，對一個大部分有程序員組成的團隊遇到了一個難題的時候，他們更傾向於用代碼來表達他們的解決辦法，而不是用文檔。他們寧願埋頭寫代碼而不是先寫一份規范。
在 設計階段，當你發現問題時，你可以很容易地通過編輯幾行文本就修復它。一旦開始寫代碼，修復問題的代價就大大地提高了，無論在感情上（人們討厭扔掉代碼） 還是在時間上，所以這時候修復問題是有阻力的。不是從規范開始建立起來的軟件通常會很糟糕地結束設計，並且日程安排會不受控。這個在Netscape好像 已經成為大問題了，Netscape的前四個版本慢慢變得一團糟，然後管理層愚蠢地決定拋棄舊代碼再重新開始。然後他們又在Mozilla上再一次犯了這 個錯誤，創建了一個失控的怪物，並且浪費了好幾年時間才又回到初始階段。
我的一貫主張是，這問題可以通過把程序員送去學習寫作的集中課程，把他們變為差不多的寫手來解決。另一個方案是雇傭一些聰明的程序管理人員，讓他們來寫代碼規范。在這兩種情況下，你應該執行簡單的規則“無規范不出代碼”。
廣泛的記錄表明，通過給知識型員工提供空間、安靜和隱私就能提高生產力。經典的軟件管理書《人件》就廣泛地記錄了生產力受益於這些方面。
問 題來了。我們都知道知識型員工隨著“靈感流動”工作最好，就是我們所說的“進入狀態”，在哪裡他們會全身心專注於他們的工作，並且完全脫離了周圍的環境。 通過絕對的專注，他們忘記了時間，產生出偉大的代碼。這是他們把工作完成的過程。作家、程序員、科學家，甚至籃球運動員都會告訴你要進入狀態。
問題是，進入狀態並不那麼容易。當你嘗試去考量它的時候，在最大生產力下好像需要15分鐘才能開始工作。有時，如果你累了或那天已做了很多創造性工作時，你就是進入不了狀態，你會把這天剩下的時間都用來擺弄點什麼，看看網頁，或玩玩俄羅斯方塊。
另 一個問題是，很容易脫離那個狀態。噪聲，來電話，出去吃午飯，不得不開5分鐘車去星巴克喝咖啡，還有被同事打擾–尤其是被同事打擾–都會把你從那個狀 態裡拉出來。如果同事問你問題，導致了一分鐘的中斷，但這個會很悲慘地把你從狀態裡脫離出來，你的話費半個小時才能再次變的高效起來，你的整體生產力會遇 到很大的麻煩。如果你在一個含咖啡因的網絡公司喜歡創造的嘈雜的牛棚一樣的環境裡，有營銷人員在程序員身邊尖叫著打電話，你的工作效率會大幅下跌，因為知 識型工作者一次又一次的被打斷，一直都進入不了狀態。
對 程序員來說，這就更難了。工作效率依賴於能夠同時在短期記憶中兼顧很多小細節。任何類型的打斷都會導致這些細節轟然倒下。當你重新開始工作，你已經記不起 任何細節（比如你剛才還在使用的本地變量名字，或你剛想出來的實施搜索算法的好點子）了，你不得不一直回想這些事情，這會讓你變得很慢，直到你重新變得高 效起來。
這 有一個簡單的代數運算。可以這麼說（有證據暗示）如果我們打斷了一個程序員，即使只有一分鐘，我們真的會失去15分鐘的工作效率。在這個例子裡，我們假設 有兩個程序員，Jeff和Mutt，在一個標准的相鄰開放的格子間裡。Mutt記不起strcpy函數的Unicode版本的名字。他可以查一查，這需要 30秒，或者他可以問問Jeff，這需要15秒。因為他就坐在Jeff旁邊，所以他選擇直接問Jeff。Jeff被分心了，失去了15分鐘的工作效率（僅 僅節省了Mutt的15秒）。
現 在我們把他們兩個分到有門和牆隔開的兩個辦公室去。這時如果Mutt忘記那個函數名，他可以花30秒去查一查，或者花45秒去問問Jeff，這過程包括了 站立起來（考慮到程序員的平均體能這並不是一項簡單的任務！）。所以他會選擇自己查一查。這樣Mutt失去了30秒的工作效率，但同時為Jeff節省了 15分鐘。哈哈哈哈！
在 公園裡使用家用電腦立即用一門編譯語言寫代碼仍然是最不能做的事情之一。如果你的編譯過程超過幾秒鐘，使用最新和性能最強的電腦會讓你節省點時間，當編譯 器運行的時候，程序員會感到厭倦，這是他們會切換到閱讀點別的書籍，這會吸引他們的注意力，失去好幾個小時的工作效率。
使用單個顯示器調試GUI代碼是很痛苦的，這也不是不可能。如果你在寫GUI代碼，兩台顯示器會讓很多事情變得更加容易。
大多數程序員最終要處理圖標或工具欄的位圖，但他們大多數都沒有一個好用的位圖編輯器。嘗試用Microsoft Paint來處理位圖是個笑話，但這就是大部分程序員們所要做的。
在 我上一份工作中，系統管理員一直給我發自動的垃圾郵件抱怨，說我用了超過220兆字節的服務器上的硬盤存貯空間。我指出，鑒於最近硬盤的價格，這些硬盤空 間的成本比我使用的衛生紙的成本都低多了。甚至花費我10分鐘來清理我的郵件目錄，這真是對我工作效率的極為荒誕的浪費。
頂尖的開發團隊不會折磨他們的程序員。即使是因為功能不完善的工具引起的小挫折累加起來，也會使程序員脾氣暴躁和不愉快。一個脾氣暴躁的程序員是不會有工作效率的。
程序員最容易接受最酷、最新的東西賄賂了。與支付有競爭力的薪水比起來，這是一種讓他們為你工作更便宜的方式。
如 果你的團隊沒有專門的測試人員，至少應該為兩三個程序員就配一個測試人員，你會寫出有很多bug的產品，或者你在花冤枉錢讓測試人員30刀每小時就能做的 工作交給100刀每小時的程序員來做。在測試人員身上節省下來的錢是一個離譜的虛假的經濟，我只是想讓更多的人認識到這一點。
你會雇傭一個沒看過他魔術技巧的魔術師麼？當然不會。
你會雇傭一個沒嘗過他的食物的餐飲服務商來為你的婚禮服務麼？我對此表示懷疑。
然 而，一天天的，程序員通過讓人印象深刻的簡歷被雇用，或是因為面試者喜歡跟他們聊天。或者他們被問到很細的問題（“CreateDialog（）和 DialogBox（）之間有啥不同？”），這些看文檔就能回答了。你不關心他們是否記得關於編程的成千上萬的細節，你只關心他們到底能不能寫出代碼。或 者，更糟糕的是，他們被問到的都是“啊？”問題：就是那種你知道答案就看起來很簡單，但如果不知道答案就什麼也回答不上來的問題。
拜托，以後不要這麼干了。在面試期間你想怎麼問就怎麼問，但一定要讓參加招聘的程序員寫點代碼。
走廊可用性測試就是當你在走廊上遇到一個路人就強迫他試著用你剛寫的代碼。如果你對五個人做過這種事，你會學到你代碼裡需要學習的95%的實用性問題的答案。
好的用戶界面設計並不像你想的那麼難，如果你想讓用戶喜歡並購買你的產品這就至關重要了。
但關於用戶界面最重要的事情是，如果你把你的程序展示給很多人看（實際上五六個就足夠了），你就會發現人們存在的最大的問題。即使你的用戶界面設計技術還不怎麼樣，只要你強迫自己去做走廊可用性測試，這並沒什麼代價，而你的用戶界面會越來越好的。（完）