CSDN博客

img TopWolf

我的关于软件工程的一些观点ZT

发表于2003/5/19 21:31:00  705人阅读

目前国内的软件方面的人才开始大量的关注软件工程这门学科,大有80年代末90年代初国人追捧汉字系统的劲头,但是实事求是的理解国内的开发过程,我认为软件工程固然是一个方面(甚至可能是非常重要的一面),但隐藏在表象后的问题也是不容忽视的,我认为目前开发环节中存在着一些问题或理解的偏差,其中典型的表现在:

1、 学而优则士

这个问题很普遍,很多人都是这样想:开发到35岁以后就应该考虑管理的问题了。这个想法是“学而优则士”的想法,好的开发人员,不一定是好的管理人员,因为侧重的面不一样,知识结构也不一样。但是,由于很传统的思想,认为领导就是应该各方面都好些,所以强把“学”推为“士”。这样不但没有更好的提高效率,反而浪费了很好的人才。同时,也是由于传统的思想,“士”更受人尊敬,而“学”往往被认为是蓝领,所以很多的“学而优”者也就有成为“士”的激励诱因了。我认为,这是一个不正常的现象。“学而优”的地位及受人尊敬应该有相应的评判机制,比如说:系统设计师应该比项目经理更加受人尊敬。也只有这样,“学”者才可以安心设计,“士”者也可以更好发挥“士”的职能。

2、过程与阶段

只有过程没有阶段是没有意义的,我们都知道,任何一个软件产品的开发是需要很长时间的开发过程的,这个过程也是充满风险的,如果没有有效的把过程细化,只是简单的严格的按照需求、设计、开发、编码、测试的流程去做,问题也就蕴含其中了。必须明确的是没有绝对成功的软件工程,也没有满足一切情况下的绝对的开发过程,将过程阶段化只是将风险降低,将蛋糕切细,一次吃不了多次吃。这个在软件工程中的相应的解决方法是里程碑。在绝大多数的开发过程中,里程碑的作用是非常重要的。在有些开发过程中讲究的是渐进式的开发,螺旋式的过程,其实也是对里程碑的一种扩展而已,只不过这些开发过程的里程碑是定义在自己的开发过程中而已。
好的开发过程应该是在风险管理上的尽量灵活,我不赞成将里程碑式的阶段管理放入到开发过程中的明细规定中,而是应该在不同的产品或项目开发上灵活掌握。有时一个里程碑可能只是在需求分析阶段的初期,但是如果符合实际的开发的需要,我认为就是好的开发方法。用这种观点观察RUP,我认为RUP中关于里程碑的定义有些刻板,RUP基本上是一个演化式的开发方法,演化的层次很清楚,但是,对于实际的开发中的里程碑定义的灵活性表现的不够充分。当然,任何开发方法不可能满足所有要求,在相对固定的需求的项目上,RUP还是有很大的长处的。在这一点上,我比较偏向于MSF的开发方法。

3、软件工程的左与右

以前学马列的时候学了一个概念,就是左倾与右倾,好像是这样定义的:左倾是指的把将来的事现在做,右倾指的事把过去的事现在做。这两种都是不好的。实事求是的讲,我认为现在的推崇RUP、CMM等有些左倾的味道。从管理的角度来讲,管理有三个阶段:能人管理、制度管理、标准管理。我认为RUP、CMM等属于标准管理的范畴。现阶段很多的公司的能人管理还没有做好,就急于开展标准管理不是正确的方向。首先将能人管理方式进化到制度管理才是当务之急。所谓制度管理就是建立符合公司实际的规章制度,做到人尽其才,在一个游戏规则下做事,这样就可以很大的提高工作效率,更好的沟通开发中的方方面面问题。也只有这样,才能更加深刻的理解标准管理的重要。越过这个阶段,直接跳向更高层次,就象在现阶段实现共产主义的想法一样,有些不切实际。当然,少数公司的制度管理已经很好了,工作效率确实很高了,那就另当别论了。

4、缺少什么样的人才

记得一个笑话说:外国人搞软件工程是在一个黑屋子里面抓黑猫,不过到现在还是没有抓住,而中国人是在一个黑屋子里面,而里面连猫都没有,然后有人说,我已经抓到猫了。这个笑话一方面是说明直到现在,软件工程还是一个在继续探索、发展的过程,另一个侧面也说明中国搞软件工程摸不着边的局面。(以上摘自《我有一个梦》,作者:胡朝晖,详细参见ChinaByte.com)

那么中国最缺少什么样的人才呢?我认为是系统构架师。很多人会说:我们缺少软件工程人员、缺少良好的项目经理、缺少……,是的,这些人我们确实也缺,但最重要的是系统设计师。因为,无论是项目经理、精通软件工程的人员,我们都可以培养,相对的培养成本也不是很高,而系统构架师却需要多年的行业经验和高超的设计水平,这些都不可能短时间内得到。

