Daniel Hu的技术生活博客

有位大三还在公司实习的同学问了我一个问题，说他在加入公司之前通过网上下载一些Hibernate、Spring之类的视频来学些一些主流的Java技术和框架，通过这种方式和内容的学习，他的作品得到了老师的认可，并成为了公司的实习生。可在到了部门以后，发现我特别强调面向对象设计、设计模式的运用、UML以及文档。可就他自己的感觉而言，他对这些内容的学习不怎么感冒，我当时没有直接回答这个问题，今天整理了一下我的思路，说不上是一个回答，只是谈一下我的感觉吧。

故事的起点其实并不久远，就在我加盟现在的公司，并在9月份开始接手了一个产品线的开发工作。至此以后，我面对了很多的难题：

• 产品的规划、维护做的很差，看不出模块化的设计，很多模块混成一团，理不清减还乱。这种“人造”的复杂，再加上缺乏文档，开发人员的陆续离开，系统的理解、维护出现很大的真空。
• 产品的升级、扩展、改造难度大。
• 产品设计、编码质量很差。这种情况存在在部门负责的多个系统中，不只是我们的产品线有这样的问题。这一点给我提了一个大大的问号？甚至是让我产生了离开公司的想法，其中的纠结是很难向外人说明白的。
• 团队绩效低下，新的团队成员很难摸清楚现有的业务逻辑、长期依赖原有的开发人员开展工作，要很长的时间才能成为某个模块的owner，至于说整个产品线的，更加困难。
• 产品质量差，新增加一个功能往往会影响几个历史功能，每次有新的大小版本要发布，都提心吊胆。这一点不仅影响到了开发团队，连测试部门很增加了很多的压力。
• 工作压力大，对工作的满意度差。由于上面的几点严重影响了工作的效率，导致我和我的团队加班越来越频繁，满意度、幸福感随之下降。

与此相反的是我和我的团队所负责的产品线，需要支持一个年收入30亿的公司的使用，有10几20个业务部门在该产品线上开展核心的非核心的业务，每年有上百个的功能改进需求，有4-5次的产品版本升级，以上种种任务都需要一个7人左右的开发团队来支撑。如此突出的矛盾，我如何解决呢？我把强化设计视为解决我和我团队诸多问题的方案之一。坦白的说，我之前的工作经历中，我和我之前的公司、同事都没有对相关的内容有特别的关注，正是客观的环境教育了我，使得我把近期把技术重点放到了相关的内容上来。

在这段时间，我特别要求我和我的开发团队做好产品线的设计工作，强烈地要求我的团队重视设计工作、强化设计能力、完善文档、做好产品模块化的设计。也直接地在具体的工作中对团队成员的面向对象设计、设计模式、UML等方面的知识有提出了一定的要求，这些内容或许给他们有了不少的压力，他们多数是刚刚走出校园的学生或从未对相关的内容进行系统的学习。

最后回到那位同学问我的问题，具体的技术和设计如何取舍。首先，我不认为两者存在什么冲突和矛盾，如果说要有什么冲突和矛盾，也是由于一定时间内人的学习精力和时间有限，所以很难在两者直接加以平衡。我对技术的整理可以以下面这张图来理解。黄色图框的面向对象、设计模式之类的技术都是那些超越了具体语言、框架、平台的内容，而蓝色图框中的都是针对的某些语言或某种平台。但大家不要错误地认为两者之间是“井水不犯河水”的，其实两者之间存在着紧密的联系，以Java语言为例，Web框架总是离不开MVC模式的运用，Spring最核心的功能——DI（依赖注入）也可以在很多讲述软件架构的书中找到说明和分析。以我个人的学习经验而言，很多蓝色图框中的技术、框架的学习，最后都在要通过对黄色图框中相应内容的学习，找到彻底的答案。例如，WebWork中的Interceptor是整个Webwork框架的核心概念和开发重点。如果只是去学习Webwork，甚至是看Webwork的源代码都很难理解在Webwork中为什么要有Interceptor这种概念，能给整个Web框架带来什么样的好处，这些问题的都可以在Interceptor的相关设计模式中找到答案。

所以请我们的同学根据自己的情况、从事的工作内容在黄色图框和蓝色图框间做好平衡。其实我们每天的工作就像镜子一样可以反映出我们的缺陷，引导我们加以改进，如果我们能更主动地来加以调整，我们每个人的学习成长经历会更有效率和充满乐趣。最后，附上一个“木桶原理”的示意图，供大家玩味。