回复关系：
作者 内容
 liujunsong  软件开发：作坊还是工厂？
软件开发：作坊还是工厂？

对于软件的开发，有两种分歧很大的开发模式，一种是作坊式的开发模式，一种是工厂式的开发模式。

早期的软件开发大多是作坊式的开发，现在的系统则大多是工厂式的开发。现在很多人都认为作坊式的开发已经过时，应该关闭，改开工厂了，我认为问题没这么简单，无论采用那种开发模式，其实都与具体情况有关，怎么能脱离实际情况空谈应该采用那种开发模式呢？

那么究竟应该采用作坊式的开发呢，还是工厂式的开发呢？
要回答这个问题，首先要讨论一下这两者的区别，分析他们的长处和不足，才能得出有用的结论。

两者的区别，首先是在分工上的区别，作坊中没有明确的分工，一个人今天干这个，明天也许就干那个，他的角色不是固定的，而是随着情况的变化而进行变化；而工厂中则存在明确的分工，定岗定编，一个萝卜一个坑，每个人的角色是固定的，做的工作也是固定的。是否存在明确的分工，是作坊和工厂的根本区别，这个根本区别从而引发了其他的一系列区别。

在人员之间的关系上，作坊中的基本关系是师傅和学徒的关系，而工厂中的基本关系是经理和程序员的关系；前者的关系是老师和学生的关系，后者的关系是管理者和被管理者的关系。前者之间的师傅，徒弟之间的关系一般是不变的，而后者经理，程序员的关系是可变的；前者主要依靠经验，后者主要依靠能力。在新一代的培养上，由于教会了徒弟，师傅的地位就会受到威胁，所谓“教会徒弟，饿死师傅”所以强调“师傅领进门，修行在各人”，对于徒弟的培养，师傅的态度往往是很消极的；而在工厂中，由于程序员的能力提高会威胁到经理的地位，经理对于培养程序员也是心存戒心，强调“术业有专攻”,鼓励程序员专心研究技术，对其他不闻不问，尽力培养出一些除了技术，对其他一无所知的人才出来
。作坊中，起决定作用的是大师傅，工厂中，起决定作用的是项目经理。

作坊中，技术是大师傅安身立命的法宝，所以他轻易不传授给别人，最后往往导致技术的失传；工厂中，技术是大家所共有的，也根本无法进行独占，这一方面提供了信息的共享，另一方面却也使得个人的学习更加盲目，不知该如何进行，分工也使得每个人对别人的工作知之甚少，最后交流起来变得非常困难。

如果打个比喻的话，作坊式的开发就如同武林中的门派，全靠师父进行传功，代代相传；而工厂则象科学上的分类，分门别类，科目林立，每个人在其中钻研其中的一小部分，对其他人的工作不闻不问。

很多人都在讨论软件开发是科学还是艺术，依我看来，这就是作坊式的开发与工厂式的开发的不同了，

如果把软件开发当成一门艺术的话，那么就会倾向于用作坊式的开发；如果把软件开发当成一门科学的话，那么就会倾向于用工厂式的开发。事实上，软件开发是科学和艺术的有机结合体，两者不可分割，只要把作坊式的开发和工厂式的开发结合起来，才是解决软件开发问题的根本方法，任何把两者对立起来的方法，都不能真正解决任何问题。
 02/06/07 10:07 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 smilemac   呵呵，老兄是一天一篇
不过还是没有真正讲出“作坊”与“工厂”的区别。他们的本质区别在于作坊的生产是不可重复的，而工厂的生产则是可重复的生产。而重复则能产生可预测的质量，则能产生规模，规模才能产生效益。软件工程的主要目的之一就是探索质量可重复的软件过程，甚至XP这种表面极像作坊式开发的方法，深层的目标依然是一个可重复的高效的流程。所以，作坊与工厂的真正区别并不在于人多人少，也不在于是否有分工，而是开发流程是否可以重复进行。如果一个软件的开发过程是可重复的，即使一个程序员也可组成一个工厂。老兄如果能仔细研究一下CMM就能明白这一点。

但天下没有十全十美的事情，重复也是需要付出代价的，代价之一就是开发的速度可能放缓，因此是采用作坊还是工厂，我的看法是取决于具体项目的发展阶段，在拼市场，拼速度的时候，可以采用作坊式开发，而一旦在市场上站稳脚跟，则必须采用可重复的软件过程。
 02/06/07 11:40 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 liujunsong  回复: 呵呵，老兄是一天一篇
