*有代码的地方,就有程序员,有人的地方就有江湖。IT职场,不一样的江湖。 * 欧阳明一直以为知道面向对象编程,就可以天下无敌了。至少,抛去自己的修炼问题,面向对象编程(OOP)应该是最好的武功了。可是,面对一个大型系统的设计,他发现无从下手。 这里面固然有经验的问题,他也确实遇到了瓶颈。设计和编程,不是一个领域的。 俗话说,有了老大,打遍天下都不怕。有朱老大带着,感觉没问题。不过说起来,欧阳明真是天将降大任,正好赶上非典。而他们的工作环境是在一个小区里面封闭。每天都在屋子里,担惊受怕。中午出去吃饭也是如此。做城铁公交的,都会随身带着口罩。口罩有段时间都脱销了,还报道有黑心棉的口罩出现。公司也给欧阳明他们发了一些,但是都没用上。 发生非典是在春天。北京的春天,刮一下大风,更显得非典之后的荒凉。朱老大开玩笑说,在这鸟不拉屎的地方,非典也是不会来的。不过后来朱老大还是用上了口罩,因为他感冒流鼻涕了。工作中也带着,因为呼吸难受,所以还把口罩上面掖在鼻孔下面,方便出气。看上去特别有意思。 设计就这样开始了。朱老大先听一遍需求,然后用用例图(Use Case)理解一遍,然后再用顺序图,理解一下业务流程。到具体的业务模块,用包进行分组管理,在每个包内,进行相对的独立设计。 画图的技巧,基本上边读书,边理解,很快就达成一致认可了。但是关于一些具体的设计,就不容易达成一致了。 有一次遇到一个问题,关于有汇总关系的两个类的组织。小祝认为因为汇总关系,字段都差不多,不如直接继承。欧阳明认为既然不一样,还不如再抽象一个基类。朱老大来投决定性一票。但是老大就是不一样。他先和他们讨论原则问题。 “这两种方法是不是都能解决问题?” “是的。”小祝和欧阳明都承认。 “那我们是不是应该看看,什么情况下应该是继承,什么情况下不应该?” 于是这个问题,就换成了,上级汇总类,是不是下级类的一个子类,即“IS-A”的判断。这一下子转换成了一个业务问题,问题就简单多了。 不过朱老大也不是万能的。有一次遇到一个问题,小祝和欧阳明同样吵得不开交,朱老大听了之后,表示无法判断。只能邀请在旁的土博士参与进来,进行了一个倾向性判断。关于这件事,欧阳明还当面嘲笑了一下朱老大,没想到朱老大给他们深深地上了一课。 “如果两个方案,以10为总权重,一个1,一个9。权重越大表示越好。你们会选择谁?” “当然是9。”两个人异口同声。 “如果是3和7呢?” “还是7。” “那么,如果是4和6呢,或者5和5呢“ “我选6,如果都一样,就无所谓了。”欧阳明似乎有点感悟。 “但我可以选4。”朱老大却出人意料的说出这样一句话。 “为什么?”又是异口同声,但这次是惊讶。 “如果6是我提的,4是对方提的,我愿意选4。对方是4,表明可以做好,而且我自己是6,很可能是有自我暗示的因素。最关键的是,我不是为了选谁,而争论。” 欧阳明突然被震住了,因为他突然意识到,这不是个技巧问题,也不是单纯的心态问题,这更是一个做人的层次问题,视野的高度问题。要做好设计,不光是血技巧,也得随时修炼自己啊。他忽然感觉学到了很多,却又感觉自己懂得很少。 设计就这样吵吵的过去了,基本非典结束,他们也结束了。下面就进入了紧张的开发阶段,项目组要从欧阳明和小祝两人中选择一个做开发经理,他们谁会当选呢?