采用OO的回忆
?
很早的时候， C++如此神圣。一次周末，我跑到yqd那里，边吃面边看他写程序，Borland C++的，看到对话框闪烁下面掩映着代码，有不少 ::Foo()之类的写法。觉得很酷。这个：：是做什么的?不过当时没有好意思问,下来也没有搞的很清晰。相对于C，Pascal那些翻来覆去的Function ,struct ，C++有 tons of features 值得探索，显得如此的有吸引力。
?
当时公司买了一套Borland C++。光盘怎么的到没有引起我的注意，倒是两箱子的Borland的配套手册（20本吧）让我神往，摸着进口的纸张，眼神散乱，光晕中，我觉得我就是一个高手。
?
可是，当时的项目我实在很难理解。为了访问数据库，需要编写一堆代码；为了创建一个UI，也要生成一堆代码——还看不懂,比如progma,BEGIN_MESSAGE_DECLARATION这样高贵的代码之类的——一个字符写错，就是一堆阿猫阿狗的错误。玩人啊。span>非常着迷。 看了很久的书，也看了不少UML的图，可是一直不知道怎么样。有点天讨论问题，划了两个框，一个线，说这个是bill，那是是detail，两者是1对多的关系，然后我突然明白了UML的用处：确定一件事情，然后分解为几个类，指定他们的关系，这就是最简单的UML应用。随后，我在很多项目中使用UML绘图。直到发现了重构，我觉得重构是更好的学习和表达设计的方法。我甚至把UML边缘化过，在n个项目中，我都把UML作为一个不选的工具，而更多在重构的方法，通过对比代码来发现更好的设计。当做新的打印管理器的时候，我发现，UML图可以对这样的一个耦合关系非常复杂的、非常典型的对象系统中发挥很好的big map的作用，并且让我们讨论的时候更加方便。
?
当做进销存的时候，我发现虽然我知道设计中有那些类的存在，但是非常不爽的是：为什么代码内就不能和设计一致，也用类的方式去实现？有一段时间，我非常反感DataSet，因为它的存在，数据和UI就可以直接的关联了。就是说，即便在数据和UI之间没有ObjectModel，它们一样可以协作的很好。很多时候，对象是不必要的。如果真的要做一个完整的 Object Model ,然后需要把Object映射到Data，在把Object映射到UI也是可以的，但是没有任何基本架构可以直接使用，尤其是在Delphi内。都要自己完成，估计效率也会比较成问题。我还真的尝试过这样做，但是从头搭配一个体系，何其困难。玩了，也失败了。我知道只要使用了DataAware的体系，OO就只能成为整个系统中的点缀，但是还是选择了DataAware体系！
?
2004年，我开始接触重构，2005年，我第一次进行了一次完整的重构。针对一个短信项目。我把一个巨型的、职责混杂的类拆开为若干个职责明确的小类。这次成功让我非常愉快。随后在2009年初，我们开始在fx项目中正式引入了重构技术。2010年底，这个项目组从asp开发过渡到C#开发，从面向过程开发，到OO开发，从仅仅完成业务，到开始讨论面向对象，讨论设计，讨论职责分析和重构。然后CM、HH等也开始跟进。我认为我看到了技术人员的提升、看到了大家对技术的热爱，人就是IT企业的灵魂——这是我所乐见的。而重构可以更加安全的从A代码到B代码，对于我们这样的老产品的公司，重构是很好的改善代码质量、提升技术人员满意度的好方法。
?
有时候，人的特长真的是命中注定。比如我以前对非常具体的应用编码之类的一直兴趣不大。而直到发现重构，我才觉得这是我最喜欢做的事情。因为我一直反感复杂的做法，垃圾的代码，职责不清的设计。而重构是解决这些问题的法宝。很久以前，我刚刚从业的时候，还根据我们的代码逐步的提炼了一些小的技巧，比如查表法、递归法等，但是直到看到《重构》，才真的把它当成一件独立的工作，开始系统化我的思考。我对重构如痴如醉，反复的阅读MF（MartinFowler）的《重构》，看了中文版，再看英文版，在看中文版...。然后看Kentback 的书，Agile等众人的书，熊节和郑华的博客，MF的Bliki，自己写重构方面的博客，为各个项目组、外部的俱乐部提供讲座和咨询，提炼重构的各种数量化指标，甚至直接编写代码并形成套路，etc。
?
直到最近的fx项目，我依然会思考这个问题，为什么具体的商品，职员等实体都是客观存在的，但是代码中就是不能很好的用这样的类来表达？实际情况是，我们做了很多的类，但是Runner有一堆，很多QueryParams和Class 的转换，Hash之间和互相转换，大量的字符串比如CommissionWJGB之类的；对应的实体类比如Ptype即便有，也是只有数据，没有方法。我想最终的目标是比较清晰的，但是从老的代码一点点的迁移多来，确实需要一个过程。并且考虑到现在平台的代码异步运行的要求，三层分布代码的要求等特殊的情况。所以，在OO的探索方面，我们依然在路上。我们依然在完美的路上，也许再过两年，fx有更多的实体类，更少的事件类和Runner类，UI和Model分离的更加清晰，代码更加直观而不混淆，即使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语言，我们也可以，我们现在都有平台了，接下来不就是语言嘛——声明型的。
?
我相信，我们也可以。
?
出去站了会，看到外部的蜘蛛人工头站在楼上的护栏墙上，叼着烟斗，还往下看，听到下面的蜘蛛人放绳子的声音，心头打颤。
?
低调低调。
?
