代码之殇+编写可读代码的艺术（套装共2册）
《O’Reilly精品图书系列：编写可读代码的艺术》目录：
前言
第1章 代码应当易于理解
是什么让代码变得“更好”
可读性基本定理
总是越小越好吗
理解代码所需的时间是否与其他目标有冲突
最难的部分
第一部分 表面层次的改进
第2章 把信息装到名字里
查看完整
前言
第1章 代码应当易于理解
是什么让代码变得“更好”
可读性基本定理
总是越小越好吗
理解代码所需的时间是否与其他目标有冲突
最难的部分
第一部分 表面层次的改进
第2章 把信息装到名字里
查看完整
Eric Brechner，微软公司“卓越开发”部门总监，在软件行业拥有超过30年的经验积累。他曾担任过开发部门负责人、开发部经理、开发部总裁等工作，曾在Bank Leumi、Jet Propulsion Laboratory、GRAFTEK、Silicon Graphics、Boeing等公司从事职业程序员生涯，后加入微软公司。他从2001年开始为微软公司员工写“Hard Code”栏目。自那以后，其观点栏目在微软内部成千上万的软件开发者之间，激起了无休无止的关于最佳实践的讨论——如今，这些观点走出了微软，走向了整个开发社区。
《O’Reilly精品图书系列：编写可读代码的艺术》内容简介： 细节决定成败，思路清晰、言简意赅的代码让程序员一目了然；而格式凌乱、拖沓冗长的代码让程序员一头雾水。除了可以正确运行以外，优秀的代码必须具备良好的可读性，编写的代码要使其他人能在短的时间内理解才行。本书旨在强调代码对人的友好性和可读性。 《O’Reilly精品图书系列：编写可读代码的艺术》关注编码的细节，总结了很多提高代码可读性的小技巧，看似都微不足道，但是对于整个软件系统的开发而言，它们与宏观的架构决策、设计思想、指导原则同样重要。编码不仅仅只是一种技术，也是一门艺术，编写可读性高的代码尤其如此。如果你要成为一位优秀的程序员，要想开发出高质量的软件系统，必须从细处着手，做到内外兼修，本书将为你提供有效的指导。 主要内容： ·简化命名、注释和格式的方法，使每行代码都言简意赅。 ·梳理程序中的循环、逻辑和变量来减小复杂度并理清思路。 ·在函数级别解决问题，例如重新组织代码块，使…
查看完整
查看完整
《O’Reilly精品图书系列：编写可读代码的艺术》目录：
前言
第1章 代码应当易于理解
是什么让代码变得“更好”
可读性基本定理
总是越小越好吗
理解代码所需的时间是否与其他目标有冲突
最难的部分
第一部分 表面层次的改进
第2章 把信息装到名字里
选择专业的词
避免像tmp和retval这样泛泛的名字
用具体的名字代替抽象的名字
为名字附带更多信息
名字应该有多长
利用名字的格式来传递含义
总结
第3章 不会误解的名字
例子：Filter()
例子：Clip(text， length)
推荐用first和last来表示包含的范围
推荐用begin和end来表示包含/排除范围
给布尔值命名
与使用者的期望相匹配
例子：如何权衡多个备选名字
总结
第4章 审美
为什么审美这么重要
重新安排换行来保持一致和紧凑
用方法来整理不规则的东西
在需要时使用列对齐
选一个有意义的顺序，始终一致地使用它
把声明按块组织起来
把代码分成“段落”
个人风格与一致性
总结
第5章 该写什么样的注释
什么不需要注释
记录你的思想
站在读者的角度
最后的思考--克服“作者心理阻滞”
总结
第6章 写出言简意赅的注释
让注释保持紧凑
避免使用不明确的代词
润色粗糙的句子
精确地描述函数的行为
用输入/输出例子来说明特别的情况
声明代码的意图
“具名函数参数”的注释
采用信息含量高的词
总结
第二部分 简化循环和逻辑
第7章 把控制流变得易读
条件语句中参数的顺序
if/else语句块的顺序
条件表达式（又名“三目运算符”）
避免do/while循环
从函数中提前返回
臭名昭著的goto
最小化嵌套
你能理解执行的流程吗
总结
第8章 拆分超长的表达式
用做解释的变量
总结变量
使用德摩根定理
滥用短路逻辑
例子：与复杂的逻辑战斗
拆分巨大的语句
另一个简化表达式的创意方法
总结
第9章 变量与可读性
减少变量
缩小变量的作用域
只写一次的变量更好
最后的例子
总结
第三部分 重新组织代码
第10章 抽取不相关的子问题
介绍性的例子：findClosestLocation()
纯工具代码
其他多用途代码
创建大量通用代码
项目专有的功能
简化已有接口
按需重塑接口
过犹不及
总结
第11章 一次只做一件事
任务可以很小
从对象中抽取值
更大型的例子
总结
第12章 把想法变成代码
清楚地描述逻辑
了解函数库是有帮助的
把这个方法应用于更大的问题
总结
第13章 少写代码
别费神实现那个功能--你不会需要它
质疑和拆分你的需求
保持小代码库
熟悉你周边的库
例子：使用Unix工具而非编写代码
总结
第四部分 精选话题
第14章 测试与可读性
使测试易于阅读和维护
这段测试什么地方不对
使这个测试更可读
让错误消息具有可读性
选择好的测试输入
为测试函数命名
那个测试有什么地方不对
对测试较好的开发方式
走得太远
总结
第15章 设计并改进“分钟/小时计数器”
问题
定义类接口
尝试1：一个幼稚的方案
尝试2：传送带设计方案
尝试3：时间桶设计方案
比较三种方案
总结
附录 深入阅读
《代码之殇（原书第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日：“我们是功能型的吗？”
术语表
^ 收 起
前言
第1章 代码应当易于理解
是什么让代码变得“更好”
可读性基本定理
总是越小越好吗
理解代码所需的时间是否与其他目标有冲突
最难的部分
第一部分 表面层次的改进
第2章 把信息装到名字里
选择专业的词
避免像tmp和retval这样泛泛的名字
用具体的名字代替抽象的名字
为名字附带更多信息
名字应该有多长
利用名字的格式来传递含义
总结
第3章 不会误解的名字
例子：Filter()
例子：Clip(text， length)
推荐用first和last来表示包含的范围
推荐用begin和end来表示包含/排除范围
给布尔值命名
与使用者的期望相匹配
例子：如何权衡多个备选名字
总结
第4章 审美
为什么审美这么重要
重新安排换行来保持一致和紧凑
用方法来整理不规则的东西
在需要时使用列对齐
选一个有意义的顺序，始终一致地使用它
把声明按块组织起来
把代码分成“段落”
个人风格与一致性
总结
第5章 该写什么样的注释
什么不需要注释
记录你的思想
站在读者的角度
最后的思考--克服“作者心理阻滞”
总结
第6章 写出言简意赅的注释
让注释保持紧凑
避免使用不明确的代词
润色粗糙的句子
精确地描述函数的行为
用输入/输出例子来说明特别的情况
声明代码的意图
“具名函数参数”的注释
采用信息含量高的词
总结
第二部分 简化循环和逻辑
第7章 把控制流变得易读
条件语句中参数的顺序
if/else语句块的顺序
条件表达式（又名“三目运算符”）
避免do/while循环
从函数中提前返回
臭名昭著的goto
最小化嵌套
你能理解执行的流程吗
总结
第8章 拆分超长的表达式
用做解释的变量
总结变量
使用德摩根定理
滥用短路逻辑
例子：与复杂的逻辑战斗
拆分巨大的语句
另一个简化表达式的创意方法
总结
第9章 变量与可读性
减少变量
缩小变量的作用域
只写一次的变量更好
最后的例子
总结
第三部分 重新组织代码
第10章 抽取不相关的子问题
介绍性的例子：findClosestLocation()
纯工具代码
其他多用途代码
创建大量通用代码
项目专有的功能
简化已有接口
按需重塑接口
过犹不及
总结
第11章 一次只做一件事
任务可以很小
从对象中抽取值
更大型的例子
总结
第12章 把想法变成代码
清楚地描述逻辑
了解函数库是有帮助的
把这个方法应用于更大的问题
总结
第13章 少写代码
别费神实现那个功能--你不会需要它
质疑和拆分你的需求
保持小代码库
熟悉你周边的库
例子：使用Unix工具而非编写代码
总结
第四部分 精选话题
第14章 测试与可读性
使测试易于阅读和维护
这段测试什么地方不对
使这个测试更可读
让错误消息具有可读性
选择好的测试输入
为测试函数命名
那个测试有什么地方不对
对测试较好的开发方式
走得太远
总结
第15章 设计并改进“分钟/小时计数器”
问题
定义类接口
尝试1：一个幼稚的方案
尝试2：传送带设计方案
尝试3：时间桶设计方案
比较三种方案
总结
附录 深入阅读
《代码之殇（原书第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日：“我们是功能型的吗？”
术语表
^ 收 起
Eric Brechner，微软公司“卓越开发”部门总监，在软件行业拥有超过30年的经验积累。他曾担任过开发部门负责人、开发部经理、开发部总裁等工作，曾在Bank Leumi、Jet Propulsion Laboratory、GRAFTEK、Silicon Graphics、Boeing等公司从事职业程序员生涯，后加入微软公司。他从2001年开始为微软公司员工写“Hard Code”栏目。自那以后，其观点栏目在微软内部成千上万的软件开发者之间，激起了无休无止的关于最佳实践的讨论——如今，这些观点走出了微软，走向了整个开发社区。
《O’Reilly精品图书系列：编写可读代码的艺术》内容简介： 细节决定成败，思路清晰、言简意赅的代码让程序员一目了然；而格式凌乱、拖沓冗长的代码让程序员一头雾水。除了可以正确运行以外，优秀的代码必须具备良好的可读性，编写的代码要使其他人能在短的时间内理解才行。本书旨在强调代码对人的友好性和可读性。 《O’Reilly精品图书系列：编写可读代码的艺术》关注编码的细节，总结了很多提高代码可读性的小技巧，看似都微不足道，但是对于整个软件系统的开发而言，它们与宏观的架构决策、设计思想、指导原则同样重要。编码不仅仅只是一种技术，也是一门艺术，编写可读性高的代码尤其如此。如果你要成为一位优秀的程序员，要想开发出高质量的软件系统，必须从细处着手，做到内外兼修，本书将为你提供有效的指导。 主要内容： ·简化命名、注释和格式的方法，使每行代码都言简意赅。 ·梳理程序中的循环、逻辑和变量来减小复杂度并理清思路。 ·在函数级别解决问题，例如重新组织代码块，使其一次只做一件事。 ·编写有效的测试代码，使其全面而简洁，同时可读性更高。 《代码之殇（原书第2版）》内容简介： 《代码之殇（原书第2版）》是《代码大全》的姊妹篇，资深软件开发专家30余年工作经验结晶，被誉为“软件行业的财富”，微软公司软件工程师必读之书。它从软件开发流程、技术、方法、项目管理、团队管理、人际沟通等多角度总结出90余个具有代表性的问题（大多数问题可能会给公司或软件项目带来毁灭性灾难），并给出了问题的解决方案和实践，值得所有软件工程师和项目管理者研读。 《代码之殇（原书第2版）》将这90余个问题分为10章：第1章讨论如何通过管理风险、范围和沟通来保障项目按时完成；第2章介绍消除经验主义的大量过程改进的方法与技巧；第3章讨论消除低效率的策略；第4章主要讨论开发者与其他工种之间的关系；第5章重点阐释软件质量问题；第6章解析软件设计的基本原理和错综复杂的本性；第7章探讨如何规划职业生涯；第8章分析工作与生活中存在的缺点的原因与纠正措施；第9章讨论如何进行有效管理；第10章分析如何成功应对一个软件业务所面临的挑战。
^ 收 起
^ 收 起
比价列表
| 商家 | 评价 (0) | 折扣 | 价格 |
 | 暂无 | 京东缺货N个月 |  35小时前更新 |
