标签：企业 需求 amp 总监 组合 耦合 idt 统一 装箱
有这么一句古老的箴言：
如果你手里有一把锤子，所有东西看上去都像钉子。
其实这句话已经是老调中的老调重弹了，我们程序员有很多锤子：OO、设计模式、语言（C, C++, Java, Python, Ruby, etc.）、各种各样的架构tricks&workarounds，以及一堆软件过程方法论（Agile, XP, Scrum, etc.）、等等。
几则故事：
1. 阿朱的（《走出软件作坊》）：
我过去领导过架构组。架构组的人在2002年的时候，疯狂迷上了UML和设计模式，人手一本《COM本质论》和《设计模式》。我手下有一个新手，就处处是类，处处是抽象，处处是封装，处处是分离，尽量使代码高内聚低耦合。但是这样的的代码太麻烦，他花费了大量的时间，他看自己的代码赏心悦目，别人看他的代码云里雾里，不阅读懂《设计模式》就按照常规理解业务的思路去阅读他的代码根本阅读不懂，不知道他为什么这样写代码，怪异的很。本来，这位想达到可维护性，可阅读性，却真正的失去了可维护性、可阅读性。这和我前几天看我的朋友周爱民写的《大道至简》中写到：有人希望拿UML去统一用户和软件设计者。殊不知UML有多难理解，而UML设计者却认为UML可以描述一切。就这个道理，要理解你的代码还要去读懂《设计模式》，这要求太高了吧。
所幸这位新手自己都每次写的累，慢慢的也就懒了，觉得确实需要分离的时候就分离，觉得没什么必要的就懒得做了。用他自嘲的话说就是：被磨平了。其实，依我看，他现在这个代码状态才是刚刚好，即照顾了设计扩展，又照顾了实用。真正的纯OO，纯设计模式，可能只存在于教学和科学，而不在于我们的商业软件开发。我们作为商业开发，强调的是叫座的基础上叫好，所以折中方案是必须的，客户和我们自己两相宜就OK，是否符合正宗，就不在我们的商业开发管理范畴了。
这位新手还写了大量的注释。在每个源代码文件头都写上几月几号，XX创建的，这个原代码文件主要是干什么的，还画蛇添足的写上版权所有，公司名称。好像这个代码要开源，或者可能会被其他公司窃取了好表明公司版权。甚至每个函数都写了注释，每个参数是什么意思，每个参数可能出现的值代表什么意思，都写的一清二楚。久而久之，也懒的维护了。代码改动了，参数扩展了，参数状态值有了变化，注释说明却没有跟着改动，让后来看代码的人老误解，还不如不写这些注释。
我告诉他：做事不能走极端。要么全写注释，要么不写注释，都是不对的。我只在我认为要小心的地方，或者我自己都觉得很难理解懂的地方我才写注释。否则，我自己都可能会过段时间理解错了。如果某段代码我看看就能看懂，我就不写注释了。咱们做企业管理软件，深入技术又没有，只要代码能把复杂的业务处理描述的逻辑思路清晰就OK。虽然说理解能力不同，我能快速理解了的未必有新手能够理解，但是你看看我的代码你就明白了。（摘自 《走出软件作坊：代码那些事儿》）
再来一段：
有一部分所谓的架构师，技术超深厚，框架堪比Spring之类，但自己一个人闷头写框架不断优化，力竭使用最先进的技术思想，希望把最豪华的设计模式融进去，希望把OSGi融进去，希望把AOP融进去，全无视那些想利用框架减轻自己工作量提高自己工作效率的应用功能开发同事。这是在用公司工资玩技术呢，还是在满足个人技术幻想呢，还是在实验呢？到底在干吗？价值在哪里？
还有的人不会推广自己的框架。不善言辞，就幻想着技术总监能够通过行政命令让大家必须用框架，能不自己写代码就不自己写代码，能交给框架做的就交给框架做。但技术总监号召完了，大家仍然我行我素，各自开发为政，让框架开发者很孤单。
还有的人也不会推广自己的框架，沉迷在自己的理想世界。好不容易技术总监召集大家让大家来听听框架如何应用，但自说自话，满口自己最得意的词汇，听得业务功能开发人云山雾罩。大家问些问题，如这样的业务开发难题，框架怎么解决？于是，框架开发员就和业务开发员争论了起来。框架开发员觉得这根本就不能答应客户这种变态的需求，而业务开发员说这就是现状。框架开发员说你可以这样这样，业务开发员说这样太麻烦，框架开发员立刻还口这还麻烦？于是双方各执一词，框架也没推广成功。
我手底下有个框架开发员。他的技术渴望很强烈，为了技术难题攻克，可以不吃不睡。并且技术敏感度很强，学习也快。所以当时我感觉他是个程序员的料，就把他拉到我的手下。
但是有个问题，他写出的框架代码，在平时开发业务功能的时候挺麻烦。大家可能需要的是一把铁锹，但是他却给大家N根不同长度不同粗细不同材质的木棍，N个不同形状不同用途的铁锹头。大家会有N种组合。不仅导致他写代码老超任务期，而且也让使用人感觉没多大帮助。使用起来复杂，而且还得配置这个配置哪个，需要注意的地方太多。业务开发组的同事就不愿意用，还不如把代码自己直接写死了得了。超期还会影响业务功能开发组的使用。本来人家是为了想加快自己的工作效率。你答应好这个星期给业务开发组提供一个功能，但你没有拿出来。就耽误人家进度。你多次拿不出来，人家业务开发组还不如自己开发一个呢，求人不如求己。
我最后警告他：如果你认为自己技术够牛，那么你必须证明你能很快做出来。如果你认为自己技术够牛，最好能牛到，只提供一个函数就解决了他们的问题。别这个代理类，那个聚合类，这个唯一实例类。最好连参数也没有，大家调用一下写一句代码就OK。甚至你做的好，大家都不用调用你的代码，你可以包含在基础框架中，你自己去判断什么时候什么应用需要执行这个动作。如果你认为自己技术够牛，那么在业务功能需求发生变化的时候，你能够保证接口不变的情况下还能适合变化，这才你够牛。别让业务开发组的人跟着你也得改他们自己的代码，那样的设计就很烂了。
小伙听了我的话。进度保证，代码接口简洁。（摘自《走出软件作坊：走钢索的人》）
2. 坊间流传的大家耳熟能详的小故事：
话说联合利华新换了一批自动香皂包装机以后，经常出现香皂盒子是空的没有香皂的情况，而在装配线一头用人工检查因为效率问题不太可能而且不保险。这不，一个由自动化，机械，机电一体化等专业的博士组成的Solution队伍来解决这个问题，没多久他们在装配线的头上开发了全自动的X光透射检查线，透射检查所有的装配线尽头等待装箱的香皂盒，如果有空的就用机械臂取走。
不巧，中国一乡镇企业生产香皂也遇到类似问题，老板吩咐线上小工务必想出对策决之，小工拿了一个电风扇放在装配线的头上，对着最后的成品吹之，空盒子被吹走，问题解决之。（摘自 TopLanguage 上的讨论。）
因此，
正确的态度应该是：
手中有锤，心中无锤。
容我具体解释一下这句话：任何工具都有其适用范畴和前提。然而，我们在学习工具的时候由于投入很多的时间，往往在情绪上面对工具产生了太强的感情，我们既投入了时间，当然内心希望能够用上这些工具，所以就容易忘掉其适用前提，欣欣然地不管三七二十一就把黄金大锤亮出来，以显示自己的厉害。但如果我们换一个态度，仅仅将它看作我们工具箱中的又一件工具，就可以客观地评估它，视具体情况而使用了——始终别忘记自己要解决的问题是什么。Why 永远在 How 之前。
与上面对应的还有另一句话（实际上这是我杜撰的:D）：
如果你想钉一个钉子，所有东西看上去都像是锤子。
用大白话来说就是：如果你心中专注于你想要解决的问题，那么你所看到的东西就会呈现出以往你没有看到的一面。
例子：
1. 阿基米德洗了一辈子的澡，然而，只有那一次，当他想要解决皇冠密度问题的时候，想到可以利用排水体积来测量不规则物体体积（Eureka是希腊文，意为：我找到了，我发现了）。
2. 如果你也喜欢看 《Monk》 ，就会体会到把问题装在心中，甚至把自己变成问题，问题即自己的作用——当 Monk 的潜意识里面始终在寻思 How, Why, Who did it 这几个问题时，周遭环境中的一切信息都会显出另一番面目，一个平常情况下根本不会注意到的细节也能成为破案的关键，看似不相干的信息也能带来出乎意料的启发。
3. BentObjects
如果你也像我一样，习惯于经常把疑问装在大脑中酝酿好几天，你肯定会有 eureka 的体验。
或者，如果你喜欢在一段时间之内关注某个主题，你在阅读书籍资料的时候就会带着问题的眼镜，看到平常看不到的东西，作出与平常不一样的思考。
把自己变成钉子，这就是 eureka 的奥秘。
标签：企业 需求 amp 总监 组合 耦合 idt 统一 装箱
原文地址：http://www.cnblogs.com/purplefox2008/p/6064281.html
