论“软件工程”中的分工

knighter

原帖由 liuty2006 于 2007-9-28 22:14 发表
MS几千人参与的系统设计开发，怎么协调？
COM组件开发起了很重要的作用。
也就是各模块之间只暴露接口。这样，当内部实现发生改变时不会影响其他部分的运行。
可以说，WINDOWS操作系统其实就是一个组件库。
COM组件被MS应用的炉火纯青！

程序开发经历了三个阶段：
面向过程－－》面向对象－－》面向接口（组件开发）

现在正在兴起面向服务。

感觉：面向接口开发可以使系统开发并行，各个组件只对接口负责。
解决了多人开发协调的问题。

受教了！

之前了解面向过程和面向对象多一些，目前的开发模式好像仍多见为面向对象

而面向接口和面向服务，则知之甚少，庐山瀑布汗

有空找些资料看看

liuty2006

面向服务知道一些，但没有实践。
但对面向接口编程，感触很多。
好不夸张地说，对编程观念是个很大的改变，甚至可以说是革命。
觉得任何一个程序员都要了解这个技术。

面向接口后，感觉面向对象很“丑陋”：（
面向接口后，各模块之间松散结合，很柔和
而且面向接口后，编程前它会强迫你面对接口思考问题。

反正很多有点。。。

在软件领域，MS的确牛！

jaffaz

原帖由 liuty2006 于 2007-9-28 23:23 发表
面向服务知道一些，但没有实践。
但对面向接口编程，感触很多。
好不夸张地说，对编程观念是个很大的改变，甚至可以说是革命。
觉得任何一个程序员都要了解这个技术。

面向接口后，感觉面向对象很“丑陋” ...

找了点面向接口的东西看了下，觉得面向接口更注重于设计以及定义。
面向接口和面向对象之间的交集还是很大的，毕竟接口抽象在面向对象里面处于核心地位，只不过面向对象还包含了“编程”。

山中无老虎

概念混了，面向对象是一种开发的思想，面象接口是一种开发的方法。
面象接口个人认为就是一种黑盒开发方法，至于盒里的是什么，只有做他的人知道，这样很容易导致技术壁垒，有详细的文档也是扯蛋，如果开发设计组件接口的人离开，接手的人很难。
而且这种方式实际上就是一种培养软件工人的方式。
面象接口的方法并不能解决前面所说的问题

山中无老虎

原帖由 liuty2006 于 2007-9-28 22:14 发表
MS几千人参与的系统设计开发，怎么协调？
COM组件开发起了很重要的作用。
也就是各模块之间只暴露接口。这样，当内部实现发生改变时不会影响其他部分的运行。
可以说，WINDOWS操作系统其实就是一个组件库。
COM组件被MS应用的炉火纯青！

程序开发经历了三个阶段：
面向过程－－》面向对象－－》面向接口（组件开发）

现在正在兴起面向服务。

感觉：面向接口开发可以使系统开发并行，各个组件只对接口负责。
解决了多人开发协调的问题。

有这种条件的公司毕竟是少数，待遇好，条件好，即使做他的软件工人也可以衣、食无忧，但国内的公司大多没有这么好的条件，如果做一个软件工人，以后的出路在哪只有天才知道。在国内公司中如果采用这种方式，人员的流动性会很大，因为只能是少数人了解核心，大多数人都是在绕着他转，对公司的发展很不利。
你的感觉是不对的，如果底层的接口没有做好，各组件的功能也不可能完善，并行开发时能是造成更大的工期浪费。
沟通问题也没有解决，只是缩小的沟通的范围：在设计开发接口的人之间进行，也一样存在沟通。只是说采用这种方式后，如果接口（底层）有问题，跟上层没有关系是相对的，底层开发人员的开发也需要沟通，如果出现设计更改的情况，上层的开发也必须做出更改。
每一种方法都有其优势，也有其劣势，没有解决一切问题的“银蛋”。

山中无老虎

