我的草稿纸
===========================================================
设计杂谈二——变化的设计思想(1)
===========================================================

应该说我接触设计方面的东西很晚,所以很多旧的概念方法,仅仅限于书面知识,比如structural programming中的jackson方法,仅仅是课堂上学过而已,工作的时候已经完全忘了。正式收到设计方面的训练,是在98年接受Rational Rose的培训。Rose是我所接触的第一个设计工具,而RUP则是我接触的第一种正规的开发模式。所以我开始的时候接受的完全是正规的OOAD方法:建立用例;通过用例分析以及需求分析建立高层数据模型;动态分析;模型细化。。。等等等等。应该说我对于这种方法是全盘接受的。但是,在实际工作中,基本用不上:

很简单的一个例子:在实际工作中,包括项目经理在内,几乎没有权力决定一个软件什么时候完成。做出这个决定的,基本上都是市场的人员。而开发的人力,则基本是固定的,尤其是软件功能加强的时候,招聘新的开发人员基本上没用。至于软件的功能,对不起,也是市场部的说了算的。这样一来,一个软件开发中的三个因素:时间,人力,以及功能,都已经确定了。至于这三个点是不是能放进一个三角形,呵呵,这就是软件开发人员的工作了。于是乎可怜的开发人员首先想到的,根本不是什么需求分析或者是按部就班的设计。因为我们根本没有奢侈的权利。我们唯一能做的,就是把各种功能尽量简化,哪怕一些明知可以让软件在长期受益的东西,也一定要放弃,否则根本没办法按时完成。

而且客户的需求是无时无刻不在变化的。要你更改需求,你也没办法,毕竟是人家付钱。但是如果需求更改,往往来不及这么一步一步地做下去。

2000年,我第一次接触了我的偶像Martin Fowler(其实在98年就已经拜读过他的UML Distilled一书,不过真正的敬佩是从2000年开始的)。那时看到的,是他的一片关于continuous integration的文章(有兴趣的人可以去Martin Fowler的网站:www.martinfowler.com 看看他的文章,至少我觉得是字字珠玑)。当时刚刚接管一个大型项目,这个项目已经滞后了,而且内部的东西作的一塌糊涂,到处是bug。更有甚者,程序员为了赶工,把空白的方法当作完成的代码交给测试人员,等测试出来了再当成bug修改。如果这东西一个月测试不到,就一个月不用管了。老实说,遇到这种情况,我几乎抓狂,也想过离开(当时有其他的原因,倒不完全是因为这个项目作的太烂)。但是看了Martin Fowler的这篇文章之后,我马上有了茅塞顿开的感觉,马上把ant和我们当时自己开发的一套测试工具整合起来,开始了我的第一个类似XP的试验(当时把XP的想法和上面的经理们商量了一下,结果大家的反应竟然是哄堂大笑)。


yining 发表于:2004.08.28 10:10 ::分类: ( 架构设计 ) ::阅读:(457次) :: 评论 (1)
===========================================================
设计杂谈一——我的程序生涯
===========================================================

刚开始接触计算机是上小学的时候父亲从国外带来的TI99/4A。用的是BASIC。当时因为痴迷游戏,所以还使劲钻研了一阵子,写了两个程序。当时的教材就是谭浩强的。后来断断续续接触过苹果2,IBM PC AT。记得念化学的时候,全系唯一一台386是放在书记办公室做人事的。后来改行念电子工程,硬件为主,软件为辅。但是最后找工作的时候阴差阳错,还是选择了软件,一直到今天。

开始编程的时候浑浑噩噩,学了两个技巧就沾沾自喜,自以为是。正经开始工作的时候以为自己一定是大拿了。后来才发现,软件开发决不仅仅是几个技巧的堆积,称其为软件工程,是非常准确的。不过当时的学习过程中还是有所收获:当时互联网不发达(94年开始上网,但是基本查不到什么资料,yahoo好像是95年开始的?基本上和我的个人网站同时起步,不过人家的商业头脑确实发达),所以网上查不到资料,中文的书质量很差,英文的我一般买不起。而图书馆的书内容又比较老旧,所以只能拼命阅读用户手册,养成了独立寻找问题,解决问题的习惯(当时我们系里大多数人都是在SunOS上面做,好像我是不多的几个用Windows编程的)。

开始工作,我是一个懒人,平时很少看书。工作中常常碰到一些问题,而解决的方案往往大同小异。久而久之,这些方案成了定势。当时还不知道这就是设计模式,尽管这本经典著作早已经问世了。一直到后来,在一个面试的时候,因为人家看到我的简历上比较多设计工作,所以简单询问了一下对于设计模式是否熟悉(因为当时那里的要求是尽量使用设计模式)。被录取之后,临时抱佛脚买了两本设计模式的书。直到这时,我才算是碰到了设计的大门。不过,等进了门之后,发现眼前的一切相当的熟悉:大多数都是平时工作中用到过的,而且我的解决方法和这些设计模式往往不谋而合;在这之前,曾经和一些俄罗斯程序员讨论设计的方法,他们也不知道什么设计模式,只能描述怎样解决具体一个问题,比如singleton,就是我在这样的讨论中学会的。

接触的模式多了,自己也对这方面兴趣越来越大,经常找一些这方面的书来看。总是觉得如果是在工作中遇到过的模式,理解起来非常快。但是如果从来没有接触过的,理解起来往往多花很多时间。


yining 发表于:2004.08.24 13:40 ::分类: ( 架构设计 ) ::阅读:(483次) :: 评论 (0)
===========================================================
新技术的后行者
===========================================================

对于新技术,我总是不感冒的。原因很多:我本来就是一个守旧且懒惰的人;新技术日新月异,在它们出现的时候,我往往还在消化旧的东西。这样日积月累,使得自己在追逐新技术的道路上越来越落后。

后行就后行吧,也许有一天我们重新回到没有计算机的日子,那时候,我会比别人更适应些。


yining 发表于:2004.08.21 14:24 ::分类: ( 随笔 ) ::阅读:(635次) :: 评论 (7)
切换风格
新闻聚合
博客日历
文章归档...
最新发表...
博客统计...
网站链接...