程序员编码能力进阶：设计原本+代码之殇（套装共2册）

　　《代码之殇（原书第2版）》
　　本书赞誉
　　译者序
　　序
　　前言
　　第1版前言
　　第1章 项目管理失当
　　2001年6月1日：“开发时间表、飞猪和其他幻想”
　　2001年10月1日：“竭尽所能，再论开发时间表”
　　2002年5月1日：“我们还开心吗？分诊的乐趣”
　　2004年12月1日：“向死亡进军”
　　2005年10月1日：“揭露真相”
　　2008年9月1日：“我得估算一下”
　　2009年5月1日：“一切从产品开始”
　　2009年9月1日：“按计划行事”
　　2010年5月1日：“敏捷的团队合作”
　　第2章 过程改进，没有灵丹妙药
　　2002年9月2日：“六西格玛？饶了我吧！”
　　2004年10月1日：“精益：比五香熏牛肉还好”
　　2005年4月1日：“客户不满”
　　2006年3月1日：“敏捷子弹”
　　2007年10月1日：“你怎么度量你自己？”
　　2010年10月1日：“有我呢。”
　　2010年11月1日：“我在缠着你吗？Bug报告。”
　　2010年12月1日：“生产第一”
　　2011年2月1日：“周期长度--生产力的老生常谈”
　　第3章 根除低下的效率
　　2001年7月1日：“迟到的规范书：生活现实或先天不足”
　　2002年6月1日：“闲置人手”
　　2004年6月1日：“我们开会的时候”
　　2006年7月1日：“停止写规范书，跟功能小组呆在一起”
　　2007年2月1日：“糟糕的规范书：该指责谁？”
　　2008年2月1日：“路漫漫，其修远--分布式开发”
　　2008年12月1日：“伪优化”
　　2009年4月1日：“世界，尽在掌握”
　　2011年4月1日：“你必须做个决定”
　　第4章 跨越工种
　　2002年4月1日：“现代临时夫妇？开发与测试”
　　2004年7月1日：“感觉性急--测试者的角色”
　　2005年5月1日：“模糊逻辑--君子之道”
　　2005年11月1日：“废除工种--有什么理由搞专业化？”
　　2009年1月1日：“持续工程的鬼话”
　　2011年5月1日：“测试不该不受尊重”
　　第5章 软件质量不是梦
　　2002年3月1日：“你对你的安全放心吗”
　　2002年11月1日：“牛肉在哪里？为什么我们要质量”
　　2004年4月1日：“软件发展之路--从手工艺到工程”
　　2005年7月1日：“复审一下这个--审查”
　　2006年10月1日：“对质量的大胆预测”
　　2008年5月1日：“碰撞测试：恢复”
　　2008年10月1日：“盯紧标称”
　　第6章 有时间就做软件设计
　　2001年9月1日：“错误处理的灾难”
　　2002年2月1日：“太多的厨师弄馊了一锅好汤--唯一权威”
　　2004年5月1日：“通过设计解决”
　　2006年2月1日：“质量的另一面--设计师和架构师”
　　2006年8月1日：“美妙隔离--更好的设计”
　　2007年11月1日：“软件性能：你在等什么？”
　　2008年4月1日：“为您效劳”
　　2008年8月1日：“我的试验成功了！（原型设计）”
　　2009年2月1日：“绿野中长满蛆了”
　　第7章 职业生涯历险记
　　2001年12月1日：“当熟练就是目标”
　　2002年10月1日：“人生是不公平的--考核曲线”
　　2006年11月1日：“职业阶段上的角色”
　　2007年5月1日：“与世界相连”
　　2007年11月1日：“找个好工作--发现新角色”
　　2007年12月1日：“要么带头做事，要么唯命是从，要么赶紧离开”
　　2008年7月1日：“猩猩套装中的机遇”
　　2010年3月1日：“我是很负责的”
　　2010年4月1日：“新来的伙计”
　　2010年６月１日：“升级”
　　2010年９月１日：“辉煌时代”
　　2011年１月１日：“个体领导者”
　　第8章 自我完善
　　2002年12月1日：“合作还是分道扬镳--协商”
　　2005年2月1日：“最好学会平衡生活”
　　2005年6月1日：“有的是时间”
　　2005年8月1日：“寓利于乐，控制你的上司”
　　2006年4月1日：“你在跟我讲吗？沟通的基础”
　　2007年3月1日：“不是公开与诚实那么简单”
　　2009年3月1日：“我听着呢”
　　2009年7月1日：“幻灯片”
　　2009年12月1日：“不要悲观”
　　2010年8月1日：“我捅娄子了”
　　2011年3月1日：“你也不赖”
　　第9章 成为管理者，而不是邪恶的化身
　　2003年2月1日：“不仅仅是数字--生产力”
　　2004年9月1日：“面试流程之外”
　　2004年11月1日：“最难做的工作--绩效不佳者”
　　2005年9月1日：“随波逐流--人才的保持和流动”
　　2005年12月1日：“管理我在行”
　　2006年5月1日：“比较的恶果--病态团队”
　　2008年3月1日：“必须改变：掌控改变”
　　2009年6月1日：“奖赏，很难”
　　2009年10月1日：“招人总是后悔”
　　2009年11月1日：“管理馊了”
　　2010年1月1日：“一对一与多对多”
　　2010年7月1日：“文化冲击”
　　第10章 微软，你会喜欢它的
　　2001年11月1日：“我是怎样懂得不再焦虑并爱上重组的”
　　2005年3月1日：“你的产品单元经理是个游民吗？”
　　2006年9月1日：“有幸成为Windows的主宰者”
　　2006年12月1日：“Google：严重的威胁还是糟糕的拼写？”
　　2007年4月1日：“中年危机”
　　2008年11月1日：“虚无主义及其他的创新毒药”
　　2010年2月1日：“我们是功能型的吗？”
　　术语表
　　《设计原本：计算机科学巨匠Frederick P.Brooks的反思》
　　Managing in the Next socManaging in the Next society
　　译者序
　　前言
　　第一部分 设计之模型
　　第1章 设计的疑问
　　1.1 培根的结论对吗
　　1.2 什么是设计
　　1.3 何为实在？设计理念
　　1.4 对设计过程的思考
　　1.5 设计面面观
　　1.6 注释和参考文献
　　第2章 工程师怎样进行设计思维-理性模型
　　2.1 模型概览
　　2.2 该模型的构思从何而来
　　2.3 理性模型有哪些长处
　　2.4 注释和参考文献
　　第3章 理性模型有哪些缺陷
　　3.1 在初始阶段我们并不真正地知道目标是什么
　　3.2 我们通常不知晓设计树的样子-一边设计一边探索
　　3.3 （设计树上的）节点实际上不是设计决策，而是设计暂定方案
　　3.4 效用函数无法以增量方式求值
　　3.5 必要条件及其权重在持续变化
　　3.6 约束在持续变化
　　3.7 对理性模型的其他批评
　　3.8 尽管存在诸多缺陷和批评，理性模型依然顽固存在
　　3.9 那又如何？我们的设计过程模型真的那么事关紧要吗
　　3.10 注释和参考文献
　　第4章 需求、罪念以及合同
　　4.1 一段恐怖往事
　　4.2 殊为不幸，无独有偶
　　4.3 抵制需求膨胀和蠕变
　　4.4 罪念
　　4.5 合同
　　4.6 一种合同模型
　　4.7 注释和参考文献
　　第5章 有哪些更好的设计过程模型
　　5.1 为什么要有一个占主导地位的模型
　　5.2 共同演化模型
　　5.3 Raymond的集市模型
　　5.4 Boehm的螺旋模型
　　5.5 设计过程模型：第2～5章的讨论小结
　　5.6 注释和参考文献
　　第二部分 协作与远程协作
　　第6章 协作设计
　　6.1 协作在本质上是好的吗
　　6.2 团队设计是现代标准
　　6.3 协作的成本
　　6.4 挑战在于保持概念完整性
　　6.5 如何在团队设计中获得概念完整性
　　6.6 协作何时有帮助
　　6.7 对设计本身而言，协作何时无用
　　6.8 两人团队很神奇
　　6.9 对于计算机科学家意味着什么
　　6.10 注释和参考文献
　　第7章 远程协作
　　7.1 为什么要远程协作
　　7.2 就地取材-IBM System/360计算机系列的分布式开发（1961～1965）
　　7.3 让远程协作有效
　　7.4 远程协作的技术
　　7.5 注释和参考文献
　　第三部分 设计面面观
　　第8章 设计中的理性主义与实证主义之争
　　8.1 理性主义与实证主义
　　8.2 软件设计
　　8.3 我是一个根深蒂固的实证主义者
　　8.4 其他设计领域中的理性主义、实证主义与正确性验证
　　8.5 注释和参考文献
　　第9章 用户模型-宁错勿淆
　　9.1 定义明确的用户模型和使用模型
　　9.2 团队设计
　　9.3 如果实际情况难以预料，有什么对策
　　9.4 注释和参考文献
　　第10章 英寸、盎司、比特与美元-预算资源
　　10.1 何谓预算资源
　　10.2 钱不是万能的
　　10.3 同一种资源也会有不同风格，甚至有替代品
　　10.4 预算资源并非一成不变
　　10.5 那我们究竟该怎么办
　　10.6 注释和参考文献
　　第11章 约束是友非敌
　　11.1 约束
　　11.2 归结于一点
　　11.3 设计悖论：通用产品比专用产品更难设计
　　11.4 注释和参考文献
　　第12章 技术设计中的美学与风格
　　12.1 技术设计中的美学
　　12.2 揭开逻辑之美的面纱
　　12.3 技术设计中的风格
　　12.4 何谓风格
　　12.5 风格的特点
　　12.6 若要使风格保持一致，请将它写成文档
　　12.7 如何形成良好的风格
　　12.8 注释和参考文献
　　第13章 设计中的范例
　　13.1 全新的设计是罕见的
　　13.2 范例所扮演的角色
　　13.3 计算机和软件设计中的问题
　　13.4 研究范例的设计原理
　　13.5 应该用什么样的方式来改进基于范例的设计
　　13.6 范例-惰性、创新与自满
　　13.7 注释和参考文献
　　第14章 智者千虑，必有一失
　　14.1 错误
　　14.2 曾经最糟糕的计算机语言
　　14.3 JCL何至于此
　　14.4 经验教训
　　14.5 注释和参考文献
　　第15章 设计的分离
　　15.1 设计与使用和实现的分离
　　15.2 为什么分离
　　15.3 分离的结果
　　15.4 补救措施
　　15.5 注释和参考文献
　　第16章 展现设计的演变轨迹和理由
　　16.1 简介
　　16.2 知识网线性化
　　16.3 我们的设计演变轨迹记录
　　16.4 我们研究房屋设计过程的过程
　　16.5 深入设计过程
　　16.6 决策树与设计树
　　16.7 模块化与紧密集成的设计
　　16.8 Compendium和可选工具
　　16.9 DRed：一个诱人的工具
　　16.10 注释和参考文献
　　第四部分 一套计算机科学家梦寐以求的房屋设计系统
　　第17章 计算机科学家梦寐以求的房屋设计系统-从头脑到电脑
　　17.1 挑战
　　17.2 愿景
　　17.3 输入机构的愿景：从头脑到电脑
　　17.4 指定动词
　　17.5 指定名词
　　17.6 指定文字
　　17.7 指定状语
　　17.8 指定视点和视图
　　17.9 注释和参考文献
　　第18章 计算机科学家梦寐以求的房屋设计系统-从电脑到头脑
　　18.1 双向通道
　　18.2 视觉显示-多个并列显示的窗口
　　18.3 听觉展示
　　18.4 触觉展示
　　18.5 推而广之
　　18.6 可行性
　　18.7 注释和参考文献
　　第五部分 卓越的设计师
　　第19章 伟大的设计来自伟大的设计师
　　19.1 伟大的设计与产品过程
　　19.2 产品过程-优点和不足
　　19.3 观点碰撞：过程扼杀创新，但又不可避免，如何是好
　　19.4 注释和参考文献
　　第20章 伟大的设计师从哪里来
　　20.1 我们必须教会他们设计
　　20.2 我们必须为伟大设计而招募人才
　　20.3 我们必须有意识地培养他们
　　20.4 我们必须在管理他们时发挥想象力
　　20.5 我们必须积极地保护他们
　　20.6 把自己培养成一名设计师
　　20.7 注释和参考文献
　　第六部分 设计空间之旅：案例研究
　　第21章 案例研究：海滨小屋“View/360”
　　21.1 亮点和特性
　　21.2 背景介绍
　　21.3 目标
　　21.4 机会
　　21.5 约束条件
　　21.6 设计决定
　　21.7 考虑正面
　　21.8 小屋的尺寸
　　21.9 设想的开始
　　21.10 在设计之后，构建之前的设计改动
　　21.11 在框架和外墙完成和初次入住之后的设计改动
　　21.12 结果评估（在项目验收37年后）
　　21.13 学到的一般经验
　　第22章 案例研究：增加厢房
　　22.1 亮点和特性
　　22.2 背景介绍
　　22.3 目标
　　22.4 约束条件
　　22.5 非约束条件
　　22.6 事件
　　22.7 设计决定和迭代
　　22.8 结果评估-成功与缺憾
　　22.9 学到的一般经验
　　22.10 注释和参考文献
　　第23章 案例研究：厨房重新建模
　　23.1 亮点和特性
　　23.2 背景介绍
　　23.3 目标
　　23.4 机会
　　23.5 约束条件
　　23.6 关键宽度预算的推理
　　23.7 长度预算的推理
　　23.8 其他设计决定
　　23.9 结果评估
　　23.10 满足的其他迫切需求
　　23.11 在设计中使用图纸、CAD、模型、仿真模型和虚拟环境
　　23.12 学到的一般经验
　　23.13 注释和参考文献
　　第24章 案例研究：System/360体系结构
　　24.1 亮点和特性
　　24.2 项目介绍和相关背景
　　24.3 目标
　　24.4 机遇（截至1961年6月）
　　24.5 挑战和限制
　　24.6 最重大的设计决策
　　24.7 里程碑事件
　　24.8 结果评估
　　24.9 学到的一般经验
　　24.10 注释和参考文献
　　第25章 案例研究：IBM Operating System/360操作系统
　　25.1 亮点和特性
　　25.2 项目介绍和相关背景
　　25.3 接受挑战
　　25.4 设计决策
　　25.5 结果评估
　　25.6 设计师团队
　　25.7 学到的一般经验
　　25.8 注释和参考文献
　　第26章 案例研究：《Computer Architecture： Concepts and Evolution》 图书设计
　　26.1 亮点和特性
　　26.2 项目介绍和相关背景
　　26.3 项目目标
　　26.4 机遇
　　26.5 约束
　　26.6 设计决策
　　26.7 结果评估
　　26.8 经验教训
　　第27章 案例研究：联合计算中心组织：三角区大学计算中心
　　27.1 要点和特点
　　27.2 项目介绍和相关背景
　　27.3 目标
　　27.4 机遇
　　27.5 限制
　　27.6 设计决策
　　27.7 备选的董事会投票方案
　　27.8 结果评估
　　27.9 经验教训
　　27.10 注释和参考文献
　　第28章 推荐读物
　　致谢
　　参考文献

