从 Unix 开源开发学习应对大型项目开发
封装和抽象
在 Unix 、 Linux 系统中，有一句经典的话，“Everything is a file” ,翻译成中文就是 "一切皆文件"。这句话的意思是，在 Unix 、Linux 系统中，很多东西都被抽象成 “文件“ ，这样一个概念，比如 Socket、驱动、硬盘、系统信息等。 它们使用文件系统的路径作为统一的命名空间（namespace），使用统一的 read、write 标准函数来访问。
比如，要查看 CPU 的信息，在 Linux 系统中，只需要使用 Vim 、Gedit 等编辑器或者 cat 命令，像打开其它文件一样，打开 /proc/cpuinfo , 就能查到相应的信息。除此之外，还可以通过查看 /proc/uptime 文件，了解系统运行了多久，查看 /proc/version 了解系统的内核版本等。
实际上，一切皆文件，就体现了封装和抽象的设计思想。
封装了不同类型设备的访问细节 ，抽象为统一的文件访问方式，更高层的代码就能基于统一的访问方式，来访问底层不同类型的设备。这样做的好处是，隔离底层设备访问的复杂性。统一的访问方式能够简化上层代码的编写，并且代码更容易复用。
除此之外，抽象和封装还能有效控制代码复杂性的蔓延，将复杂性封装在局部代码中，隔离实现的易变性，提供简单、统一的访问接口，让其它模块来使用，其它模块基于抽象的接口而非具体的实现编程，代码会更加稳定。
分层与模块化
模块化是构建复杂系统的常用手段。
对于像 unix 这样的复杂系统，没有人能掌控所有的细节。之所以能开发出如此复杂的系统，并且维护得了，最主要的原因就是将系统划分成各个独立的模块，比如进程调度、进程通信、内存管理、虚拟文件系统、网络接口等模块。不同得模块之间通过接口来进行通信，模块之间耦合很小，每个小的团队聚焦于一个独立的高内聚模块来开发，最终像搭积木一样，将各个模块组装起来，构建成一个超级复杂的系统。
除此之外，Unix 、Linux 等大型系统之所以能做到几百、上千人有条不紊地协作开发，也归功于模块化做的好。不同的团队负责不同的模块开发，这样即便在不了解全部细节的情况下，管理者也能协调各个模块，让整个系统有效运转。
实际上，除了模块化之外，分层也是常用来架构复杂系统的方法。
我们常说，在计算机领域的任何问题都可以通过增加一个间接的中间层来解决，这本身就体现了分层的重要性。比如，Unix 系统也是基于分层开发的，它可以大致上分为三层，分别是 内核、系统调用、应用层。 每一层对上层封装实现细节，暴露抽象的接口来调用。而且，任意一层都可以被重新实现，不会影响其它层的代码。
面对复杂系统的开发，要善于利用分层技术，把容易复用、跟业务关系不大的代码，尽量下沉到下层，把容易变动、跟具体业务强关联的代码，尽量上移到上层。
基于接口通信
刚刚讲了分层、模块化，那不同的层之间、不同的模块之间，是如何通信的？一般来讲都是通过接口调用。在设计模块（module）或者层（layer）要暴露接口的时候，我们 要学会隐藏实现，接口从命名到定义都抽象一些，尽量少涉及具体的实现细节。
比如，Unix 系统提供的 open() 文件操作函数，底层实现非常复杂，涉及权限控制、并发控制、物理存储，但我们用起来却非常简单。除此之外，因为 open() 函数基于抽象而非具体的实现来定义，所以在修改 open() 函数的底层实现的时候，并不需要改动依赖它的上层代码。
高内聚、松耦合
高内聚、松耦合是一个比较通用的设计思想、内聚性好、耦合少的代码，能让我们在修改或者阅读代码的时候，聚焦到一个小范围的模块或者类中，不需要了解太多的其他模块或类的代码，让我们的焦点不至于太过发散，也就降低了阅读和修改 代码的难度。而且，因为依赖关系简单、耦合小，修改代码不会牵一发而动全身，代码改动比较集中，引入 bug 的风险也就减少了很多。
实际上，刚刚讲到的很多方法，比如封装、抽象、分层、模块化、基于接口通信，都能有效地实现代码的高内聚、松耦合。反过来，代码的高内聚、松耦合，也就意味着，抽象、封装做的比较到位、代码结构清晰、 分层和模块化合理、依赖关系简单，那代码整体的质量就不会太差。即便某个具体的类或者模块设计的不那么合理，代码质量不怎么高，影响的范围也是非常有限的。可以聚焦于这个模块或者类做相应的小型重构。而相对于 代码结构的调整，折中改动范围比较集中的小型重构的难度就小多了。
为扩展而设计
越是复杂项目，越要在前期设计上多花点时间，提前思考项目中未来可能会有哪些概念需要扩展，提前预留好扩展点，以便在未来需求变更的时候，在不改动代码整体结构的情况下，轻松地添加新功能。
做到代码可扩展，需要代码满足开闭原则。特别是像 Unix 这样的项目，有 n 多人参与开发，任何人都可以提交代码到代码库中。代码满足开闭原则，基于扩展而非修改来添加新功能，最小化、集中化代码改动，避免新代码影响到老代码，降低引入 bug 的风险。
除了满足开闭原则，做到代码可扩展，前面也提到很多方法，比如封装和抽象、基于接口编程等。识别出代码可变部分和不可变部分，将可变部分封装起来，隔离变化，提供抽象化的不可变接口，供上层系统使用。当具体的实现发生变化的时候，我们只需要基于相同的抽象接口，扩展一个新的实现，替换掉老的实现即可，上游系统的代码几乎不需要修改。
KISS 首要原则
简单清晰、可读性好，是任何大型软件开发要遵循的首要原则。只要可读性好，即便扩展性不好，顶多就是多花点时间、多改动几行代码的事情。但是，如果可读性不好，连看都看不懂，那就不是多花时间可以解决得了的了。如果你对现有代码的逻辑似懂非懂，抱着尝试的心态去修改代码，引入 bug 的可能性就会很大。
不管是自己还是团队，在参与大型项目开发的时候，要尽量避免过度设计、过早优化，在扩展性和可读性有冲突的时候，或者在两者之间权衡，模棱两可的时候，应该选择遵循 KISS 原则，首选可读性。
最小惊奇原则
《Unix 编程艺术》一书中提到一个 Unix 的经典设计原则，叫“最小惊奇原则”，英文是“The Least Surprise Principle”。实际上，这个原则等同于“遵守开发规范”，意思是，在做设计或者编码的时候要遵守统一的开发规范，避免反直觉的设计。实际上，关于这一点，我们在前面的编码规范部分也讲到过。
遵从统一的编码规范，所有的代码都像一个人写出来的，能有效地减少阅读干扰。在大型软件开发中，参与开发的人员很多，如果每个人都按照自己的编码习惯来写代码，那整个项目的代码风格就会千奇百怪，这个类是这种编码风格，另一个类又是另外一种风格。在阅读的时候，我们要不停地切换去适应不同的编码风格，可读性就变差了。所以，对于大型项目的开发来说，我们要特别重视遵守统一的开发规范。
总结
- 封装与抽象
- 分层与模块化
- 基于接口通信
- 高内聚、松耦合
- 为扩展而设计
- KISS 首要原则
- 最小惊奇原则