>>而工厂的生产则是可重复的生产。
请问软件开发的过程是可重复的吗?我认为既然是脑力劳动,就必然有其不可重复性.同样一个问题,想到第二遍时和第一遍总是有些差别的,不是吗?

>>而重复则能产生可预测的质量，则能产生规模，规模才能产生效益。
从本质上讲,软件开发是不可重复的,所以可预测的质量只是自欺其人而已.请问这个质量应该用什么来衡量呢?软件的质量,本身就是一个很含糊的概念,并没有明确的指标,所有各种指标其实都是一些搞管理的人自以为是做出来的东西罢了,靠这些东西来进行预测,我认为是荒唐的.
至于规模,软件的规模和其效益并没有直接关系,用1000人写出来的软件,未必比比100人写出来的软件更好用,更能产生效益.一个编写糟糕的软件,其市场越大,以后给它自己带来的麻烦也可能越多,给用户带来的问题也可能越多.所以规模和效益并没有逻辑关系.

各种质量管理方法,例如CMM之类的东西,其出发点都是作出更好的软件,防止软件开发中的问题,但是具体能不能真正达到这个目的,需要根据具体情况来决定,而不能一概而论.工具并没有智能,只有人才有智能.
 02/06/07 15:06 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 liujunsong  回复: 呵呵，老兄是一天一篇
>>而工厂的生产则是可重复的生产。
请问软件开发的过程是可重复的吗?我认为既然是脑力劳动,就必然有其不可重复性.同样一个问题,想到第二遍时和第一遍总是有些差别的,不是吗?

>>而重复则能产生可预测的质量，则能产生规模，规模才能产生效益。
从本质上讲,软件开发是不可重复的,所以可预测的质量只是自欺其人而已.请问这个质量应该用什么来衡量呢?软件的质量,本身就是一个很含糊的概念,并没有明确的指标,所有各种指标其实都是一些搞管理的人自以为是做出来的东西罢了,靠这些东西来进行预测,我认为是荒唐的.
至于规模,软件的规模和其效益并没有直接关系,用1000人写出来的软件,未必比比100人写出来的软件更好用,更能产生效益.一个编写糟糕的软件,其市场越大,以后给它自己带来的麻烦也可能越多,给用户带来的问题也可能越多.所以规模和效益并没有逻辑关系.

各种质量管理方法,例如CMM之类的东西,其出发点都是作出更好的软件,防止软件开发中的问题,但是具体能不能真正达到这个目的,需要根据具体情况来决定,而不能一概而论.工具并没有智能,只有人才有智能.
 02/06/07 15:06 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 liujunsong  回复: 呵呵，老兄是一天一篇
>>而工厂的生产则是可重复的生产。
请问软件开发的过程是可重复的吗?我认为既然是脑力劳动,就必然有其不可重复性.同样一个问题,想到第二遍时和第一遍总是有些差别的,不是吗?

>>而重复则能产生可预测的质量，则能产生规模，规模才能产生效益。
从本质上讲,软件开发是不可重复的,所以可预测的质量只是自欺其人而已.请问这个质量应该用什么来衡量呢?软件的质量,本身就是一个很含糊的概念,并没有明确的指标,所有各种指标其实都是一些搞管理的人自以为是做出来的东西罢了,靠这些东西来进行预测,我认为是荒唐的.
至于规模,软件的规模和其效益并没有直接关系,用1000人写出来的软件,未必比比100人写出来的软件更好用,更能产生效益.一个编写糟糕的软件,其市场越大,以后给它自己带来的麻烦也可能越多,给用户带来的问题也可能越多.所以规模和效益并没有逻辑关系.

各种质量管理方法,例如CMM之类的东西,其出发点都是作出更好的软件,防止软件开发中的问题,但是具体能不能真正达到这个目的,需要根据具体情况来决定,而不能一概而论.工具并没有智能,只有人才有智能.
 02/06/07 15:06 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 smilemac   对不起，刚才的语言有些不妥，这是修订版：）
在软件工程里，“重复”一词并不是指传统Manufactory式的重复，而是指软件过程的重复（软件过程这个词在软件工程也是有比较严格的定义的），是指重复一个同样的开发过程（不是把一个软件再开发一遍，呵呵，真没想到你是这样理解），可以产生一个可以控制的软件质量，这样，软件质量是可以预期的（是从统计意义上--工程科学的思维，想想，即使工厂也会上生产出一个半个的废品）。