很多人说,我们的项目大多都是低成本的包工头似的项目,但是大家是否想过,如果,真的有一个项目是让大家去完成很尖深的系统,又有几个公司可以胜任?!为什么很多的Open Source的系统可以做的很大,不是因为这些Open Source有多么的软件工程,只是由于有一些优秀的系统设计师在参与设计而已。软件工程只能使得可以做到的工作做的更好,不能解决连做都做不出来的工作。这也可以说明为什么商业软件中软件工程的重要性,其原因很简单:在大家都能做到的情况下,就要比较谁的作的更好了。

软件工程是贴在楼房上的马赛克,有了当然更好,但是如果楼房的结构不好,贴在多的马赛克也可能只是金玉其外、败絮其中。

5、对程序员的正常理解

程序员是要求有创造性的,几乎每个人都是这样想。但在实际的情况下,又有很多人开始谈论如何将程序员当作运转机器的一个齿轮!这是很不对的,是对软件工程的一个曲解!首先,程序员不是打字员,程序员之所以重要,在于他的脑袋而不是他的键盘。程序员又不是设计师,这就不要求他有宏观的观点。程序员是要求对某个方面非常的精通的,哪怕是很小的一部分。系统设计师不可能将设计做到可以编程序的地步,他需要把握的是整体。而相对的,程序员需要把握的是局部。当然,如果任何局部都做的很好,整体不一定好,反之也一样。就想一条船,设计师是舵手,他需要有宏观的能力、需要知道那有险滩、需要辟其风险,而程序员是划手,他需要做到和大家行动一致、需要使用最佳的划船姿势、需要有吃苦耐劳的精神。

不要认为程序员是机器,在他的岗位上一样可以知道船航行的轨迹,要仔细听取他们的建议,因为,有时航行的问题往往都是先被划船的人发现的。

6、讨论的也需一定的标准

有时候会有这样的问题:一帮市场人员与一帮技术人员讨论,为了要解决市场与技术的协调问题,其中市场人员说市场的问题,技术人员说技术的问题,结果往往公说公有理、婆说婆有理。所以,讨论的也需一定的标准!如何定义这个标准在不同的场合和环境下是不尽相同的。技术人员最终需要解决市场上的问题,可是解决的方法并不是简单的服从。如果那样,是不可能做出真正符合市场的产品,因为市场人员看到的只是一定阶段的市场表象,他们并不清除这里面的原因,也不清楚原因的本质。

比如说:比如说现在人们常说的3层结构,往往客户需要让你使用3层结构的思路去解决实际的问题,可是他们并不清除为什么,只是认为很多人都是这样的做的。我不是否定3层结构的优点,只是说,在很多的项目中并不一定要求使用3层结构,因为那会使复杂度增加,而灵活性的掌握又需要很多客户的支持(客户的很明确的说明业务逻辑),同时,真正发挥3层结构的好处,还需要很强的设计师的良好的设计。在很多的小项目中完全没有必要多此一举,把两层的问题3层化。

建立这个讨论的标准就要求,技术人员理解问题的缘由,清楚问题的实质。我说的意思并不是要求技术人员要有很强的市场的眼光,而是需要把这些更深层次的原因及时的说明给市场人员听。

简单的服从市场人员的意志往往是项目可控性失败的直接原因。

7、片面的理解管理学;

现在有一股势头认为,软件工程中的管理者只要拿个手册照搬执行,肯定10有8、9不会有大的问题。但是问题真是这样吗?在《软件工程—实践者的研究方法》中有这样一段关于管理者的神话:
神话:我们已经有了关于建造软件的标准和规程的书籍,难道它们不能给人们提供所有其需要知道的信息吗?
事实:不错关于标准的书籍已经存在,但真正用到了它们吗?……它们完整吗?很多情况下,对于这些问题的答案均是“不”。(P.11)
我们必须明确管理的责任、实质与优劣。优秀的管理是无为管理,管理的目标就是不管理。不管的前提是有一套符合实际的游戏规则,大家按照游戏规则做游戏。有些人理解管理就是天天跟到被管理者的后面,不定的催促、不停的调度。这是不对的,这样的管理者是妨碍了正常的工作,是对管理的曲解。
所以说,优秀管理的前提是建立一套大家都能遵守的有效的游戏规则,在此规则下,达到高效工作的目的。
那种认为管理就是找人谈话、挑人问题、催促进度的理解是错误的,如果,真的遇到了这样的问题,我认为那确实是需要重新审视一下自己定义的规则的时候了。

8、您有一个持续发展的框架吗?

