警惕技术人员的极端性

简介:
警惕技术人员的极端

以前一直在研究技术,没日没夜的学习,后来发现:把技术玩的转,那不算什么大的本事,把人玩的转,才是本事。看到多,接触的多,思考的多了,感触也自然多了。
很多的技术朋友,在没有搞技术之前,思维是很正常的,一旦踏入技术圈子之后,就好像失去了自我。这里说这些,没有啥意思,只是希望审视自己,看有没有这样的情况,因为自己也是花了很长的时间才慢慢的明白这个道理。

每次只要一谈技术,一谈什么问题,一提到什么解决方案,很多人喜欢反问一句“有没有最好的方法”,“有没有最快的方案”,“有没有最….”。似乎很多的人都喜欢“最”这个字眼,或许至于人类本身追求完美的天性有关,或者是被教育制度的戕害(因为凡事都有标答,或者所谓的最佳答案),或者已经习惯了说出“最”字。
很多的事情,往往没有所谓的“最”的。此时的最好,可能随着时间的变化,或者环境的改变就慢慢的开始退化,成为“次好”,“一般”,甚至“差”。

attachment.aspx?attachmentid=507


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

记得之前在一个项目中,时间比较早了,那时候,Linq语言和Linq2SQL刚刚出来。公司的技术爱好者一看:不得了了,有神器出来了,再也不用写一大堆的ADO.NET代码。现在只要一拖,全部搞定。完美了。
确实,漂亮的可视化界面,简单的拖拽,链式的代码编写方式,确实把技术人员解救出来了,一时间,全国上面Linq一片。但是,不久问题就出来了。后来发现Linq2SQL在更新数据的时候,有点小bug,因为总是报出“对象已经存在了”这样的错误,一时间,N多人傻了眼,于是千辛万苦在官方网站找到了解决的方法。

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


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

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

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

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


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

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

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


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

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

attachment.aspx?attachmentid=506

就算骂赢了,又怎么样?!人家还是在用java,还有有人用.NET。

其实,说一个东西不好,可以给出千千万万的理由,同样,说一个东西好,也可以给出千千万万的理由。
attachimg.gif attachment.aspx?attachmentid=508


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






















本文转自yanyangtian51CTO博客,原文链接:http://blog.51cto.com/yanyangtian/1058598  ,如需转载请自行联系原作者







相关文章
|
程序员
技术人员的职业规划可能是这样的??
本文有感于越来越多的阿里或者行业内的大牛开始分享职业规划这件事,还把标题写的很唬人,很多技术小白以为听了这样一节不痛不痒的课就能怎样,当然第一次听的人还是收获很大的,但第二次听就没有任何感觉了,还不如去写几行代码,睡会觉。
1445 0
|
测试技术 UED
技术人员应该如何让产品经理妥协
文章背景,来自于群内周五晚上的一次头脑风暴式的思维碰撞交流活动。活动主题由无痕哥发起。文章版权属于群内发过言的任何一位同学,我只是做了简单的梳理或整理。 1. 技术人员了解产品这个岗位所需要做的事情,然后试着从产品的角度出发,考虑当前页面功能的真实需求,挖掘更深层的可扩展需求,从而在另一个方面去引导产品。
1012 0
|
安全
像黑客一样思考,像安全专家一样做事
本文讲的是 像黑客一样思考,像安全专家一样做事,用不同的视角看待问题,安全威胁也会不同。我们在对应用系统进行安全构建时也是如此。
1419 0

相关实验场景

更多