免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
楼主: knighter
打印 上一主题 下一主题

论“软件工程”中的分工 [复制链接]

论坛徽章:
0
41 [报告]
发表于 2007-09-29 10:33 |只看该作者
原帖由 山中无老虎 于 2007-9-29 10:24 发表

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

昨晚我仔细想了想,觉得好像面向接口只是面向对象的一种衍生

但是现在没有找资料,没有发言权

论坛徽章:
2
综合交流区版块每日发帖之星
日期:2015-08-06 06:20:00每日论坛发贴之星
日期:2015-08-06 06:20:00
42 [报告]
发表于 2007-09-29 10:35 |只看该作者
原帖由 knighter 于 2007-9-29 10:33 发表

昨晚我仔细想了想,觉得好像面向接口只是面向对象的一种衍生

但是现在没有找资料,没有发言权

看了2006的发言后,找的一篇文章。
引用自:http://www.e-midas.cn/Article_Show.asp?ArticleID=107
在一个面向对象的系统中,系统的各种功能是由许许多多的不同对象协作完成的。在这种情况下,各个对象内部是如何实现自己的对系统设计人员来讲就不那么重要了;而各个对象之间的协作关系则成为系统设计的关键。小到不同类之间的通信,大到各模块之间的交互,在系统设计之初都是要着重考虑的,这也是系统设计的主要工作内容。面向接口编程我想就是指按照这种思想来编程吧!实际上,在日常工作中,你已经按照接口编程了,只不过如果你没有这方面的意识,那么你只是在被动的实现这一思想;表现在频繁的抱怨别人改的代码影响了你(接口没有设计到),表现在某个模块的改动引起其他模块的大规模调整(模块接口没有很好的设计)等等。

  Booch先生那天谈到Interaction Designer,它就是指做这类设计的人,只不过层次更高一些。我想目前我们的软件设计队伍中,这类人是最缺乏的人才之一。
非接口编程?是不是就是面向过程的编程思想?

  1.关于接口的理解。
  接口从更深层次的理解,应是定义(规范,约束)与实现(名实分离的原则)的分离。
  我们在一般实现一个系统的时候,通常是将定义与实现合为一体,不加分离的,我认为最为理解的系统设计规范应是所有的定义与实现分离,尽管这可能对系统中的某些情况有点繁烦。
  接口的本身反映了系统设计人员对系统的抽象理解。
  接口应有两类:第一类是对一个体的抽象,它可对应为一个抽象体(abstract class);
  第二类是对一个体某一方面的抽象,即形成一个抽象面(interface);
  一个体有可能有多个抽象面。
  抽象体与抽象面是有区别的。

  2.设计接口的另一个不可忽视的因素是接口所处的环境(context,environment),系统论的观点:环境是系统要素所处的空间与外部影响因素的总和。任何接口都是在一定的环境中产生的。因此环境的定义及环境的变化对接口的影响是不容忽视的,脱离原先的环境,所有的接口将失去原有的意义。

  3.按照组件的开发模型(3C),它们三者相辅相成,各司一面,浑然一体,缺一不可。

  面向对象是指,我们考虑问题时,以对象为单位,考虑它的属性及方法
  面向过程是指,我们考虑问题时,以一个具体的流程(事务过程)为单位,考虑它的实现
  接口设计与非接口设计是针对复用技术而言的,与面向对象(过程)不是一个问题

  我认为:UML里面所说的interface是协议的另一种说法。并不是指com的interface,CORBA的interface,Java的interface,Delphi的interface,人机界面的interface或NIC的interface。

  在具体实现中,是可以把UML的interface实现为语言的interface,分布式对象环境的interface或其它什么interface,但就理解UML的interface而言,指的是系统每部分的实现和实现之间,通过interface所确定的协议来共同工作。

  所以我认为,面向interface编程,原意是指面向抽象协议编程,实现者在实现时要严格按协议来办。也就是Bill Joy同志说的,一边翻rfc,一边写代码的意思。面向对象编程是指面向抽象和具象。抽象和具象是矛盾的统一体,不可能只有抽象没有具象。一般懂得抽象的人都明白这个道理。 但有的人只知具象却不知抽象为何物。

  所以只有interface没有实现,或只有实现而没有interface者是没有用的,反OO的。

  所以还是老老实实面向对象编程,面向协议编程,或者什么都不面向,老老实实编程。

  但是我很讨厌讨论这样的术语,不如我们谈谈什么叫面向领导的编程?面向用户的编程?领导和用户有时都很BT,我们就面向BT编程?

