《代碼之殤》是2013年機械工業出版社出版的圖書，作者是Eric Brechner。本書主要介紹了如何通過管理風險、範圍和溝通來保障項目按時完成等。
基本介紹
- 書名：代碼之殤
- 作者：（美）Eric Brechner
- 原作品：I. M. Wright’s“Hard Code”：A Decade of Hard-Won Lessons from Microsoft，Second Edition
- 譯者：林鋒
- ISBN：9787111416821
- 頁數：422
- 定價：79.00元
- 出版社：機械工業出版社
- 出版時間：2013-4
- 裝幀：平裝
- 開本：16開
- 叢 書 名：華章程式設計師書庫
- 紙 張：膠版紙
編輯推薦,作者簡介,簡介,目錄,
編輯推薦
《代碼大全》姊妹篇，資深軟體開發專家30餘年工作經驗結晶
微軟公司軟體工程師必讀之書，被譽為“軟體行業的財悼拔奔己富”
從軟體開發流程、技術、方法、項目管理、團隊管理、人際溝通等多角度總結出90餘個具有代表性的問題並給出了解決方案，值得所有堡擔婚軟體工程師研讀
作者簡介
Eric Brechner，資深軟體開發專家，擁有30餘年開發經驗，現就職於微軟公司，擔任“卓越開發”部門總監。曾在Bank Leumi、Jet Propulsion Laboratory、GRAFTEK、Silicon Graphics、Boeing等公司供職，擔任過開發部門負責人、開發部經理、開發部總裁等職務。從2001年開始為微軟公司員工撰寫“Hard Code”專欄，該欄目在微軟內部影響十分廣泛，幾乎是每一位工程師必讀的，從而也激起了關應辣敬於最佳實踐的廣泛討論。如今，“Hard Code”專欄中的有益觀點和真知灼見走出微軟，走向整個軟體開探邀驗閥發社區，所有軟體開發者都能從中受益。
簡介
本書是《代碼大全》的姊妹篇，資深軟體開發專家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年6月1日：“升級”203
2010年9月1日：“輝煌時代”207
2011年1月1日：“個體領導者”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
第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年6月1日：“升級”203
2010年9月1日：“輝煌時代”207
2011年1月1日：“個體領導者”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
