推荐搞IT的你读读《软件随想录》
《軟件隨想錄（Joel on Software）》，這是我多年前看的一本書，也是對我影響很大大的一本書。這不是一本講軟件技術(shù)的書，但跟技術(shù)強相關(guān)，推薦給朋友們讀一下。
這本書嚴格來講，不是作者專門寫的書，是對作者 45 篇博客隨筆的合集——記錄了 2000-2004 年間的工作所感所悟。雖然不是按照時間順序來的，但整篇文集整體上散而不亂，而且獲得了第 15 屆 JOLT 大獎，被讀者譽為堪比《人月神話》的經(jīng)典軟件項目管理文集。
關(guān)于編程本身
軟件和互聯(lián)網(wǎng)行業(yè)本質(zhì)上都是屬于服務業(yè)：通過服務客戶、滿足客戶需求來賺取利潤，簡而言之，賣的是服務，是客戶體驗，誰給客戶的體驗好，誰就能賺到錢。
所以，為了甲方提供更好的服務，作為提供服務的乙方就得不斷地折騰自己，不斷的折騰自己，在一定意義上就意味著晚交付，但晚交付對甲方來說就是不好的服務體驗。這就是一個悖論。
所以從這點上來講，Joel on software 就是教我們在整個開發(fā)過程中怎么樣才能少折騰自己。
在本書中提到了著名的喬爾測試。是喬爾在 22 年前提的，現(xiàn)在已經(jīng)成為開發(fā)團隊的標準配置。
你們用源代碼管理系統(tǒng)嗎？
你們能一鍵編譯嗎？
你們做每日編譯嗎？
你們有 bug 數(shù)據(jù)庫嗎？
你們在寫新代碼前修改以前的代碼嗎？
你們的進度表是最新的嗎？
你們有軟件規(guī)格書嗎？
程序員的工作環(huán)境安靜嗎？
你們使用了能買到的最好的工具嗎？
你們有測試人員嗎？
你們面試時會要求應聘人員寫代碼嗎？
你們做過走廊可用性測試嗎？
喬爾應該特別重視功能規(guī)格書，用了整4篇的篇幅來講功能規(guī)格書：
為什么要寫
什么是規(guī)格書
怎么寫
以及寫作技巧
歸結(jié)起來就是：一是：為了減少日后與甲方的扯皮（節(jié)省溝通時間）；二是：為了自己能順利實現(xiàn) feature，防止推倒重來，所以寫規(guī)格書最根本的是讓甲乙雙方都看得懂。
喬爾在規(guī)格書中必寫的內(nèi)容：
免責聲明
作者
使用場景
非目標
概述
細節(jié)
待解決的問題
多角度的注解
規(guī)格書要與時俱進
其中我覺得 「非目標」 比較有意思。
每個開發(fā)者都會認為自己的功能是好的，要非實現(xiàn)不可，但軟件開發(fā)畢竟付出的是腦力和時間，從效費比上來論，就要去偽存真，把能不實現(xiàn)的就不要去觸碰，以減少在非必要功能上鋪張浪費，所以在規(guī)格書中就明確什么不能碰，真是個非常聰明的點子。
當然，規(guī)格書不可能是一成不變的，尤其是在中國這個社會，變與不變都是甲方爸爸一句話的事，喬爾也提到了，產(chǎn)品代碼開發(fā)完成之時，才是規(guī)格書定稿之日。
喬爾在書中提到了五個世界，就是軟件開發(fā)的五個基本方向：
盒裝軟件（2C的軟件）
內(nèi)部軟件（2B的軟件）
嵌入式軟件
游戲
用過即拋的代碼
每個方向注重的問題不一樣，產(chǎn)生問題的解決方法也不一樣，如果混淆的處理方法，那就是不斷地折騰自己。對于新入行的開發(fā)人員來講，要弄懂你們公司涉及的領(lǐng)域，以及理解老板為什么要這么做，理解了，就會減少很多負面的情緒。
比如喬爾講「2C」和「2B」的區(qū)別：
?內(nèi)部軟件和盒裝軟件的一個關(guān)鍵差異就是，在達到某個臨界點之后，再投入更多資金去提升內(nèi)部軟件的穩(wěn)定性和易用性，其邊際效果會有明顯降低，而對于盒裝軟件，不斷追求軟件的穩(wěn)定性和易用性，永遠符合經(jīng)濟定律，都是對公司核心競爭力的提升。所以令人嘆息的是，很多內(nèi)部軟件雖然能完美地實現(xiàn)既定的功能，但是質(zhì)量卻非常差。年輕、有熱情的開發(fā)者經(jīng)常會被潑冷水，勸他們不要再完善某個軟件了，因為已經(jīng)足夠好了，這通常會讓他們十分沮喪。
?對于游戲和嵌入式軟件來講，喬爾提到只能有一個版本.而一個版本，對質(zhì)量就有很高的要求，同時面臨的經(jīng)濟壓力也要求軟件盡可能一次到位?！?這個前提是單機游戲，這可能是因為在 2000 年左右，受帶寬的限制，大型網(wǎng)絡(luò)游戲還沒出現(xiàn)，你看現(xiàn)在的網(wǎng)絡(luò)游戲都是先推出再說，部分有 bug 可定時或隨時迭代更新。
關(guān)于管理開發(fā)者
不得不承認，管理程序開發(fā)者團隊與其他團隊是有差別的。
比如“獎勵有害論”：喬爾認為績效評估會給員工帶來巨大的壓力
?評價對于士氣的影響是一邊倒的：負面評價嚴重影響士氣，而正面評價對于士氣或生產(chǎn)效率沒有影響
?事實上，只要涉及腦力勞動者的，都脫離不了“文無第一、武無第二”的魔咒。文案、設(shè)計等工作者，都會對自己的作品感覺良好，獎勵是給小部分的人，那么大部分得不到獎賞的人心情難免會沮喪，喪失士氣。而且喬爾在評估機能失調(diào)這一章節(jié)，對這一現(xiàn)象再次進行了強調(diào)：
?每一次試圖對腦力工作成果進行定量評估，似乎都會以失敗而告終，并且對團隊造成巨大破壞
?對原有代碼推翻重來并不是好辦法，曾經(jīng)的網(wǎng)景公司，被喬爾反復引用. 最主要的一次就是網(wǎng)景公司的戰(zhàn)略性錯誤，網(wǎng)景瀏覽器發(fā)布到6.0beta版，5.0版沒有出現(xiàn)，是從4.0直接蹦過來的，6.0往后他們不再做代碼優(yōu)化，而是丟棄以前全部代碼，從頭開始寫一個已經(jīng)發(fā)行過的程序代碼，當幾年后最終改名為 Mozilla 的瀏覽器重新上市時，已經(jīng)沒了他們的立足之地?！?估計現(xiàn)在年輕人都不知道網(wǎng)景瀏覽器曾經(jīng)存在過。
普通的團隊，我們更期望于一個人能同時開展多個項目，而根據(jù)喬爾的經(jīng)驗：
?如果把一項任務指派給一個人，這個人能很好的完成任務；而當你把兩項任務同時指派給某個人的時候，通常的結(jié)果是兩件事都做不好。這個人要么做好其中一項任務，而完全不做另一項，要么會用比蝸牛還慢的速度同時做兩項任務。這是因為在編程任務之間進行切換的時間太長了。
?作為管理者要明白: 「程序員是單核單進程的CPU，工作要順序來」
關(guān)于企業(yè)發(fā)展
喬爾在 2000 年創(chuàng)立了 Fog Creek Software，這本博客合集當然也記錄了他的創(chuàng)業(yè)所感. 所以，對于從事軟件、互聯(lián)網(wǎng)創(chuàng)業(yè)的人來講，這也是一本啟蒙書。
喬爾講，如果你想在軟件行業(yè)取得成功，必須有一支完全理解并熱愛編程的管理團隊，但他們還必須理解并熱愛商業(yè)運作。
所以關(guān)于企業(yè)發(fā)展，作者用自己在微軟和朱諾的工作時的切身經(jīng)歷來闡明管理水平對商業(yè)的影響。
喬爾用了 5 個章節(jié)專門講企業(yè)發(fā)展戰(zhàn)略，他提出創(chuàng)業(yè)的兩種模式：
一種類似本杰瑞的慢慢的、自然的發(fā)展；
一種是類似亞馬遜這種靠大量資金的投入迅速做大
并指出最不可取的模式，就是在兩種模式之間搖擺不定。同時，他也給出了警告，這個行業(yè)不能形成標準化的規(guī)則：
?雖然能讓任何人都產(chǎn)出可憐但勉強過得去的業(yè)績水平，但同樣對真正有才華的人它是一種沉重的負擔，限制了他們的發(fā)展
?總結(jié)
書中喬爾在這三個方面的態(tài)度：
在編程上，追求效益的同時要少折騰自己；
在管理上，要想盡一切辦法促進開發(fā)人員的積極性，不做打擊士氣和積極性的事；
在創(chuàng)業(yè)上，一定要考慮商業(yè)運作，因為軟件行業(yè)的本質(zhì)還是要賺錢的。
《軟件隨想錄（卷一）》45章節(jié)的內(nèi)容遠不止講了這么多。從初入行編程語言選擇、開發(fā)工具的優(yōu)劣到軟件行業(yè)創(chuàng)業(yè)，都能在其中找到答案。
可以這樣說，只要是從事的軟件行業(yè)的或者想了解軟件行業(yè)的人，讀了它之后都會對這個行業(yè)有一種豁然開朗的感覺，別忘了這是一本快 20 年的書了。本書翻譯的有好有壞，翻譯比較好的，楊帆譯本、阮一峰譯本都還可以，當然，英文好的建議直接看英文原版。
關(guān)于作者
「喬爾·斯波爾斯基」 ：
1991 年，畢業(yè)于耶魯大學，并曾在 Microsoft 的 Excel 團隊工作，擔任項目經(jīng)理，負責在 Excel 5.0 中推出 VBA。
2000 年，創(chuàng)立了Fog Creek Software并推出了Joel on Software博客
2008 年，他與 Jeff Atwood 合作推出了Stack Overflow 程序員問答網(wǎng)站。使用為 Stack Overflow 提供支持的 Stack Exchange 軟件產(chǎn)品，Stack Exchange 網(wǎng)絡(luò)現(xiàn)在托管了 170 多個問答網(wǎng)站。
目前，擔任Stack Overflow、Glitch和HASH的董事會主席。
總結(jié)
以上是生活随笔為你收集整理的推荐搞IT的你读读《软件随想录》的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Natasha 4.0 探索之路系列(三
- 下一篇： ABP vNext微服务架构详细教程——