Joel Spolsky on Software文章選

不知道是從什麼時候開始讀Joel Spolsky（周思博、約耳）的文章，還記得一開始看的是中文翻譯『周思博趣談軟體』，後來開始看原文部落格Joel on Software（這裡有另有各種語言的翻譯），幾乎每篇都不放過，對他的文章與意見，我從崇拜學習到有贊成有反對，惠我良多，可惜的是在三個月前，Joel宣布不再寫部落格了（不過好像會找其他管道作另一種形式的發表），心中升起一股淡淡的哀傷感；為記錄我的一些感想，選出以下的文章，並寫下我的意見與感想。



這裡有Joel的背景介紹，簡單講就是耶魯大學畢業，在Microsoft、Viacom Interactive Services與Juno Online Services工作過後，與夥伴在紐約創立Fog Creek Software至今，其產品包括FogBugz（專業管理與臭蟲追蹤）、Fog Creek Copilot（遠端控制電腦，可穿過各種防火牆與NAT）以及其他軟體。過去十年來Joel寫過超過1000篇的文章，討論軟體開發、專案管理、軟體與商業與電腦科學等等，Joel的網站聽說是每個寫程式的、搞軟體的定期都要拜訪的。


以下是我挑的選輯，以及我的感想與看法並配上一幅漫畫。另外有點要事先聲明，有些文章都好幾年前了，有些內容仍然擲地有聲，但有部分或許以現在的觀點看來已經過時或是老掉牙了，甚或你會覺得不正確了，希望你可以想像當年的時空背景，發掘其內涵。我依照我的想法把內容有關連的放在近一點的位置，所以不是照發表日期排列。



Five Worlds，2002.05.06：
斯斯有兩種，軟體不只兩種，這篇文章將軟體分類為五種，五這個數字不是絕對的，重要的是要搞清楚你是在哪個領域開發何種軟體，誰會是使用者，搞錯就好像穿西裝去運動場，格格不入。這裡要注意的是，Joel的領域是他文中所謂的shrinkwrap軟體，是要賣給很多人的那種，當看Joel的文章時，要把這點謹記心。


User Interface Design For Programmers（共九篇），2000.04.10：
這是給軟體工程師看的使用者介面設計的入門手冊，道理雖淺但不可不知。摘錄一段：
人的資質分佈是個鐘型曲線. 你的客戶可能有98%夠聰明到能使用電視機. 大約70%能使用Windows. 有15%能使用Linux. 只有1%能寫程式. 不過卻只有0.1%能用C++之類的語言寫程式. 而只有0.01%能攪懂Microsoft ATL程式設計 (而且他們都留鬍子戴眼鏡, 沒有例外.)


The Joel Test: 12 Steps to Better Code，2000.08.09：
想增進軟體開發的效率嗎？要怎麼評量一個軟體開發的環境呢？這十二項是個簡單又具關鍵性的指標。


Daily Builds Are Your Friend，2001.01.27：
所謂"build是指將原始程式碼經過一連串的程序轉成最後的產品，隨時保持整個軟體專案在可build可執行的狀態是很重要的，人越多就越難達到，如果壞了造成的損害也越大，開發的人就沒辦法把新增修改的部份放上去，也沒辦法抓到最新狀態的程式。


Painless Functional Specifications（Part 1, Part 2, Part 3, Part 4），2000.10.02：
你覺得寫規格書是個惡夢嗎？不知道怎麼寫，寫了沒人看，不斷地要求修改，到底為什麼呢？


The Iceberg Secret, Revealed，2002.02.13：
不論你在什麼職位，你一定有"客戶"，可能是上司、主管、同儕、買家，你寫的程式總會有人要用要看要測試要審核，這篇告訴你一個秘密，客戶不知道他們想要的是什麼，千萬別預期他們能夠告訴你；文中有更多的探討與因應對策。


Top Five (Wrong) Reasons You Don't Have Testers，2000.04.30：
凡實驗必有誤差，凡程式必有bug，就我所知，號稱自己寫的程式絕對沒有臭蟲的人好像只有Linus Torvalds（linux kernel的爸爸）而已，所以，測試吧！


A Hard Drill Makes an Easy Battle，2001.11.20：
Windows有這麼多版本怎麼辦？不要以為你用的是Win32 API就可以通吃，沒測過到時候就會出現一堆奇奇怪怪的問題，測試吧。雖然這是篇很早的文章，講的是在Windows上開發軟體，但看看今日的狀況，這麼多不同血統的瀏覽器與版本，可供借鏡。


Painless Software Schedules，2000.03.29，Evidence Based Scheduling，2007.10.26：
開發進度的追蹤，是件極度不可能的任務，最常見的狀態就是不斷的delay，有人說訂schedule的意義就是用來delay的。


Painless Bug Tracking，2000.11.08：
軟體工程師不只是一直寫程式寫程式，事實上，根據統計，花在debug的時間反而是最多的，所以花點時間想想該怎麼做臭蟲追蹤吧。


Making Wrong Code Look Wrong，2005.05.11：
寫程式是件困難的事情，要盡力把各種阻礙除去，降低寫錯的機率以及提高除錯的效率與可能性，譬如採取一套正確的命名法可以幫助我們看出寫錯的程式碼，文中也點出，如果同一行程式碼可能會有不同的行為（技術上叫做context-sensitive），譬如overloading，有些程式碼的行為需要參考更多其他程式碼才能得知，譬如exception，都應該令人擔心，使用上要非常注意，因為會大大提高修改與維護的困難度。


Getting Things Done When You're Only a Grunt，2001.12.25：
就算你只是個大組織中的小螺絲，還是有很多事情你可以做可以努力，以個人的力量來讓整個專案與團隊變得更好。


