OSChina 第 29 期高手问答 —— 软件工程实践

红薯 发布于 2012/11/10 23:42
阅读 9K+
收藏 25

解读下一代网络:算力网络正从理想照进现实!>>>

OSCHINA 本期高手问答我们请来了周爱民为大家解答关于软件工程实践方面的问题。

周爱民(Aimingoo),有十余年的软件开发、项目管理、团队建设的经验。曾任多家软件公司高级程序设计师、项目经理、部门经理、区域总经理等职,前支付宝(中国)公司业务架构师,前盛大网络平台架构师。目前主要从事软件工程、体系架构和语言基础方面的研究与实践。

为了鼓励大家踊跃提问,我们准备了三本由 @博文视点 出版的《大道至简:软件工程实践者的思想(典藏版)》作为奖品,在问答结束后由周爱民从提问者中随意抽取赠与此书。

OSChina 高手问答一贯的风格,不欢迎任何与主题无关的讨论和喷子。

下面欢迎大家就软件工程实践方面的问题向 @aimingoo 提问,请直接回帖提问。

加载中
2
aimingoo
aimingoo

@桂文佳 @刘鑫华 @范庆辉 几位都提到了架构的问题,但架构话题并没有在《大道至简》这本书里讨论过,而在另一本《大道至易——实践者的思想》才有所讨论。不过这里我还是乐于解释一下一些基本的问题,或谈谈我的一些基本的观点。

仅以架构而言,要讨论的问题总的来说就两个方面,一是“范围”,就是项目与项目目标要做多大、多久,做到怎样效果的问题,并且围绕这个“范围”来给出一些合理的方案给开发实施的团队。二是“联接件”,就是如果上述的范围要由多个阶段或多个构件来构成,那么这些范围或构件之间如何关联的,以及如何确保这些关联是长期有效的。

为了简单的说清这个架构的概念,以一个插件的架构来说,就是确定“插件用于补充主体软件的某个功能”,并确定“插件与主体软件之间如何衔接通讯”。那么有了这两点,插件的架构,也就设计完了。把这个模式扩大到一个平台,或一个大型的系统,或者细化到它们的各个局部中去,就是“平台架构”或“系统架构”了。当然,这仅在简单地、形式化地在讨论“架构”这个东西,因为“架构”与规模问题尽管有关系,但并非是一一对应的。不能说“大系统就要架构,小东西就不需要”,这样的认识是不正确的。

架构在根底上来说,是一种系统化的视角。如果你将一个对象理解为“系统”,或“有系统性的”,那么它就必然存在内部的关系与外部的边界——否则,必是离散的,或混沌不清的。而架构的“范围”与“联接件”,谈的就是这个对象的内部关系与外部边界。如果你具有架构思维,那么在你的视角下,凡事、凡物、凡内外,无不如此。

而架构师,要么离散上述关系、肢解上述结构,要么通过明确的方式来固化上述的关系与结构。如是,是做架构。

1
极品渣子
极品渣子
@aimingoo :非常喜欢这几个字“大道至简”,这就是人和动物的区别。
1
aimingoo
aimingoo

@灰灰 @unnamed @rainkin @bloy @MrMign @秦殇 @mjrao @mickelfeng 几位提到的问题都是在软件工程如何学、如何用以及如何实践的问题。请原谅我无法用太短小的问题来回复这几个相互间有关联的话题。要阐述这些,得花点工夫,所以便一并回复了

首先,软件工程是学不得的。是所谓“学之不得”,通过死学,是得不到什么有价值的东西的。我们必须自己提一些问题,然后来求解,通过这个求解的过程,来学习与领会它。我想第一个要问的问题,就是“什么是工程”。我们学工科、理科、文科之类,为什么要这么分呢?工程为什么是“工科”的一部分呢?更有趣的问题是,为什么没有所谓的“文学工程”呢?

工程就本意,指向的就是“产出一个东西”。工科,也偏向于“实做一个东西”。你不能去找理论数学或理论物理的人,去做一个实际的产出来。工科,以及这里谈的工程,就是要“做出一个东西”。而软件工程,无非就是要讨论“做一个软件”这件事的做法,而已。