http://www.e-midas.cn/Article_Show.asp?ArticleID=107

论坛徽章:
0
43 [报告]
发表于 2007-09-29 10:50 |只看该作者
原帖由 山中无老虎 于 2007-9-29 10:35 发表

看了2006的发言后,找的一篇文章。



谢了老虎,感觉之前的理解也算是正确的

涉及到软件生产的指导思想和操作方法的问题了

论坛徽章:
0
44 [报告]
发表于 2007-09-29 10:57 |只看该作者
[quote]原帖由 山中无老虎 于 2007-9-29 10:22 发表


错了,软件工程的分工做法恰恰有利于挽留对公司有重要作用的人员,因为这样分工,他们可以专注于全局,而不必事事亲历亲为。

你想啊,在一个公司中,是人人都是轴承好呢,还是只有那么几个轴承好呢?要是人人都是轴承,你要花费力气去挽留任何一个人啊,要不,只要有一个人离开了,他负责的项目就完蛋了,因为从头到尾,只有他自己知道,文档也没留下。而只有几个轴承呢,公司要做的是集中精力去挽留这么几个人而已。

为了减少轴承掉了后的影响,目标就是要让轴承的工作有可替代性,坏了可以马上换一个,插上直接就可以用。这就要强调标准、规范、流程。甚至让总经理、董事长之类的离开了,他所定下的远程目标依然能够运转。当然,人的因素之所以最重要,也在于人的脑力劳动是不可复制的。所以,对于这个目标,也只能是减量去靠近。

当然理论永远是理论,而且理论的作用更多的是告诉人们要去做什么,而无法告诉人们怎么去做。怎么去做要跟实际结合,找到符合自己实际情况的有效办法。

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

论坛徽章:
0
45 [报告]
发表于 2007-09-29 11:13 |只看该作者
原帖由 aha111 于 2007-9-29 10:57 发表
错了,软件工程的分工做法恰恰有利于挽留对公司有重要作用的人员,因为这样分工,他们可以专注于全局,而不必事事亲历亲为。

你想啊,在一个公司中,是人人都是轴承好呢,还是只有那么几个轴承好呢?要是人人都是轴承,你要花费力气去挽留任何一个人啊,要不,只要有一个人离开了,他负责的项目就完蛋了,因为从头到尾,只有他自己知道,文档也没留下。而只有几个轴承呢,公司要做的是集中精力去挽留这么几个人而已。

为了减少轴承掉了后的影响,目标就是要让轴承的工作有可替代性,坏了可以马上换一个,插上直接就可以用。这就要强调标准、规范、流程。甚至让总经理、董事长之类的离开了,他所定下的远程目标依然能够运转。当然,人的因素之所以最重要,也在于人的脑力劳动是不可复制的。所以,对于这个目标,也只能是减量去靠近。

当然理论永远是理论,而且理论的作用更多的是告诉人们要去做什么,而无法告诉人们怎么去做。怎么去做要跟实际结合,找到符合自己实际情况的有效办法。

师姐原来也是高人啊!

不过和老虎说的不矛盾,在一个项目里都有那么一个或多个关键轴承,比如项目经理。

这便于项目的执行管理,减少了项目失败的风险。也就为企业的管理设定了指导思想。

而对于个人,首要任务还是加强自身修为

