对软件工程的理解

软件工程就是经过时间考验、实践证明的思想和方法论的集合，是一门经验学科。

对于一个稍微大型的工程我们不仅仅只要求数据结构简洁、算法实现快速。因为在我的理解下，软件工程有一个更重要的核心--人。不论是软件开发者还是使用者都是人，所以我们在设计软件、甚至设计开发模式的时候都需要考虑更多的东西：

• 可读性。现在来看无论是数据结构和算法都几乎由代码描述。而一个工程不可能只是写一次就甩手不干。我们在开发时要为未来的维护者考虑（不论自己还是他人），所以市场上出现了许多的开发规范，这些开发规范大部分面向普遍的程序员。在规范出现的同时程序员们也开发了各种帮助开发者遵守规范的程序xxx-lint。不仅仅是代码可读，逻辑也需要可读，所以推荐大部分人在实现复杂功能时添加一些注释，来表明代码段的功能和状态；而过多的注释反而会使代码变得冗长降低了可读性，所以找到一个注释量的平衡点也是一个很考验水平的工作。

• 可扩展性。软件工程不像是土木工程，楼只盖一次下次几乎就是拆了。软件工程更像是乐高玩具，一层一层往上搭，哪天不高兴了把楼顶拆了继续搭。所以我们需要在代码里留一些可以拆的“楼顶”，或者可以扩展的“插槽”。怎么留应当尊重需求，过度的可扩展性很可能带来性能问题与抽象过度问题。

• 跟上时代。一个版本下的程序员大都用同一个套路写代码，而这些代码可能会被下个版本所抛弃。此时我们不应该去学习兼容旧的技术，而是要去用新的技术（保证功能的情况下）替代旧的技术。新的技术不仅会带来性能、安全的提升，也会带来新的设计模式，能够节约开发部署时间。我们要酌情选择新技术版本，要以需求为主。虽然跟进版本是好事，但更新的最主要目的是增强代码、降低未来的人力成本。

• 自动化测试。当我们实现一个算法时，随便跑一个程序就可以测试结果是否准确。但对于一个几十个接口，复杂状态的工程项目，把程序跑起来也很难断定结果，甚至程序都无法在本地跑起来。如果没有自动化测试，我们在添加新功能或修复bug时就会很“心虚”，不确定是不是解决了问题。而在有测试的情况下，我们不仅能保证程序正确，也能在复杂的问题出现时排除错误，快速定位错误。

• 编写日志。在复杂的系统里，日志不仅仅用于定位自身的错误，也会经常用于协助其他系统定位他们的错误。