程序江湖：第八章
释放成长的烦恼
回复： 有网友说，目前这样写，有些空洞。确实是这样的，一些细节确实跳过去了，没有勾勒。目前因为还有工作，每日写一篇，主要还是讲职场故事。要写出小说级别的，需要更多的时间投入。希望大家继续支持。
有代码的地方，就有程序员，有人的地方就有江湖。IT职场，不一样的江湖。
有一天，突然传来一个消息。说在某项目组的岳亮，已经当上项目经理了。这个岳亮也是和他同时进入公司，同时参加培训的。这犹如一个石头，砸进了欧阳明平静的心里。同屋的小伍似乎看出这点，说了一句：“谁先当上项目经理，不代表什么。关键还是做出成绩。”
也有人跟上话。小祝说：“话是这么说，但是，他确实是第一人啊。”
小伍继续说：“什么叫后来者居上啊？他这是有机会了，等到你们有机会的时候，你们照样上。”
后来，事实证明，这些项目经理成了先烈。因为从技术转项目经理，必须克服很多东西，很多人都克服不了。当然了，这是后话。欧阳明他们还停留在羡慕他们的地步上。
不管怎么样，心里的荡漾，逐渐促使他开始思考下一步走向哪里的问题。正好有一天，公司的总经理来到办公室，和他们交流了一段话。老大嘛，大概就是讲讲使命和远景。但是你还别说，很多人并不清楚自己的部门的使命和远景，于是就容易迷茫。欧阳明就是这样。
总经理说：“研究所，是研究技术，但是我们不是科研单位，我们来自项目，还有走进项目。所以我们的人也一样。也需要到项目里去回炉，然后再出来。”
当时还有很多人很热烈的和总经理谈话。欧阳明及记住这句了。是啊，他感觉他得出山了。在几年以后的一次总结中，他把这部叫成：英雄下山了。当然了，这要和后面的机遇联系在一起完成。这里且先不说。
方向问题基本解决了，这让欧阳明轻松不少。可是日常的工作中，同样也会出现很多困扰。最典型的就是一些问题解决不了，非常头疼。后来，他找到了一个方法，这个方法很简单，欧阳明取了一个名字叫：烦恼转移法。就是当他因为某件事想不清楚的时候，就去找另外一个人，试图给他讲清楚整件事。往往是讲到一半，他就知道该怎么办了，反而留下对方，在哪里傻愣着，不知道怎么回事。
这个方法很好，不过就是苦了萝卜头小祝了。不过小祝随之练就了另外一个功夫：三不神功。对于任何别人的烦恼，都可以做到不听、不想、不究。你以为他听了，他其实没听进去。
这也让他们俩人，成为了一对好朋友。一起共患难，一起创造成就。
欧阳明真的要下上了，可是下山之后还有很多事情需要他去做，他知道怎么做吗？
程序江湖：第九章
设计就是画类图？
王维是第二个成为项目经理的！知道这个消息的时候，欧阳明已经不惊讶了。虽然多少还是有点羡慕，但还是由衷的祝福他的朋友。没等他当面祝福，王维已经来找他了。王维需要招兵买马！他希望小祝和欧阳明成为他的左膀右臂。
这不是欧阳明自己能决定的。但他显然很愿意接受这个请求。
事实上，上面早就已经同意。只是需要征求他们自己的意愿罢了。既然都没问题，这件事就定下来了。
他们下来的准备工作，就是对新系统进行一个系统架构设计。设计？架构？怎么做？王维不知道，他交待给欧阳明和小祝来做。可对于欧阳明他们来说，他们也不知道怎么开始。他们之前的工作都是一个小模块，并没有项目设计的经验。
那怎么办？看看书上怎么说！哦，说到设计，有一个软件叫Rose，有一个语言叫UML。那就便用边学吧。打开软件，其他也没明白怎么回事，但对于对象设计还是大概了解的，那就画类图吧。搞清楚类图，系统架构应该就搞清楚了吧。
他们也煞有其事的，在一个小屋子你反复讨论业务中对象之间的关系。然后在针对这些对象进行抽象。设计对象的属性和方法。最终，形成了一个复杂的类图。
王维来问问系统进度，他们就拿了Rose图给他看。
“这可以吗？”王维充满了疑虑。但是，那个时候，公司没有一个人知道系统应该如何设计。
欧阳明却拍着胸脯说，“没问题，就是这样子的。”
最终，王维的担心得到了支持。公司派出公司最高的技术牛人朱鹤亭，驻场主导设计，欧阳明和小祝跟着。按照老朱的说法，他们三人组成了JAD。原则是少数服从多数。不过，老朱也是一个不懂得业务的人，所以设计还得欧阳明的老大土博士友情参与。这样实际上形成了一个3+1小组。三人决策不了的问题，会加入土博士进来，再进行决策。
风风火火的设计就这样开始了。欧阳明能学到什么呢？
程序江湖： 第十章 三人吵出的设计
有代码的地方，就有程序员，有人的地方就有江湖。IT职场，不一样的江湖。
欧阳明一直以为知道面向对象编程，就可以天下无敌了。至少，抛去自己的修炼问题，面向对象编程（OOP）应该是最好的武功了。可是，面对一个大型系统的设计，他发现无从下手。
这里面固然有经验的问题，他也确实遇到了瓶颈。设计和编程，不是一个领域的。
俗话说，有了老大，打遍天下都不怕。有朱老大带着，感觉没问题。不过说起来，欧阳明真是天将降大任，正好赶上非典。而他们的工作环境是在一个小区里面封闭。每天都在屋子里，担惊受怕。中午出去吃饭也是如此。做城铁公交的，都会随身带着口罩。口罩有段时间都脱销了，还报道有黑心棉的口罩出现。公司也给欧阳明他们发了一些，但是都没用上。
发生非典是在春天。北京的春天，刮一下大风，更显得非典之后的荒凉。朱老大开玩笑说，在这鸟不拉屎的地方，非典也是不会来的。不过后来朱老大还是用上了口罩，因为他感冒流鼻涕了。工作中也带着，因为呼吸难受，所以还把口罩上面掖在鼻孔下面，方便出气。看上去特别有意思。
设计就这样开始了。朱老大先听一遍需求，然后用用例图（Use Case）理解一遍，然后再用顺序图，理解一下业务流程。到具体的业务模块，用包进行分组管理，在每个包内，进行相对的独立设计。
画图的技巧，基本上边读书，边理解，很快就达成一致认可了。但是关于一些具体的设计，就不容易达成一致了。
有一次遇到一个问题，关于有汇总关系的两个类的组织。小祝认为因为汇总关系，字段都差不多，不如直接继承。欧阳明认为既然不一样，还不如再抽象一个基类。朱老大来投决定性一票。但是老大就是不一样。他先和他们讨论原则问题。
“这两种方法是不是都能解决问题?”
“是的。”小祝和欧阳明都承认。
“那我们是不是应该看看，什么情况下应该是继承，什么情况下不应该？”
于是这个问题，就换成了，上级汇总类，是不是下级类的一个子类，即“IS-A”的判断。这一下子转换成了一个业务问题，问题就简单多了。
不过朱老大也不是万能的。有一次遇到一个问题，小祝和欧阳明同样吵得不开交，朱老大听了之后，表示无法判断。只能邀请在旁的土博士参与进来，进行了一个倾向性判断。关于这件事，欧阳明还当面嘲笑了一下朱老大，没想到朱老大给他们深深地上了一课。
“如果两个方案，以10为总权重，一个1，一个9。权重越大表示越好。你们会选择谁？”
“当然是9。”两个人异口同声。
“如果是3和7呢？”
“还是7。”
“那么，如果是4和6呢，或者5和5呢“
“我选6，如果都一样，就无所谓了。”欧阳明似乎有点感悟。
“但我可以选4。”朱老大却出人意料的说出这样一句话。
“为什么？”又是异口同声，但这次是惊讶。
“如果６是我提的，４是对方提的，我愿意选４。对方是4，表明可以做好，而且我自己是6，很可能是有自我暗示的因素。最关键的是，我不是为了选谁，而争论。”
欧阳明突然被震住了，因为他突然意识到，这不是个技巧问题，也不是单纯的心态问题，这更是一个做人的层次问题，视野的高度问题。要做好设计，不光是血技巧，也得随时修炼自己啊。他忽然感觉学到了很多，却又感觉自己懂得很少。
设计就这样吵吵的过去了，基本非典结束，他们也结束了。下面就进入了紧张的开发阶段，项目组要从欧阳明和小祝两人中选择一个做开发经理，他们谁会当选呢？
程序江湖：第十一章 不一般的小插曲
读者反馈：有朋友hhkun0120希望能描绘的再细致一些，那样的话，文章的耐读性会更高，而且更具有教育意义。这点我非常认可。刚开始写作，最关键在于坚持。慢慢顺了，就能进行这方面的改进了。谢谢lifg06938的支持。
有代码的地方，就有程序员，有人的地方就有江湖。IT职场，不一样的江湖。
欧阳明开发的项目，对公司来说是一个非常全新的尝试。公司完全启用的新人，采用新的工作模式。虽然欧阳明不知道，但是能隐约感觉到这些。一天公司的大王总来看他们了。之所以叫大王总，是因为有很多王总，这位岁数最大。这是欧阳明非常尊敬和景仰的一位领导。很有亲和力和感染力。刚到了，就喊他们几个出来搬东西。
“给你们带了点水果，你们吃吃。”王总随便说了一下。
欧阳明和小祝就一人搬了一箱，王总又问：”沉不沉啊？”
欧阳明赶紧回了一句：”不重不重。“心想，就这点事，哪能叫苦呢。
没想大王总补了一句，”你们真不会说话，人家带来东西，要说沉，表示带的多嘛。哈哈！”
欧阳明和小祝心里一阵汗啊。
王总是下午来的，等和王维交流完工作后，已经是晚上了。就说要请我们吃饭。这点欧阳明非常欢迎。特别是大老大请客，一定要吃。吃饭的时候，王总说了几句语重心长的话，让欧阳明和小祝两人倍感责任。
“公司这次全新的尝试，是有风险的。但是，公司相信你们可以。”
“不过，这个重担，不是王维一个人能承担的，你们哥俩要做好王维的左膀右臂，帮助他承担啊。”
说得欧阳明和小祝立即主动表态：”这点您放心。我们本来就是一起的。他要是有什么困难，我们都会上的。”
“那就好。”
有些话，王总没有明说，但是在后面的几天，逐渐的露出端倪。欧阳明隐约知道，王维感觉压力大，就和上面请辞了。所以大王总才特意过来看大家的。为此，欧阳明和小祝协商好了，特意找了王维一次，第一给他鼓气，第二想让他打消这个念头。
至此，这件事算告一段落了。他们仨的沟通也越来越紧密。王维还经常请他们俩吃饭。印象最深刻的就是烤羊棒，这在之前，欧阳明是没有吃过的，南方好像没有这个，而且感觉特别香。从此他就爱上这个菜了。
| 