软件到底有没有明确的质量目标，这个在很多软件工程的书已有论述。虽然软件复杂性与可靠性的关系目前还在研究，但定性的结论已有很多，也出现很多针对解决特定复杂性问题的方法。国外的一些研究项目的成果也表明，大多数软件失效是可以控制的。因此，我认为，软件质量是可以被规划的。
 02/06/07 15:36 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 smilemac   同样的话说三遍和说一遍是一样的， 玩笑
liu老兄，不用一下回三次吧。
 02/06/07 15:38 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 liujunsong  回复: 呵呵，老兄是一天一篇
作为一个软件项目开发来说，好象是有明确的目标的，但是仔细想来，就会发现其中有很多是虚的东西，放在口头上说说可以，实际去做根本办不到。
例如满足客户要求，做到什么程度就叫满足呢？满足与不满足之间的界限如何划分呢？其实这是一句很虚的话，根本没有确切的标准来衡量，难道不是吗？
再比如：按照项目进度。可是项目的进度是按照推测而设计的，在实际过程中情况在不断变化，又任何真正地来执行这些计划呢？例如项目规定要10个月完成，可是在实际中如果时间不足，那么怎么办呢？最初的原始条件就不够正确，又怎么能得出这样的结论呢？

软件工程的书我也看过很多，可是总的感觉就是一个字：虚。
听起来好像是那么一回事儿，仔细想想发现都经不起推敲。

重复一个开发过程有什么意义？为什么别人做这个分析需要1天，我就不能用2天？如果承认人与人的不同，承认脑力工作的特殊性，那么就最好干脆放弃这种制定时间进度，想让工程师按照自己的思想速度来想问题的思维方式。

可以控制的软件质量，拿什么度量呢？软件质量这个东西虚无缥缈，制定出来的标准真的那么合理，那么科学吗？还是制定标准的人自以为是来制定的呢？

究竟，什么是软件质量，它应该拿什么来度量呢？
 02/06/07 15:48 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 supergaosong  作坊还是工厂？
莎翁筆下的哈姆萊特說:生存?還是滅亡?這是個問題.同樣,對我來說,作坊?還是工廠?這也是個問題.
我從開始接觸軟件開發,就是從最基本的代碼的編寫開始,我一直夢想著成為軟件開發工程師,這曾經是個我可望而不可及的工作.就在我朝著我認為的方向努力地時候,我突然發現,我正在朝著一個以前從沒有認識的目標走.我無法判斷我的方向.也就是說:我不知道我應該繼續從事編碼的工作,還是調整方向,去做設計和分析.
對現在的軟件的開發來說,設計和分析工作幾乎是必需的,這一點在這個論壇裡可以找到很多理論證據.但是我自認為對於需求分析這樣的工作並不擅長,對於其他的領域的業務問題我也很難感興趣.是否這樣我就注定了無法成為一個合格的軟件工程師?是不是只有作坊式的軟件開發才適合我?
 02/06/07 15:58 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 smilemac   回复: 呵呵，老兄是一天一篇
如果一个团队里所有岗位的人员水平都很差，确实项目失败的可能性也很大，即使在工厂里，如果工人不合格，那么生产出废品的可能性也是非常大的，但这和作坊式开发好还是工厂式开发好的问题没有太大干系，因为岗位人员合格应该是最起码的要求，对任何活动都是如此。
但即使是在“蜀中无大将”局面下，采取软件工程的方法有计划有目标地实施项目管理，其风险也是低于放任自流，摸着石头过河的作坊式开发方法，除非你是要与对手比速度（闷着头跑可能是最快的，但方向却可能是错误的，这是赌博，而非项目）。
但即使在比速度时，合理地计划与粗糙的计划也是有天壤之别的。我在两年前曾带着一支7人队伍（包括测试文档)在两个月的时间里完成了近30万行代码，项目也基本达到了预期的目标。初看我那个项目里完全没有软件工程的影子，但实际不是。软件工程并不虚，但如果你教条地使用它，他就虚了。
 02/06/07 16:11 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 smilemac   回复: 呵呵，老兄是一天一篇
[[引文]重复一个开发过程有什么意义？为什么别人做这个分析需要1天，我就不能用2天？如果承认人与人的不同，承认脑力工作的特殊性，那么就最好干脆放弃这种制定时间进度，想让工程师按照自己的思想速度来想问题的思维方式。]

算了，不说了，你还是不明白。
 02/06/07 16:15 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 正宗百晓生  回复: 软件开发：作坊还是工厂？