How to be a program manager，2009.03.09：
你從小工程師晉升到軟體專案的管理者嗎？你知道專案管理需要哪方面的知識與技巧嗎？看這篇就對了。


The Development Abstraction Layer，2006.04.11：
不是會寫程式就能夠成立一家軟體公司的，除了技術還需要什麼呢？


Fire And Motion，2002.01.06：
一個簡單的概念，但卻不可不知，要不然被人牽著鼻子走（不斷地追求新技術）卻不知向何方而去。


Three Wrong Ideas From Computer Science，2000.08.22：
盡信書不如無書，有些不知不覺中形成的映像，有些約定俗成看似大家都同意的概念，其實可能是錯的，譬如這裡有分散式計算的一些錯誤假設，這本書講軟體工程的謬論，這篇提出三個電腦科學看似正確卻有問題的觀念。


The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)，2003.10.08：
現代人不可不知Unicode、character set、encoding、code page、UTF8、UTF16、ASCII等等，這篇算是初階入門的文章，讓你有個簡單清楚的開始。


Platforms，2002.08.30：
有些人寫的軟體是"平台"，其真正的目標對象應該是"寫程式的開發人員"，而非一般的使用者，但有人（或公司）搞不清楚這點，以致於其平台無法成功。


The Law of Leaky Abstractions，2002.11.11：
整合開發工具、高階語言、低階語言、作業系統、軔體、CPU與memory、電子電路、量子力學、等等，一層一層堆砌起來的技術，經過一道又一道的抽象化手續，讓你產生錯覺，誤以為底下住著一隻精靈，有如魔術般地忠實完成你提出的需求，可是，萬一有一天，某一層有破洞，地底妖魔跑出來大亂天下，怎麼辦呢？


Lord Palmerston on Programming，2002.12.11：
很久很久以前（我指的是Peter Norton那個年代），你只要讀完一本書，大概就可以動手開發軟體了，現在，想的美喔，你要花上大把大把的時間在一拖拉庫的"物件"上打轉；有人說可以在一星期學會某某語言，但是，那又如何呢？


Can Your Programming Language Do This?，2006.08.01：
工欲善其事，必先利其器。有時候要回過頭重新檢視一下寫程式最重要的工具：程式語言，其優劣如何，是否是最適合目前工作的選擇。


How Microsoft Lost the API War，2004.06.13：
Win32 API一度是王者，造就了Windows平台上各式各樣的軟體可用，但漸漸地失去了風采，原因是什麼，因為網際網路浪潮是擋不住的嗎？難道Microsoft都沒有做任何努力？WinForm、.NET 1.0 1.1 2.0...、Avalon、Visual Basic .NET各種新的技術都無所用嗎？看看這篇吧。


Biculturalism，2003.12.14：
解釋windows一方的文化與unix一派的文化之間的不同與差異，既然用到"文化"這個字眼，沒有對兩方都有一定程度的了解是無法做出公平客觀的評價的。


The Perils of JavaSchools，2005.12.29：
談論美國電腦科學系所改採Java當做的教學語言所造成的傷害。文中論及，Java並不適合，不夠難，沒辦法在學生中區分出一流與二流的程式員；教OOP也不是，學校教的OOP只是記憶一堆術語，諸如inheritance、encapsulation、is-a vs has-a、polymorphism等等；不是說這些東西不該教或不用教，而是真正電腦科學該教的重點是proofs (recursion)、algorithms(recursion)、languages(lambda calculus)、operating systems (pointers)、compilers (lambda calculus)，真正該建立的能力是同時能以多層的抽象化方式來思考問題，有興趣的看看MIT教授在二三十年前的教學錄影，或是這裡也有Stanford最近的上課錄影，看看他們對電腦科學一年級生教些什麼。


Strategy Letter II: Chicken and Egg Problems，2000.05.24：
先有雞還是先有蛋，這問題不妨無著邊際討論一番，但是，這問題萬一發生在你的產品上，那該怎麼辦？譬如你要賣手機平台，如果很多消費者買，那就會吸引很多開發者寫軟體，如果很多開發者寫軟體，那就會吸引很多消費者買，沒完沒了，變成雞蛋問題。


Strategy Letter VI，2007.09.18：
隨著CPU越來越快，memory越來越大，寫程式似乎不需要在意效能了，錯了，新的戰場是在瀏覽器上跑著JavaScript的AJAX程式，依然還是有限制條件，網路頻寬與執行效率，但是，歷史會一再重演，有人汲汲營營於效能，有人忽略這些會被時間解決的問題（或者說，會有其他人出來解決），盡力地寫出功能更多更好的應用軟體，你覺得以長期而言，誰會贏呢？


Why are the Microsoft Office file formats so complicated? (And some workarounds)，2008.02.19：
以銅為鏡，可以正衣冠；以史為鏡，可以知興替。但世界變化的這麼快，技術演進的這麼迅速，連讓人喘口氣小憩一會兒的工夫都沒辦法了，哪來的時間讀歷史故事啊。雖說如此，但如果不了解一些技術的背後理念，不清楚前人作法之後的歷史因素，有些事情就很難理解。這篇敘述了Microsoft Office檔案格式看起來這麼古怪的原因。


Martian Headsets，2008.03.17：
闡述為什麼web發展到今日的局面，網站與瀏覽器之間多對多的關係，致使開發網站很困難，開發瀏覽器也很困難，原因就是沒有一個標準，啥？沒有標準？明明有W3C的HTML啊，錯了，看起來是，但其實沒有，原因詳見內文。



這只是我的選輯，事實上，還有很多好文章我沒有挑選進來，如果你覺得有遺珠之憾，請寫在留言板，謝謝。你可以到Joel Spolsky的網站去找其他文章，有以主題分類好了。