文章出处：http://www.blogjava.net/cenwenchu/archive/2009/12/08/305083.html
其实想说这句话很久了,和很多同事接触,有时候或多或少的都会发现大家会陷入在自己的一亩三分地里面。
主要表现得症状：
1. PD的需求就是目标，踏实的实现，不懂的就猜。
2. 经验盖过一切，设计系统就是要够完备够复杂。
从开发人员角度来看
第一种人多半比较有自己的想法，同时也有不少的工作经验，同时可能对技术比较着迷。
另一种人多半是刚刚工作或者经验不足，要么就是习惯性把工作当任务，而不是爱好，写程序也就是一份赚钱的活。
但看起来其实各自都在自己的一亩三分地上捣鼓，忘记了作为一个开发人员最基本的原则：“满足客户需求”。
先说1类型吧，在我们的Team有一个刚毕业一年多的同学，很勤奋，不论从学习以及工作，实实在在，踏踏实实。我们这边来需求，通常大需求我们都会全体过一下，一些小点的需求他就自己考虑一下就作了。那天正要上线，突然说了一下设计修改的内容，发现不仅满足不了PD原有的需求，而且给系统带来了缓存暴增的隐患。然后找来PD一谈，其实他要的功能已经在现有系统中已经实现，只是需要做部分的修改，而不需要新的去建立一套机制。这样的情况其实在前前后后出现了不少次数了，但其实一直没有和他细谈。后来我下班时候和他一起回家的时候说：“很多时候， PD为了让你理解，从开发的角度想要去描述一个需求，但其实最终失去了他自己想要的东西。因此对你来说第一步不是急忙的去考虑如何实现PD的想法或者和他争论他的设计是否合理，而是需要先问他：你想要什么，想要实现的东西最终目的是什么，能满足客户的什么需求？当他能够说清楚他想要什么，也知道要的东西能给客户带来什么价值的时候，我们再回过头来看，究竟应该怎么做？”
这其实和我每次和同学分享一些设计的时候步骤是一样的，首先为什么要这么做，然后才是考虑如何从我的目标去寻找行动的方法方式，不然你会发现你和别人讨论了许久的东西，实现出来的时候已经背离了你的目标很远。
因此在做任何需求或者设计的时候第一个问题就要问自己为什么要做，作的过程中时刻要记得我的目标是什么。这让我想起了我在离开阿软的那些日子和王坚博士谈话以及听他的一些对于设计的理念，很多时候还没有到规模化的情况下，先解决客户的需求，在解决客户需求以后，逐步的去考虑规模化问题的设计。（当然不是说第一版设计就可以随便作，良好的基础能够提升后续改进的速度）。
2类型的就比较多了，其实是很多开发人员的通病，包括有时候我自己也会陷入这样的误区。通常情况下有两种场景会陷入这样的误区，同时当事人却又不愿意改变。
第一种情况就是觉得自己有不少的经验，同时对技术很执着，希望设计出来的都是很完美的，一次发布就可以满足个1，2年，但其实从这些年的设计角度来看，首先系统都是不断迭代进化的，因此一步到位的说法基本上不靠谱（除非就是一模一样的场景代码重复使用），其次系统的架构要做的足够灵活，通常情况就需要先做核心功能，预留出足够的空间和切入点，这样对未来扩展和需求变化有足够的适应度。
从这两点来看，其实设计初期就是要求找到客户最想要的，扩展可以实现客户可能要的，防范客户没有估量到的。但这其实就需要和我们的产品设计师有充分的交流，好的产品设计师不会告诉你怎么去实现，但是他会告诉你我想要的是什么，这些能给客户带来什么，这时候你可以告诉他我能够通过什么方式来满足你的需求。这样的开发和产品设计交流的结果才是技术化的产品，大家各司其职，同时也通晓对方领域的一些情况，对对方领域的只能给出建议，不是指导，这点在TOP我很庆幸有很好的黑羽同学，我们的交流就是这样产生良性互动。
这有点撤远了，刚才说了第一种场景，然后说说第二种场景，就是初期其实大家都没有明确细节，但是在实施过程中开发人员会根据自己的接触面来选择一些技术和架构设计，最后看起来很复杂，很完美，但其实越是复杂的设计背后有越多的隐患。但是此时因为已经设计好了，就不愿意再去简化，也不愿意听任何人的意见，其实这是很危险的。我过去也犯过类似的错误，但是其实当你冷静下来，想想那句话，我们的目标是什么：“满足客户需求”，这时候你就会考虑，这么复杂的系统会不会给客户带来更多的不稳定以及复杂度，其实客户不关心你背后如何实现的，但是你需要满足客户的最基本的需求，用起来方便，高效，实实在在提供了解决问题的手段。
今天下午面试了一个外部的同学，工作年限比我长，看了简历也经历了很多项目，同时在描述的时候写了对高并发，分布式等等都很熟悉和热衷，我开始看了简历就担心，可能我这边不一定要他，因为我怕他开口就是说一大堆如何做高并发和分布式的内容。
在我看来如果你没有搞清楚你什么时候要用牛刀，什么时候要用剪刀的人，和你谈论牛刀的构造其实没啥意思，因为在我看来，技术只要你肯花时间去学，没什么学不到的，但是做事方式和项目设计经验却是长时间积累的。幸好今天和他一谈，他对于技术的态度以及架构设计的思想都和我想的比较接近，不是为了技术而技术，不是为了过程而过程，了解如何从简如繁，再从繁入简，最终能够找到自己的目标。
当然后来还是谈了很多技术细节的问题，毕竟干活还是要一个好手，作了那么多年如果没有经验和技术积累也是很可怕的事情。最后我问了他两个问题：
1.你学习一个新技术的过程是怎么样的？
2.你和你同事如果在设计方案上有冲突你怎么解决？
他告诉我他学习新技术首先会去考虑这个技术的特点是什么，和其他技术的差别，他的擅长领域是什么，这样才能够用到实处。
第二个问题他和我说就是开会讨论，最后大家群体决定。
我对他第一个问题感到很满意，因为我就需要这样的同事。
第二个问题我给了他一个建议，其实在很多时候，将别人的架构设计的优点融入到自己的设计中，不再以方案作为边界，那么大家最终就很容易达成一致，因为你在接受别人的思想时其实能够看到自己的不足，同时对待别人不是用否定的态度，会让你更容易得到认可和接受。（这点作起来需要不断的改变程序员自身的好胜个性，我起码还是出于变化中…）。
我记得我小时候上政治课的时候，老师给我们划分了三种人：
1) 有能力但是没有道德的人是危险的人；
2) 没有能力但是有道德的人是对社会无害的人（觉得像葛优说的那个对社会无害的海龟一个概念）；
3) 有能力同时也有道德的人是对社会有益的人。
我觉得其实程序员也就可以从两个纬度看：
1) 有能力，有经验，对技术有追求
2) 对产品化和客户没有任何感觉
拥有了素质1但是没有素质2，那么最多也就只能说是试验室的花朵，在大学搞搞研究还不错，实际要做出产品来可能就是纸上谈兵，好钢始终用不到刀刃上，有力没地使。
素质1有所欠缺，素质2很明晰，对自己目标不断追求，其实这样的人，有时候笨鸟也会飞的比聪明的鸟更高。
拥有1，2的人，当然就是最好的人，只需要学会做人那么就可以发挥自己的能量。（程序员有时候就是很难改变自己的个性，去学会如何沟通和理解）。
最后一类就是自以为有1和2的人，这类人最怕就是面试的时候被考官通过，那么后续的问题就大了。
说了这么多，其实也无非想说出一个程序员这些年的经历，从做开发到做基础平台，到做业务平台，该怎么踏实做事，该在什么时候找到自己的瓶颈，该在什么时候改变自己的状态，都需要自己好好的让自己冷静下来想想。
做基础平台需要耐得住寂寞，同时也要知道自己是有客户的，服务不好客户，那么基础组件平台就是玩具。
做业务平台需要学会去分析和沟通，需要去了解每一个层次的设计如何协作，同时在兼顾业务需求的同时满足隐性需求（稳定性，可用性，响应速度，规模化等等）。
但归根到底，能给开发人员不断能量的不是技术本身，而是你用技术给你的客户带来的价值，对你的认可是长期做事的一个最基本的动力，因为当你现在觉得纯做技术能够支持你不断向前走的时候，其实在不远的将来你会体会到原来过程和目标是同样重要的。
走出自己的一亩三分地，给自己多一点的空间，会让自己看得更远，走的更高。