本書是《代碼大全》的姊妹篇，資深軟件開發專家30余年工作經驗結晶，被譽為“軟件行業的財富”，微軟公司軟件工程師必讀之書。它從軟件開發流程、技術、方法、項目管理、團隊管理、人際溝通等多角度總結出90余個具有代表性的問題（大多數問題可能會給公司或軟件項目帶來毀滅性災難），并給出了問題的解決方案和最佳實踐，值得所有軟件工程師和項目管理者研讀。

本書將這90余個問題分為10章：第1章討論如何通過管理風險、范圍和溝通來保障項目按時完成；第2章介紹消除經驗主義的大量過程改進的方法與技巧；第3章討論消除低效率的策略；第4章主要討論開發者與其他工種之間的關系；第5章重點闡釋軟件質量問題；第6章解析軟件設計的基本原理和錯綜復雜的本性；第7章探討如何規劃職業生涯；第8章分析工作與生活中存在的缺點的原因與糾正措施；第9章討論如何進行有效管理；第10章分析如何成功應對一個軟件業務所面臨的挑戰。

獻給當初對我說“為什么不由你來寫”的人Bill Bowlus。

獻給當初對我說“好的，我幫你編輯一下”的人我的妻子。

你手上拿著的是一本關于最佳實務的書，它會比較乏味，但也許會有點吸引力，你能從中得到知識，讀后甚至對你產生些許影響，但讀起來肯定是干巴巴而無趣的。為什么這么說呢？

最佳實務的書是乏味的，因為這個“最佳”是跟具體的項目、具體的人、他們的目標以及偏好緊密相關的。一個實務是不是“最佳”，大家可能看法不一。作者必須把實務列舉出來讓讀者自己選，并分析在什么時候、什么原因選擇哪個方案作為“最佳”。但是這種做法是現實的、是非分明的，它會讓人感到乏味和厭煩。通過多個案例的研究使原本模棱兩可的概念涇渭分明，從而會使文字有味一些，但作者仍必須把選擇的機會留給讀者，否則作者就會顯得傲慢、教條并且死板。

然而，人們喜歡看到傲慢、教條、死板的學者之間的針鋒相對。大家喜歡引用學者們的觀點片段，與朋友和同事一起討論。為什么不將對這些最佳實務的爭論作為觀點欄目來發表呢？唯一的條件就是只要有人愿意將自己扮演成一個思想保守的傻瓜。

本書的由來

2001年4月，在歷經了Bank Leumi、Jet Propulsion Laboratory、GRAFTEK、Silicon Graphics及Boeing等公司總共16年的職業程序員生涯，并在微軟做了6年的程序員和經理之后，我轉而加入了微軟內部的一個以在公司范圍內傳播最佳實務為職責的團隊。當時這個組正在運作發行一個名叫《Interface》的月刊網絡雜志的項目。它很有意義且富有知識性，但同樣也是干巴巴而無趣的。我那時建議增加一個觀點欄目。

我的上司Bill Bowlus建議由我來寫。我拒絕了。作為一個半大孩子，我努力使自己成為一個協調員，撮合多方產生成果，而成為一個愛嘮叨的實務學者會毀掉我的名譽和效力。因此，我當時的想法是說服一個大家公認的偏執的工程師來寫，他可能是我在微軟6年工作經歷中接觸過的一位特別固執的開發經理。

但Bill指出，我有22年的開發經驗，4年的開發管理經驗，寫作技巧也還行，而且有足夠的態度來做這件事，我只需要放下自身的心理包袱。另外，其他的開發經理都忙于常規的工作，不可能每個月來為我們寫一些個人觀點。最后Bill和我想出了一個用筆名撰稿的點子，于是“代碼之殤”（Hard Code）欄目誕生了。

從2001年6月開始，我使用“IMWright，微軟逍遙的開發經理”（IMWright,Microsoft development manager at large）這個署名為微軟的開發者和他們的經理寫了91個“代碼之殤”觀點欄目。這些欄目的標簽行都打上了“絕對誠實，直言不諱”（Brutally honest，no pulled punches）的標語。每個月，有成千上萬的微軟工程師和經理會閱讀這些欄目。

