代码要清晰地表达意图（PIE原则 program intently and expressively）
这个问题强调过很多遍的。
命名问题参见：代码整洁之道,对命名问题讲得很好。
要编写清晰的而不是讨巧的代码。向代码阅读者明确表明你的意图。可读性差的代码一点都不聪明。
现在对弈显而易见的事情，对别人可能并非如此，对于一年以后的你来说，也不一定显而易见。
用代码沟通
用注释沟通。使用细心选择的、有意义的命名。用注释描述代码意图和约束。注释不能替代优秀的代码。
注释就像是是可以帮助你的好朋友，可以先阅读注释，然后快速浏览代码，从而完全理解它做了什么，以及为什么这样做。
动态评估取舍
动态评估权衡。考虑性能、便利性、生产力、成本和上市时间。如果性能表现足够了，就将注意力放在其他因素上。
不要为了感觉上的性能提升或者设计的优雅，而将设计复杂化。
不要过度设计，最重要是适合，即使不能面面俱到，你也应该觉得已经得到了最重要的东西--客户认为有价值的特性。
增量式编程与测试（指编程的时候）
在很短的编程/构建/测试循环中编写代码。这要比花费长时间仅仅做编写代码的工作好得多。可以创建更加清晰、简单、易于维护的代码。
长时间编码后再想测试，出的问题往往容易摸不着头脑，不利于在代码中发现问题。
页面测试、控件测试、页面功能实现后测试我一般分为。
保持简单、编写内聚的代码
开发可以工作的、最简单的解决方案。除非有不可辩驳的原因，否则不要使用模式、原则和高难度技术之类的东西。
让类的功能尽量集中。让主键尽量小。要避免创建很大的类或组件，也不要创建无所不包的大杂烩类。
体会项目分类准确，图片、IO、控件等等相应的工具类要分好地方，在项目中不要出现相似名字的类也不要出现经常性复制代码，之前在公司的项目就存在很多代码重复的地方，一控件做的不够可扩展，二是一些工具类没有设计相应的存放的地方，导致这些类在其他包不可见，只能复制过去。
告知，不要询问
命令与查询相分离模式（command-query separation），将功能和方法分为这两类并在源码中记录下来。
不要抢别的对象或是组件的工作。告诉它做什么，然后盯着自己的职责就好了。
不能允许一个看起来无辜的查询去修改对象的状态
根据契约进行替换
当使用继承时要想想派生类是否可以替换基类，如果答案是不能，而是希望在编写新类的时候重用基类中的代码，也需要考虑转而使用聚合。
通过替换代码来扩展系统。通过替换循环接口契约的类，来添加并改进功能特性。