 |
-- 會員 / 註冊 --
|
 |
|
|
|
代碼之殤（原書第2版） ( 簡體 字) |
| 作者：（美 ）Eric Brechner 著 | 類別：1. -> 程式設計 -> 綜合 |
| 譯者： |
| 出版社：機械工業出版社 |  3dWoo書號： 35602
詢問書籍請說出此書號！【有庫存】
NT售價： 395 元 |
| 出版日：5/1/2013 |
| 頁數：313 |
| 光碟數：0 |
|
站長推薦：   |
| 印刷：黑白印刷 | 語系： ( 簡體 版 ) |
| |
加入購物車  │加到我的最愛
(請先登入會員) |
| ISBN：9787111416821 |
| 作者序 | 譯者序 | 前言 | 內容簡介 | 目錄 | 序 |
| (簡體書上所述之下載連結耗時費功, 恕不適用在台灣, 若讀者需要請自行嘗試, 恕不保證) |
| 作者序： |
| 譯者序： |
前言：獻給當初對我說“為什么不由你來寫”的人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
請注意，上面的郵箱地址不對微軟的軟件產品提供支持。 |
內容簡介：本書是《代碼大全》的姊妹篇，資深軟件開發專家30余年工作經驗結晶，被譽為“軟件行業的財富”，微軟公司軟件工程師必讀之書。它從軟件開發流程、技術、方法、項目管理、團隊管理、人際溝通等多角度總結出90余個具有代表性的問題（大多數問題可能會給公司或軟件項目帶來毀滅性災難），并給出了問題的解決方案和最佳實踐，值得所有軟件工程師和項目管理者研讀。
本書將這90余個問題分為10章：第1章討論如何通過管理風險、范圍和溝通來保障項目按時完成；第2章介紹消除經驗主義的大量過程改進的方法與技巧；第3章討論消除低效率的策略；第4章主要討論開發者與其他工種之間的關系；第5章重點闡釋軟件質量問題；第6章解析軟件設計的基本原理和錯綜復雜的本性；第7章探討如何規劃職業生涯；第8章分析工作與生活中存在的缺點的原因與糾正措施；第9章討論如何進行有效管理；第10章分析如何成功應對一個軟件業務所面臨的挑戰。 |
目錄：本書贊譽
譯者序
序
前言
第1版前言
第1章項目管理失當1
2001年6月1日：“開發時間表、飛豬和其他幻想”2
2001年10月1日：“竭盡所能，再論開發時間表”4
2002年5月1日：“我們還開心嗎？分診的樂趣”7
2004年12月1日：“向死亡進軍”11
2005年10月1日：“揭露真相”14
2008年9月1日：“我得估算一下”18
2009年5月1日：“一切從產品開始”21
2009年9月1日：“按計劃行事”25
2010年5月1日：“敏捷的團隊合作”28
第2章過程改進，沒有靈丹妙藥31
2002年9月2日：“六西格瑪？饒了我吧！”32
2004年10月1日：“精益：比五香熏牛肉還好”33
2005年4月1日：“客戶不滿”39
2006年3月1日：“敏捷子彈”44
2007年10月1日：“你怎么度量你自己？”50
2010年10月1日：“有我呢。”54
2010年11月1日：“我在纏著你嗎？Bug報告。”58
2010年12月1日：“生產第一”62
2011年2月1日：“周期長度——生產力的老生常談”65
第3章根除低下的效率70
2001年7月1日：“遲到的規范書：生活現實或先天不足”71
2002年6月1日：“閑置人手”73
2004年6月1日：“我們開會的時候”77
2006年7月1日：“停止寫規范書，跟功能小組呆在一起”79
2007年2月1日：“糟糕的規范書：該指責誰？”82
2008年2月1日：“路漫漫，其修遠——分布式開發”85
2008年12月1日：“偽優化”89
2009年4月1日：“世界，盡在掌握”91
2011年4月1日：“你必須做個決定”94
第4章跨越工種98
2002年4月1日：“現代臨時夫婦？開發與測試”99
2004年7月1日：“感覺性急——測試者的角色”101
2005年5月1日：“模糊邏輯——君子之道”105
2005年11月1日：“廢除工種——有什么理由搞專業化？”109
2009年1月1日：“持續工程的鬼話”111
2011年5月1日：“測試不該不受尊重”114
第5章軟件質量不是夢118
2002年3月1日：“你對你的安全放心嗎”119
2002年11月1日：“牛肉在哪里？為什么我們要質量”121
2004年4月1日：“軟件發展之路——從手工藝到工程”127
2005年7月1日：“復審一下這個——審查”131
2006年10月1日：“對質量的大膽預測”136
2008年5月1日：“碰撞測試：恢復”138
2008年10月1日：“盯緊標稱”142
第6章有時間就做軟件設計146
2001年9月1日：“錯誤處理的災難”147
2002年2月1日：“太多的廚師弄餿了一鍋好湯——唯一權威”149
2004年5月1日：“通過設計解決”151
2006年2月1日：“質量的另一面——設計師和架構師”155
2006年8月1日：“美妙隔離——更好的設計”158
2007年11月1日：“軟件性能：你在等什么？”161
2008年4月1日：“為您效勞”164
2008年8月1日：“我的試驗成功了！（原型設計）”167
2009年2月1日：“綠野中長滿蛆了”170
第7章職業生涯歷險記174
2001年12月1日：“當熟練就是目標”175
2002年10月1日：“人生是不公平的——考核曲線”177
2006年11月1日：“職業階段上的角色”180
2007年5月1日：“與世界相連”183
2007年11月1日：“找個好工作——發現新角色”187
2007年12月1日：“要么帶頭做事，要么唯命是從，要么趕緊離開”190
2008年7月1日：“猩猩套裝中的機遇”194
2010年3月1日：“我是很負責的”196
2010年4月1日：“新來的伙計”200
2010年６月１日：“升級”203
2010年９月１日：“輝煌時代”207
2011年１月１日：“個體領導者”210
第8章自我完善213
2002年12月1日：“合作還是分道揚鑣——協商”214
2005年2月1日：“最好學會平衡生活”216
2005年6月1日：“有的是時間”219
2005年8月1日：“寓利于樂，控制你的上司”224
2006年4月1日：“你在跟我講嗎？溝通的基礎”228
2007年3月1日：“不是公開與誠實那么簡單”231
2009年3月1日：“我聽著呢”234
2009年7月1日：“幻燈片”236
2009年12月1日：“不要悲觀”240
2010年8月1日：“我捅婁子了”243
2011年3月1日：“你也不賴”245
第9章成為管理者，而不是邪惡的化身248
2003年2月1日：“不僅僅是數字——生產力”249
2004年9月1日：“面試流程之外”251
2004年11月1日：“最難做的工作——績效不佳者”255
2005年9月1日：“隨波逐流——人才的保持和流動”258
2005年12月1日：“管理我在行”262
2006年5月1日：“比較的惡果——病態團隊”266
2008年3月1日：“必須改變：掌控改變”269
2009年6月1日：“獎賞，很難”272
2009年10月1日：“招人總是后悔”275
2009年11月1日：“管理餿了”278
2010年1月1日：“一對一與多對多”280
2010年7月1日：“文化沖擊”284
第10章微軟，你會喜歡它的287
2001年11月1日：“我是怎樣懂得不再焦慮并愛上重組的”288
2005年3月1日：“你的產品單元經理是個游民嗎？”290
2006年9月1日：“有幸成為Windows的主宰者”293
2006年12月1日：“Google：嚴重的威脅還是糟糕的拼寫？”298
2007年4月1日：“中年危機”301
2008年11月1日：“虛無主義及其他的創新毒藥”305
2010年2月1日：“我們是功能型的嗎？”308
術語表312 |
| 序： |
|
