`
1000copy
  • 浏览: 72504 次
  • 性别: Icon_minigender_1
  • 来自: 成都
文章分类
社区版块
存档分类
最新评论

采用OO的回忆

阅读更多


 

很早的时候, C++如此神圣。一次周末,我跑到yqd那里,边吃面边看他写程序,Borland C++的,看到对话框闪烁下面掩映着代码,有不少 ::Foo()之类的写法。觉得很酷。这个::是做什么的?不过当时没有好意思问,下来也没有搞的很清晰。相对于CPascal那些翻来覆去的Function ,struct C++ tons of features 值得探索,显得如此的有吸引力。

 

当时公司买了一套Borland C++。光盘怎么的到没有引起我的注意,倒是两箱子的Borland的配套手册(20本吧)让我神往,摸着进口的纸张,眼神散乱,光晕中,我觉得我就是一个高手。

 

可是,当时的项目我实在很难理解。为了访问数据库,需要编写一堆代码;为了创建一个UI,也要生成一堆代码——还看不懂,比如progma ,BEGIN_MESSAGE_DECLARATION这样高贵的代码之类的——一个字符写错,就是一堆阿猫阿狗的错误。玩人啊。

 

然后狂看C++,继续昏倒。那会的面向对象基本上都是以C++为蓝本的。仅仅是多态、继承都让人昏昏然。何况还有构造函数,析构函数,友元、模板这样的概念。尤其是继承,难道代码不就是一堆机械的东西吗?怎么还可以像是生物一样继承呢?

 

C++太过复杂,太早标准化,实在是一个灾难。比如Windows内最基本的消息处理的转发,它必须用宏来完成,后来的OLE封装,也大量的使用了宏,只是为了符合标准。每当我看到有些类库的龌龊设计而百思不解的时候,往往会想到:偶,因为要符合标准啊。Shit, TMD的标准。

 

书看的比较多了,慢慢的我的感觉是,把C++的东西都搞明白,要一年;把MFC 类库用的熟练要一年,还需要了解Windows的消息处理,句柄,回调函数这些非常基本的概念,再来一年。等学成的时候,人都饿死了。

 

接下来一个C++项目比较简单,是一个数据导入程序,把数据导入到LotusNotes内。花费了两周时间,处理若干种格式。我发现只是使用类,不管面向对象,UI也不多的情况下,也是比较容易的。至于代码职责分离,何必管那么多,所有的函数都放到一个类内就行,反正也不复杂。在这个项目中,我使用了CString类做字符串处理,完成后,我牛哄哄的觉得C++就是我亲戚,然后我顺便用Delphi做了同样的工具,逻辑是一样的,而只不过换用了Delphistring而已。我发现效率上来说,“神圣”的C++居然不如Delphi。——光环消失了。我甚至觉得C++的存在根本就是欺骗。因为有人喜欢复杂——这不可怕,可怕的是他喜欢复杂而又驾驭不了复杂。

 

后来用C++做了一个语言解释器,发现这个C++的类库用来做语言真的是方便,其实C++在这个方面非常强大,所有,我认为CXX虽然是设计为通用语言,但是很多细节的引入是为了解决语言,编译器,操作系统之类的特定需求,故而做应用软件实在是不适合。并且异常处理,也是比较龌龊的。这些年的重要语言进步,如内置多线程,异常处理,消息处理,UI设计,重构等在C++语言本身体现不多。C++来自于80S,现在在大部分领域都显得苍老而过时。即便如此,那个年代,人们疯狂的用C++替代老的编程语言,作为C++的作者,我认为他应该是忧心而不是快乐。很多的应用程序,弄Delphi反而更好。但是Delphi是几个强人在搞,Java是一帮和我们想法接近的人在搞,而DotnetJava的都弄过来在加上一帮强人在搞,因此,尽管DotNet并没有什么东西拿出来一招把人打翻,但是用起来真的很贴心、样样都很如意,没有什么特别扭着干的——无论语言设计还是类库设计。被C++祸害的人们都无比喜欢C#,尽管它的本地化调用很丑。

 

这样我的看法是,软件的东西开始不能弄太多的概念,而必须从例子出发,从项目出发。打入一个锲子,然后寻找下一步的方向。

 

在做Lotus项目中,我发现很多时候,我是在访问Word。因为Lotus作为文档管理系统,其实管理的内容就是Word。大量使用VBAWord的类模型,体验着业界老大微软在API设计方面的巧妙和全面。我也梦想,某一天,我的软件也可以想WordLotusNotes,AutoCAD 那样,有完整全面,考究的API ,给大量的程序员一个可以踩的肩膀。

 

2002年的时候,对UML非常着迷。 看了很久的书,也看了不少UML的图,可是一直不知道怎么样。有点天讨论问题,划了两个框,一个线,说这个是bill,那是是detail,两者是1对多的关系,然后我突然明白了UML的用处:确定一件事情,然后分解为几个类,指定他们的关系,这就是最简单的UML应用。随后,我在很多项目中使用UML绘图。直到发现了重构,我觉得重构是更好的学习和表达设计的方法。我甚至把UML边缘化过,在n个项目中,我都把UML作为一个不选的工具,而更多在重构的方法,通过对比代码来发现更好的设计。当做新的打印管理器的时候,我发现,UML图可以对这样的一个耦合关系非常复杂的、非常典型的对象系统中发挥很好的big map的作用,并且让我们讨论的时候更加方便。

 

当做进销存的时候,我发现虽然我知道设计中有那些类的存在,但是非常不爽的是:为什么代码内就不能和设计一致,也用类的方式去实现?有一段时间,我非常反感DataSet,因为它的存在,数据和UI就可以直接的关联了。就是说,即便在数据和UI之间没有Object Model,它们一样可以协作的很好。很多时候,对象是不必要的。如果真的要做一个完整的 Object Model ,然后需要把Object映射到Data,在把Object 映射到UI也是可以的,但是没有任何基本架构可以直接使用,尤其是在Delphi内。都要自己完成,估计效率也会比较成问题。我还真的尝试过这样做,但是从头搭配一个体系,何其困难。玩了,也失败了。我知道只要使用了DataAware的体系,OO就只能成为整个系统中的点缀,但是还是选择了DataAware体系!

 

2004年,我开始接触重构,2005年,我第一次进行了一次完整的重构。针对一个短信项目。我把一个巨型的、职责混杂的类拆开为若干个职责明确的小类。这次成功让我非常愉快。随后在2009年初,我们开始在fx项目中正式引入了重构技术。2010年底,这个项目组从asp开发过渡到C#开发,从面向过程开发,到OO开发,从仅仅完成业务,到开始讨论面向对象,讨论设计,讨论职责分析和重构。然后CMHH等也开始跟进。我认为我看到了技术人员的提升、看到了大家对技术的热爱,人就是IT企业的灵魂——这是我所乐见的。而重构可以更加安全的从A代码到B代码,对于我们这样的老产品的公司,重构是很好的改善代码质量、提升技术人员满意度的好方法。

 

有时候,人的特长真的是命中注定。比如我以前对非常具体的应用编码之类的一直兴趣不大。而直到发现重构,我才觉得这是我最喜欢做的事情。因为我一直反感复杂的做法,垃圾的代码,职责不清的设计。而重构是解决这些问题的法宝。很久以前,我刚刚从业的时候,还根据我们的代码逐步的提炼了一些小的技巧,比如查表法、递归法等,但是直到看到《重构》,才真的把它当成一件独立的工作,开始系统化我的思考。我对重构如痴如醉,反复的阅读MFMartin Fowler)的《重构》,看了中文版,再看英文版,在看中文版...。然后看Kent back 的书,Agile等众人的书,熊节和郑华的博客,MFBliki,自己写重构方面的博客,为各个项目组、外部的俱乐部提供讲座和咨询,提炼重构的各种数量化指标,甚至直接编写代码并形成套路,etc

 

直到最近的fx项目,我依然会思考这个问题,为什么具体的商品,职员等实体都是客观存在的,但是代码中就是不能很好的用这样的类来表达?实际情况是,我们做了很多的类,但是Runner有一堆,很多QueryParamsClass 的转换,Hash之间和互相转换,大量的字符串比如CommissionWJGB之类的;对应的实体类比如Ptype即便有,也是只有数据,没有方法。我想最终的目标是比较清晰的,但是从老的代码一点点的迁移多来,确实需要一个过程。并且考虑到现在平台的代码异步运行的要求,三层分布代码的要求等特殊的情况。所以,在OO的探索方面,我们依然在路上。我们依然在完美的路上,也许再过两年,fx有更多的实体类,更少的事件类和Runner类,UIModel分离的更加清晰,代码更加直观而不混淆,即使OO的初学者也不会感到追踪代码困难,OO难以掌握,那么我们就成功了。这不但是重构和OO的成功,而尤其是个人的提升,进而导致公司技术的成功。

 

个人的技术提升,必然带来效率的提升,进而带来公司的效率提升,而效率提升的量变必然导致工作特性的质变——有完成工作到乐趣工作——Work Hard ,Play Funny。可以有更少的时间完成公司的要求任务,Make thing done,有更多的时间去创新,去Make thing happen。技术提升到底会带来多大的效率提升?我以前听过一个经验的说法,是10倍。当然,信者恒信,不信者恒不信。但是最近我看到了一个证据。无意中,和我说,“,我现在一个打印管理器,两个平台,几个工具的代码共有40万行”,我立刻来了兴趣,查询了下fx的代码,共32万行,8个人做,就是说其他项目的代码量也应该差不了太多。仅仅是数量上看,的个人效率就可能是10倍数,何况他维护的代码更加复杂,需要的设计和维护的成本也更加高。因此,这样10倍并不算令人讶异。

 

我认为,公司每个人都可以提高两倍的效率,没有就自己培养——只要有好的氛围,大家都可以有机会更快的提升自己——比如说每周培训,Scurm让每个人都可以表达自己、比如通过重构建立流程,大家有机会讨论令人费解的代码,得到更好的设计。说实话,我认为每个人都可以达到。利用更好的工具,有更好的流程和管理服务,有更好的技术素养,两倍算什么。我会有更多机会,有更多的人讨论面向对象,讨论更加高级的话题,“谈笑有鸿儒往来无白丁”,这就是我的梦想版本。这是我孜孜以求的境界,为此,我愿意做这些推广和普及的工作。花费大量的业务时间,看很多的代码,阅读很多的书籍和论文,花费时间去组织俱乐部,和微软等公司沟通,如此等等。

 

msf就是一个案例。刚刚转入trd,就开始做xiwa代码。这样的代码是比较复杂的,boss也通过多种方式和我沟通,说这样的代码还是yqd做好一点,包括暗示,明讲等等。我不为所动,相信以trd的技术氛围,msf虽然以往没有这样的平台经验,但是可以很快提升。事实正是如此。msf的进展和提升让公司有了新的看法:大胆启动新人,以有挑战性的工作为基础,以技术氛围和足够的支持帮助员工成长,公司和员工共同受益。

 

fx作为样本,不过两年时间,让我看到了这种可能性是存在的,绝非空中楼阁。也许再过5年,公司每个人以技术为乐。搞进销存软件并不可悲,也不会被认定是一定没有技术的,要知道37Signls就是做项目管理软件的,MF也是做什么破音像租赁、HIS系统的起家,Thoughtworks给做的MIS系统的人提供咨询,Kent Beck扬名立万的是克莱斯勒工资系统,瞧瞧,瞧瞧。并且也要做MIS…,SAP说是ERP,其实还不是MIS一路的,人家可以有ABAP语言,我们也可以,我们现在都有平台了,接下来不就是语言嘛——声明型的。

 

我相信,我们也可以。

 

出去站了会,看到外部的蜘蛛人工头站在楼上的护栏墙上,叼着烟斗,还往下看,听到下面的蜘蛛人放绳子的声音,心头打颤。

 

低调低调。

 

1
0
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics