原帖在这里话说英孚（一）话说英孚（二）话说英孚（三）话说英孚（四），一共有四篇。
应该感谢博主让我有了动力来更新荒废了一年的博客。动力的来源就是，我曾经有多么相似的经历，不论是客观环境还是自己的主观态度。光是共鸣也没什么，我后来的领悟我觉得对博主也是一种启发吧。
我现在越来越觉得大的外企是不是都是有这个问题存在呢？说到底就是僵化的制度，流程造成人浮于事，得过且过，敷衍了事. 这样是最好的结局吗？我在上一家公司也经常是这样抱怨，不同项目人员交流效率低，半瓶子的老外架构师设置重重障碍，开发流程，工具，技术上的种种限制。觉得这些客观因素限制了我的能力发挥，把本来双核甚至四核的CPU变成了8086来用，而改变这些又不是我的责任，而且即使有心改变，也是处处碰壁，还不如逆来顺受。直到碰到了这么一个事情，让我有了些不同看法。
公司里有个人L，简单讲情况是这样，L手底下有几个人一起做项目，但是项目都是从总部那边接过来，但是总部那边也是有相应的开发团队的，项目给你了他们做什么呢？所以那边很紧张，不会轻易把活交给这边做。L这边只能自己去找项目做，就有了这么一个优化搜索系统的项目，姥姥不疼，舅舅不爱的。其实，这个系统已经在那里用了很多年了，一直觉得性能低，不满足需求，但是没有人懂，更没有说明文档，只有产品和大量的代码，所以没人愿意干这个活。到这里，估计要是我也没有勇气去接这个受累不讨好的项目，除非实在没辙了，人要吃饭啊，有活做就不错了。L接下这个活第一步就是了解这个系统的大概脉络，没有文档，没有熟悉的人，硬件没有更新，给的时间，资源又很有限，最要命的是很多其他系统依赖这个系统，所以不能改变任何外部接口，甚至不能影响现有系统的运行。怎么办呢，只能多方打听，了解。了解一点这个系统的人在别的部门就要通过上层领导协调来沟通，别人配合不配合还两说，难度可想而知。再有就是啃代码，一点一点的揣摩代码的意图，如果是个小系统还罢了，这是一个要运行在n多台服务器上的一个多层架构的系统，工作量可想而知。总之，最后了解大概结构，脉络以后，自己再重新定义模型，优化搜索规则，改进算法，继承遗留系统接口，等等这些工作一步一步的做下来。最后硬是按时交付了，性能据介绍有了数十倍的提高，还申请了专利。在这样没有任何支持，没有资源的情况下完成这个项目，并不是随便一个高级程序员能做到的，除了过硬的技术能力还有一些交流的能力，要打消对方顾虑，让别人不遗余力帮助你，这种能力是很重要的。最后如果L找工作的时候，简历上应该就会很好看，出色的完成了“不可能的任务“（Mission impossible）。这种双赢的结果当然好了，即使最后没有得到想要的结果，也会比在找工作的时候对面试官抱怨怎么怎么没有用武之地来得更有说服力。
我没有说教的意思，相互探讨，我的一些想法是这样
- 组织混乱，流程僵化，这并不能阻止你去做改进，即使这不是你的责任，如果你尝试去做了，不管成功与否，你都会有额外收获的。我们那个架构师曾经也是不允许他不懂得技术用在项目上。有一个Java的项目用到了JSTL标签库，架构师不让用，其他的程序员都抱怨这个猪头架构师。我当时刚开始参与这个Java项目，以前都是.Net的系统，了解了一下JSTL标签，就类似ASP.net中在aspx文件中的那些非html的tag一样，我觉得这是一个很自然的应用，禁止是毫无道理的，就斗胆给他领导发了几封邮件来反驳。结果也可想而知，架构师是得宠的，领导说让架构师评估一下，看看可不可以用。但我觉得我也没损失什么，只是一次改进的尝试失败了而已。后来再用到了一个叫JAXB的技术，就是XML到对象的自动映射的类库，经过反复几个回合，最后还是采纳了这个”新“技术，结果呢就是我们不用繁琐的花时间去手动解析XML文档了，多好。
- 对于代码库，各种服务器的访问速度等问题。我也遇到了相同的问题，但是除了大骂之外，我们的各种增加带宽的要求没有回应之后，自己想了办法。一个同事建了一个中转的源代码服务器，我们只需要本地checkin/checkout因为和美国有时差，所以我们下班以后，这个中转服务器会自动和主代码服务器同步，也不会有冲突。还有总结了一些best practice来解决服务器部署的问题，这样虽不能彻底扭转局面，至少让自己受虐的时候舒服了一点。
- 应用系统框架，我们当时也有一个类似的框架。其实上边说到的架构师对JSTL的抵制就是，如果采用JSTL那这个烂框架就会被绕过去，变成了没用的废物，架构师还是很有前瞻性的呵呵。但问题说回来，接触多了，也就慢慢理解这个框架出现也是有原因的，是为了解决一个普遍问题而被设计出来的。不是为了要惩罚我们而强迫我们使用的一个刑具。虽然，这丝毫不能改变这是一个烂框架的事实，但至少在态度上我们认识到它的意图是好的，只是没有被设计的那么灵活，完善，强壮而已。
- 够用就好。我也一直使这种refactory的观点，持续改进嘛，有必要为了实现一个几行代码的功能那么兴师动众吗。其实这种情况下就要具体问题具体分析了。本来就是一个平衡的艺术，有时候就要有点前瞻性，明知道以后会有扩展，会有复用，那就要提前想到，能不重复做的就没必要。当然，如果根本预测不到增加的这么多工作量所带来的潜在收益，那绝对是吃饱了没事干了。这和敏捷开发中提倡的适度设计有相同的观点。
说了这么多，我的观点就是很多东西不是生下来就是完美的，他是不停地由不同的人来完善出来的。最后遵循这个完善制度，流程的人是不会意识到其中的奥妙的，而那些为其完善做出努力，试图做出努力地人才是最大的受益者。