　　FrederickP.Brooks,Jr，著名计算机科学家、软件工程教父、美国两院院士、图灵奖和IEEE计算机先驱奖得主。他在计算机软硬件的架构与设计和软件工程领域有极其深厚的造诣，并取得了举世瞩目的成就。
　　他是IBMSystem/360计算机和OperatingSystem/360操作系统的项目经理和总设计师，还是IBMStretch和Harvest等沿续至今的计算机体系结构的总架构师。他不仅提出了软件工程领域具有深远影响的“没有银弹”的著名论点，而且著有软件工程领域的传世之作《人月神话》，畅销30余年，为软件行业的发展做出了巨大贡献。
　　此外，他在建筑设计方面也有十分深入的研究，曾参与北卡罗来纳大学的西特森厅的设计，是设计委员会的正式成员。
　　高博，资深软件开发工程师、架构师和项目经理，毕业于上海交通大学计算机系，在微软、惠普和盛大等国内外知名企业从事软件开发相关的工作近10年，积累了丰富的经验。对程序设计语言、软件测试方法学、软件架构设计、软件项目管理和云计算等技术方向和领域有浓厚的兴趣，并致力于这些方面的研究和实践。他热衷于分享，近年来翻译了《C++：99个常见编程错误》、《微软的软件测试之道》、《源码中国》、《研究之美》等多本经典著作，在业界颇有影响力。
　　朱磊，资深软件开发工程师，毕业于上海交通大学软件工程系，现就职于EMC上海卓越研发中心，担任软件开发工程师。业余时间潜心于技术的钻研，非常喜欢与人分享和交流，担任上海交通大学饮水思源论坛Java版版主已4年有余。曾参与过数本软件开发类著作的翻译。
　　王海鹏，资深软件开发工程师、架构师、咨询顾问和培训讲师，毕业于华东师范大学，有近20年软件行业从业经验，经验十分丰富。专注于软件架构及其方法学的研究，致力于提高软件开发的效率和品质。翻译经验颇丰，已为国内软件行业从业者们奉上了近20本经典著作，主题涵盖敏捷方法学、需求工程、UML建模和测试等多个领域。
　　EricBrechner，微软公司“卓越开发”部门总监，在软件行业拥有超过30年的经验积累。他曾担任过开发部门负责人、开发部经理、开发部总裁等工作，曾在BankLeumi、JetPropulsionLaboratory、GRAFTEK、SiliconGraphics、Boeing等公司从事职业程序员生涯，后加入微软公司。他从2001年开始为微软公司员工写“HardCode”栏目。自那以后，其观点栏目在微软内部成千上万的软件开发者之间，激起了无休无止的关于最佳实践的讨论——如今，这些观点走出了微软，走向了整个开发社区。

