最近工作有点感触， 关于如何分工的。
我觉得所谓设计和实现是无论如何都很难分拆出去的。就是说你不实现你设想的结构，永远都很难知道哪里有问题；即使没有问题，换一个人来实现你想的东西，也无法把设计意图全部传达过去。如果可以做到，那么耗费的时间和精力足够你自己来实现了。
这也是为什么我之前说，软件项目需要很多人一起完成可能是一个骗局 。但毕竟，一个人精力有限，项目时间也有限。分工是无奈之举。可这件事情怎样做才对呢？
我最近有所体会的还是那些被嚼过很多年的老道理。就是模块划分清晰，强内聚，低耦合之类。想强调的是，模块的层次一定要适中，同一层次上规模不能太大，有严格输入、输出接口。
这些并不是为了方便测试，检验工作正确性，而是为了拆分工作。
软件可以有若干层次，总体设计一个人来做没有问题，但在每个层次上应该有足够独立的接口。接口数据要严格控制，并有最小化的知识依赖。包括接口引用的数据类型，接口的参数数量。最好是单一语言的，如有可能，只使用 C 语言的函数和 C 语言的基础类型最为通用。即使各个组件的实现不是用 C 来编写的。
每个层次对上或对下都应该是黑盒子，有比较单一的输入输出点交互。同一层次接口数量过多，应该想办法切分成多个模块。判断模块是否应该切分的标准，不在于实现的代码行数，而在于模块的接口的数量。
这样，我们可以清晰的文档化模块的需求定义。方便把工作分拆后，其他人可以利用文档自行编写假盒子，来让自己实现的部分可以工作起来。
编写一些其他人正在做的模块的假盒子很重要。即使他人的工作已经完成，可以用真盒子来整合也不要轻易去用真的那份。因为编写假盒子的过程，这样可以增进对自己的模块的理解，也可以检验接口设计是否合理。如果假盒子太难编写，很可能是设计有问题，把交互特别繁杂的模块强行分开了。
基于这些点，就能发现，其实单一模块的规模最终控制在一个人可以完成的规模最好，然后设计和实现同一个人来完成就好了。对于不同的人合作时，只是在最后做一些接口粘合和小修正工作。