前16個欄目在內部網絡雜志《Interface》上發表了。這些欄目都是編輯（Mark Ashley和Liza White）給我分配的。我和《Interface》的美工Todd Timmcke還一起制作了作者的很多搞怪照片。當網絡雜志停刊的時候，我才得以有喘息的機會，但也停止了寫作。

14個月之后，在我們組的編輯Amy Hamilton（Blair）、Dia Reeves、Linda Caputo、Shannon Evans和Marc Wilson的幫助下，我又開始在內部站點上發表我的欄目。2006年11月，我將所有的欄目轉移到一個內部的SharePoint博客上。

2007年春天，正當我打算度過幾年前獎勵給我的假期的時候，我現在的經理Cedric Coco給了我在休假期間將《代碼之殤》出版成書的授權。而微軟出版社的Ben Ryan也同意了。同年，本書第1版出版。

除了我已經提及的人，我還想感謝《Interface》的其他成員（Susan Fario、Bruce Fenske、Ann Hoegemeier、John Spilker和John Swenson），其他幫助本書出版的人（Suzanne Sowinska、Alex Blanton、Scott Berkun、Devon Musgrave和Valerie Wolley），支持我的管理層（Cedric Coco、Scott Charney和John Devaan），曾審核過我的欄目并提出過很多主題的團隊成員（William Adams、Alan Auerbach、Adam Barr、Eric Bush、Scott Cheney、Jennifer Hamilton、Corey Ladas、David Norris、Bernie Thompson、James Waletzky、Don Willits和Mitch Wyle），以及寫下第1版“前言”的Mike Zintel。關于第2版，我想重點提下本書的審核人員及長期讀者（Adam Barr、Bill Hanlon、Bulent Elmaci, Clemens Szyperski、Curt Carpenter、David Anson、David Berg、David Norris、Eric Bush、Irada Sadykhova、James Waletzky、JDMeier、Jan Nelson、Jennifer Hamilton、Josh Lindquist、Kent Sullivan、Matt Ruhlen、Michael Hunter、Mitchell Wyle、Philip Su、Rahim Sidi、Robert Deupree（Jr）、William Adams和William Lees）；還有James Waletzky，他在我休假的時候為我的讀者寫了兩篇專欄文章；Adam Barr和Robert Deupree（Jr），他們發動我為專欄記錄了一段播客并發布出去；Devon Musgrave和Valerie Woolley，是他們讓第2版順利出版；我的上司（Peter Loforte和Curt Steeb）對我的努力給予了莫大的支持；Mitch為我寫了第2版的“序”；以及我的妻子Karen，當我讓編輯加入Xboxcom工作時，她接手了我的專欄編輯工作。

最后，我要感謝我才華出眾的中學英語老師（Alan Shapiro），以及那些慷慨給予我反饋的讀者們。尤其是，我還要感謝妻子Karen和兒子Alex和Peter，他們讓我做任何事情都充滿信心。

本書的讀者對象

組成本書的 91個觀點欄目最初是寫給微軟的開發者及其經理看的，盡管它們也是我過去在軟件行業6個不同的公司、32年的工作經驗中提煉出來的。編輯和我一起修改了語言表達，注解了那些微軟內部的特殊用語，使得本書適合于所有軟件工程師和工程經理閱讀。

我在這些欄目中表達的觀點是我個人的，不代表我現在和以前任職過的任何一家公司，包括微軟。我在欄目中的注解以及本簡介中的言論同樣都是我個人的，與任何公司無關。

本書的結構

根據主題的不同，我把所有欄目分成10章。前6章剖析了軟件開發流程，接下來3章重點討論人的問題，最后1章批判軟件業務運轉方式。解決這些問題的工具、技巧和建議遍布全書。本書的最后還附有術語表方便大家參考。

每一章的各個欄目均按照當初在微軟內部發表的時間順序排列。每章開頭我都給出了一個簡短的介紹，隨后就是當初我以“IMWright”筆名發表的欄目內容。當將其編輯成書的時候，我還適時在欄目中加上了“作者注”，以解釋微軟的術語，提供更新內容或者額外的背景知識。

編輯和我盡力保持原有欄目的完整性。我們做的工作僅僅是糾正語法和內部引用。稱得上改動的其實只有一處：就是將原來一個叫“你被解雇了”的欄目標題改成了“最難做的工作——績效不佳者”，因為以前那個標題太容易讓人誤解了。

