« lua 5.2 的 _ENV | 返回首页 | 开发笔记 (7) : 服务器底层框架及 RPC »

关于分工合作

最近工作有点感触， 关于如何分工的。

我觉得所谓设计和实现是无论如何都很难分拆出去的。就是说你不实现你设想的结构，永远都很难知道哪里有问题；即使没有问题，换一个人来实现你想的东西，也无法把设计意图全部传达过去。如果可以做到，那么耗费的时间和精力足够你自己来实现了。

这也是为什么我之前说，软件项目需要很多人一起完成可能是一个骗局 。但毕竟，一个人精力有限，项目时间也有限。分工是无奈之举。可这件事情怎样做才对呢？

我最近有所体会的还是那些被嚼过很多年的老道理。就是模块划分清晰，强内聚，低耦合之类。想强调的是，模块的层次一定要适中，同一层次上规模不能太大，有严格输入、输出接口。

这些并不是为了方便测试，检验工作正确性，而是为了拆分工作。

软件可以有若干层次，总体设计一个人来做没有问题，但在每个层次上应该有足够独立的接口。接口数据要严格控制，并有最小化的知识依赖。包括接口引用的数据类型，接口的参数数量。最好是单一语言的，如有可能，只使用 C 语言的函数和 C 语言的基础类型最为通用。即使各个组件的实现不是用 C 来编写的。

每个层次对上或对下都应该是黑盒子，有比较单一的输入输出点交互。同一层次接口数量过多，应该想办法切分成多个模块。判断模块是否应该切分的标准，不在于实现的代码行数，而在于模块的接口的数量。

这样，我们可以清晰的文档化模块的需求定义。方便把工作分拆后，其他人可以利用文档自行编写假盒子，来让自己实现的部分可以工作起来。

编写一些其他人正在做的模块的假盒子很重要。即使他人的工作已经完成，可以用真盒子来整合也不要轻易去用真的那份。因为编写假盒子的过程，这样可以增进对自己的模块的理解，也可以检验接口设计是否合理。如果假盒子太难编写，很可能是设计有问题，把交互特别繁杂的模块强行分开了。

基于这些点，就能发现，其实单一模块的规模最终控制在一个人可以完成的规模最好，然后设计和实现同一个人来完成就好了。对于不同的人合作时，只是在最后做一些接口粘合和小修正工作。

云风 提交于 January 7, 2012 07:12 PM |

Comments

深有同感~~

Posted by: anders | (10) January 13, 2012 08:37 AM

https://github.com/tinyzhang/asynchronous-complete-utility 我也写一个，求指教，c++写的。

Posted by: tinyzhang | (9) January 12, 2012 07:24 PM

深有感触

Posted by: haxixi_keli | (8) January 9, 2012 11:52 AM

又不是开发操作系统，多大的游戏核心开发几个就可以了。其他人还不如多招点搞市场的。

Posted by: tigerdx | (7) January 8, 2012 10:38 PM

好悲观的结论啊

Posted by: cat | (6) January 8, 2012 02:24 PM

游戏中实践单元测试可以看这里： http://gamesfromwithin.com/category/test-driven-development

Posted by: cap | (5) January 8, 2012 09:34 AM

游戏的单元测试很早就有人使用了。看这里 http://gamesfromwithin.com/category/test-driven-development

Posted by: Anonymous | (4) January 8, 2012 09:33 AM

完全同意，确实很多项目不需要太多人，我没有具体计算过我经历过的项目的人均每天生产代码的行数，不过我估计应该在100行以下。 我个人认为，《人月神话》里提到的增加人手不能提高项目进度的观点有一个前提，就是项目本身无法被切割成相对可以独立开展的工作，或者这种切割在项目后期已经太昂贵(比如代码重构的成本，给项目新成员培训的成本等等),这就会出现云风提到的自己做更快的情况。 项目后期加入新成员的收益是非常有限的，所以，如果在项目的规定期限内，设置几个milestone检查项目的进度非常有用，越早发现需要加人，风险越小，收益也越大。即使刚开始的时候，让新成员做的时间比自己做还要长，这种投资也是值得的。 云风提到的"假盒子"，大概和"The Programatic Programmer"书中(第二章第10节)提到的"曳光弹"有点类似。 这确实是一个很重要的技巧，帮助程序员在很早就可以有一个可以"工作"的系统，这个好处太多了，我在项目中就大量的使用。 不过我认为，"假盒子"最好能由负责这个盒子内部实现的程序员实现，他需要保证如果其他人按照接口输入，他的盒子的输出是"可用"的(即使是hard-coded也没关系)，而其他与这个模块交互的程序员，理想的状态是不需要关心这个盒子是真的还是假的，这在分工上才是更好的"解耦"。 一旦负责这个盒子内部实现的程序员宣布盒子是可用的"真盒子"了，还是越早集成越好，这样有可能发现更多bug(盒子里的和盒子外的)。

Posted by: zkong | (3) January 8, 2012 09:26 AM

强内聚，低耦合。几乎每本程序书和教师的授课的时候都会提出。脱离书本，很多实践的东西，拆分和综合需要强大的记忆力和整合能力。~

Posted by: icicle | (2) January 7, 2012 10:51 PM

Hi,云风 请问你怎么看敏捷开发？之前我也在国内的游戏圈混过一段，但项目中连单元测试都很少更别提TDD scrum了。 前段时间参加了Craig Larman的Agile Modeling & OOAD的培训，发现通过TDD和UT的方式来搭建脚手架能很好地将设计意图保持下来。（否则test就fail了:P）当然，设计在最初阶段是由组内（或模块负责的）所有人一同参加，通过各种草稿最后确定设计方案并文档化。 不知道在你们的团队中考虑过采用敏捷的形式，或者可以说说你们是如何做单元测试的吗？以前的同事总是说“游戏难以做自动测试”，我觉得这是不对的。 谢谢！

Posted by: Patz | (1) January 7, 2012 09:44 PM

Post a comment

非这个主题相关的留言请到：留言本