警惕技术人员的极端性

以前一直在研究技术，没日没夜的学习，后来发现：把技术玩的转，那不算什么大的本事，把人玩的转，才是本事。看到多，接触的多，思考的多了，感触也自然多了。

很多的技术朋友，在没有搞技术之前，思维是很正常的，一旦踏入技术圈子之后，就好像失去了自我。这里说这些，没有啥意思，只是希望审视自己，看有没有这样的情况，因为自己也是花了很长的时间才慢慢的明白这个道理。

每次只要一谈技术，一谈什么问题，一提到什么解决方案，很多人喜欢反问一句“有没有最好的方法”，“有没有最快的方案”，“有没有最….”。似乎很多的人都喜欢“最”这个字眼，或许至于人类本身追求完美的天性有关，或者是被教育制度的戕害（因为凡事都有标答，或者所谓的最佳答案），或者已经习惯了说出“最”字。

很多的事情，往往没有所谓的“最”的。此时的最好，可能随着时间的变化，或者环境的改变就慢慢的开始退化，成为“次好”，“一般”，甚至“差”。

11270_200706140145041.jpg(34.12 K)

9/13/2012 7:38:44 PM

发现这样一个问题：每次想问一些包含“最”问题的时候，说明我们考虑事情就不够充分，比较的片面。是的，从单方面，单个因素来看，某个东西确实是最好的，但是把其他的因素一考虑进来，事件就开始变得复杂，很多的人就开始变得躁狂，因为他们心中的“最”已经没有了。其实这才是事情的真相：每个事情，都是有多个因素同时在影响，只是我们要现决定先考虑那个，或者如何权衡她们。

记得之前在一个项目中，时间比较早了，那时候，Linq语言和Linq2SQL刚刚出来。公司的技术爱好者一看：不得了了，有神器出来了，再也不用写一大堆的ADO.NET代码。现在只要一拖，全部搞定。完美了。

确实，漂亮的可视化界面，简单的拖拽，链式的代码编写方式，确实把技术人员解救出来了，一时间，全国上面Linq一片。但是，不久问题就出来了。后来发现Linq2SQL在更新数据的时候，有点小bug，因为总是报出“对象已经存在了”这样的错误，一时间，N多人傻了眼，于是千辛万苦在官方网站找到了解决的方法。

后来更多的人傻眼了：平时总是用所谓的三层结构开发的项目，现在有了Linq2SQL，他们不知道如何三层了：以前业务层，数据访问层，等等，搞的很清楚，现在倒好，Linq2SQL一拖，很多的实体类就生成好了，以前总是用ADO.NET一个个数据库字段赋值到业务类的字段中，现在这过程省了，很多人就直接用Linq2SQL生成的类作为业务类，很多人开始有点难受了：貌似只有两层了。

更糟的还在后面：每次只要数据库中的表和字段一改动，那么就要再去把表拖一次，而且一改动，其他的人必须要重新获取代码管理器中的代码，如果一个人出问题，其他的人都停在那里等着了。很多意想不到的问题一个个的出来把大家折腾的晕头转向，开发效率非常的低。其实这就是技术人员常常犯的一个问题：思考问题的片面性。

确实，好的东西出来，我们第一眼看到的就是它的好处，但是任何事物都是一个平衡体，带来同等的好处，那么必然隐藏同等坏处。就好像买车，可能我们已经厌烦了每天上班挤公交，平时认为花费太多的时间在路上，于是希望有辆车就好了，于是就开始想到各种各样买车的好处。但是把车买了之后，发现，油价是个问题，过路费是个问题，车位和停车费是个问题，车子的保养是个问题，还有这这那那名目众多的费用等。这个道理，在日常生活中，大家都懂，但是一到技术上面，就完全变了样，各种极端，偏执狂就出来。

201208240929248685.jpg(25.16 K)

9/13/2012 7:38:44 PM

很多人喜欢在项目中尝试新的技术，我这里也不反对，但是，在使用的同时，有没有考虑它的其他方面，如万一出错，是否有齐全的文档或者即使的官方说明。新东西的研究和学习的时间成本如何，在开发过程中对项目带来的好处是什么，带来的好处是否可以平衡它带来的不足；不同的人对这些东西的掌握是不是都在预期之中，还是说，只有少部分人掌握，其余的跟着混；这个东西在整个团队层面上面的影响如何…..

大家可能要说：你谈的这些有点偏管理了。

那么，这里就要问了：为什么硬是把技术和管理划分的那么明显，非得搞出一个三八线处理？！

平时我们在无形中也是在进行个人的管理，个人的规划。管理，是让事情尽可能的朝着目标方面走而已，把一些事情规划的清楚有条理。好好管理自己
，也是让自己朝着所谓的理想靠近，不至于让自己糊里糊涂的生活。

所以，不要认为搞技术的就不要懂管理，不要谈到“管理”就色变。其实不谈所谓的管理不管理，其实就是要大家看问题全面，思考问题要周全一些。我们平时再买个东西的时候
都要货比三家，左思右想，先观望，然后下手，为什么一到技术上面，就不比较呢？！

很多的朋友们总是问，如何成为架构师，如何成为牛人。方法千千万，但是有一点可以确认的就是：思维肯定是要开阔的。特别在做设计或者架构的时候，考虑的问题不仅仅只是技术层面，项目的利益人，投资人，时间，钱，沟通成本，软硬件条件，甚至公司的发展和业务走向都是需要考虑的。所以，可能我们平时说“我会做架构”，其实很多的时候，仅仅只是拘泥于技术上面而已，甚至说只是拘泥于片面的技术，如：有朋友以为懂得一些模式，懂得分层，就是会做架构了。其实这里架构很远很远。以前我也不懂，后来发现：学的越多，发现自己懂的越少。

所以，用平常的观点去分析和看待技术，切忌极端。一旦物极必反，自己就陷入泥沼。例如，常常看到社区中有很多的激烈的骂战，如java好，还是.NET好；再如，是sql server好，还是oracle好。这些讨论，其实意义不大，除了把自己搞的郁闷，搞的不爽之外，还有啥。

20090327203708103.gif(15.24 K)

9/13/2012 7:38:44 PM

就算骂赢了，又怎么样？！人家还是在用java，还有有人用.NET。

其实，说一个东西不好，可以给出千千万万的理由，同样，说一个东西好，也可以给出千千万万的理由。

[wallcoo_com]_TREES_0EA49086.jpg(189.52 K)

9/13/2012 7:38:44 PM

一棵树的成长必定是吸收各种光谱，才能健康成长，同理，一个人只有全面的思考问题，才能把问题看得透彻！

©著作权归作者所有：来自51CTO博客作者yanyangtian的原创作品，谢绝转载，否则将追究法律责任

职业规划 AgileSharp 技术人生程序人生

微博 QQ 微信

上一篇：如何快速的提高自己：一切取决于你... 下一篇：谈谈SQL Server高可用的...

yanyangtian

99篇文章，106W+人气，13粉丝

关注

Ctrl+Enter 发布

发布

取消

16条评论

按时间倒序按时间正序

猜你喜欢

我的友情链接这个时代会残酷惩罚不肯改变的人 Raid磁盘阵列数系列问题答疑全是干货：MBR分区结构以及GPT分区结构北京某公司IBM X3650M3存储崩溃的解决过程 6个平凡人的经历，参悟工程师的成功秘密百亿互金平台救火故事六年程序生涯

扫一扫,领取大礼包

关注

yanyangtian