　　《代码之殇（原书第2版）》　　《代码之殇（原书第2版）》是《代码大全》的姊妹篇，资深软件开发专家30余年工作经验结晶，被誉为“软件行业的财富”，微软公司软件工程师必读之书。它从软件开发流程、技术、方法、项目管理、团队管理、人际沟通等多角度总结出90余个具有代表性的问题（大多数问题可能会给公司或软件项目带来毁灭性灾难），并给出了问题的解决方案和实践，值得所有软件工程师和项目管理者研读。　　《代码之殇（原书第2版）》将这90余个问题分为10章：第1章讨论如何通过管理风险、范围和沟通来保障项目按时完成；第2章介绍消除经验主义的大量过程改进的方法与技巧；第3章讨论消除低效率的策略；第4章主要讨论开发者与其他工种之间的关系；第5章重点阐释软件质量问题；第6章解析软件设计的基本原理和错综复杂的本性；第7章探讨如何规划职业生涯；第8章分析工作与生活中存在的缺点的原因与纠正措施；第9章讨论如何进行有效管理；第10章分析如何成功应对一个软件业务所面临的挑战。　　《设计原本：计算机科学巨匠FrederickP.Brooks的反思》　　如果说《人月神话》是近40年来所有软件开发工程师和项目经理们必读的一本书，那么《设计原本：计算机科学巨匠FrederickP.Brooks的反思》将会是未来数十年内从事软件行业的程序员、项目经理和架构师必读的一本书。它是《人月神话》作者、著名计算机科学家、软件工程教父、美国两院院士、图灵奖和IEEE计算机先驱奖得主Brooks在计算机软硬件架构与设计、建筑和组织机构的架构与设计等领域毕生经验的结晶，是计算机图书领域的又一史诗级著作。　　《设计原本：计算机科学巨匠FrederickP.Brooks的反思》从工程师和架构师的视角深入地探讨了设计的和过程，尤其是复杂系统的设计过程，旨在提高产品的实用性与有效性，以及设计的效率和优雅性。全书共28章，分为6个部分：第一部分（1~5章）主要讨论了什么是设计、设计过程的思考、设计的类别、理性模型及其缺陷、以及对一些好的设计过程模型的探讨；第二部分（6~7章）主要讨论了协作设计与远程协作；第三部分（8~16章）全面总结了设计中的各种原则、经验和教训，包括设计中理性主义与经验主义、用户模型、资源预算、约束、设计中的美学与风格、设计中的范本、设计的分离、设计的演变途径和理由，以及专业设计者为何会犯错；第四部分（17~18）探讨了建筑设计与计算机软硬件设计在设计思想和方法上的一些共同点和不同之处；第五部分（19~20章）探讨了卓越的设计和卓越的设计师之间的关系，以及如何培养卓越的设计师；第六部分（21~28章）通过各个领域的各种类型的案例进行了分析和研究，旨在深刻揭示隐藏在这些案例背后不变的设计过程和思想。　　除了从事计算机软硬件相关工作的读者应该阅读本书之外，其他领域的设计者、设计项目经理和设计理论研究人员也都能从《设计原本：计算机科学巨匠FrederickP.Brooks的反思》中找到大量宝贵资料。