代碼之殤(原書第2版)

代碼之殤(原書第2版)

《代碼之殤(原書第2版)》是2013年5月北京華章圖文信息有限公司出版的圖書,作者是Eric Brechner。

基本介紹

  • 中文名:代碼之殤(原書第2版)
  • 譯者:林鋒
  • 著作權:北京華章圖文信息有限公司
  • 書號:978-7-1114-1682-1
  • 作者:【美】Eric Brechner
  • 類型:計算機
  • 出版時間:2013年05月01日
  • 紙書價格:79.0
內容簡介,圖書目錄,作者簡介,

內容簡介

如果你想了解禮儀,你會直接光顧網站MissManners;如果你在戀愛上刪院戀遇到什麼麻煩,你可能就會瀏覽論壇DearAbby;
如果你想了解微軟到底出了什麼狀況以及一位名叫I.M.Wright的大個頭到底是怎么辦事的,那么這本書就是為你而寫的。I.M.Wright就是在微軟眾所周知的EricBrechner。
《代碼之殤(原書第2版)》是《代碼大全》的姊妹篇,資深軟體開發專家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

作者簡介

Eric Brechner 資深軟體開發專家,擁有30餘年開發經驗,現就職於微軟公司,擔任“卓越開發”部門總監。曾在Bank Leumi、Jet Propulsion Laboratory、GRAFTEK、Silicon Graphics、Boeing等公司供職,擔任過開發部門負責人、開發部經理、開發部總裁等職務。從2001年開始為微軟公司員工撰寫“Hard Code”專欄,該欄目在微軟內部影響十分廣泛,幾乎是每一位工程師必讀的,從而也激起了關於最佳實踐的廣泛討論。如今,“Hard Code”專欄中的有益觀點和真知灼見走出微軟,走向整個軟體開發社區,所有軟體開發者都能從中受益。
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

作者簡介

Eric Brechner 資深軟體開發專家,擁有30餘年開發經驗,現就職於微軟公司,擔任“卓越開發”部門總監。曾在Bank Leumi、Jet Propulsion Laboratory、GRAFTEK、Silicon Graphics、Boeing等公司供職,擔任過開發部門負責人、開發部經理、開發部總裁等職務。從2001年開始為微軟公司員工撰寫“Hard Code”專欄,該欄目在微軟內部影響十分廣泛,幾乎是每一位工程師必讀的,從而也激起了關於最佳實踐的廣泛討論。如今,“Hard Code”專欄中的有益觀點和真知灼見走出微軟,走向整個軟體開發社區,所有軟體開發者都能從中受益。

相關詞條

熱門詞條

聯絡我們