[TL][复杂度]开发软件，如何管理复杂度
jun lin
根据我个人的经验，开发软件，往往会遇到以下几类问题：
1.需求变更。
2.技术风险。
3.逐渐增加的复杂度。
现在我要说的是第3个，任何大项目都会遇到的问题。
作为我个人而言，开发经验其实不多，实际从事的项目就只有很少的几个。
但是在这几个项目里面，都多多少少遇到这样的问题：
当项目随着开发进度逐渐增长的时候，
以前的模块渐渐变得复杂，定义好的接口渐渐不能满足需求，
程序架构开始变得无法理解。
尤其是界面程序开发。
虽然可以通过水平分层和模块切割减少系统耦合，
但是整体的系统，对于个人来说，需要相当长的时间，才能够理解。
对于稳定的系统，比如ERP之类，可以学习掌握，
但是对于开发中的系统，出现问题，或者效率瓶颈，需要debug的时间成指数级别的上升。
以前做过一个监控系统，底层需要监控好几个设备，跑了很多的线程，同时处理各种各样的判断逻辑。
在不断地修改中，程序bug渐渐变得难于fix，而代码也变得非常复杂，超过了我能够处理的程度。。
最后项目宣告失败。。。
我想要问几个问题：
如何计划开发这样的系统？是否只有靠增量式的开发？以及不断地重构？
作为程序员，如何能够掌握复杂系统？当程序失去控制，
或者说自己脑袋已经无法处理这么多复杂内容的时候，应该如何处理？
大家是否有成功或者失败的大型软件开发经验？有学到什么？可否分享？
sagasw
我个人觉得这个问题是无解的。
联想到一个很有趣的实验，就是“生物圈2号“
http://baike.baidu.com/view/593000.html?fromTaglist
软件开发的复杂度也许不如生物圈，但是某些大型项目已经接近，比如windows7，整个项目应该不少于几千人涉及。
http://news.skycn.com/article/22716.html
在这种复杂程度下，切分也好，优秀的设计方案也好，精英云集也好，都会产生你说的越来越复杂的情形，
常常遇到的情况是，不是对手太强，而是内部问题太多。（不怕狼一样的敌人，就怕猪一样的队友）
对于这种问题也许只有一个答案：破而后立。
历史上，各种政权的反复轮回也证明了这一点。
------------------------------------
C++, Lua, living in Dalian
http://sunxiunan.com/
http://twitter.com/sagasw
------------------------------------
Fuzhou Chen
Windows8还要增加。
2009/12/24 sagasw <sag...@gmail.com>:
> 常常遇到的情况是，不是对手太强，而是内部问题太多。（不怕狼一样的敌人，就怕猪一样的队友）
>
说“猪一样的队友”有点严重了。读大软件的时候往往一个团队每个人熟
悉的部分都不一样，经常是彼此拖后腿。《梦断代码》中说做一个大型
软件如同建巴比伦塔，大概就是这个意思。
就目前我见过的项目而言为了减轻这个问题都是多管齐下：项目划分、
文档管理、老人带新人。我经验中最有效的是老人带新人，在新人本身
足够努力的前提下上手的速度会快很多；其次是解bug，通过尝试解决
产品中新产生的bug可以高速理解系统，缺点是单纯关注bug细节容易
丢失整体观念，而且短时间突发阅读量非常大，加班免不了。相对而言
最低效的是读文档，因为文档不能具体到每一行代码，而且只能告诉我
们理论结果，真正研究细节时（比如观察bug行为）必须回到代码里。
至于破而后立，现实中可能性不大。对于小软件可能有用，但如果说到
Windows、GCC、Linux kernel那个规模的软件，从头再来的成功率
基本为0，而且成本上也不允许。
最后发个牢骚。写代码始终是手艺，手艺还是要时间去积累的。所以有
经验的老人留在组里绝对是一笔财富。
2009/12/24 sagasw <sag...@gmail.com>:
--
《采莲》·江南
为卿采莲兮涉水，为卿夺旗兮长战。为卿遥望兮辞宫阙，为卿白发兮缓缓歌。
另抄自蒜头的评论：http://www.douban.com/review/1573456/：
且祭一束紫琳秋，为一段落花流水的传说
且饮一杯青花酒，为一场几多擦肩的错过
且焚一卷旖旎念，为一腔抛付虚无的惜怜
且歌一曲罢箜篌，为一刻良辰春宵的寂寞
jun lin
问题在于一个项目，很难被细分，而项目中含有的细节非常的多。
比如PDF编辑器，word，wps之类。maillist好像有当年wps的开发者？
sagasw
比如文档，cmmi、iso9000能帮助一个软件公司成功完成项目么？
转来转去，不还是那个没有银弹的话题么。
《没有银弹》《梦断》《观止》，这些大型中型项目的经验告诉我们，所谓“成功”的项目，
只是有非常非常牛逼的人让它看起来像是成功了，而且市场也恰巧认同了这个产品而已。
还有，如何保证大家都是一股心思都往你所认为的那个“成功”的方向上使劲，而不是为了升官发财，
软件开发是一门手艺（这点我非常同意），所以每个人几乎都是无法替代的，尤其是项目中的核心开发者，
对于一个几千人的团队来说，怎么可能会有这种强有力的凝聚力，
拿我们公司来说，每年的流动率大概在百分之几，走的不怕是末尾，就怕是精英。
一个软件产品如果到了这种复杂度超级混乱的程度，就如同一个已经进入日暮末年的帝国，
再强的精英也只能稍微拖延一下死亡的脚步，而无法阻挡新的国家的产生。
从市场的角度来说，就是新的产品自然淘汰旧的产品，
所谓的破而后立，未必是自愿发生，也许就是被逼的。
我倒是觉得另外一种开发模式也许更有生机，就是平台加应用的模式，
但是这种模式只限于互联网应用。
------------------------------------
C++, Lua, living in Dalian
http://sunxiunan.com/
http://twitter.com/sagasw
------------------------------------
liyun peng
到是可以在
--
思索的秋天
Fuzhou Chen
遇到个脾气暴的可能就要吵起来了。
关于您的质疑：
我不知道这个“表面上”的东西是什么。也从没说过我说的那几条是银弹，我所关注
的是开发知识在人走人流过程中的传承和整理。而且我说的就是我所在的公司二十
年来坚持的做法，其实就是国内前一段时间吹上天的mentor制度。微软中国的宣
传是吹得有些邪乎，但就我们公司内部的执行情况来看效果相当不错，我不知道我
的观点理想化在何处。
回到“成功”的问题，我承认有了知识传承的传承也不能保证产品一定成功，但我能
肯定的是知识传承不下去则这个项目必然失败——我想这个大家都能同意，特别是
对于Windows那个级别的项目而言，要求每个新人从头独立学习从成本和时间上看
根本不现实。
至于“破而后立”，如果是站在整个业界的观点上看是成立的，当一个软件已经过分
臃肿的时候它更可能被一个从头开始没有包袱的同类产品取代。但如果站在单个产
品发展的角度上看我认为不现实，或者说它只适合于两类情况：一是这个项目本身
规模很小知识要求不高可以整体重构；二是项目中某个模块独立性较强允许部分重
构。但无论如何这不可能作为一个普适的做法推广单个产品的版本升级过程中去。
从楼主的帖子上看，我比较倾向于认为他希望讨论的是单个产品的发展过程，故而
我有此论。
2009/12/24 sagasw <sag...@gmail.com>:
jun lin
现在的问题是，我们开发的软件，往往不是工具层面上的，而是工具集整合，
而这样的整合，往往使得系统复杂度是所有工具复杂度之和。
举个实例，一个界面程序，无数工具都可以修改界面上的图形，
而工具处理的方式足够复杂到无法公用一个父类接口，
这个时候我们会采用多态的方式，最后会出现一个继承树，以及一堆的接口类。
ps:
请不要用“封人的嘴”等直接针对个人的词语，这样会刺激情绪，使讨论走偏。
Fuzhou Chen
思维方式下断语，这客观上是在阻止对方进一步讨论，不过我的用词确
实过火，有伤人的可能。jun lin说得是，我会注意。sagasw也请见谅。
＝回到正题＝
对于UNIX的哲学我一贯是喜欢的，但如果进入到现实世界我们就能看到，
不是所有程序的设计师都愿意按这个实现的。
不举别的例子，就Gnome吧，从头到尾都是UNIX世界里产生的软件包。
可它的组件也不是拿出来就能用的。如果一个用户试图把epiphany拿出来
用，就至少得配置这么些东西：
gconf-editor2 // 注册表
gnome-key-ring // 密码管理
pulseaudio // 音频 －－ 如果你希望USB耳机能即插即用的话
gstreamer // 视频
PolicyKit // 访问视频设备的权限
ConsoleKit // 快速用户切换
gnome-panel + exchange-data-server // 鬼知道为什么要这个
也许它这么设计有它的道理，但要是指望每个新人刚进来几个星期就得在
无人帮助的情况下理解这一切，也未免强人所难了些。
这也就是我坚持认为知识传承在软件成功过程中地位非常的原因。如果
商业开发团队找不到一个合理的方式来缩短这个过程，那么它需要花在
培训上的成本就会随着产品规模的扩大慢慢吃掉所有的预算，而成本控制
不住会带来什么，我想大家都是有共识的。
顺便说一句，jun lin下面这句话一针见血，精确地点出了集成测试的难点
所在。作为一个维护期的专职集成测试，我举双手赞同。
>
> 而这样的整合，往往使得系统复杂度是所有工具复杂度之和。
>
2009/12/24 jun lin <linjun...@gmail.com>:
Fuzhou Chen
我说的不是epiphany，而是empathy，Gnome的新一代即时通信软件。
其依赖的也不是exchange-data-server，是evolution-data-server。
非常抱歉。
2009/12/24 Fuzhou Chen <cppo...@gmail.com>:
Tinyfool
--
Tinyfool的开发日记 http://www.tinydust.net/dev/
代码中国网 http://www.codechina.org
myTwitter: http://twitter.com/tinyfool
Fuzhou Chen
2009/12/24 Tinyfool <tiny...@gmail.com>:
Tinyfool
Fuzhou Chen
《人月神话》相反，它更重在解释本质，IBM的案例实际上作为证据存在的。
我看《梦断》的感觉是，这帮子牛人就是在不停地寻找完美方案，想法都
很好，但他们都没有指出这些功能需要通过何种方式实现，而且他们本身对这
些技术细节也不了解，比如他们提出的p2p，如何给邮件打tag，还有用Python
和wxWidget做UI。最后的结果实际上是边做边学，几乎每一步都花了大量的
额外精力，而且这种不熟悉也导致了后来在设计上的摇摆，比如后期他们又把
p2p换成WebDAV。这种犹豫不决的决策在我看来就是后来的失败的主因。
所以嘛，能有一个次优解，咱们就先用上。慢慢地也许就走运混到了个最优解
了呢？
2009/12/24 Tinyfool <tiny...@gmail.com>:
sagasw
再强调一次破而后立，对于公司来说，如果两三年没有同类型产品的升级版本出现，那么就意味着死亡，比如微软，搞定了windows7，立刻就在广为宣传windows8要如何如何。Linux kernel虽然名字没变，但是里面的代码和早期版本应该已经是相差万里，几乎没有可比性。
如果自己公司没有这种投入，那么外部力量会来做这件事情，比如myspace，从第一大sns站点到现在被facebook取代，不过也就几年时间，而facebook能坚持几年排头，谁的预测都不保靠。
实际点举例，从我们公司角度来谈，主要产品已经进入第三代的设计阶段，大概三四年就要推出一个新产品吸引眼球，这个新产品估计再过一两年就要拿到大连来做维护开发。所谓阶段解决，对于一个处于上升或者平稳期的软件来说是有必要的，对于一个大家都不关注，没人想要继续投入精力的项目，那就是个泥潭。
当然，如果整个公司就你或我知道如何修改某个软件，而且还有大客户在继续使用，你或我在这个期间会非常有价值，
比如cobol，但是问题是：对于个人来说，没有未来，职业发展前景可能会很成问题。
其实不需要去研究什么其他的复杂系统或者复杂项目，能把人的脑袋研究清楚了，对于复杂系统的设计开发就是非常有参考价值的。
BTW，就是讨论而已，无所谓的，逗闷子好玩罢了。
------------------------------------
C++, Lua, living in Dalian
http://sunxiunan.com/
http://twitter.com/sagasw
------------------------------------
ZhiGang Qi
--
Zhigang Qi
345 park ave, W12-302
San Jose , CA 95110, USA
Cell: (812)272-1809
work: 408-536-247
Fuzhou Chen
最终都会变得越来越复杂，这个趋势会延续在这个软件的整个生命周期里。
但这里还有一个问题没解决：所谓“破而后立”中的“破”该如何解释？我的理解
是把已经写好的代码拿来重写。我同意在整体代码不变的前提下可以通过部
分地重写代码修正复杂度上的问题。但如果把“破”解释为一次性地把软件大部
分推翻重写，那我觉得不现实也很难理解。
我手头也有例子，比如我能肯定这次Windows7中将一台workgroup计算机加
入指定domain的算法肯定是重写过，因为抓包时我们能发现原来VISTA中的一
些RPC操作消失而LDAP的包内容被加密了。但我不太相信活动目录的其他部分
被重写，因为我看到的基本LDAP包通信规则还是一样的。
2009/12/24 sagasw <sag...@gmail.com>:
Fuzhou Chen
工作中的学习和课堂上的学习也不同，大部分时间我们主要是自学，
但自学是有瓶颈的，有时候初学者头痛很久的原因往往就是他不了解产
品的一部分历史变化，如果他试图自己研究就可能需要阅读大量的
文献和代码来了解整个过程。而mentor的作用就在于捅破这层窗户纸让
初学者省去无用的探索时间，降低学习的成本。
无论是牛X的top coder，还是平庸的工兵，这个过程都不可避免。
2009/12/24 ZhiGang Qi <zhiga...@gmail.com>:
翁翊成
dear all forks:
根据我个人的经验，开发软件，往往会遇到以下几类问题：
1.需求变更。
昨天聊了一会，冒出个想法是通过use cases搭配文字，扔到wiki上来实现，不知道有没有同道实践过这条路，是否可以分享下经验。
2.技术风险。
3.逐渐增加的复杂度。
现在我要说的是第3个，任何大项目都会遇到的问题。
jun lin
重量级的方法靠CMMI，轻量级的方法靠ticket。
ZhiGang Qi
第二步： use cases by architect.
第三步： 优先级划分，必要性划分
第四步： conceptual design
第五步： 从新开会讨论第三步的工作，
然后roadmap... draw a line...
以上内容分步都放到wiki上，以便以后查询。
Fuzhou Chen
说起来我们这边的办法非常简单：WORD ＋ 人肉字典解决问题。
开发组那边由产品经理负责，维护组这边由测试人员负责。实践
中的问题就是这两个角色任务非常重，而且每次交接都会造成知
识损失，所以我们现在都是千方百计地留住老员工。
2009/12/25 翁翊成 <wen...@gmail.com>:
--
missdeer
多，不同的需求也可以对应用不同的方法管理。
以前我在一个部门大概有40人左右，同时开发维护的项目有大概有30个左右，当然活动量大的可能不到10个，一个时期内主要专攻的项目不到5个。部门使
用RedMine同时用于收集用户需求，提交软件Bug，分配跟踪开发任务和测试任务。项目相关的文档（对应于你说的"归档"的那些）写在wiki上，
这是项目经理听了一微软的哥们儿后觉得大有道理做的。
使用redmine可以更直接地看到某条记录的变更情况，当然wiki也是有这些记录的，但不够直观。另外一个比较明显的优点是，从工具角度提供了各种
issue间关联的便利，比如从一个用户需求，在该记录内可以看到各种讨论过程和结果，然后由此用户需求衍生出了哪些开发需求，这些开发需求又是怎么处
理的......这个过程比较直观且容易地用工具展现出来。除此之外，还有对于管理人员的便利，因为redmine使用MySQL存储数据，表结构非常简单易
懂，因此可以很容易做些个性化强烈的统计、生成报表之类的工作，曾经我们就做过好几个自动通过邮箱发送项目进度报表给相关领导的redmine插件、独
立小工具。
PS. 怎么感觉我像是redmine的托啊:(
On Dec 25, 4:12 pm, 翁翊成 <weng...@gmail.com> wrote:
> 2009/12/24 jun lin <linjunhal...@gmail.com>
sagasw
这个比较有意思，他们自己应该有用project server吧。
------------------------------------
C++, Lua, living in Dalian
http://sunxiunan.com/
http://twitter.com/sagasw
------------------------------------
missdeer
On Dec 26, 10:06 am, sagasw <sag...@gmail.com> wrote:
> 微软用redmine？
> 这个比较有意思，他们自己应该有用project server吧。
>
> ------------------------------------
> C++, Lua, living in Dalianhttp://sunxiunan.com/http://twitter.com/sagasw
> ------------------------------------
>
> 2009/12/26 missdeer <missd...@gmail.com>
sagasw
PM用sharepoint做文档和项目网站，另外用project server做进度管理（我都是瞎填的）
微软自己不这么用，实在说不过去啊，
不过这些工具也比较适合我们pm的使用水平。
------------------------------------
C++, Lua, living in Dalian
http://sunxiunan.com/
http://twitter.com/sagasw
------------------------------------
missdeer
用wiki时，我们就说是不是sharepoint，他明显愣了一下才反应过来，我就猜他丫根不用这玩意。
也用过大概一年时间的Project，结果下面的人怨声载道，最后也不了了之了。
On Dec 26, 10:22 am, sagasw <sag...@gmail.com> wrote:
> 我们公司算是忠诚的微软党，
> PM用sharepoint做文档和项目网站，另外用project server做进度管理（我都是瞎填的）
> 微软自己不这么用，实在说不过去啊，
> 不过这些工具也比较适合我们pm的使用水平。
>
> ------------------------------------
Shuo Chen
sharepoint 我觉得没有 twiki 好用，经常发个链接给别人，别人说访问不了，一点都不 share。
不晓得 Team Foundation Server在微软内部推行得如何，有没有替换原来的工具。
TFS也很搞，代码仓库存在SQL Server里，是我见过的惟一一个在SQL里存版本历史的版本控制工具。
（IBM 的 VisualAge 据说也是）
我觉得公司里小团队日常工具的最佳组合式 Jira + Perforce (或 svn) + twiki。
On Dec 26, 10:22 am, sagasw <sag...@gmail.com> wrote:
> 我们公司算是忠诚的微软党，
> PM用sharepoint做文档和项目网站，另外用project server做进度管理（我都是瞎填的）
> 微软自己不这么用，实在说不过去啊，
> 不过这些工具也比较适合我们pm的使用水平。
>
> ------------------------------------
jun lin
Shuo Chen
我呆过的三个公司的版本管理都是 Perforce，我自己在家用 subversion。对我来说
版本管理工具了解这两个已经足够了，没有动力去学 git，除非我要参加的开源项目
是用 git 的，目前还没这个打算。
trac 我试过，很好用，也看见有的开源项目在用它。如果几个朋友要搭伙干点啥，
而又不方便放到 google code 上，那么我会考虑用的。
否则，就用 google code 好了，一应俱全。
On Dec 26, 11:28 am, jun lin <linjunhal...@gmail.com> wrote:
> mercurial ,trac用的人多否？
>
> 2009/12/26 Shuo Chen <giantc...@gmail.com>
raymond
On Dec 24, 10:25 pm, jun lin <linjunhal...@gmail.com> wrote:
> dear all forks:
> 根据我个人的经验，开发软件，往往会遇到以下几类问题：
> 1.需求变更。
> 2.技术风险。
> 3.逐渐增加的复杂度。
> 现在我要说的是第3个，任何大项目都会遇到的问题。
>
> 作为我个人而言，开发经验其实不多，实际从事的项目就只有很少的几个。
> 但是在这几个项目里面，都多多少少遇到这样的问题：
> 当项目随着开发进度逐渐增长的时候，
> 以前的模块渐渐变得复杂，定义好的接口渐渐不能满足需求，
> 程序架构开始变得无法理解。
问题是什么？系统会变得越来越复杂是个现象，引起这个的原因最可能的是大的需求变更，以及最初的不合理设计（没有想明白需求就做设计）。
如何防止打的需求变更？在做一个软件之前，这个软件做什么需要明确定义，不做什么也会被明确定义。
如果是最初的不合理设计，那可能很难解决，可能只有推到重来，或者宣告失败。
> 尤其是界面程序开发。
> 虽然可以通过水平分层和模块切割减少系统耦合，
> 但是整体的系统，对于个人来说，需要相当长的时间，才能够理解。
> 对于稳定的系统，比如ERP之类，可以学习掌握，
> 但是对于开发中的系统，出现问题，或者效率瓶颈，需要debug的时间成指数级别的上升。
这个怎么说呢，更像管理问题。比如有一帮做操作系统的，一帮做应用的，做应用碰到bug开始调试，两天之后，发现是底层的一个bug，于是提交到底层人
员，人家几分钟就解决了。这是什么问题？
1. 底层接口了解不够，或者说底层文档，FAQ之类的提供的不足，总之，管理有问题。
2. 对自己的问题了解不够。除非底层有些东西让我们根本无法控制我们的程序如何运行（比如提交程序到google的平台上运行），否则我们是可以确定
问题到底处在哪里的，而且，不会花很长时间。关键是，我们对自己需要解决的问题的认识有多么深刻。
>
> 以前做过一个监控系统，底层需要监控好几个设备，跑了很多的线程，同时处理各种各样的判断逻辑。
> 在不断地修改中，程序bug渐渐变得难于fix，而代码也变得非常复杂，超过了我能够处理的程度。。
> 最后项目宣告失败。。。
如果没有回归测试和相对完整的unittest体系，出现这种情况并不奇怪。对于逻辑复杂的东西（比如某个模型的训练，大堆的数据处理，如果出现了些微
的错误，最后是很难检查的），我们在fix某个bug的时候，极可能破坏了另外的逻辑，加上了多线程，噩梦一样。
赵帅
你可以看看前几天有人提到的c++大会的post。
我个人觉得这个问题是无解的。
联想到一个很有趣的实验，就是“生物圈2号“
http://baike.baidu.com/view/593000.html?fromTaglist
软件开发的复杂度也许不如生物圈，但是某些大型项目已经接近，比如windows7，整个项目应该不少于几千人涉及。
http://news.skycn.com/article/22716.html
在这种复杂程度下，切分也好，优秀的设计方案也好，精英云集也好，都会产生你说的越来越复杂的情形，
常常遇到的情况是，不是对手太强，而是内部问题太多。（不怕狼一样的敌人，就怕猪一样的队友）
对于这种问题也许只有一个答案：破而后立。
历史上，各种政权的反复轮回也证明了这一点。
------------------------------------
C++, Lua, living in Dalian
http://sunxiunan.com/
http://twitter.com/sagasw
------------------------------------
2009/12/24 jun lin <linjun...@gmail.com>
dear all forks:
根据我个人的经验，开发软件，往往会遇到以下几类问题：
1.需求变更。
2.技术风险。
3.逐渐增加的复杂度。
现在我要说的是第3个，任何大项目都会遇到的问题。
作为我个人而言，开发经验其实不多，实际从事的项目就只有很少的几个。
但是在这几个项目里面，都多多少少遇到这样的问题：
当项目随着开发进度逐渐增长的时候，
以前的模块渐渐变得复杂，定义好的接口渐渐不能满足需求，
程序架构开始变得无法理解。
尤其是界面程序开发。
虽然可以通过水平分层和模块切割减少系统耦合，
但是整体的系统，对于个人来说，需要相当长的时间，才能够理解。
对于稳定的系统，比如ERP之类，可以学习掌握，
但是对于开发中的系统，出现问题，或者效率瓶颈，需要debug的时间成指数级别的上升。
以前做过一个监控系统，底层需要监控好几个设备，跑了很多的线程，同时处理各种各样的判断逻辑。
在不断地修改中，程序bug渐渐变得难于fix，而代码也变得非常复杂，超过了我能够处理的程度。。
最后项目宣告失败。。。
sagasw
猪不猪的只是个比喻，不必如此敏感。
------------------------------------
C++, Lua, living in Dalian
http://sunxiunan.com/
http://twitter.com/sagasw
------------------------------------
Kenny Yuan
人人生而“平等”，但是不同的人的智力却从来没有“同等”过。
--
Kenny Yuan
C++, UI, LISP, MMA, Psychology and Automobile.
BLOG: CS巴别塔(Computer Science Babel)
URL1: http://csbabel.wordpress.com/
URL2: http://blog.csdn.net/yuankaining/
jun lin
Kenny Yuan
missdeer
On Dec 28, 8:48 am, Kenny Yuan <yuankain...@gmail.com> wrote:
> 那也有很大的区别：有的人99%时间是是猪，有的人5%的时间是猪。
>
> 2009/12/28 jun lin <linjunhal...@gmail.com>
>
>
>
> > 大家其实都有猪的时候。。。
>
> > 2009/12/27 Kenny Yuan <yuankain...@gmail.com>
>
> > 估计你还没有见过某种类型的人类，所以才会这样说吧。
>
> >> 人人生而"*平等"*，但是不同的人的智力却从来没有"*同等*"过。
>
> >> 2009/12/27 赵帅 <rostin...@gmail.com>
>
> >>> 可能在你觉得你的队友是猪的时候，别人也觉得你是猪。
>
> >>> 2009/12/24 sagasw <sag...@gmail.com>
>
> >>>> 你可以看看前几天有人提到的c++大会的post。
>
> >>>> 我个人觉得这个问题是无解的。
> >>>> 联想到一个很有趣的实验，就是"生物圈2号"
> >>>>http://baike.baidu.com/view/593000.html?fromTaglist
> >>>> 软件开发的复杂度也许不如生物圈，但是某些大型项目已经接近，比如windows7，整个项目应该不少于几千人涉及。
> >>>>http://news.skycn.com/article/22716.html
>
> >>>> 在这种复杂程度下，切分也好，优秀的设计方案也好，精英云集也好，都会产生你说的越来越复杂的情形，
> >>>> 常常遇到的情况是，不是对手太强，而是内部问题太多。（不怕狼一样的敌人，就怕猪一样的队友）
>
> >>>> 对于这种问题也许只有一个答案：破而后立。
> >>>> 历史上，各种政权的反复轮回也证明了这一点。
>
> >>>> ------------------------------------
> >>>> C++, Lua, living in Dalian
> >>>>http://sunxiunan.com/
> >>>>http://twitter.com/sagasw
> >>>> ------------------------------------
>
> >>>> 2009/12/24 jun lin <linjunhal...@gmail.com>
Tinyfool
Fuzhou Chen
>
> 问题是什么？系统会变得越来越复杂是个现象，引起这个的原因最可能的是大的需求变更，以及最初的不合理设计（没有想明白需求就做设计）。
> 如何防止打的需求变更？在做一个软件之前，这个软件做什么需要明确定义，不做什么也会被明确定义。
> 如果是最初的不合理设计，那可能很难解决，可能只有推到重来，或者宣告失败。
要解决需求变更的问题，软件设计师必须理解什么需求可以接受，而什么
必须拒绝。如果我们承认软件是一种工具，那么我们就得承认工具有适用
范围。锤子不能当钳子用，这是起码的常识。
可惜到了现实中却完全不是这么回事，设计师没完没了地往程序里堆砌
没用的接口和参数，理由仅仅是“为了将来保持扩展性”。这种时候重
构往往还不能解决问题。房梁都错了，再怎么弥补也解决不了根子。还是
直接重来更有效。
> 这个怎么说呢，更像管理问题。比如有一帮做操作系统的，一帮做应用的，做应用碰到bug开始调试，两天之后，发现是底层的一个bug，于是提交到底层人
> 员，人家几分钟就解决了。这是什么问题？
> 1. 底层接口了解不够，或者说底层文档，FAQ之类的提供的不足，总之，管理有问题。
> 2. 对自己的问题了解不够。除非底层有些东西让我们根本无法控制我们的程序如何运行（比如提交程序到google的平台上运行），否则我们是可以确定
> 问题到底处在哪里的，而且，不会花很长时间。关键是，我们对自己需要解决的问题的认识有多么深刻。
所以我说知识传承比什么都重要。很多时候知识不够不是大家有意为之，往往
就是一个大牛离职之后大家惊奇地发现他/她什么资料都没留下来。如果再加上
开发组间交接之类之类的，就是雪上加霜。
我记得我有一个朋友曾经不无恼火地告诉我，所谓的fix，就是当你发现 1+1 = 3
的时候把它修改成 1 + 1 - 1 = 3 - 2 = 2。这也确实是我见过的一些维护期bug最
终的解决方案。
加强管理未必都管用，因为程序员不爱写文档几乎是个通病，我曾见过的一些文
档复查常常干脆就是走过场，跟代码复查不是一个级别。所以至少在我的公司，
传帮带仍然是不可缺少的。
raymond
On Dec 29, 3:27 am, Fuzhou Chen <cppof...@gmail.com> wrote:
> 2009/12/26 raymond <shiqu...@gmail.com>:
>
>
>
> > 问题是什么？系统会变得越来越复杂是个现象，引起这个的原因最可能的是大的需求变更，以及最初的不合理设计（没有想明白需求就做设计）。
> > 如何防止打的需求变更？在做一个软件之前，这个软件做什么需要明确定义，不做什么也会被明确定义。
> > 如果是最初的不合理设计，那可能很难解决，可能只有推到重来，或者宣告失败。
>
> 要解决需求变更的问题，软件设计师必须理解什么需求可以接受，而什么
> 必须拒绝。如果我们承认软件是一种工具，那么我们就得承认工具有适用
> 范围。锤子不能当钳子用，这是起码的常识。
>
> 可惜到了现实中却完全不是这么回事，设计师没完没了地往程序里堆砌
> 没用的接口和参数，理由仅仅是"为了将来保持扩展性"。这种时候重
> 构往往还不能解决问题。房梁都错了，再怎么弥补也解决不了根子。还是
> 直接重来更有效。
>
> > 这个怎么说呢，更像管理问题。比如有一帮做操作系统的，一帮做应用的，做应用碰到bug开始调试，两天之后，发现是底层的一个bug，于是提交到底层人
> > 员，人家几分钟就解决了。这是什么问题？
> > 1. 底层接口了解不够，或者说底层文档，FAQ之类的提供的不足，总之，管理有问题。
> > 2. 对自己的问题了解不够。除非底层有些东西让我们根本无法控制我们的程序如何运行（比如提交程序到google的平台上运行），否则我们是可以确定
> > 问题到底处在哪里的，而且，不会花很长时间。关键是，我们对自己需要解决的问题的认识有多么深刻。
>
> 所以我说知识传承比什么都重要。很多时候知识不够不是大家有意为之，往往
> 就是一个大牛离职之后大家惊奇地发现他/她什么资料都没留下来。如果再加上
> 开发组间交接之类之类的，就是雪上加霜。
看到这句话我特别有感触，我喜欢将一切写清楚，对于我的程序，我会给出用法实例，还可以改进的地方，照着做就没有问题，原因就是不喜欢被一遍遍问，这个
如何执行，那个如何执行，参数什么意思，那个功能有没有等等，等等，如果我是主管，我肯定主张，你的文档必须保证队友可以不问你任何问题就可以正确执
行。
但是有时候未必能达到如此，不知道大家是不喜欢呢还是怎么回事。
missdeer
>
这有开发人员个人的问题，比如主观情绪上不喜欢（？），懒，等等。
但不可否认管理上也是有很大责任的，考评的时候很可能只是看开发人员产出了多少代码，实现了多少特性，修正了多少问题，而少有关注他同时编写了多少文
档，甚至如果某些人编写文档方面做得比大多数人好却得不到相应的激励。既然除了良心上道德上（？）的有那么一点惩罚，其他的没实质影响，为什么要比别人
花更多力气去做这些事呢？
Fuzhou Chen
唯一原因就是没有产出。
这就和测试在中小规模的商业软件开发项目中常常被所谓的top coder
们认为是骗吃骗喝一样。商业的本质是追逐利润，那么只要是对利润没
有贡献的开销，资本家就不可能主动地投钱，除了一种例外，就是资本
家确实看到了这些投入会带来隐性的收益。
举例来说，我们假设某天某微软高管脑袋发昏，要求关闭MSDN在线网站，
宣布所有第三方Windows开发公司必须购买Visual Studio来获得文档，
那么我们几乎可以立即肯定整个微软商业体系会瞬间崩溃，因为他们将
立即失去大量的客户支持。别忘了有为数不少的学生甚至商业用户是依靠
免费的MSDN和Windows Platform SDK/DDK开发的。
当然，微软的高管不是蠢货。他们显然能够意识到这个问题，这就解释了
为什么这么多年他们一直会坚持花钱维护MSDN在线文档：因为这是保存
整个微软开发生态的要件。反过来，很多软件项目的盈利模式中没有这个
要件，那么这时没文档显然更有利，因为客户出问题之后无法找别人解决，
还是得来找我。
所以虽然我很尊敬那些主动维护文档的兄弟，但我不会把软件改进的希望
寄托在他们身上，因为这不可能成为一个广泛的群体行为。
P.S.：顺便说一句，很多时候MSDN的资料仍然忽略了大量的细
节。一个很好的的例子是CreateProcess()中的dwProcessCreationFlags
选项。每一次我修改bug的时候都是心惊胆战，因为所有flags之间并不是正
交而是存在优先和继承关系的，我生怕搞出什么奇怪的行为来。可没办法，
MSDN没有给出对这些内容做更详细的说明，也没有source code参考，我
只能一个一个操作系统地试过去。
2009/12/29 missdeer <miss...@gmail.com>:
--