每個欄目都以一段激昂的演說開場，然后是問題根源的分析，最后以我對這個問題如何改善的建議結束。我酷愛文字游戲、頭韻和通俗文化，因此欄目中充斥著這些東西。特別是大部分欄目的標題和副標題都直接取材于歌詞、電影對白和諺語。是的，我自娛自樂，但撰寫這些欄目確實給我帶來了些許樂趣，同時也使我得到了痛快宣泄。希望你也會喜歡！

微軟的組織結構

因為這些欄目最初是寫給微軟的內部員工看的，因此有必要簡要了解一下微軟以及我在工作中扮演的角色，這有助于更好地理解這些文字。

目前，微軟的產品開發分成七大業務部門，各個部門相應負責我們的主營產品——Windows、Office、Windows Phone、Interactive Entertainment（包括Xbox）、服務器軟件及工具（包括Windows Server和Visual Studio）、Dynamics以及在線服務軟件（包括Bing與MSN）。

每個部門大約包含20個獨立的產品單元或管理小組。通常情況下，這些產品單元共享源代碼控制、創建、安裝、工作條目跟蹤和項目協調（包括價值主張、里程碑安排、發布管理和持續性工程）。除了這些相應的服務之外，產品單元或小組還有高度的自主權，可以對產品、流程和人員做出自己的安排。

 持續性工程（sustained engineering）指直接發布軟件產品而不像通常先出測試版改進后再出正式版，產品發布后根據用戶使用情況再改進，然后再次發布新版本，如此反復。——譯者注

一個典型的管理小組通常由三個專職經理組成：項目組項目經理（Group Program Manager ，GPM）、開發經理（Development Manager）和測試經理（Test Manager）。一個產品開發單元通過這三個專職經理向產品單元經理（Product Unit Manager，PUM）負責。如果沒有產品單元經理，那么他們分別向他們的上司并最終向部門主管匯報。其他工程領域，比如用戶體驗、內容發布（比如在線幫助）、創建和實施，這些可能單獨對某個產品單元負責，也可能在整個部門中共享。

每個工程領域抽出一個或多個代表組成一個虛擬團隊，由該團隊向這三個專職經理負責并為一個單獨的功能模塊工作，該團隊稱為功能團隊（feature team）。有些功能團隊選擇敏捷方法，有些喜歡精益模型，有些采用傳統的軟件工程模型，有些則根據實際情況綜合采用上述多種方法。

微軟如何整合所有這些多樣化又獨立自治的團隊并使其朝向一個共同的目標有效地工作呢？這就是部門公共項目協調組所要扮演的角色了。例如，部門的價值主張是為所有的專職管理小組和他們的功能團隊設置統一的關鍵示例、質量尺度和準則。

示范工具和文檔

本書提到的稱為“在線資料”的示范工具和文檔，都可以通過如下地址下載：

http://gomicrosoftcom/FWLink/?Linkid 220641

在線資料列表

工具欄目 章節

SprintBacklogExamplexls；SprintBacklogTemplatexlt敏捷子彈2

ProductBacklogExamplexls；ProductBacklogTemplatexlt敏捷子彈2

Spectemplatedoc；Specchecklistdoc糟糕的規范書：該指責誰？3

InspectionWorksheetExamplexls；InspectionWorksheetTemplatexlt；Pugh Concept Selection Examplexls復審一下這個5

InterviewRolePlayingdoc面試流程之外9

系統要求

本書提供的工具都是微軟的Office Excel 2003和Office Word 2003格式的。只要你的電腦上安裝有Word Viewer和Excel Viewer，就能使用這些文件。你也可以從如下站點下載這兩個應用程序：

http://wwwmicrosoftcom/downloads/en/detailsaspx?familyid=941b34703ae94aee8f43c6bb74cd1466&displaylang=en

勘誤及圖書支持

我們盡最大的努力保證本書及其附屬內容準確無誤。自本書出版以來發現的錯誤已經發布在oreillycom上的Microsoft Press站點：

http://gomicrosoftcom/FWLink/?Linkid=220642

如果你發現有錯誤還未公布出來，可以通過這個網站告知我們。如果你需要更多幫助，請發Email到Microsoft Press圖書支持部：

mspinput@microsoftcom

請注意，上面的郵箱地址不對微軟的軟件產品提供支持。