任何一个笨蛋都能够让事情变得越来越笨重、越来越复杂、越来越极端。需要天才的指点以及许多的勇气，才能让事情向相反的方向发展。
如何保证项目开发过程中压力正常，而不是在后期面对过多的压力，以致噩梦连连呢？最简单的方式，就是在开发过程中便细心“照看”代码。
好的编码习惯：
- 代码要清晰地表达意图
- 总是用代码沟通
- 动态评估取舍以得到最佳的决策
- 增量式编程
- 保持简单
- 编写内聚的代码
- 告知，不要询问
- 通过设计能够根据契约进行替换的系统
代码要清晰地表达意图
设计软件有两种方式。一种是设计得尽量简单，并且明显没有缺陷。另一种方式是设计得尽量复杂，并且没有明显的缺陷。
当开发人员们像一群旁观者见到UFO一样围在代码四周，同样也感到恐惧、困惑与无助时，这个代码的质量就可想而知了。
开发代码时，应该更注重可读性，而不是只图自己方便。代码阅读的次数要远远超过编写的次数，所以在编写的时候值得花点功夫让它读起来更加简单。实际上，从衡量标准上来看，代码清晰程度的优先级应该排在执行效率之前。
PIE原则
Program Intently and Expressively，即意图清楚而且表达明确地编程
在编写代码时，应该使用语言特性来提升表现力。使用方法名来传达意向，对方法参数的命名要帮助读者理解背后的想法。异常传达的信息是哪些可能会出问题，以及如何进行防御式编程，要正确地使用和命名异常。好的编码规范可以让代码变得易于理解，同时减少不必要的注释和文档。
用代码沟通
注释就像是可以帮助你的好朋友，可以先阅读注释，然后快速浏览代码，从而完全理解它做了什么，以及为什么这样做。
动态评估取舍
考虑性能、便利性、生产力、成本和上市时间。如果性能表现足够了，就将注意力放在其他因素上。不要为了感觉上的性能提升或者设计的优雅，而将设计复杂化。
即使不能面面俱到，你也应该觉得已经得到了最重要的东西——客户认为有价值的特性。
如果现在投入额外的资源和精力，是为了将来可能得到的好处，要确认投入一定要得到回报（大部分情况下，是不会有回报的）。
真正的高性能系统，从一开始设计时就在向这个方向努力。
过早的优化是万恶之源。
增量式编程
如果不对自己编写的代码进行测试，保证没有问题，就不要连续几个小时，甚至连续几分钟进行编程。相反，应该采用增量式的编程方式。增量式编程可以精炼并结构化你的代码。代码被复杂化、变成一团乱麻的几率减少了。
所开发的代码基于即时的反馈，这些反馈来自以小步幅方式编写代码和测试的过程。
采取增量式编程和测试，会倾向于创建更小的方法和更具内聚性的类。你不是在埋头盲目地一次性编写一大堆代码。相反，你会经常评估代码质量，并不时地进行许多小调整，而不是一次修改许多东西。
持续做一些细小而有用的事情，而不是做一段长时间的编程或重构。
在很短的编辑/构建/测试循环中编写代码。这要比花费长时间仅仅做编写代码的工作好得多。可以创建更加清晰、简单、易于维护的代码。
保持简单
简单不是简陋
Simple is not simplistic
简单性，在编程或是写作中，就像是厨师的收汁调料。从大量的葡萄酒、主料和配料开始，你小心地进行烹调，到最后得到了最浓缩的精华部分。这就是好的代码应该带给人的感觉——不是一大锅黏糊糊的、乱七八糟的东西，而是真正的、富含营养的、口味上佳的酱汁。
怎样才算优雅？
优雅的代码第一眼看上去，就知道它的用处，而且很简洁。
评价设计质量的最佳方式之一，就是听从直觉。直觉不是魔术，它是经验和技能的厚积薄发之产物。在查看一个设计时，听从头脑中的声音。如果觉得什么地方不对，那就好好想想，是哪里出了问题。一个好的设计会让人觉得很舒服。
开发可以工作的、最简单的解决方案。除非有不可辩驳的原因，否则不要使用模式、原则和高难度技术之类的东西。
要将目标牢记在心：简单、可读性高的代码。强行让代码变得优雅与过早优化类似，同样会产生恶劣的影响。
编写内聚的代码
让类的功能尽量集中，让组件尽量小。要避免创建很大的类或组件，也不要创建无所不包的大杂烩类。
感觉类和组件的功能都很集中：每个类或组件只做一件事，而且做得很好。bug很容易跟踪，代码也易于修改，因为类和组件的责任都很清晰。
告知，不要询问
作为某段代码的调用者，开发人员绝对不应该基于被调用对象的状态来做出任何决策，更不能去改变该对象的状态。这样的逻辑应该是被调用对象的责任，而不是你的。在该对象之外替它做决策，就违反了它的封装原则，而且为bug提供了滋生的土壤。
将命令与查询分离开来
Keep commands separate fromqueries
与告知，不要询问相关的一个很有用的技术是：命令与查询相分离模式（command-query separation）。就是要将功能和方法分为“命令”和“查询”两类，并在源码中记录下来（这样做可以帮助将所有的“命令”代码放在一起，并将所有的“查询”代码放在一起）。
根据契约进行替换
保持系统灵活性的关键方式，是当新代码取代原有代码之后，其他已有的代码不会意识到任何差别。
Liskov替换原则[Lis88]告诉我们：任何继承后得到的派生类对象，必须可以替换任何被使用的基类对象，而且使用者不必知道任何差异。
当使用继承时，要想想派生类是否可以替换基类。如果答案是不能，就要问问自己为什么要使用继承。如果答案是希望在编写新类的时候，还要重用基类中的代码，也许要考虑转而使用聚合。
那么继承和委托分别在什么时候使用呢？
如果新类可以替换已有的类，并且它们之间的关系可以通过is-a来描述，就要使用继承。
如果新类只是使用已有的类，并且两者之间的关系可以描述为has-a或是uses-a，就使用委托吧。
网友评论