面向理论的编程

如果你有一个需求，只要在算法层面这个需求在图灵机上是可实现，那么程序员就一定可以在现实的计算机上工程上进行实现。

条条大陆通罗马。你可以任意选一种编程语言，任意选择一种架构方式（裸代码还是操作系统），任何一种操作系统进行实现。python能不能用来编写操作系统？当然可以，你只要自己写一个把python代码编译CPU识别的二进制命令流，同时在python语言中定义各种操作系统API即可。

但是，我们一般不会这么做。是因为传统，和懒。我们不喜欢在没必要的时候重复发明轮子。对任何工作来说，我们都是在出卖精力。老板不喜欢浪费自己的钱，我们不喜欢浪费自己的精力。所以，我们在技术选型的时候以下因素

• 功能可实现（这是我们老板能赚到钱的前提）
• 性能可接受（这是我们老板能少花钱在硬件成本的必要）
• 开发效率高（这是我们老板能明天解雇几个程序员节省人力成本的必要）

前两者都是很明确的。可以明确的评价是非优劣。但是最后一个，就众说纷纭了。几乎每一个人都有自己对开发效率高的一种理解。

早在软件行业刚开始的时候，模块化就是共识。这是我们的机械领域的前辈给的宝贵建议。模块化则依赖最开始的整体性设计。忘记大学时代喜欢从helloworld一步步写代码完善功能并越来越兴奋的日子吧。架构师的钱并没有用那么好挣。还记得我们开始的一句话吗，架构程序不是搞科研，没有试探式开发的必要，因为反正一定可以实现，只是让你给出最佳实现。缺乏整体的架构和规划，那不叫设计系统，那叫给未来的自己埋坑。一路坑坑踩踩的过去，如果是一个大学生还行，如果你带领的是一个团队，花了一个月写的代码直接被删除，士气的打击不言而喻。

一个模块，可以是拷贝给人家的一个源代码文件夹，也可以是一个二进制库（dlc，jar包操作系统自带的内部库等等），也可以是分别部署的若干进程（操作系统的自带进程，其他写作进程等等）。模块化的好处在于一方面模块可以复用，一方面模块可以修改和更新。 在上面的三种方式中，显然第一种最不利于模块的更新（更改代码，重新编译，重新上线），中间一种需要更改线上的二进制码（可能支持热部署也可能不支持），最后一种最有利于模块的更新（只需要重启需要更新的模块进程而已）。相应的进程之间进行通讯的成本则比较高昂。

模块架构的最核心的问题是模块的粒度，范围和模块之间约定。 这几乎是架构师最需要关注的问题，也是最困难的问题。从情感上讲，我们希望模块粒度尽可能低，约定尽可能简单。但是前者会带来性能问题，后者在涉及性能问题（交互的内容的多少）的同时，也取决于我们本身的功能复杂度。这个问题没有标准答案，这往往取决于一个企业的研发团队的人员架构。
一般而言，对于架构师，我们需要掌握到的模块粒度是一个程序员的一个具体任务。一个任务就是一个模块。我们不会把一个模块同时分给两个程序员（结对编程除外）。每个程序员负责不同的相对独立的模块是我们能进行人事管理的KPI考核的前提。一般模块的分割遵循“下一层或上一层”。

所谓下一层，一个完整系统分割成若干子系统，那么这个子系统及其向下一层分割层次，可以作为一个模块
所谓上一层，是指一个相对独立评估验证的功能，那么这个功能及其上一个分割层次，可以作为一个模块。

（这两句话实际上是废话，如果模块等于完整系统，也就没必要分模块了。模块自然必须要能独立评估验证。）

模块的粒度和范畴确定后，我们就要定义模块之间的耦合方式了。对于紧密合作的若干人，我们可以采用相对紧密耦合的方式来派发任务，同时我们的验证和KPI评价都更多基于这个团队整体。这就是我们所说的“给力小团队”模式。小团队要想给力，必须彼此信任，关系好，而且核心编码人员不能有弱者。给力小团队可以配置相应的辅助工作人员，但是必须与核心人员拉开待遇差距。给力小团队的成员并非必须要一个知识领域内的，同行会相轻，隔行又容易彼此不解，这个依赖于管理人员对人性的把握。

第二种情况，就是合作松散（异地办公，在家办公），团队成员水平参差不齐。所谓的大团队模式。在当前的中国，这种模式广泛出现在各种大型企业，特别是国企中。大团队模式中每个人都有自己的任务，有小组划分但是小组关系比较松散。会有核心人员，但是核心人员并没有明确的职责划分和责任承担，只有大概的方向分类。他们承担着自己本身的核心职责，同时承担着团队其他人员的培训和问题解决。在这种情况下，应该首先尊重核心成员的意见。采用复杂度极度聚集的方式，将程序中最复杂的地方都集中在若干由核心人员维护的核心的模块中。对不能聚集的复杂度尽量约束为明确的规范，辅助以充分的开发文档和实例工程。这样充分发挥非核心人员和低水平开发者的能力。

第三种情况，就是个人模式。企业拥有非常多的优秀程序员，但是他们之间的联系比较松散。此时，应该采取最为清晰的模块范围界定。架构师应该统筹所有工作，并清晰的进行分工。

最后，我们是架构师，我们不是管理者，我们无权也不应该对组织架构指手画脚，开除和聘用都不应该是我们的锅。我们必须根据组织架构来设计最合理的构建方式。

模块架构的最直观的利益是模块复用。对于架构师而言，在开始架构的时候，最功利的目的往往是节省开发量。在这一点上，我们第一希望我们的组件可以重复利用。第二希望我们可以使用一些已经有的组件（开源或者公司已经开发过的）。