明知不可为而为之的后果是怎样的呢?可能是这样的:项目进度太紧、产品问题很多、每天陷入到工期的泥潭之中……。很多人说项目太紧是市场的时间给的太紧、是项目计划不严密、是软件工程不到位等等,但是,回头想想,如果真的做到了:市场的时间给的充分、项目计划严密、软件工程符合实际,那么,您有把握完成一个符合用户实际需要的、优秀的、低维护的项目吗?我认为,还不行。
可能很多人不会反对,如果客户的要求是让我们做一些Word、PowerPoint的模板(无需编写很多的代码),我们可以很容易的满足客户的需求。但是,如果客户让我们做一些关于MIS、POS、甚或是如教育、政务等软件,我们的成功的把握度就大大降低了。为什么呢?如果,我们做其他类的软件如同做Word的模板一样容易的话,我们还会没有把握吗?我们缺什么呢?我们在做这些软件的时候为什么就有些信心不足呢?
问题的症结在于:您是否有一个持续发展的框架。您如果有一个基本满足用户需要的semi-application的话,您将不会遇到那些问题。
如果您在实际工作中屡战屡败又屡败屡战的时候,您会不会问自己这样一个问题:您有一个持续发展的框架吗?

9、对过程范型的误解;

任何过程范型都有它的优点和缺点。我们不能否定瀑布模型的优点也不能否认其缺点,我们不能否定演进模型的优点同时也不能否认其缺点,其他范型也一样。很多人推崇RUP、XP等过程范型,但是前提是我们必须知道这样的模型是演进模型,有很多的优点,同时也不可避免的有其缺点的存在。
比如说:我们需要做一个需求很明确,并且在一段时间内需求不易改变的项目的时候,如:一个数据结构类库、一个通讯底层库等,这时候,使用瀑布模型可能会得到更好的效果。为什么呢?首先,演化模型的任何一次跌代的终点就是下一次跌代的起点,这样有助于用户更好的把握系统,可以更好的理解需求,但这种模型并不适合需求非常清晰的情况,如果需求非常清晰,这种跌代只能更多的产生冗余的文档,更可能产生很多过渡的设计,而这些显然是一种浪费。有些人,干脆就把演进模型当作瀑布模型来使用,讲究的是一步到位,这种做法就更有问题了!
如果需要一步到位的系统(即需求非常明确,同时需求很少改变),演化就变成了瀑布,这时候提倡演化无非就是多走了几个弯路而已。

正确的理解过程范型是正确的使用过程范型的前提。

10、对测试工作的误解;

我们应该重视测试工作,但是,过度的重视测试又会产生严重的问题。测试工作最重要的是要发现问题,是保证提交给客户的软件中不再出现问题,从这个观点说,测试很重要,但是,我们不能因为测试而测试,很多问题不是能够通过测试而解决的。
发现问题的时候解决是对的,正如亡羊补牢,未为晚已。但是对于问题的源头我们需要更加的重视。我们更加需要重视对于需求分析的审核、对于设计的复审、对于代码的复审。将问题消灭在摇篮中,总比与问题搏斗来的容易。
对软件的测试固然重要(无论是单元测试还是系统测试),但这种只对产生了问题征兆的测试是一种狭义的测试。我们决不能忽略对需求分析的测试(需求复审)、对设计的测试(设计评测),这样的种种测试的综合,才是软件工程中对测试的广义理解。
如果,您发现在工作中测试的环节上发现了太多的问题,您就是真正应该考虑在其他环节上“测试”是否出了问题的时候了。有时候,羊亡的太多,补牢也就晚了。

测试在软件工程中是一个狭义的概念,但是我们应该努力广义的去理解。

11、对文档作用的错误理解;

文档在开发过程中是很有用的,但文档泛滥就不好了。有些人说,开发过程中文档越多越好,我认为这种观点是不对的。首先我们要明确开发过程中为什么要写文档,文档的最根本的作用是为了沟通!一个项目或产品可能需要延续很长的时间,开发过程中可能需要很多的环节,可能会遇到很多的问题和很多的解决的方法,这时,我们需要文档的帮助,我们需要有一个记录,我们需要有一个共同的声音。文档不过是一个准绳,将开发中的各个树枝树叶扶正。如果,这个准绳太多太紧,大树可能会发育的很高很直,但是就是有些畸形,如果这个准绳太少太松,大树可能就会变成灌木丛。文档的多少、繁简是有度的,绝对不能说越多越好。
那么这个度是多少最好呢?我觉得有几个标准:1、文档需要说明解决问题的方法而不是解决问题的理论;因为解决问题的理论是在文档形成中做到的。2、文档完整即可,每一份文档说明一个问题,无需将多个文档的内容放在一个文档的里面;3、除了重要阶段形成文档,其它部分都只是讨论或者说是想法(这些通过其它工具可以有效的管理起来);4、不要让文档成为累赘,如果真是这样,我认为就是该考虑写作这些文档的必要性的时候了。

我们在文档的时候,一定要明白为什么要写这些(无论是为了现在还是为了将来)。

12、仔细审视神话!

在实际的软件工程的实施过程中,我们往往会遇到很多的神话,“软件神话具有一些特征使得它具有欺骗性……软件神话仍被不少人相信着”(参见《软件工程—实践者的研究方法》P.10),如果,我们使用审视的眼光,而不是盲听盲信的话,我们就有可能发现其中更多的玄妙了。

希望和大家共同努力,仔细审视软件工程中存在的神话!
0 0

相关博文

我的热门文章

img
取 消
img