论坛徽章:
2
综合交流区版块每日发帖之星
日期:2015-08-06 06:20:00每日论坛发贴之星
日期:2015-08-06 06:20:00
46 [报告]
发表于 2007-09-29 11:24 |只看该作者
我跟你的理解正好相反。
我的理解是:所有人都参与,但有分工。而不是软件工程先分工,然后各干各的(当然也要沟通),这样关键人只是公司指定的,而并不一定真的是关键人物,因为大家都对全局有一定的了解,每一个人都有可能是轴承,这样我就不用为了挽留某一个人而费心,也就是平时所说的:没了谁地球都一样转。而软件工程,我觉得他忽略的正是人的重要性,特别是关键人的重要性,把关键人变成不一定是关键人是关键。
替代性我一直是这么做的,我不喜欢让别人威胁我,所以在项目中虽然有一个绝对的核心,但他也一定有备份存在,而且不止一个,因为大家都了解这些东西,只不过了解程度不同,做备份的档次也不同。
至于文档方面,是必须通过公司的制度来执行的,但软件技术文档不同于管理制度文档,因为即使有文档,你所能了解的也只是文档的内容,但实际开发中情况千变万化,如果有一个也对项目有一定的了解的人来接手这部分工作,会比一个外来人强的多。
我主要是强调人的重要性,在软件工程方面,任何的制度、方法只能起到辅助的作用,永远代替不了人(前提是公司资源有限的情况)。

论坛徽章:
2
综合交流区版块每日发帖之星
日期:2015-08-06 06:20:00每日论坛发贴之星
日期:2015-08-06 06:20:00
47 [报告]
发表于 2007-09-29 11:26 |只看该作者
原帖由 knighter 于 2007-9-29 11:13 发表

师姐原来也是高人啊!

不过和老虎说的不矛盾,在一个项目里都有那么一个或多个关键轴承,比如项目经理。

这便于项目的执行管理,减少了项目失败的风险。也就为企业的管理设定了指导思想。

而对于个人 ...

你师姐是个高人,受益菲浅啊。

论坛徽章:
0
48 [报告]
发表于 2007-09-29 11:26 |只看该作者
原帖由 knighter 于 2007-9-29 11:13 发表

师姐原来也是高人啊!

不过和老虎说的不矛盾,在一个项目里都有那么一个或多个关键轴承,比如项目经理。

这便于项目的执行管理,减少了项目失败的风险。也就为企业的管理设定了指导思想。

而对于个人 ...

我不是高人

论坛徽章:
2
综合交流区版块每日发帖之星
日期:2015-08-06 06:20:00每日论坛发贴之星
日期:2015-08-06 06:20:00
49 [报告]
发表于 2007-09-29 11:28 |只看该作者
原帖由 aha111 于 2007-9-29 11:26 发表

我不是高人

软件工程方面的书看的不是很多,到目前为止系统看过的就两本:人月和人件。我是一个纯粹的实践派

论坛徽章:
0
50 [报告]
发表于 2007-09-29 11:44 |只看该作者
原帖由 山中无老虎 于 2007-9-29 11:24 发表
我跟你的理解正好相反。
我的理解是:所有人都参与,但有分工。而不是软件工程先分工,然后各干各的(当然也要沟通),这样关键人只是公司指定的,而并不一定真的是关键人物,因为大家都对全局有一定的了解,每 ...


没错,大致是这样。这也是这篇文章有提的,也是我前面所说的这篇文章唯一的意义,但却不能因此就全盘否定软件工程中的分工啊

我觉得软件工程只是一个系统的方法论,给你一个大体的导向,并不是要你就一定要完全照搬啊。比如,它有说要有系统分析员,系统架构师,程序员。在一个小项目,这个分工也是有意义,在这里,系统分析员、架构师、程序员完全可以是一个人,但如果这个人具有软件工程的理论,他应该明白,他承担了这三个方面的工作,每个方面的工作和步骤,他自己可以有一个清楚的认识和理解,而不是说,他想怎么就怎么样,只要最后能出得来可交付的成果就可以了。

至于分工嘛,我还是比较赞同先分工,也赞同参与项目的人都要对项目从头到尾有个认识,先分工,可以提高效率,也可以提高每个人对自己的工作的关注度,在一起了解项目的过程度,每个人会侧重自己更应该关注的方面。
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP