再谈职场之路

五一假期及近尾声，不如趁此独居一隅的清静时刻再聊聊关于个人发展的话题。事实上在我自己一直都做着这样的事情，这一篇就记录下我在毕业一年之后的想法罢。

技术和艺术

刚才朋友发短信来问我为什么不考 GT 出国，就算到香港科大去一个月拿 13000 的奖学金不也很爽吗？不错，这些奖学金是比俺的血汗钱还多，可无论如何现在不是走老路的时候，现在我还算初入职场，关注的全是如何做好手头的工程项目。嗯，我注意到自己不再说俺是搞技术的那样的傻话了，这是我这个工科专业毕业的大学生必然经历的变化。首先，我不是聪明绝顶的那种人，不是技术大牛；其次，我所遇见的工程真的是不需要最 cutting edge 的技术。

其实搞技术的和搞艺术的差不多，面对时尚大潮总是会不由自主地随波逐流。比如从 COM 到 .NET。就现在，framework 真是很流行哇，去年写了一个关于 Struts 的入门教程，就不断有爱好者举着 Struts 来敲我 QQ 的门。勿庸置疑的，Struts 肯定是一个好东东，但你真的需要吗？对对，你可能确实需要实现 MVC 模式，那么为什么不用 Turbine？你想过吗？

我也一直关心数据库层的持久性逻辑的解决方案，用存储过程（stored procedure），还是 Torque 或者 Hibernate？它们的运行效率、部署代价各不相同，而每一个技术总有其适用性。我目前的视野也很小，比如就始终没有涉及到表示商务逻辑的中间件或者应用服务器，要说那也不算太过高深，但我只是用不到。退几步说，就算你必须得到多层架构带来的那种可靠性、可伸缩性和可维护性，你的客户也愿意为此掏腰包，你面对新玩具欣喜若狂，跑着去参加 Oracle、Sun 在各个城市的秀场，又花了多时去克服那个 learning curve，经历了设计、编码、测试一年半载的折磨，说不定这个技术又被淘汰了。

瞧瞧，SOA（面向服务的体系结构）已经摆上了 IBM 和 BEA 的台面，你玩过吗？算了，我不想争论，我只是说我不会这样浪费青春。即使你不是跟在 IBM、BEA 的屁股后面哪又怎样，不要相信这有什么终极意义。话再说回来，我也不想一直做个偏激的人被你骂，Web Services 作为炙手可热的技术在某个时刻应用到企业的 IT 系统和商业流程之中，肯定是可以给企业带来经济效益，做为下一代 Web Services 的基础架构的 SOA 也是大有希望。

不选贵的，只选对的

如果把老的技术和新的技术比作一个工具盒（toolkit），我只是会在合适的时候选择恰当的工具来使用，简单的改锥有时会比复杂的电钻更顺手、更安全、更省电。说到这里我想起一个实际的例子，某公司的一名年轻员工使用 FoxPro for DOS 为本公司开发了一个跨部门的应用系统，通过跑在网络、数据库上的功能满足实际需要，至今使用了七年。如今的改造则真的需要 Oracle、Tuxedo、WebSphere 吗？

再露骨一点说，技术之所以有三六九等，所谓的新与旧、先进与落后都只是表象，人们真正关心的是它的市场价值。基于这个原因，现实中有很多工程师存在严重的跟风习惯，也就是只要媒体对某个技术炒作一下，什么程序员挣到了大钱，他们立刻就会蜂拥过去，从 PowerBuilder 拥到 Visual C++，从 Delphi 拥到 JBuilder，从 WSAD 又拥回 DriverStudio。是的，会用新的开发工具并不一定拿到高薪，他们就这样拥来拥去，最后只能迷失了自己。哪个才是该要的？能够帮助你开发出满足需求的应用程序的工具就是你该要的。曾经，EditPlus 就是我该要的，后来 Visual C++ 是我该要的，现在 Delphi 是我该要的。说到这里，学习能力是你最该要的。

everything 都有规律可循

从产品中跳出来吧，大海航行靠舵手，开发软件要靠软件工程思想。从 UML 这样的重量级方法到近年来发展出来的 XP、FDD、Scrum 这样的敏捷方法（agile methodologies），关于生命周期（lifecycle）的讨论已经够多，下面聊聊软件复用（software reuse）吧。不管是源代码（source code）、组件（component）的复用，还是模式（pattern）的复用，正发挥出越来越大的能量。尤其是模式，模式的伟大之处在于它总结了许多有用的设计理念和经验。算法（algorithm）不是设计模式，因为算法致力于解决实现问题而非设计问题。你可能没注意到，模式还是有效的沟通工具，开发人员在讨论软件设计的时候，只需说一声“使用工厂模式”，而不是费尽吐沫星子的讲几个类之间的关系，大家就都能明白，很 cool 吧？然而，对模式的频繁使用又常导致过度工程（over-engineering）。因为在设计初期就使用模式的话，注意力会被集中到如何使用模式上，而不是如何满足需求上。于是出现了重构（refactoring），来跟踪设计的演进过程，最终达成设计目标。

计算机辅助软件工程（CASE）工具和软件配置管理（SCM）工具始终应该是核心工具。因为在软件过程中，并行开发、版本控制、nightly build、变更管理、产品发布都已经成为必不可少的特性。比如 CVS、Ant、EclipseUML、JUnit 等工具的使用无疑标志着软件开发的管理水平，而不会带来过高的成本。

需求是人的需求，智慧是人的智慧

对于一个项目，特别是企业信息化领域的软件项目，除去软件工程的技巧和经验之外，决定成败的另一个重要的因素就是业务知识。在软件生命周期中，大家可能都意识到了需求分析的重要性，但是由于现实的因素用户的倾心配合常会成为项目的稀缺资源，因此做为工程师，具有行业内部的应用环境和商业流程的知识将是一个大大的 plus。在这一点上，目前立足民航机场这个应用领域，我甚至已经感到了巨人泰坦（Titan）的力量。

回到技术和艺术的讨论，有一种认识，电影艺术在逐渐变为工业，所谓的艺术可能只体现在前期和后期，在中间过程中只要一开机，帐户上就开始往外哗哗流银子啦，导演在关心怎样换场才节约成本的问题，老天爷不下雨得雇个水车，更添乱的是，刚才灯光和化妆还吵了一架，XX 演员一有功夫就发她的破短信。项目也是一样，技术并不是项目的本质，做为项目经理，他要关心的是进度、成本、质量三个要素，如何获取资源，如何调动团队成员的积极性，如何管理变更等等。只不过国内的状况是，在一个项目中，项目经理通常又是一个 technical lead 甚至 lead developer，他必须要知晓使用的产品，采用的技术，以及开发的过程。汗！这就叫 primary responsibility 罢。

另外要告诫自己的一点：一个人在事业上的成功或者狭隘的说个人财富的积累是一个人的资源整合能力的结果，而绝对不是由技术能力单方面决定的。在过去的经历中，我遇到过有些技术高超的工程师，他们很聪明，但是缺乏在公司具体的人际关系环境下生存的能力，而变成愤世嫉俗的人。智商高低和技术新旧乃至上学时期的学习成绩不会意味着职场的成败。不要抱怨自己所处的环境的复杂性，其实无论是管理井然的跨国公司还是管理混乱的民营企业，只要有人的地方，就不可避免有各种形式的人事斗争，锻炼并提升自己在复杂环境中的领导能力十分重要。

生活在由人群组成的社会之中，成功不仅来自在技术上的核心能力，也来自工程实践、行业背景、管理技巧，以及人际关系。