高效程序的45个习惯---第六章 敏捷编码

25 代码要清晰地表达意图

软件设计有两种方式，一种方式是设计得尽量简单，并且明显没有缺陷。另一种方式设计得尽量复杂，并且明显没有缺陷。

 

开发代码时，应该更注重可读性，而不是只图自己方便。代码阅读的次数要远远超过编写的次数，所以在编写的时候值得花点功能让它读起来更加简单。实际上，从衡量标准上来看，代码清晰程序的优先级应该排在执行效率之前。

 

在改动代码以修复bug或者添加新功能时，应该有条不紊地进行。首先，应该理解代码做了什么，它是如何做的。接下来，搞清楚将要改变哪些部分，然后着手修改并进行测试。作为第1步的理解代码，往往是最难的。如果别人给你的代码是很容易理解，接下来的工作就省心多了。

 

明天地告诉阅读程序的人，代码做了什么 ，这是让其便于理解的一种方式。

 

PIE原则：

    代码必须明确说出你的意图，而且必须富有表达力。这样可以让代码更易于被别人音读和融解。代码不让人迷惑，也就减少了发生潜在错误的可能。一言以蔽之，代码应意图清晰，表达明确。

 

要编写清晰的而不是讨巧的代码。向代码音读者明确表明你的意图，可读性差的代码一点都不聪明。

 

平衡的艺术

 

1 现在对你显而易见的事情，对别人可能并非如此，对于一年以后的你来说，也不一定显而易见。不妨将代码视作不知道会在未来何时打开的一个时间胶囊

2 不要明日复明日，如果现在不做的话，以后你也不会做的。

3 有意图的编程并不是意味着创建更多或者类型。这不是进行过分抽象的理由。

4 使用符合当时情形的耦合。

 

26 用代码进行沟通

 

建立代码文档无外乎两种方式： 利用代码本身利用注释来沟通代码之外的问题。

 

如果你必须通读一个方法的代码才能了解它做了什么，那么开发人员先要投入大量的时间和精力才能使用它。反过来讲，只需短短几注释说明方法行为，就可以让生活变得许多。开发人员可以很快了解到它的意图，它的期待结果，以及应该注意之处。

 

平衡的艺术

 

1 Pascal定理的创始人Blaise Pascal曾说，他总是没有时间写短信，所以只写长信。请花时间写彰明扼要的注释吧。

2 在代码可以传递意图的地方不要使用注释。

3 解释代码做了什么 的注释用处不那么大。相反，注释要说明为什么会这样写代码。

4 当重写方法时，保留描述原有方法意图和约束的注释。

 

27 动态评估取舍

 

 

平衡的艺术

 

1 如果现在投入额外的资源和精力，是为了将来可能得到的好处，要确认投入一个定要得到回报。

2 真正的高性能系统，从一开始设计时就在向这个方向努力。

3 过早的优化是万恶之源。

4 过去用过的解决方案对当前的问题可能适用，也可能不适用。不要事先预设结论，先看看现在是什么状况。

 

 

28 增量式编程

 

如果不对自己编写的代码进行测试，保证没有问题，就不要连续几个小时，甚至连续几分钟进行编码。相反，应该采用增量式的编程方式。

 

平衡的艺术

 

1 如果构建和测试循环花费的时间过长，你就不会希望经常运行它们了。要保证测试可以快速运行。

2 在编译和测试运行中，停下来想一想，关暂时远离代码细节，这是保证不会偏离正确方向的好办法。

3 要休息的话，就要好好休息，休息时请远离键盘。

4 要你重构你的代码那样，重构你的测试，而且要经常重构你的测试。

 

 

29 保持简单

 

评价设计质量的最佳方式之一，就是听从直觉。直觉不是魔术，它是经验和技能的厚积薄发之产物。在查看一个设计时，听从头脑中的声音，如果觉得什么地方不对，那就好好想想，是哪里出了问题。一个好的设计会让人觉得很舒服。

 

开发可以工作的，最简单的解决方案。除非有不可辩驳的原因，否则不要使用模式，原则和高难度技术之类的东西。

 

 

平衡的艺术

 

1 代码几乎总是可以得到进一步精炼，但是到了某个点之后，再做改进就不会带来任何实质性的好处了。这时开发人员就应该停下来，去做其他方面的工作了。

2 要将目标牢记在心：简单，可读性高的代码。强行让代码 变迁 优雅与过早优化类似，同样会产生恶劣的影响 。

3 当然，简单的解决方案必须要满足功能需求。为了简单而在功能上妥协，这就是过分简化了。

4 太过简洁不等于简单，那样无法达到沟通的目的。

5 一个人认为简单的东西，可能对另一个人就意味着复杂。

 

30 编写民内聚的代码

 

让类的功能尽量集中，让组件尽量小。要避免创建很大的类和组件，也不要创建无所不包的大杂烩类。

 

感觉类和组件的有都很集中：每个类或组件只做一件事，而且做得很好。bug很容易跟踪，代码也易于修改，因为类和组件的责任都很清晰。

 

平衡的艺术

1 有可能会把一些东西拆分成很多微小的部分，机遇使其失去了实用价值。

2 具有良好内聚性的代码，可能会根据需求的变化，而成比例地进行变更。考虑一下，实现一个简单的功能变化需要变更多少代码。

 

 

31 告知，不要询问

 

平衡的艺术

 

1 一个对象，如果只是用作大量数据容器，这样的做法很可疑。有些情况下会需要这样的东西，但并不像想象的那么频繁。

2 一个“命令”返回数据以方便使用是没有问题的。

3 绝对不能允许一个看起来无辜的“查询”去修改对象的状态。

 

32 根据契约进行替换

 

那么继承和委托分别在什么时候使用呢？

1 如果新类可以替换已有的类，并且它们之间的关系可以通过is-a来描述，就要使用继承。

2 如果新类只是使用已呢的类，并且两者之间的关系可以描述为has-a或uses-a,就使用委托吧。

 

通过替换代码来扩展系统。通过替换遵循接口契约的类，来添加加并改进功能特性，要多使用委托而不是继承。

 

平衡的艺术

 

1 相对继承来说，委托更加灵活，适应力也更强。

2 继承不是魔鬼，只是长久以来被 大家误解了。

3 如果你不确定一个接口做出了什么样的承诺，或者有什么样的需求，那就很难提供一个对其有意义的实现了。