代码要清晰表达意图,项目是增量式开发,写程序也应该增量式编程。
代码要清晰地表达意图
要编写清晰地而不是讨巧的代码,向代码阅读者明确表明你的意图,可读性差的代码一点都不聪明(让自己或者团队任何人,可以读懂自己一年前写的代码,而且只读一遍就知道它的运行机制)
代码沟通
用注释沟通,使用细心选择的、有意义的命名。用注释描述代码意图和约束。注释不能替代优秀的代码
动态评估取舍
动态评估权衡,考虑性能、便利性、生产力、成本和上市时间。如果性能够了,就应该把注意力放在其他因素上,不要为了感觉上的性能提升或者设计的优雅,从而将设计复杂化。
增量式编程
在很短的编辑/构建/测试循环中编写代码,这要比花费长时间仅仅做编写代码的工作好得多,可以创建更加清晰、简单、易于维护的代码。
保持简单
开发可以工作的、最简单的解决方案,除非有不可辩驳的原因,否则不要使用模式、原则和高难度技术之类的东西。
当你觉得所编写的代码中没有一行多余的,并且仍能交付全部功能时,这种感觉就对了。这样的代码容易理解和改正。
编写内聚的代码
让类的功能尽量集中,让组件尽量小,要避免创建很大的类或组件,也不要创建无所不包的大杂烩类。
告知,不要询问
不要抢别的对象或者组件的工作,告诉它做什么,然后盯着你自己的职责就好了。
根据契约进行替换
通过替换遵循接口契约的类,来添加并改进功能特性,要多使用委托而不是继承。
记录问题解决日志
对解决的问题可以记录以下条目:
问题发生日期
问题简述
解决方案详细描述
引用文章或者网址
任何代码片段,设置或对话框截图
警告就是错误
嵌入带有警告的代码,就跟嵌入有错误或者没有通过测试的代码一样,都是极差的做法。
对问题各个击破
在解决问题时,要将问题域和周边隔离开,特别是大型应用中
报告所有的异常
处理或向上传播所有的异常,不要讲他们压制不管,就算是临时这样做也不行,在写代码时要估计到会发生的问题。
提供有用的错误信息
提供更易于查找错误细节的方式,发生问题时,要展示出尽量多的支持细节,不过别人用户陷入其中。