标签：美国 代码质量 书评 问题 地方 最佳实践 重构 比较 任务
相信每个人都曾经抱怨过同事的代码写的烂，抑或是前同事遗留的代码惨不忍睹......这些几乎没法修补的代码，其实不一定是人为因素造成，而是遗留代码的问题。其实每个人对遗留代码的定义都不一样，你可以认为遗留代码是指因为种种原因，格外难以修正、改进以及使用的代码。
事实上，最难的不是让你写代码，而是要你维护别人的遗留代码，当你碰到这种情况时，你就会萌生一种重构的想法，或者是去寻找其他更好的实现方式......这个过程，相信一定会让你十分煎熬和挫败。
为了不让自己代码成为别人眼中的烂代码，首先你要知道什么样的代码称得上是整洁代码。
Michael Feathers（《修改软件的艺术》作者）认为整洁的代码应该是：
● 看起来总是像很在乎代码质量的人写的
● 没有明显的需要改善的地方
● 代码的作者似乎考虑到了所有的事情
Michael一针见血。整洁代码就是作者竭尽全力写出的代码，会花大量时间让它保持简单有序，并且适当地关注到了细节，让人找不出明显需要改善的地方。其实这也是《修改代码的艺术》的主旨所在。
● 作者是世界级软件开发大师
● 美国亚马逊全五星好评，深受程序员认可
● 揭示高质量软件的秘密，阐述真正的敏捷开发之道
如果你是软件开发者，你将学到一套实践方法以构建易修改的代码，因为代码在应用当中经常需要修改。对于和软件开发者合作的管理者来说，本书会向你展示为何引入这9个基本的实践方法，会使你的团队更加有效地交付软件，而不至于让软件演变成遗留代码
本书共分为三部分，如下：
第一部分：遗留代码危机，这一部分主要介绍了什么是遗留代码，解释了项目为什么会失败，怎么解决因遗留代码造成的项目失败问题？
下面我们就来看看 Michael Feathers 是如何解决因遗留代码造成的项目失败问题：
1、敏捷
从不同的角度出发，一群成功的软件开发者努力找到了一个轻量级的软件开发流程，命名为“敏捷软件开发流程”。“通过持续不断地及早交付有价值的软件使客户满意”，这一承诺是敏捷流程的核心。换句话说，敏捷理论摒弃了用增加流程来保证质量的方式，建议流程更加精简，好让开发者有更多的时间实施更切实际的工程实践。
2、敏捷误区
敏捷2001年就已经诞生了，但是在软件行业中依然未被广泛理解。许多组织只实施了一个或者几个简单的敏捷实践，诸如“站立式会议”和“两周冲刺”，然后就声称自己已经“敏捷”了。
单纯去掉需求说明文档而没有用软件开发者和产品负责人之间的交流取代，并不是敏捷的初衷。我们需要深入其中，去了解敏捷中隐含的精髓，并不仅仅是有一个产品负责人然后抛弃所有文档，而是要真正地将对话的主题从如何去做变为做什么和为什么这么做。
3、实现敏捷
人们常常通过一系列“应该这样做，别那样做”的规则学习敏捷。那仅仅是学习的第一阶段，但是很多人认为只要学了一些规则便可以进行敏捷了。
像软件开发这样的复杂活动很难用一些规则定义，为了准确建模，我们首先必须了解建模的目标，同时需要理解我们有哪些建模技能或者方法。把这些方法分为两类，即原则和实践，比较便于理解。
第二部分：延续软件生命（和价值）的9种实践方法 ，此部分将会像你展示一套实践方法以构建易修改的代码，因为在应用当中代码经常需要修改。
目录如下：
— 部分摘编自《修改软件的艺术》
@Chain：作者30年的从业经验，在TDD这章用了一个极其简单的Person类来阐述，是没有说服力的。勇气真的是非常非常重要，重要到我认为只要能拥有勇气就能成功的程度。
@fwQGmC9qUrAKYX ：依然是敏捷。首先相信优秀的工程师的实践是可以复制的，给团队以自信。对于怎么做可能想清楚做什么为什么做更重要。开发过程中快速迭代，持续集成，同时添加必要的测试，有利于及时发现问题，提高软件质量。对于遗留代码则是多步修改，一点点进化，而不是一次完成。
@匿名：了解标题中“遗留代码”一词的使用非常重要。一旦完成一段代码并继续执行下一个任务，它就是遗留代码 - 从那时起，一切都是维护。正如作者所指出的，维护成本远远超过代码创建。作者阐述的九种做法旨在提高代码质量，从而降低您之前编写的代码的后续维护费用。
@嘉陵：很容易让人觉得内容很水的书，但其实面对遗留系统代码，你要做的还是那些反复重复的最佳实践，我关注作者怎么把大道理再用自己的经历说一遍，比如敏捷宣言，作者关注到Jeff Sutherland说采用敏捷的第一成功要素是追求技术卓越，技术卓越你注意到了吗？你是否读过这本书，如果读过，不妨留言告诉大家你的读后感。你还可以点击查阅：《没读过这本书，你都不知道你的代码有多Low》
标签：美国 代码质量 书评 问题 地方 最佳实践 重构 比较 任务
原文地址：https://blog.51cto.com/15060204/2567791