原帖由 liuty2006 于 2007-9-28 23:23 发表
面向服务知道一些，但没有实践。
但对面向接口编程，感触很多。
好不夸张地说，对编程观念是个很大的改变，甚至可以说是革命。
觉得任何一个程序员都要了解这个技术。

面向接口后，感觉面向对象很“丑陋” ...

面向接口只是一个方法，不是一种技术。
面向接口编程还是没有跑出面向对象的的范围。
比如持久层对DAO实行接口编程，可以实现业务层和持久层的分离，但你再细分析一下，DAO与持久层的内容，不也就是一个个的类么，只不过进行了一些封装而已。接口也只不过是一种抽象。

aha111

[quote]原帖由 山中无老虎 于 2007-9-29 09:13 发表


    只赞同你这一句“每一种方法都有其优势，也有其劣势，没有解决一切问题的银蛋”，这篇文章就是以软件工程中详细分工方法的缺点来完全否定软件工程，提倡完全个人全程操作。

    无论在什么样的公司，人员的流动性是不可避免的，无论是主动的还是被动的，对公司来说，考虑如何让人员不流动是毫无意义的。软件工程的提出确实是为了流水线操作，这样做的目的呢，既是为了提高开发效率，不只是只有几个高手才可以参与项目，这样也可以减少人力资本。同时，也是为了减少员工的流动对项目造成的影响，公司就是想让任何一个人都是一颗螺丝，拔掉一颗螺丝还能运转。从企业管理或项目管理的角度来说，这种想法不是很应该的吗？

   确实，这篇文章提出了一个软件工程中普通面临的问题，全篇而言，有意义的也仅此而已。

[ 本帖最后由 aha111 于 2007-9-29 10:13 编辑 ]

liuty2006

面向接口是对面向对象的升华。
将面向对象中的纯虚类以接口的方式固定下来。
从“最好使用”改变为“必须使用”接口方式编程。
以物理的方式强迫你面向接口进行思考。

山中无老虎

原帖由 aha111 于 2007-9-29 09:46 发表

无论在什么样的公司，人员的流动性是不可避免的，无论是主动的还是被动的，对公司来说，考虑如何让人员不流动是毫无意义的。软件工程的提出确实是为了流水线操作，这样做的目的呢，既是为了提高开发效率，不只是只有几个高手才可以参与项目，这样也可以减少人力资本。同时，也是为了减少员工的流动对项目造成的影响，公司就是想让任何一个人都是一颗螺丝，拔掉一颗螺丝还能运转。从企业管理或项目管理的角度来说，这种想法不是很应该的吗？

看到你的引用后，我才发现，银弹的弹写成蛋了。
人员流动是正常的，如果一个公司没有人员流动，这个公司离关门也不太远了，因为没有了活力。这一点我绝对赞同。我所说的防止人员流动是指那些有培养价值的人的外流，这对公司的打击是很大的，这类人是公司以后发展的关键。
至于软件工程方面的说法，我觉得这种想法是应该的。但这仅是一种理论的想法，每一个人都是一颗螺丝，少了一个螺丝对运转影响不大，但毕竟还有轴承，采用软件工程的方法，轴承如果掉了，机器的运转会出现什么情况呢？即使找到一个新的轴承，所花费的时间恐怕要比不采用软件工程的方式要多的多吧。我个人觉得软件工程学考虑了面的问题，他试图将复杂问题简单化，但没有考虑点的问题，特别是关键点的问题。毕竟一个项目/产品，必须有一个或几个关键的人来支撑的，关键人的因素是不能忽略的。单纯的流水化作业方法并不是可取的。

山中无老虎

原帖由 liuty2006 于 2007-9-29 10:11 发表
面向接口是对面向对象的升华。
将面向对象中的纯虚类以接口的方式固定下来。
从“最好使用”改变为“必须使用”接口方式编程。
以物理的方式强迫你面向接口进行思考。

那只是编程方法，但不是编程的思想。