但是我们要看到,“做一件事”,要确定做法,所以说要谈到“软件的开发”,于是有了写软件的代码工人,写软件的技术与方法等等。但这个问题不是软件工程本身讨论的,它被归在了“工具”这个范畴内。同样,“做一件事”,还涉及到“人”,但也不归在软件工程本身讨论,而归在了管理中。等等类似这些的东西,都因为有各自的学科,而被划分出去了,“软件工程”这门功课的本身,就只剩下了一个“纯学术”的东西,它只讨论“软件该怎么做”的问题,而放弃了具体做法中的具体的人、具体的技术和具体的研发对象。这个“软件怎么做”的问题,被学“工科”的思想用了一个简单的模型来讲,就是:软件工程=(做一个面向软件开发的工程的)过程+方法+工具。

但是有趣的事情是,凡工科,凡“做一个东西”,要把这个事情工程化,好象它的结论都会“用一个过程,找一些方法,拿一些工具,来做”。所以,将软件工程化,与将任何事情工程化,并没有本质的区别。从工业革命开始到现在,前辈们都是这样做的。纯理论的来说,做的模式都是如此。换而言之,上面那个公式/模型,也可以简而言之为“软件工程=用工程化的方法,来做软件”。

你再看那本叫《软件工程》的书,写的就是没用嘛。因为这纯粹不需要讲,懂了“将一件事工程化,都不过是如上的方法”,那么整本书也就成了个备查手册——查查别人都用了什么过程、方法与工具,以及有什么效果。

学“软件工程”,学得懂了上面的这点东西,就够了。在工科来说,剩下的就是“练习”了。如同操刀杀牛,同一个过程,练3、5遍不行,练3~50遍总是行的。学“软件工程”也不过如此,一套过程、方法与工具用熟了,不过是把工夫做足了,做纯熟了而已。

而对于一个具体的工程(例如一个具体的项目)来说,上面的东西几乎完全无用。为什么呢?因为我们前面说过,《软件工程》这样的一门学科把“什么东西”、“什么人”、“做的技术”这些东西清理了出去,变成了一门纯粹的“工学”。而事实上,一个具体的工程项目,却正好是包含在这些东西、人、技术上面的。所以做具体工程的,碰到人的问题,就要谈管理,而“我学了软件工程”并不表明我会管理;碰到东西的问题,就要谈产品,而“我学了软件工程”并不表明我会产品设计;等等如此。我们的一个具体的工程,并不一定具有一个“面面俱到”的团队,所以实作工程的时候,总是这方面不足哪方面不够,碰到的问题总不在书里。

但,你再看看,你面临的这件事、这个项目,这个具体的工程,就解决问题的法子来说,也不过是“找到一个过程,用一些方法,拿一些工具”来做,而已。所以,真懂软件工程的人,知道这个原理——这个在《软件工程》这本书中讲的核心原理,就够了。其它的,神见杀神,佛见杀佛,自个去做便是了。哪有在一个具体的工程里谈什么RUP的,谈XP的?就好象说,你明明已经在千军万马里了,还从太极的起手式耍起!开玩笑嘛!见一个砍翻一个,砍错了该Y的倒霉,就是如此嘛。

套路有没有呢?原则有没有呢?还是有的,《大道至简》里说过,千军万马里面用剑,不要去砍,剑身是用来挡的,剑尖是用来刺的,刺死砍伤,用最有效的法子,就好。这就是些基本原则了。到一个具体的工程里了,对A员工到软声细语,对B员工要敲敲打打,对C员工的测试一定要复测……等等这些,你在工程中去总结就好。因人、因事、因环境、因目标对象一一应对,然后你就成功了,就牛人了,就项目精英了,就50多岁了。

练就。不练,怎么有成就呢?《软件工程》只讲一个核心原理,真到做了,还是一个项目、一群人、一个产品目标。三个方面的东西,一个不可少地去照顾到了,去找到他们的方法、过程与工具了,去磨过去拼过,才有结果的。

我从来不相信学完《软件工程》就去做工程的那个人。

灰灰
灰灰
那么,软件工程是用在哪一个阶段?开发的筹划与计划?工程后的实施?还是结束后的报告?而软件工程存在的意义是什么?
0
侯文斌
侯文斌
@aimingoo :刚才手机上发到动弹了,转过来---------- 想问下,针对当前的互联网发展趋势如何分析,下一个互联网,软件爆发点在哪?作为一个软件公司,如何定位自己的个性目标?而不是价格战!
aimingoo
aimingoo
我个人看好电子商务。但个性项目这件事,就不好说了。如果你要创业,那么我认为“做有兴趣的事”,比“有钱途的事”可能更要紧。但真到创业团队变成一个公司的时候,上面这个判断却要颠倒过来,如果你能不及时地把“钱途”当成自己的兴趣,那么我建议:换CEO吧。
0
memorybox
memorybox

