开发漫谈

957人阅读 评论(0) 收藏 举报
学生时代是紧张的,学生时代是稚嫩的,学生时代是快乐的,学生时代是自由的……
曾经在那样一个想象飞翔的年代对程序员有着诸多憧憬,诸多幻想;曾经对自己灵感的实现那么的自豪和满足;曾经单枪匹马挑灯夜战完成千行程序而认为自己就是英雄……
曾经走过那么多曾经,蓦然回首进入公司这段时间的工作生活,回首在开发道路上走过的沟沟坎坎,猛地发现时代的变迁,历史的演进。Bill Gates那样一两个人完成系统的英雄时代已经成为曾经的曾经,离我们而去了。开发之路需要重新审视。
也许大家都读过《大教堂与集市》这篇文章,讲的是关于封闭的开发和开放的开发的事情,也就是微软的windows开发和linux的开发。虽然从网络精神之一的共享精神,从开源软件的代表――linux来看,很多朋友显然是支持linux,也就是支持开放的开发(“集市”)方式;但是,随着对软件产品或工程的各个方面要求的提高,随着我们对CMM体系的认识逐渐深入,对印度软件业成功道路的逐渐了解。我们不得不放弃后者,我们需要更可控的产品过程和质量,需要可预见的工作进程。这样才能用更小的代价换取更大的价值。所以,真正意义上程序员的定义是不同的,我们应该洗洗脑了:-)
既然提到软件工程,我觉得很多相关论著确实是很好的参考手册,一些基本的理论在其中都有着详细的、明确的解释,但它们多半比较理论化、理想化、学术化,这里没有必要罗列一条条规范去理解软件工程的意义所在,那样往往会花费太多时间与精力去顾忌规范却迷失掉一些最基本、最自然的东西。编程其实没什么大不了的,灵感、热情加上一点耐性是可以搞定你手上的东西的,当然随着软件复杂度的增加必须引入一些科学的手段对过程进行控制,但是问题的关键不是这些“本本框框”,而是要明确哪些手段适于你要开发的软件。比如在八十年代以前软件复杂度还很低,完全可以不要什么控制,一两个人两三天就可以搞定的东西如果有问题完全可以重来。也犯不着为了那么点东西写上几百页的文档。但是如今的软件复杂度已经达到任何天才也不可能一气呵成的完成源代码实现的地步,一旦软件到后期出现问题,很难重新来过了,甚至连测试代码也很难插进去。修正要花上数倍的代价!由此可见,取舍之间效率永远是根本所在。
让我们一起回想一下软件工程核心的由来,不难发现它是与教条的书本完全不同的两码事,而很多人却深陷其中,越发迷茫。软件工程专著追求的是科学性、严密性、完备性。而软件公司关心的是效率、时间、费用、质量。怎样去高效高质量的完成软件开发任务,怎样规范的组织这些任务的开展来保证开发过程的顺利进行并有选择的提高最终软件产品的质量才是最根本的。CMM中不同级别有不同的KPA(Key Process Area)要求也有这个道理。
那么作为程序员,我们完全可以从构思谈起。当还是学生时代的时候,有时会灵感突现,很难控制自己把灵感实现为程序的冲动。也许你会认为要趁热打铁,可是答案却不同。这时要做的应该是进一步的仔细考虑,在没有对灵感进行足够的酝酿、综合、分析之前要尽量避免过早的去实现它。过早的实现不仅意味着过早把灵感禁锢起来,扼杀在摇篮中,也意味着很可能因为对多方面因素的不成熟考虑,导致最终实现浪费大量的时间与精力。软件开发的一个重要规律就是越到开发后期,对基本构思的改动会越难实现。因为这个时候你的思想已经融入软件的每一个“毛孔”,剥离它无异于扒层皮,后果可想而知,将如同严重烧伤一样造成大面积感染进而危及生命。当然,凡事有度,也不能老在那里构思个不停,不然你会总是原地踏步,无任何进展。另外,也要注意,构思并不是考虑实现细节,考虑实现可能性以及各种想法之间是否存在矛盾只会约束你的创意,具体分析是后面的事情。当你的构思逐渐明晰、成熟之后……不要慌!还不是进一步的时候!应该把构思写成草案review一下。既方便下一步的工作又可以在梳理思绪的时候找出缺陷。说到这里P-D-C-A(plan-do-check-action)的那个circle大家一定还记得把。软件质量也就是在这样周而复始的循环中阶梯式的上升,开发的效率也随之得到了保证。
到这儿也许有人会问:“有必要为个构思花那么大力气吗?”。对此,我要讲的是二八原则。不知你注意到没有,在创造软件的过程中,最初的两成工作八成决定着最终的成败;而剩下的二成成败则要付出八成的工作来保证。怎么来解释这句话呢?以画广告画为例,如果有了创意,搞出一个基本草图花的时间和工作量非常小,然后,要调整大小比例、着颜色、出效果等等的工作才耗费了大部分的时间和精力,但是改进却不是革命性的,而是细节性的,一旦基本架构出来了,整体效果大体也就有了。同样的在软件开发中,算算那个比例,如果前面两成的工作出了问题将意味着什么。所以应该充分利用好最初那20%的工作努力!放之整个开发生命周期大家应该明白,需求分析、架构设计是多么重要的事情了把。当你有了真正做好了前期工作,实现起来应该是一件惬意的事情。所以也就出现了那么多新兴的方法让我们以新的方式去从事开发工作。模型驱动架构、测试驱动开发等等,都是把前期工作做好的催化剂。
再回到二八原则,我们也不难发现实际上它应验着我们早已熟知的许多道理,而也许恰恰是因为熟知,我们忽略了他们。决定八成成败的那两成工作就是软件开发的主要矛盾――“射人先射马,擒贼先擒王”;而那决定两成成败的80%的工作却照样要兢兢业业的做好,不然软件产品仍然是有缺陷的、不完美的――“行百里路,而半于九十”;我们需要预先的构思,需要提前估算,需要风险预测来做好那重要的20%的工作――“预则立,不预则废”……可是,为什么我们忽略了这些最重要的自然的东西呢?“太熟悉他们以至忽略”显然不可以圆满的回答这个问题。答案就是曾经对自己灵感的实现那么的自豪和满足;曾经单枪匹马挑灯夜战完成千行程序而认为自己就是英雄,就是太沉迷于开发中间,以至身在此山中,云深不知处了。
解决之道并不难――登高望远。站的高一点,跳出原来的小圈子,找出最好的路。这路不一定是二八原则,也许是三七原则,也许根本就不需要什么原则,只要你站的足够高,看的足够远,找的足够准。所以-design in a high level!路就在眼前!
当然真正的软件开发绝对不仅仅是这些,关于软件开发几本论著都说不完其中道理,从软件危机催生了软件工程到如今ISO、CMM大行其道,这么多年,软件的成功率仍然没有达到令人满意的程度。这其中各个方面的原因都制约着软件的成败。也从一个侧面说明了软件复杂度几何量级的猛增使得我们不可能重温英雄时代的旧梦,各种技术的突飞猛进也让我们告别了冷兵器时代。我们应该重新审视自己的认识,重新武装我们的大脑了。
 
注:这里谈的主要是对狭义上开发的一些随感,主要是从程序员的角度看世界,update一个入门者对程序员、对开发的理解。
0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:188961次
    • 积分:2877
    • 等级:
    • 排名:第12354名
    • 原创:75篇
    • 转载:22篇
    • 译文:1篇
    • 评论:124条
    最新评论