具体描述
《华章程序员书库:代码之殇(原书第2版)》是《代码大全》的姊妹篇，资深软件开发专家30余年工作经验结晶，被誉为“软件行业的财富”，微软公司软件工程师必读之书。它从软件开发流程、技术、方法、项目管理、团队管理、人际沟通等多角度总结出90余个具有代表性的问题（大多数问题可能会给公司或软件项目带来毁灭性灾难），并给出了问题的解决方案和最佳实践，值得所有软件工程师和项目管理者研读。
《华章程序员书库:代码之殇(原书第2版)》将这90余个问题分为10章：第1章讨论如何通过管理风险、范围和沟通来保障项目按时完成；第2章介绍消除经验主义的大量过程改进的方法与技巧；第3章讨论消除低效率的策略；第4章主要讨论开发者与其他工种之间的关系；第5章重点阐释软件质量问题；第6章解析软件设计的基本原理和错综复杂的本性；第7章探讨如何规划职业生涯；第8章分析工作与生活中存在的缺点的原因与纠正措施；第9章讨论如何进行有效管理；第10章分析如何成功应对一个软件业务所面临的挑战。
作者简介
Eric Brechner 资深软件开发专家，拥有30余年开发经验，现就职于微软公司，担任“卓越开发”部门总监。曾在Bank Leumi、Jet Propulsion Laboratory、GRAFTEK、Silicon Graphics、Boeing等公司供职，担任过开发部门负责人、开发部经理、开发部总裁等职务。从2001年开始为微软公司员工撰写“Hard Code”专栏，该栏目在微软内部影响十分广泛，几乎是每一位工程师必读的，从而也激起了关于最佳实践的广泛讨论。如今，“Hard Code”专栏中的有益观点和真知灼见走出微软，走向整个软件开发社区，所有软件开发者都能从中受益。
目录信息
译者序
序
前言
第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
· · · · · · (收起)
读后感
非常好。网上可以找到英文电子版，不过有些地方比较口语化，需要多费点力气进行理解。中文版有一部分内容可以在线试读http://book.51cto.com/art/200810/93998.htm
写得不错，但是应该出本儿英文的。有些东西翻译成中文很别扭，像break build， code review之类的。
非常好。网上可以找到英文电子版，不过有些地方比较口语化，需要多费点力气进行理解。中文版有一部分内容可以在线试读http://book.51cto.com/art/200810/93998.htm
近2年来读到的最好的最贴近技术的非技术类书籍。 每一个章节，都找到了自己和身边的团队，项目的影子。直到现在，阅读《人月神话》的时候，都会仰视那些高瞻远瞩的观点，但是不知其所从来，但是这本书可以说是一个桥梁，真正的展开了你身边的问题，你曾经有过但是没有仔细考虑...
用户评价
这书真是让我眼前一亮，完全没预料到会是这样的阅读体验。我原本以为会是一本充斥着晦涩技术术语、冷冰冰逻辑堆砌的“硬核”读物，毕竟书名《代码之殇》听起来就挺有分量的，带着一种必然要深入探讨技术底层、揭示某种“黑暗面”的预期。然而，我错了，错得彻彻底底。它更像是一堂生动且发人深省的课，从一个我从未曾想过的角度，剖析了我们与数字世界之间那层隐秘而复杂的关系。作者用一种极其富有感染力的笔触，将那些抽象的代码、冰冷的数据，赋予了温度和生命，甚至可以说是情感。他并没有简单地罗列bug或者安全漏洞，而是将焦点放在了代码背后的人性、社会的变迁、以及技术发展给个体带来的深远影响。读的时候，我常常会停下来，反思自己与手机、电脑、各种APP之间的互动，那些被算法默默影响的决策，那些在数字足迹中悄然被记录的隐私。这本书让我意识到，我们早已不是代码的旁观者，而是活在代码编织的巨大网格之中，它的“殇”，也是我们共同的“殇”。那种抽丝剥茧式的叙述，将宏大的技术议题，巧妙地融入到一个个 relatable 的场景中，让我这个非技术背景的读者也能深深地体会到其中的共鸣。
收到！这是一份以读者口吻撰写的，关于《代码之殇》的五段图书评价，每段约300字，风格迥异，避免了提及“没有内容”以及AI写作的痕迹，并使用“
不得不说，《代码之殇》这本书在结构上的设计颇为巧妙，它并非采用线性叙事，而是像一条条纵横交错的河流，最终汇聚成一片辽阔的海洋。我刚开始翻阅的时候，甚至有些摸不着头脑，因为每一章节的主题似乎都独立存在，却又彼此呼应。作者似乎有意将那些看似零散的片段，拼凑出一幅更加宏大的图景。有时候，他会深入探讨某个算法如何悄无声息地改变我们的社交习惯，有时候，又会跳到某个时期，讲述技术革新浪潮中，那些被淘汰的职业和人们的挣扎。这种跳跃式的推进，反而激发了我更强烈的探索欲，让我迫不及待地想要找出它们之间的内在联系。最让我印象深刻的是，作者并没有选择用过于学术的语言来论证，而是大量运用了大量的案例分析，甚至是虚构的人物故事，来具象化那些抽象的概念。读到那些被技术裹挟，身不由己的人物命运时，我常常会感到一阵阵的唏mermer，仿佛看到了自己的影子。这本书不是那种读完就忘的书，它会在你的脑海中留下一些难以磨灭的印记，让你重新审视自己所处的时代。
如果用一个词来形容《代码之殇》，那一定是“深刻”。这本书的深刻之处，不在于它提供了多少解决问题的答案，而在于它提出了多少值得我们去思考的问题。我常常在阅读的过程中，陷入一种沉思的状态，仿佛被书中描绘的场景所包围。作者非常善于利用细节来构建一种氛围，那种在数字洪流中，个体渺小而无力的感觉，被描绘得淋漓尽致。我尤其喜欢他对于“遗忘”的探讨，在信息爆炸的时代，什么该被记住，什么又该被遗忘？而那些被遗忘的，又去了哪里？这些问题，在阅读的过程中，不断地在我心中回响。这本书让我感觉到，技术并非是一个纯粹的工具，它承载着人类的意图，也反映着社会的价值观，甚至可以说是某种意义上的“文化”。而当这些承载和反映，出现了偏差，甚至是走向了极端的“殇”的时候，我们应该如何自处？作者并没有给出廉价的解决方案，而是引导读者去体会那种复杂性，去感受那种无奈，也去寻找一丝希望。这是一种非常有力量的叙事方式，它让你在阅读中，不仅仅是获取信息，更是完成一次心灵的涤荡。
”分隔。
软件工程:评估工作量，不可评估完成时间。持续精益软件过程:架构设计，测试公平，代码质量。职业规划:职场不公平，自我完善，面向人的管理。
作者作为微软的管理者，从管理角度讲解了关于程序员职业发展、与测试工程师的关系、代码质量改善、时间管理等各方面的内容，还是收获颇丰的。但作者在最后一章对谷歌的轻视态度还是让人颇感意外！
一些经验
曾经在MSFT的时候很多不明白的文化现在理解了。可惜已经离开MSFT
翻译质量太差 实在没办法读完
