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