有点意思，刘兄在江湖榜上的位置看来却需好好思量。
老树发新枝榜一定是状元啦。
 02/06/07 16:22 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 killcamel  呵呵，那老兄就什么都别干了
用户给你5万，你一个月后给用户一个写得很差的程序，到处是goto，无法维护，预计只能使用一年，但用户在这一年中可以削减3个年薪3万的人员。是不是用户会更感谢你用1年时间收集需求，2年后提供大量的UML设计文档和RUP过程文档，完美的OO程序，唯一的问题就是用户公司已经退出这一业务了。？
 02/06/08 00:31 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 killcamel  呵呵，大牛啊。
7人队伍（包括测试文档)在两个月的时间里完成了近30万行代码。
重复代码不少吧。

在“蜀中无大将”局面下，类似CMM的规范管理可是绝对优势。如果一个团队里所有岗位的人员水平都很差，作坊式基本没有成功的可能。但工厂式只要有一套sample，用用paste，不考虑代码复用，逐个调整修改定制。不考虑程序的内部质量，完成项目还是很有可能的。虽然投入的人月多了，但单价降低了，总的人工成本也高不了多少，而且是用户出钱培训了开发人员。好处多多啊。
 02/06/08 00:44 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 smilemac   回复: 呵呵，大牛啊。
[重复代码不少吧。 ]

有一些重复，我针对该问题域设计实现了一种新的体系结构，主要的类的结构变得很相似，有些代码的结构也变得很相似，所以可以从模版中拷贝然后修改，以至不少用传统方法编写需要想一想或很小心作的代码在这里变成了纯粹的体力劳动，而且出错率也比较低，这一点在我们开发过程中确实提高了不少效率，不过那两个月也够累的，所有人除了睡觉吃饭其他时间都在工作。
 02/06/08 00:59 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 smilemac  你说得不错。:）不过项目管理者要具有足够的水平，否则可能还是逃脱不了失败的命运，只不过失败了比较容易找原因罢了。
[ 在“蜀中无大将”局面下，类似CMM的规范管理可是绝对优势。如果一个团队里所有岗位的人员水平都很差，作坊式基本没有成功的可能。但工厂式只要有一套sample，用用paste，不考虑代码复用，逐个调整修改定制。不考虑程序的内部质量，完成项目还是很有可能的。虽然投入的人月多了，但单价降低了，总的人工成本也高不了多少，而且是用户出钱培训了开发人员。好处多多啊。 ]

你说得不错。:）不过项目管理者要具有足够的水平，否则可能还是逃脱不了失败的命运，只不过失败了比较容易找原因罢了。
 02/06/08 01:04 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 killcamel  回复: 呵呵，大牛啊。
是啊。
其实如果有时间，人才，还可能考虑是不是用template pattern减少重复代码。只是没有必要。人才供给有限，应该被用在更重要的项目上。在这种项目上现在有了原型模版，只是投入人员和时间的问题了。只要有一个普通开发人员从原型模版的设计上学到了东东，对公司反而更有利。这种项目中的培训比再怎么努力看书自学都有用。
 02/06/08 01:12 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 smilemac   纠正一下
我前面的帖子可能将不同内容不合适地放在了一起，以至引起了误解。在我那个项目里，每个人都很优秀，都是独当一面的好手，但即使是好手，当时的时间要求也是非常紧迫的，为了抢时间，必须在设计和开发方法上想办法。当时我们接下那个项目时，有不少同事认为我发疯了，或认为肯定不成功。赫赫，侥幸。
 02/06/08 10:53 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 killcamel  我是针对这种开发方法说的
这种开发是鬼子常见的。
所以我还是知道这种方式下7个人2个月写30万行是什么概念。就算有10万行的sample，光告诉一般程序员调用关系就不止2个月了。你这个项目的进度表意味着程序员看一眼sample程序就明白了设计意图并能贯彻。
但我和那些认为你发疯了的同事们有同感。你的幸运在于你能获得足够比例的优秀程序员。这在很多时候几乎是不可能的。
另外，我不同意你说的在这个项目中软件工程影子作用的说法。我不相信你们会在这样的项目中实行软件工程。之所以会在事后回顾时觉得有软件工程的影子只是由于项目成员的经验，在开发中自觉使用了自己所知道的方法。最简单的例子就是对程序员来说，确保自己修改的程序在最新版本的源程序中编译通过是最基本的常识，很难说在这时是由于软件工程的影子作用。事实上，我觉得就这个项目而言，直觉是最重要的，不管是设计还是优先级安排。你没有时间仔细考虑，更没有时间犯错误。对我来说，我不是天才，所以我的直觉只会来自经验，而且还不能肯定正确与否，这就需要运气了。那些不需要经验，只用书本上的名词就能正确管理开发过程的肯定是天才，我相信。
对公司而言，为数不多的优秀程序员被类似这个例子的项目大量吸纳，在大量其他的开发项目上，当然就是使用CMM之类的规范确保那些项目能被一般入门水准的程序员完成，如果运气好，能有好手给他们一个sample，运气不好，用JAVA写面向过程也无妨，只要项目能完成。
所以我对国内只有几十个程序员的开发公司都盯住CMM过级觉得很有趣。是好笑话。
 02/06/08 11:26 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 smilemac   你说的对
