披着盛装的稻草人-- 编程中的随笔

1 不是使用了spring ,hibernate 等企业级产品的框架,我们就是企业级产品了。不是我们采用了新瓶装旧酒的web 2.0 我们就走在技术的前沿了。我门所需要的是一个高性能的,健壮的 产品,是一个可以降低我们实施成本,一个可以树立我们企业品牌的产品。在这里我不得不对我们产品的所谓的架构们产品疑问,Archetectures,what are you doing?

2 在实现框架代码的时候,当你对采用那种实现方式犹豫不决的时,换个角度,想一想如果你是程序员,喜欢怎么这些框架。在实现框架的时候一定要考虑程序员是否能够理解你写框架的思路,除非万不得已不要用一些自以为很高明很巧妙,然而却很晦涩难懂的方法,那样的框架,程序员至少合格的程序员是不愿意使用的。我想程序员和编码工人最大的区别就是程序员不仅要知其然,还要知其所以然。

3 只有在不断实践中,才能激发你不断的求知欲。只有把学到的知识不断的应用道实践中,你才能在学习中得到满足。不要为了学习而学习(学院派,不好听点就是纸上谈兵),而是要从实际问题出发,在解决问题的过程中不断深入,不断总结,所以说,当你离开了编程的第一线,你将失去学习编程知识的欲望。当然如果你愿意,在别的领域还有更广阔的天空,但是请不要总是说自己原来编程怎么怎么,其实你已经被三振出局了。

4 想外行一样思考,想专家一样实践,一本书的名字,虽然书没有看过,但她的名子就已经非常有意思了。这岂不就是我们作需求,和作架构时的座右铭吗?既能象“外行”一样的站在客户的角度思考问题,又能象“专家”一样参与到整个产品的开发和实施当中,在实践中不断提高自我。然而,不幸的是许许多多的所谓的架构师,系统分析员们却正向着相反的方向迈进。“真正”的做到了,象“专家”一样思考,象“外行”一样实践,可悲呀可悲。
5设计做到什么样才叫做到位呢。我想只有真正的开发者才有权利发言。只有有它们才是设计的真正使用者和受害者。因为就我所知和所见,绝大多数设计都是设计者自己的游戏(当然,我可能是井底之蛙了没有见过什么好的设计),程序员所开发往往还是对着原形自己再进行一遍设计,且不说额外增加了多少工作量,浪费了多少时间,就工作质量而言,也是差强人意。毕竟大多数情况下,设计者或称为架构师的在技术方面的经验都更为丰富,对业务的理解也更为深入,另外由一个人进行设计在功能复用,和整体性能方面的考虑也更完整一些。但怎么做才能熊掌和鱼兼得呢?下面我发表一下我个人的看法:
  1 代码就是最好的设计,这句话不是我说的,是 xp开发届 中的一位大牛说的。之所以在这里引用别人的观点,并不是自己是一个xp 的fans,也并不时完全赞同xp 的理论,我只是觉得这句话得太对了,对程序员来说什么设计比代码读起来更亲切呢?。其实设计无非是向开发所着传达设计者的思想,告诉开发者系统需要开什么个对象,具有什么属性和行为,它们之间的调用关系又如何。我们在设计文档中经常使用的方法就是有class 图,协作图,和顺序图对上面所提到的进行描述。然而结果呢,面对这大量的令人畏惧的抽象图表,开发者可选择的也只有是“重整江河待后生了”。想想,这样的设计和代码能够同步吗,这样的设计文档还有什么用呢?所以说与其是这样还不如把设计变成代码,如对象属性可以这直接在代码中体现,方法可以只定义接口,实现方式可以作为代码的注释,向写需求分析用例似的来一步一步说明程序是需要怎样调用。当客户要求设文档的时候,只需要提出javadoc就可以了,而其保证和代码同步。而开发者呢,在开发前需要阅读用例,了解需求,然后在设计者已经搭好的代码框架中进行开发就可以了。如果需要修改的话,不用在去设计文档中更改,只需要修改一下代码注释就可以了,(程序员是比较懒的,不怎么愿意写写文档的)。当然了,让懒惰的程序员能够自觉地写好文档也不是一件容易事,下面也许能给你提供一个好的方法
  2 交差开发能够帮助完成最好的设计文档。
  3 设计者在开发阶段还作什么呢?                 
待续                                                               

posted on 2006-10-11 14:36 康文 阅读(233) 评论(0)  编辑  收藏 所属分类: 软件工程


只有注册用户登录后才能发表评论。


网站导航:
 
<2006年10月>
24252627282930
1234567
891011121314
15161718192021
22232425262728
2930311234

导航

统计

常用链接

留言簿(1)

随笔分类

随笔档案

文章档案

搜索

最新评论

阅读排行榜

评论排行榜