Joel測試
1.你使用原始碼管理麼？
2.你能在一步之內編譯程式麼？
3.你每天都編譯程式碼麼？
4.你有bug資料庫麼？
5.你在寫新程式碼前會修復bug麼？
6.你有最新的日程安排麼？
7.你寫程式碼有規範麼？
8.程式設計師有安靜的工作環境麼？
9.你使用錢能買到的最棒的工具麼？
10.你有測試人員麼？
11.來找工作的人在他們面試的時候會寫程式碼麼？
12.你會做走廊可用性測試麼？
Joel測試的好處是很容易快速得出針對每一個問題的“是”或“不是”。你不必去翻出那些每日程式設計行數和每個拐點的平均bug數。如果你的團隊有一個“是”就得一分。關於Joel測試令人失望的是，你真的不應該用它來確保你的核電站軟體的安全。
獲得12分是完美的，11分也還可以容忍，但10分或更低的分數表明你有嚴重的問題。事實上，大多數軟體企業都以2分或3分的分數在運轉著，他們真的很需要幫助，因為像微軟這樣的公司一直以來都以12分的完美表現在運轉。
當然，這些都不是決定成敗的唯一因素：特別是當你有一個正在開發沒人要的產品的偉大的軟體團隊的時候，那麼，人們是真的不會接受這個產品的。同時一個沒有這麼做的“神槍手”仍然能產生出令人難以置信的改變世界的軟體也是可能存在的。但是，在其他條件相同的情況下，如果你把這12件事情都做好了，你就會擁有一個能始終如一完成任務的團隊。
7.你寫程式碼有規範麼？
書寫規範就像牙線，每個人都同意這是一個很好的事情，但卻沒人做。
我不知道這是為什麼，但很可能是因為大多數程式設計師討厭寫文件。結果，對一個大部分有程式設計師組成的團隊遇到了一個難題的時候，他們更傾向於用程式碼來表達他們的解決辦法，而不是用文件。他們寧願埋頭寫程式碼而不是先寫一份規範。
在設計階段，當你發現問題時，你可以很容易地通過編輯幾行文字就修復它。一旦開始寫程式碼，修復問題的代價就大大地提高了，無論在感情上（人們討厭扔掉程式碼）還是在時間上，所以這時候修復問題是有阻力的。不是從規範開始建立起來的軟體通常會很糟糕地結束設計，並且日程安排會不受控。這個在Netscape好像已經成為大問題了，Netscape的前四個版本慢慢變得一團糟，然後管理層愚蠢地決定拋棄舊程式碼再重新開始。然後他們又在Mozilla上再一次犯了這個錯誤，建立了一個失控的怪物，並且浪費了好幾年時間才又回到初始階段。
我的一貫主張是，這問題可以通過把程式設計師送去學習寫作的集中課程，把他們變為差不多的寫手來解決。另一個方案是僱傭一些聰明的程式管理人員，讓他們來寫程式碼規範。在這兩種情況下，你應該執行簡單的規則“無規範不出程式碼”。
8.程式設計師有安靜的工作環境麼？
廣泛的記錄表明，通過給知識型員工提供空間、安靜和隱私就能提高生產力。經典的軟體管理書《人件》就廣泛地記錄了生產力受益於這些方面。
問題來了。我們都知道知識型員工隨著“靈感流動”工作最好，就是我們所說的“進入狀態”，在哪裡他們會全身心專注於他們的工作，並且完全脫離了周圍的環境。通過絕對的專注，他們忘記了時間，產生出偉大的程式碼。這是他們把工作完成的過程。作家、程式設計師、科學家，甚至籃球運動員都會告訴你要進入狀態。
問題是，進入狀態並不那麼容易。當你嘗試去考量它的時候，在最大生產力下好像需要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分鐘。哈哈哈哈！
9.你使用錢能買到的最棒的工具麼？
在公園裡使用家用電腦立即用一門編譯語言寫程式碼仍然是最不能做的事情之一。如果你的編譯過程超過幾秒鐘，使用最新和效能最強的電腦會讓你節省點時間，當編譯器執行的時候，程式設計師會感到厭倦，這是他們會切換到閱讀點別的書籍，這會吸引他們的注意力，失去好幾個小時的工作效率。
使用單個顯示器除錯GUI程式碼是很痛苦的，這也不是不可能。如果你在寫GUI程式碼，兩臺顯示器會讓很多事情變得更加容易。
大多數程式設計師最終要處理圖示或工具欄的點陣圖，但他們大多數都沒有一個好用的點陣圖編輯器。嘗試用Microsoft Paint來處理點陣圖是個笑話，但這就是大部分程式設計師們所要做的。
在我上一份工作中，系統管理員一直給我發自動的垃圾郵件抱怨，說我用了超過220兆位元組的伺服器上的硬碟存貯空間。我指出，鑑於最近硬碟的價格，這些硬碟空間的成本比我使用的衛生紙的成本都低多了。甚至花費我10分鐘來清理我的郵件目錄，這真是對我工作效率的極為荒誕的浪費。
頂尖的開發團隊不會折磨他們的程式設計師。即使是因為功能不完善的工具引起的小挫折累加起來，也會使程式設計師脾氣暴躁和不愉快。一個脾氣暴躁的程式設計師是不會有工作效率的。
程式設計師最容易接受最酷、最新的東西賄賂了。與支付有競爭力的薪水比起來，這是一種讓他們為你工作更便宜的方式。
10.你有測試人員麼？
如果你的團隊沒有專門的測試人員，至少應該為兩三個程式設計師就配一個測試人員，你會寫出有很多bug的產品，或者你在花冤枉錢讓測試人員30刀每小時就能做的工作交給100刀每小時的程式設計師來做。在測試人員身上節省下來的錢是一個離譜的虛假的經濟，我只是想讓更多的人認識到這一點。
11.來找工作的人在他們面試的時候會寫程式碼麼？
你會僱傭一個沒看過他魔術技巧的魔術師麼？當然不會。
你會僱傭一個沒嘗過他的食物的餐飲服務商來為你的婚禮服務麼？我對此表示懷疑。
然而，一天天的，程式設計師通過讓人印象深刻的簡歷被僱用，或是因為面試者喜歡跟他們聊天。或者他們被問到很細的問題（“CreateDialog（）和DialogBox（）之間有啥不同？”），這些看文件就能回答了。你不關心他們是否記得關於程式設計的成千上萬的細節，你只關心他們到底能不能寫出程式碼。或者，更糟糕的是，他們被問到的都是“啊？”問題：就是那種你知道答案就看起來很簡單，但如果不知道答案就什麼也回答不上來的問題。
拜託，以後不要這麼幹了。在面試期間你想怎麼問就怎麼問，但一定要讓參加招聘的程式設計師寫點程式碼。
12.你會做走廊可用性測試麼？
走廊可用性測試就是當你在走廊上遇到一個路人就強迫他試著用你剛寫的程式碼。如果你對五個人做過這種事，你會學到你程式碼裡需要學習的95%的實用性問題的答案。
好的使用者介面設計並不像你想的那麼難，如果你想讓使用者喜歡併購買你的產品這就至關重要了。
但關於使用者介面最重要的事情是，如果你把你的程式展示給很多人看（實際上五六個就足夠了），你就會發現人們存在的最大的問題。即使你的使用者介面設計技術還不怎麼樣，只要你強迫自己去做走廊可用性測試，這並沒什麼代價，而你的使用者介面會越來越好的。
原文：http://www.joelonsoftware.com/articles/fog0000000043.html
（翻譯：PHP100_Alex）
來自：PHP100
相關閱讀
評論(1)