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