1221
社区成员
项目开发，真的人越多越不好吗？
基本上，所有的项目管理书籍上都是说，项目开发人员要尽量少，这样减少了沟通的成本。
但是我在想，难道必须要相互沟通吗，难道每个人都要理解系统所有的内容？
既然有了com，有了接口，那么一些人就可以只实现某些独立的功能，对这个功能的要求可以由项目经理负责收集和分配。而接口实现了黑箱的封装，某个程序员只需要关注里面的细节就可以了，在里面申请的资源自己负责释放，如果不能释放，在开发文档上标出，提示别人负责释放。
本人比较肤浅，只是纸上谈兵，有不对的地方还请各位指点！！
但是我在想，难道必须要相互沟通吗，难道每个人都要理解系统所有的内容？
既然有了com，有了接口，那么一些人就可以只实现某些独立的功能，对这个功能的要求可以由项目经理负责收集和分配。而接口实现了黑箱的封装，某个程序员只需要关注里面的细节就可以了，在里面申请的资源自己负责释放，如果不能释放，在开发文档上标出，提示别人负责释放。
本人比较肤浅，只是纸上谈兵，有不对的地方还请各位指点！！
...全文
当前发帖距今超过3年，不再开放新的回复
发表回复
blue 2004-09-08
确实，勾通是不可少的，否则，到项目下不了台的时候就知错了。
unp 2004-09-06
我今天看了软件工艺一书(英文版),其中P14有一段引文：
Mary had a little lamb.
一句简单的句子，重读不同的单词或词组，得到不同的意思。(声明：本人英语水平有限，理解有误见谅，在此大家共同讨论)
Mary(重读) had a little lamb. It was Mary's lamb, not John's
Mary had(重读) a little lamb. She doesn't have it any longer.
Mary had a(重读) little lamb. She had only one lamb; other people had more.
Mary had a little(重读) lamb. It really was surprisingly small.
Mary had a little lamb(重读). She didn't have the curried chicken that every one else had.
如果简单的语句，读出来理解的意义相差万里，语言表达太丰富,在开发过程中沟通是必须的.
Mary had a little lamb.
一句简单的句子，重读不同的单词或词组，得到不同的意思。(声明：本人英语水平有限，理解有误见谅，在此大家共同讨论)
Mary(重读) had a little lamb. It was Mary's lamb, not John's
Mary had(重读) a little lamb. She doesn't have it any longer.
Mary had a(重读) little lamb. She had only one lamb; other people had more.
Mary had a little(重读) lamb. It really was surprisingly small.
Mary had a little lamb(重读). She didn't have the curried chicken that every one else had.
如果简单的语句，读出来理解的意义相差万里，语言表达太丰富,在开发过程中沟通是必须的.
icevi 2004-09-05
楼上说得很有道理，另外我觉得沟通不止是技术上的，还会有很多其它方面的沟通。
我觉得并不是人越多越不好，只是人多的时候管理的难度会增加。如果确实项目工作量大，人多也是必须的。做大项目时可以把人员按功能模块划分成多个小组，每个小组的人数不要太多就好了。
我觉得并不是人越多越不好，只是人多的时候管理的难度会增加。如果确实项目工作量大，人多也是必须的。做大项目时可以把人员按功能模块划分成多个小组，每个小组的人数不要太多就好了。
baryjim 2004-09-05
原来是这样，我还以为框架写好后就不能轻易修改了，我没有参加过项目的开发，只是纸上谈兵。
我刚考上研究生，实验室是.net开发中间层的，我想先把vc拿下来，毕竟.net太年轻，用的太少了
我刚考上研究生，实验室是.net开发中间层的，我想先把vc拿下来，毕竟.net太年轻，用的太少了
stonespace 2004-09-04
其实不用com，一般的OOP比如c++、java就可以实现对接口的封装。
如果希望通过对接口的设计就可以彻底消除沟通成本的影响，这种想法是非常理想化的，当然好的架构设计可以降低沟通成本，但是沟通成本很难降低到成为一种次要因素。
问题的关键在于：即使是最有经验的架构师，也无法在早期设计出完全正确的架构，他可以设计出一个架构，可以确定系统中有哪些类每个类有那些方法，那个类调用其他那些类，但是最后实现的时候，这些方法的参数返回值，类之间的关系都可能和最初设计不一样；因为按照最初的设计无法实现重要的需求，或者效率不能满足要求。
更根本的原因是：接口不可能和具体实现细节完全无关
因此，在架构设计阶段，架构师就需要和程序员沟通，以便设计出比较正确的架构；但是还没完，不论是架构师或者程序员，都不可能完全预计到具体实现对接口的影响，等程序员具体实现的时候，还会不断发现架构的错误，这时候需要更多的沟通活动，来修改接口。
如果希望通过对接口的设计就可以彻底消除沟通成本的影响，这种想法是非常理想化的，当然好的架构设计可以降低沟通成本，但是沟通成本很难降低到成为一种次要因素。
问题的关键在于：即使是最有经验的架构师，也无法在早期设计出完全正确的架构，他可以设计出一个架构，可以确定系统中有哪些类每个类有那些方法，那个类调用其他那些类，但是最后实现的时候，这些方法的参数返回值，类之间的关系都可能和最初设计不一样；因为按照最初的设计无法实现重要的需求，或者效率不能满足要求。
更根本的原因是：接口不可能和具体实现细节完全无关
因此，在架构设计阶段，架构师就需要和程序员沟通，以便设计出比较正确的架构；但是还没完，不论是架构师或者程序员，都不可能完全预计到具体实现对接口的影响，等程序员具体实现的时候，还会不断发现架构的错误，这时候需要更多的沟通活动，来修改接口。
「风险评估」支持国产密码算法的OpenSSL设计实现及应用 - 金融安全.zip 「风险评估」支持国产密码算法的OpenSSL设计实现及应用 - 金融安全
WAF
基础架构安全
WAF
网络安全
APT
kernel-plus-headers-3.10.0-1160.6.1.el7.centos.plus.x86_64.rpm kernel-plus-headers-3.10.0-1160.6.1.el7.centos.plus.x86_64.rpm
