从 Unix 开源开发学习应对大型复杂项目开发（上）

如果大家觉得文章有错误内容，欢迎留言或者私信讨论~

前引

  软件开发的难度无非两点。第一点是技术难，就是说，代码量不一定多，但要解决的问题比较难，需要用到一些比较深的技术解决方案或者算法，不是靠“堆人”就可以解决的，比如自动驾驶、图像识别、高性能消息队列等。第二点则是技术不难，但项目很庞大，业务复杂，代码量多，参与开发的人员多。比如物流系统、财务系统等。今天需要了解的是第二点。

  简单的"hello world"谁都可以写出来，几千行的代码谁都能维护。但是当代码量开始上涨——几万行、十几万行甚至几十万行、百万行代码的时候，软件的复杂度就会呈指数型上涨。这种情况下，我们不仅仅要求程序运行得了，运行得正确，还要求代码看得懂、维护得了。实际上，复杂度不仅仅体现在代码本身，还体现在协作研发上，如何管理庞大的团队，来进行有条不紊地协作开发，也是一个很复杂的难题。

  如何应对复杂的软件开发？Unix 开源项目就是一个值得学习的例子。希望你能够从这三点出发：

• 从设计原则和思想的角度来看，如何应对庞大而复杂的项目开发？
• 从研发管理和开发技巧的角度来看，如何应对庞大而复杂的项目开发？
• 聚焦在 Code Review 上来看，如何通过 Code Reviwe 保持项目的代码质量？

  话不多说，让我们开始吧。

封装和抽象

  在 Unix、Linux 系统中，有一句经典的话，“Everything is a file”，翻译成中文就是“一切皆文件”。在 Unix、Linux 系统中很多比如 Socket、驱动、硬盘、系统信息等都使用文件系统的路径作为统一的命名空间，使用统一的 read、write 标准函数来访问。
  比如，我们要查看 CPU 的信息，在 Linux 系统中，我们只需要使用 Vim、Gedit 等编辑器或者 cat 命令，像打开其他文件一样，打开 /proc/cpuinfo，就能查看到相应的信息。除此之外，我们还可以通过查看 /proc/uptime 文件，了解系统运行了多久，查看 /proc/version 了解系统的内核版本等。

  实际上“一切皆文件”就体现了封装和抽象的设计思想。

  装了不同类型设备的访问细节，抽象为统一的文件访问方式，更高层的代码就能基于统一的访问方式，来访问底层不同类型的设备。这样隔离底层设备访问的复杂性，统一的访问方式能够使得上层代码的编写变得简单；并且抽象和封装还能有效控制代码复杂性的蔓延，提供简单、统一的访问接口，让其他模块来使用，其他模块基于抽象的接口而非具体的实现编程，代码会更加稳定。

分层与模块化

  对于像 Unix 这样的复杂系统，没有人能掌控所有的细节。之所以我们能开发出如此复杂的系统，并且能维护得了，最主要的原因就是将系统划分成各个独立的模块，比如进程调度、进程通信、内存管理、虚拟文件系统、网络接口等模块。不同的模块之间通过接口来进行通信，模块之间耦合很小，每个小的团队聚焦于一个独立的高内聚模块来开发，最终像搭积木一样，将各个模块组装起来，构建成一个超级复杂的系统。

  Unix、Linux 等大型系统之所以能做到几百、上千人有条不紊地协作开发，也归功于模块化做得好。不同的团队负责不同的模块开发，这样即便在不了解全部细节的情况下，管理者也能协调各个模块，让整个系统有效运转。

  除了模块化，分层也是我们常用来架构复杂系统的方法。

  我们常说，计算机领域的任何问题都可以通过增加一个间接的中间层来解决，这本身就体现了分层的重要性。比如，Unix 系统也是基于分层开发的，它可以大致上分为三层，分别是内核、系统调用、应用层。每一层都对上层封装实现细节，暴露抽象的接口来调用。而且，任意一层都可以被重新实现，不会影响到其他层的代码。

  面对复杂系统的开发，我们要善于应用分层技术，把容易复用、跟具体业务关系不大的代码，尽量下沉到下层，把容易变动、跟具体业务强相关的代码，尽量上移到上层。

基于接口通信

  上面提到分层、模块化，不同层、不同模块之间该如何通信呢——通过接口来实现。在设计模块或者层要暴露接口的实现，我们要学会隐藏，接口从命名到定义都要抽象一些，尽量少涉及具体的实现细节。

  比如，Unix 系统提供的 open() 文件操作函数，底层实现非常复杂，涉及权限控制、并发控制、物理存储，但我们用起来却非常简单。并且我们在改动 open() 函数的底层实现的时候，并不需要改动依赖它的上层代码。

高内聚、松耦合

  高内聚、松耦合是一个比较通用的设计思想，内聚性好、耦合少的代码，能让我们在修改或者阅读代码的时候，聚集到在一个小范围的模块或者类中，不需要了解太多其他模块或类的代码，让我们的焦点不至于太发散，也就降低了阅读和修改代码的难度。
  简单来说就是依赖关系简单，耦合小，修改代码不会牵一发而动全身，代码改动比较集中，引入 bug 的风险也就减少很多。

为扩展而设计

  越是复杂的项目，越是需要在前期设计上多花点时间。提前思考项目中未来有哪些功能需要拓展，提前预留好拓展点（实际上我觉得这非常依赖经验），以便在未来需求变更时，在不改动代码整体结构的情况下，轻松添加新功能。

  做到代码可扩展，需要代码满足开闭原则。特别是像 Unix 这样的开源项目，有 n 多人参与开发，任何人都可以提交代码到代码库中。代码满足开闭原则，基于扩展而非修改来添加新功能，最小化、集中化代码改动，避免新代码影响到老代码，降低引入 bug 的风险。

  除了满足开闭原则，做到代码可扩展，我们前面也提到很多方法，比如封装和抽象，基于接口编程等。识别出代码可变部分和不可变部分，将可变部分封装起来，隔离变化，提供抽象化的不可变接口，供上层系统使用。当具体的实现发生变化的时候，我们只需要基于相同的抽象接口，扩展一个新的实现，替换掉老的实现即可，上游系统的代码几乎不需要修改。

KISS 首要原则

  简单清晰、可读性好，是任何大型软件开发要遵循的首要原则。只要可读性好，即便扩展性不好，顶多就是多花点时间、多改动几行代码的事情。但是，如果可读性不好，连看都看不懂，那就不是多花时间可以解决得了的了。如果你对现有代码的逻辑似懂非懂，抱着尝试的心态去修改代码，引入 bug 的可能性就会很大。

  不管是自己还是团队，在参与大型项目开发的时候，要尽量避免过度设计、过早优化，在扩展性和可读性有冲突的时候，或者在两者之间权衡，模棱两可的时候，应该选择遵循 KISS原则，首选可读性。

总结

  今天讲解的实际上就是设计模式的设计原则，能够做到以上的实际上是比较困难的，需要开发人员或者管理人员都有较高的素质。