@aimingoo :周老师您好,我原来是从事嵌入式开发工作的,现在转到web开发上来,做测试工作比较多。以前的测试工作都是完成一个release后有一个完整的测试,另外测试文档、操作步骤、记录都比较详细。但web开发的迭代非常快,另外UI、JS这方面的测试量很大。这种办法显然不适用了,目前状况是每个功能点单元测试完成后回归测试,一个版本发布前再统一做简单的用例测试。

但因为没有以前那样覆盖完整的测试过程,总觉得有点不放心。我想咨询您,在迭代非常快的项目中,测试如何保证?


谢谢。

memorybox
memorybox
回复 @Xun Jia : 我们现在也是查不多这么做的,就是不知道大型的web开发是怎样做测试的。
memorybox
memorybox
回复 @抢小孩糖吃 : 谢谢回答。我们也用了Selenium做一些自动化的测试工作,但功能迭代太快,有时候一个测试用例几次之后就不能用了,自动化能承担的东西还太少。
抢小孩糖吃
抢小孩糖吃
请使用自动化测试工具 测试工作大部分都不需要人力进行手工测试了,只需要对测试用例进行设计,并检查测试结果
贾珣
贾珣
我是做开发的,以前我们的测试人员做法很简单。就是一个Bug Free,每一个版本发布后,先回归测试,再增量测试。可能对楼主有点儿帮助。不过第一个版本的用例要根据需求来撰写。
0
灰灰
灰灰
@aimingoo :听在校的老师说软件工程,总是说到非常理论,一直都没有真正去思考过,软件工程的重要性。到了实际的开发设计时,就发现思维不行了,这种情况是不是没有软件工程的基础?
aimingoo
aimingoo
回复 @灰灰 : 当然是啊。设计不是工程模型中的一个阶段吗?所以“有设计”并不是“开始工程”的一个前提,而是“工程过程”中的一个阶段所得。当然,有些具体的工程中,比如说某个公司的某个项目,却是要“你们先设计,再拿给客户确认,再开始这个工程(项目)”。而这,只是概念上的混用而已。此工程,非“软件工程”这个学术概念中的工程。
灰灰
灰灰
回复 @aimingoo : 要有好的设计方案才开始动手,而这个设计方案是不是就跟软件工程有关?
aimingoo
aimingoo
莫将做工当工程,三千差伇如一人。若问工程如何做,《梓人传》中见说分明。:)
0
庆辉
庆辉
软件工程的名字很大,包含的内容很多,想问一下周老师在实际项目里,制定项目平台架构的时候除了业务部分都要考虑哪些部分?或者说,您在一个项目里做架构师,都需要考虑哪些东西?
庆辉
庆辉
回复 @aimingoo : 谢谢,这就去拜读一下。
aimingoo
aimingoo
你把两个问题混在一起了。做架构并不是“做软件工程”的一部分。对于架构这个话题,我在另一个评论里谈了些:http://www.oschina.net/question/12_78459?p=2#AnchorAnswer346201 更多的内容,若你有兴趣,可以读读《大道至易——实践者的思想》。:)
0
unnamed
unnamed
@aimingoo :在学校非常的系统的学了软件工程相关的课程,感觉就是理论而死板,请问在具体的工作中是如何对软件工程进行实践的呢
0
rainkin
rainkin
@aimingoo :老师,你好!我在校学习的是《软件工程--实践者的研究方法》,书中讲的非常的详细,如何沟通,策划,需求建模,设计建模,测试,部署等等,还有加上作者本身的实践经验,提醒我们在从事软件工程时要注意什么。但是,理论的东西即使再牛,缺乏实践,还是不能真正的了解它。我想问的就是,你们在实际的开发过程中,是如何规划,实践?要做哪些工作?你们更加注重开发过程的哪一方面?谢谢
aimingoo
aimingoo
顺便说,是否“缺乏”不是以人头数或工作量来论的。也可能建模、部署等等好些工作一个人就应付得来,也可能测试要3、50号人手。“足与不足”也是在具体的一个项目中、团队中去衡量的。
aimingoo
aimingoo
缺哪方面 ,补哪方面。看到一个团队/项目过程中缺了什么,补上即是。不能离开一个具体工程,来谈“更加注重什么”这样的问题。
0
bloy
bloy
@aimingoo :有没有完整的简单实例给大家来一份啊
aimingoo
aimingoo
请写一个记事本软件。条件是:用十个人开发,其中三个人决定记事本软件的产品特征项、版本规划。
返回顶部
顶部