IT圈里的程序员们(2)

3 设计，方法为指导

3.1   阶段释义

老李：老张，你负责的这个模块，要有分布式事务处理能力，还要能与客户的OA系统通信，从OA中获取客户资料的数据。

老张：好的。我将用EJB来实现分布式事务处理，然后开发一个专门的接口，用来与OA通信。

老张毕业五年，是项目组的开发经理，负责完成子系统的设计，并指导其他成员完成编码。老张从老李处获得关于所开发的产品的需求情况，然后进行设计和分析，用 UML 建出模型，并生成框架代码，由小王等去实现。

老张属于第二阶段中人，通常工作了三年以上。此阶段中人，已经完成了一定程度的技术积累。对《设计模式》、《 J2EE 核心模式》、《 UML 》等烂熟于胸，张口就是 IOC （控制反转），有事没事也要说说 AOP ，最差也得是 Factory 、 Delegate 吧，你要是说不知道什么是 Facade ，都不好意思跟人打招呼……

与第一阶段“我能—— I can do it ”不同，本阶段的人，特点是“我知道它能—— I know It can do ”，对，就是“知道它能”，至于如何去“能”，就不需要关心了。例如老张，他只需要把 EJB 接口定义清楚，知道有了这个接口就能完成相应的功能，至于小王如何去实现这个接口，是写了三个类还是五个类，就不关心了。

从技术角度，追求的不再是纯粹的技巧，而是方法这个层次，努力寻求正确的做事方法。即关心“怎样才能盖出好房子”，而不是“如何把石头从货车里搬运到工地上”。用流行的话说，就是“只要方法正确，结果就会正确”。

当然，达到这个阶段的人，技巧本身，通常也是很厉害的。举个例子吧，小王要用一个开源的 XML 文件比较工具，并编了个测试程序，比较 a.xml 和 b.xml 的区别，却怎么着都得不到正确的结果。后来老张来了，牛人根本不看 JavaDoc ，而是拿着 XOP 提供的命令行比较了 a.xml 和 b.xml ，发现结果是正确的，然后直接打开与命令行对应的 main() ，检查与 options 对应的 API ，发现小王少调用了一个 API ，加上这个 API 后测试程序就通过了。在这件事中，老张根本不熟悉 XOP 的 API ，但他掌握了查找 API 的方法，那就是：组件或工具，都有其外在特性，通过组件或工具提供的命令行能做到的事，也一定能通过它提供的 API 来完成。如果不知道如何去调用 API ，对于开源软件，看它的 source code 或 samples 中的 main() 即可；对于非开源软件，看 StackTrace ；如果都看不出来，就放弃该软件，选择别家的吧。

此阶段中人，也需要编写程序，但编写的是与业务和框架相关的核心类。所用的语句通常朴实无华，用最简单的语句完成最复杂的功能是他们的习惯。例如，求b和c中的较大值，通常不会写成

result=(b>c)?b:c

而是写成

if (b>c)

result=b;

else

result=c;

因 为后者更容易懂，而前者，相对生僻一些。开发经理的工作，是把产品的需求，转变为编码人员能理解的接口或类，并保证团队的所有成员在理解上的一致性、无二 义性，在这个前题下，简单而又精确的语句是必然的首选。所以，如果你的经理编写的程序，在你看来很“幼稚可笑”时，千万不要洋洋得意。

舍小巧而用大巧，舍弃繁花似锦的编程细节，换取简单稳定的框架结构，换取无二义性的交流效果……独孤剑圣四十岁前，以玄铁重剑纵横天下，剑法古拙，大巧不工，就是此境界（孤独大侠也走过弯路， 30 岁时用紫薇软剑，可能是追求剑招的繁复和剑法的华丽，失去控制，最终误伤义士）

3.2   应该做的事

该阶段的人，该做可做的事非常多。须知一个完整的软件产品的开发过程，编码仅仅是其中的一个环节而已。作为开发经理，老张的典型工作如下：

首 先充分理解需求，挑选其中20%左右的功能，结合非功能性需求，设计出系统的结构（Architecture Design）。通过边界类、控制类、实体类的应用，分析清楚Use Case中的交互流程，然后用一系列接口来表达这个流程，最后运行各种设计模式或技巧，实现这些接口，建出UML模型，并生成代码框架。

除了开发经理外，你还有可能是项目经理，在中国公司，项目经理和开发经理可能都是你。学习先进的开发方法是你的必修课，什么用例驱动开发、测试驱动开发，不管用不用，你都得知道个大概；选择正确的开发模型也很重要，何时选用瀑布模型，何时选用迭代模型，一定不能含糊。

遵守公司的开发流程，为 SQA （ Software Quality Assurance ）提供必需的文档和数据也是你的本职工作。如果你所在的公司尚无规范的开发流程，那么，你要帮助公司来建立。完整的开发流程贯穿整个产品生命周期，你有可能只与其中几个阶段有关。但只要与你有关，那就要尽力去配合。

该阶段的人，通常在公司中是中层干部，执行能力是一个最主要的考核指标。你的领导，可能根本不懂编程，而项目组里的小伙子们，可能无法领会领导的意图，这时，你就是中间人，好比足球场上的中场，你的沟通能力和执行能力，将决定产品开发阶段的成败。

3.3   不应该做的事

1 、尽量少编程。除了“核心接口、类和算法”，不要与其它代码纠缠，那会使你忽视宏观上的问题。而且，你也不一定比小伙子们编得快。只有当小伙子们遇上困难时，你才去协助他们解决问题。

2 、不轻言放弃。该阶段的人，工作压力巨大，即使他看上去什么事也没干，他承受的压力也不是编码人员所能体会的。在压力面前，容易失去理智，如果不注意控制自己的情绪，可能会发生一些不愉快的事。

现 在的你，可以说是“到哪都能找到工作”了。当与公司、同事发生一些摩擦时，可能会“一怒而去”，这是最要不得的。因为你现在追求的，已不是“能找到工作” 了，而是“能找到体现自己价值的工作”，千里马尚且需要伯乐来发现，换家公司就一定能受重用了？而且，不管你是否意识到，你已经学习了许多行业相关的知 识，这些知识，在更换公司后，未必能用上，到新公司后，还得从头学习——人生有几次重来的机会？

3 、戒骄戒躁。你现在已经是“有本事”的人了，加上工作压力，难免有点脾气。但是切记，你还没有功行圆满，还要“多长本事，少长脾气”。因为你的局限性，与你的优点一样明显。技术等级的提升，应该是让你眼界更开阔，并看到了更大的差距，而不是固步自封。

4 、不要迷信新技术。新技术的采用是有一定的风险的。因为技术本身，可能还不成熟。追捧新的框架可能是你的爱好。没关系，作为爱好，是可以的，但不一定要把爱好带到工作中来。老板关心的是你开发出来的东西能否买个好价钱，不是看你用了多少新的 Framework 。你的用户关心的，是产品的易用性、稳定性，用起来是否顺手，用户同样不会关心你用了 Tomcat 还是 Jetty ，甚至连 J2EE 和 .Net 都不关心——如果他不需要为此购买新的硬件或者重新培训操作员。

5 、多看人文方面的书和文章。此时的你，在技术方面已经有一定的造诣了。但是不是就大功告成了呢？回答当然是“不”，你还需要补充人文方面的知识，即进行感性思维训练。为什么？往下看。

3.4   局限性

你的局限性，与优点一样明显。如果让你列举自己的优点，你可能会说：

n  我精通设计模式，能做出重用性很好的软件

n  我对软件工程很有经验，能做一个好的项目经理

n  我熟悉建模工具、开发环境等，能提高开发效率

n  ……

是的，这些都是了不起的能力，但是：

1、 你们公司不是研究所，不卖设计模式，也不是咨询公司，不卖软件工程经验，更不是培训机构，不对外提供“建模工具、开发环境”培训

2、 你知道软件是如何被开发出来的，但很少考虑是否应该开发这个产品；

3、 你不知道用户会怎样使用你开发的产品，你不知道用户喜欢什么、抱怨什么；

4、 你不知道这个产品为公司赢得了多少利润；

5、 ……

一句话，你懂技术，但客户要的，并不是技术。摩托罗拉有世界上最好的射频工程师，但为什么手机就是卖不过诺基亚呢？因为诺基亚喜欢听客户的意见，而摩托罗拉喜欢听工程师的意见。

你说：“我热爱技术，喜欢钻研技术，至于客户在想啥，那不是我要考虑的问题——我甚至不知道客户是谁”。是的，达到你今天的这个境界非常不容易，许多人工作十年也未必能象你这样优秀，你是公司的骨干，是同事的偶像，但是……但是……《武状元苏乞儿》中有一段经典对白：

洪日庆：先别走！行行出状元！如果我没看错，你会是乞丐中的霸主！

苏  灿：乞丐中的霸主？！那是什么？

洪日庆：嗯……还是乞丐！

没错，乞丐中的霸主也是乞丐。你再优秀，也只是公司的中层干部，是干活的人中的霸主——还是个干活的：

