对软件工程的一些理解

程序由数据结构和算法组成，一个好的程序应当是数据结构简洁、算法实现快速。这是我最初学习算法竞赛时的目标，然而我算法能力并不是非常强，后来逐渐做一些工程上的项目。

---

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

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

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

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

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

5. 日志。最开始写C的时候并不会用gdb调试程序，而现在当项目变得巨大无比的时候，也很难在本地调试程序。所以我们要善用printf，及时打出状态日志错误日志。在复杂的系统里，日志不仅仅用于定位自身的错误，也会经常用于协助其他系统定位他们的错误。

算法需要时间、但开发也需要时间。而对于软件工程来说开发时间就是成本。硬件越来越发达，公共库越来越多的条件下，大部分工程并不要求算法有多快，用户体验在大多数情况下不会对零点几秒的时间很敏感。所以我们开发一个大型工程项目时不应该先考虑优化问题。举个例子，缓存在优化性能方面会带来很大的优势，实际上大部分硬件、算法都是通过缓存的机制来减少时间；而缓存却会带来数据不同步的问题，在开发人数多、功能多的情况下数据不同步的细节可能并不会被每个人了解，有些人就会在需要数据同步的地方反复同步数据，反而增加了开销。所以在开发时，在全部代码都接近尾声，甚至在做压力测试之后，我们才需要考虑算法时间问题。只要方法封装的好，甚至接口不用变换就可以任意替换算法，这也需要之前提到的扩展性。

实际上，软件工程是为了赚钱，赚钱则要考虑成本。第一次开发的时间人力、后续维护的时间人力全部都是成本。我们也并不能为了某些完美主义的想法就去无限地要求代码的准则，这可能会大量消耗首次开发的时间人力；我们更不能为了快速交付而无限降低代码质量，这样只会使用户体验变差甚至后期维护困难。

以人为本最难的地方就在于妥协，找到一个平衡点，让开发者、用户都尽量满意，软件工程也是一种算法思想，它的目的是节省开发时间金钱成本，提高交付质量。这种算法思想在代码实现里体现成了若干设计模式，在开发上体现成为了不同的迭代模式，甚至在交付上也有“先吹逼拿钱后实现”的模式。

我会逐步记录一些自己在编写代码中用到的设计模式与开发模式，这些模式让我作为一个全栈研发能快速响应需求并保持一定代码质量。