那个项目里第一功臣是直觉。（以至于我后来判断一个程序员好坏就是看他/她的直觉能力怎么样：）），但第二却是计划，当时我为做计划绞尽了脑汁。计划也完全打破常规，不再按照模块进行分工，而是个人特点、目标和时间的综合考虑结果，经常一个模块有好几个人，一个人同时参与好几个模块。我觉得这是工程化方法，（后来我回顾时发现颇有点象XP,可惜我当时不知道有这种方法，知道后可能底气会更足一些：））
你是第一个和我讲写程序要靠直觉的人，以前我和别人讲别人都不是很认同。赫赫。
 02/06/08 11:46 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 killcamel  呵呵，XP在国内也变质了
本来别人是已经下意识就使用了模式，导致了设计过度，要用XP来返朴归真。
结果很多人还不知道基本编程规范，就用XP来为自己作理由。我也看不出两个入门级程序员的配对编程会有什么好处，除了出产打着OO招牌的面向过程程序。
对我来说，先到了会设计过度的级别再来玩XP，但前提是得找个牛人搭档学东东。
我个人以为，对公司来说，好手的项目用XP，一般的项目用规范化生产是比较好的搭配。
 02/06/08 12:02 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 sealw  有一个名词叫封闭开发，其实就是把人当机器来用。
 02/06/08 13:26 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 smilemac   回复: 有一个名词叫封闭开发，其实就是把人当机器来用。
虽然像机器一样，但那两个月却是我工作生涯里最快乐的时光，现在虽然工作环境好了很多，也没那时累，却没有那时快乐。不少旧同事到现在还很怀念那段工作的时光。
 02/06/08 13:33 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 sealw  呵呵，此人之肉，彼人之毒
为什么成功经验没有被重复运用？

还是象你说的，成功本身纯属侥幸？

我只是听说过很多封闭开发失败的例子。第一次听到成功的说。
 02/06/08 13:37 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 smilemac   回复: 呵呵，此人之肉，彼人之毒
后来又搞了两次，但时间很短，两三个星期，是演进开发，也都成功了，还通过了专家鉴定。再后来，我离开了那家公司，再后来，新的公司没有这样的文化，教条主义十分盛行，后来我又换了公司。赫赫。
我认为，封闭开发虽然残酷，却很有效。
 02/06/08 13:46 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 sealw  成功却没能从胜利走向胜利，可惜啊
如果有公司要封闭我，我可能首先想到的是开路

其次想到的是开多少钱一个月啊？钱多的话，时间又不长，就牺牲一下吧。

每个人都想牺牲自我，从而实现超我。但对牺牲的方式认同程度却很低。
 02/06/08 13:52 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 smilemac   回复: 成功却没能从胜利走向胜利，可惜啊
呵呵，物质奖励是必须的，没有钱，没有人会干。
封闭开发必须以金钱为基础。
 02/06/08 14:08 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 hefangdotcom  回复: 作坊还是工厂？
软件开发是个庞大的行业，所谓的热门的OOAD只适合企业信息系统，只是软件开发行业中的一分支而已，当然企业信息系统产值很大。
如果你不适合作分析设计，你可以在自己认定的领域成为专家，并努力做到最好。这样的领域你可以自己定义，比如：图像格式处理/编码解码/信息采集
我认识的一个朋友，基本上只会作串口通信，但他干的非常好，是名副其实的领域专家。这样的人才可能不是很容易换工作，但他的地位稳固，而且容易作出成就。
 02/06/09 14:47 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 j2ee   我比较痛恨“封闭开发”，那真是C++猴，或Java猴了
 02/06/09 16:09 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：