n  客户给老板发工资

n  老板给你发工资

n  你不认识客户，客户同样也不认识你

n  既然你不认识客户，那就不知道客户喜欢什么、讨厌什么

n  如果有一天，你的产品让客户不满意（这个概率还是很大的）

n  客户很生气，后果很严重

n  老板请你喝咖啡，并建议你去度假，顺便提醒你从外面把门关好

 

再来看看圈子里：

n  没有技术，但手里有一堆客户的公司，比比皆是，他们活得很滋润。

n  没有客户，但手里有一堆技术牛人的公司，很少见——都倒闭了。

 

现在，你知道局限性在哪里了吧？

“正因为你技术太强了，所以只能当乞丐中的霸主，技术恰好就是你的枷锁”

说件真实的事吧。

某天，我奉命与一个合作伙伴交流我们的平台产品，目的是让对方了解我们的平台并在平台上做二次开发。交流进行得很顺利，对方也跟我们签合同了。后来，市场人员去合作伙伴处了解反馈意见，对方说：“你们那个 xxxx 太厉害了，问什么都难不倒”。回来后，领导就不允许我参加交流了。原因是：“你可能泄密了”。

作为技术人员，我希望充分介绍自己产品的优势，并能应付合作伙伴提出来的各种应用场景和问题。但是，从领导的角度来看，“如何满足应用场景、如何解决问题”本身，就是商业机密，是不能乱说的。举这个例子的目的，就是说明技术人员看问题的局限性。

想要达到更高的层次，就要跳出技术看问题，多了解市场，了解客户。假设孤独剑圣陶醉于玄铁重剑的威力，天天带着到处乱跑，那么他就不是剑圣，而是搬运工了。搬运工最多只能当个中层经理，当不了高层领导。

如果想进入领导班子，与老板一起玩游戏，那就赶快升级吧。

3.5   进阶指南

1、 跳出技术看技术

达到这个阶段的人，在技术上已经“很深入”，眼中所见，尽是技术。但你们公司不是卖技术的，你们卖的是产品，是服务。所以，把你的目光从技术中解脱出来，去思考一下产品和市场层面的问题。例如：

n  市场上有同类竞争的产品吗？

n  当前已有的产品，客户有什么不满意的？

n  我做的产品应该具有什么样的特色？有什么卖点？

所谓“一招鲜，吃遍天”。只要你知道客户想要啥，并能有针对性地开发产品，客户一定会情不自禁地给你钱。客户都给你钱了，老板还好意思不给你个 CTO 的头衔玩玩？

2、 了解业务

计算机技术必须为具体的行业服务，每个行业都有自己的特定背景和业务知识。技术人员应抓住机会，了解这些知识。我曾在某个电信软件公司任职三年，号称是项目经理，开发电信网管产品。那时我整天的工作就是研究各种框架，讨论各种设计模式，我眼中所见心中所想，尽是 WEB 、 Struts 、 HTML 等一大堆计算机名词。如果你问我“为什么这玩意是个网管软件，而不是淘宝易趣阿里巴巴？”我一定回答不出来。

一个公司里面，真正值钱的东西，不是技术，而是业务知识，技术是实现业务的一种手段，是为业务服务的，主从关系，不可搞错。

3、 加强非技术性的功夫

学书法时，老师曾说过“三分书内功夫，七分书外功夫”。这句话我一直不理解（事实上，到今天依然不理解），但把这句话用于计算机技术，却是明白的。三分书内功夫，是计算机技术，七分书外功夫，就是非技术性的产品和市场了。

可以通过看些“不务正业”的书，来提高自己的感性思维能力，可以多看看市面上流行的《比尔盖茨传奇》《数字化生活》《把信寄给加西亚》等，象《谁动了我的奶酪》这种只会抱怨不会解决问题的书，就不用看了。

3.6   阶段小结

适用人群： 工作三年以上，上限不封顶

输    入： 软件需求（请注意用词的区别：软件需求，而不是客户需求，你所得到到软件需求，是由别人收集来的，并不一定能代表客户，如果“别人”的水平一般，错误理解了客户的意图，那么你就等着跟他一块倒霉吧）

输    出： 设计好的类、接口和算法

阶段目标： 我知道它能—— I know it can work

技术特点： 注重方法，不关注编程语言细节

胜任职位： 高级软件工程师、开发经理、系统架构师等

升级秘笈： 换位思维，跳出技术看问题

参考薪水： ￥6 000 以上，￥15000以下（仅供参考）
转自http://wakan.blog.51cto.com