《代码大全》阅读笔记-34-软件工艺的话题

• 在架构层将系统划分为多个子系统，以便让思绪在某段时间内能专注于系统的一小部分。
• 仔细定义类接口，从而可以忽略类内部的工作机理。
• 保持类接口的抽象性，从而不必记住不必要的细节。
• 避免全局变量，因为它会大大增加总是需要兼顾的代码比例。
• 避免深层次的继承，因为这样会耗费很大精力。
• 避免深度嵌套的循环或条件判断，因为它们都能用简单的控制结构取代，后者占用较少的大脑资源。
• 别用goto，因为它们引入了非顺序执行，多数人都不容易弄懂。
• 小心定义错误处理的方法，不要滥用不同的错误处理技术。
• 以系统的观点对待内置的异常机制，后者会成为非线性的控制结构。异常如果不受约束地使用，会和一样难以理解。
• 不要让类过度膨胀，以致于占据整个程序。
• 子程序应保持短小。
• 使用清楚、不言自明的变量名，从而大脑不必费力记住诸如"x代表账号下标，〕代表顾客下标，还是另有它意？”之类的细节。
• 传递给子程序的参数数目应尽量少。更重要的是，只传递保持子程序接口抽象所必需的参数。
• 用规范和约定来使大脑从记忆不同代码段的随意性、偶然性差异中解脱出来。
• 只要有可能，一般情况下应避免“偶然性困难”

计算机不关心你的代码是否好读。它更善于读二进制指令，而非高级语言的代码。编写可读性好的代码，是为了便于别人看懂。可读性对程序的以下方面都有正面影响：

• 可理解性
• 容易复查
• 错误率
• 调试
• 可修改性
• 开发时间
• 上述因素之综合外在质量

---

深八一门语言去编程，不浮于表面

---

---

要点

• 编程的主要目的之一是管理复杂性
• 编程过程对最终产品有深远影响
• 合作开发要求团队成员之间进行广泛沟通，甚于同计算机的交互：而单人开发则是自我交流，其次才是计算机
• 编程规范一旦滥用，只会雪上加霜：使用得当则能为开发环境带来良好机制，有助于管理复杂性和相互沟通
• 编程应基于问题域而非解决方案，这样便于复杂性管理
• 注意警告信息，将其作为编程的疑点，因为编程几乎是纯粹的智力活动
• 开发时迭代次数越多，产品的质量越好
• 墨守成规的方法有悖于高质量的软件开发。请将编程工具箱中填满各种编程工具，不断提高自己挑选合适工具的能力。