2010/06/14

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 SpecificationsPart 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的網站去找其他文章,有以主題分類好了。

1 comment:

  1. Anonymous19/7/10 15:11

    Interesting. You do a lot of homework, thx

    ReplyDelete