一方面是我们技术不行、另一方面很可能没意识到自己不行,到底哪里为什么不行?到底怎么做才算好? zhuan zai

我们国内的程序员大多都不擅长交流,虽然擅长学习,但是大部分人的提高都不太明显,很多工作5年的人与很可能与工作1年的人水平没有本质的差别,很多人工作了好几年,大多都是在原地踏步徘徊不前,甚至是会感到迷茫。

   我们大多是喜欢看技术文章,不喜欢把自己的代码拿出来交流,让高手看看,说百了,高手也懒得看那些菜鸟代码,所以你得求人家看才是,因为大师给你代码来个点评,你就能知道,你的能力差距体现在哪里?哪些没能注意?

 

   菜鸟画个鸡蛋也可以画得很好,大师画个蛋不是行家也是看不出很明显的差距,都是椭圆而已,这时候需要大师来给你讲解,你画的蛋问题在哪里,我是怎么画的蛋?

   为什么老外写的软件,特别是德国人写的软件质量蛮好的、思路严谨,为什么我们写的软件,大多是粗制烂造的?

   一方面是我们技术不行、另一方面很可能没意识到自己不行,到底哪里为什么不行?到底怎么做才算好?

 

   以前我写程序,感觉很无敌了一样,一时间好像自己无所不能一样。

   见了老外的开源项目后,才明白过来,什么叫架构

   见了资深博士后的设计数据结构,才明白过来,什么叫数据库设计,什么叫先有设计,后有实现。  

   见了日本外包的规范检查,我才意识到,什么叫规范,变量名、排版、函数名、表名、字段名,甚至命名空间的引用顺序都需要注意。

   见了日本外包的测试用例、覆盖率测试、页面测试、性能测试、并发检查、压力测试、才意识到,什么叫测试

   见了大师同事给我点评代码,才意识到,设计模式的重要性。

   见了大师同事给我点评代码,才意识到,职责分明的重要型。

   见了大师同事给我点评设计,才意识到,UML用例设计的重要型。

   见了大师客户的需求分析,才意识到,数据流程的重要型。

  

   很多时候,全靠自己学习掌握,真的太不现实了,让别人点评一下,

      代码哪里不行?为什么不行?

      数据库设计哪里不行?为什么不行?怎么改进才行?

      并发控制哪里不行?为什么错误?原理是什么?

      我的日常开发哪里不行?怎么样做才是对的,能把道理讲清楚、能讲得心服口服,开发人员都可以飞跃一次,突破一次。

 

   1. 骄傲牛B型的、目中无人型的、自以为是的程序员,一般比较难得到快速提高,因为别人懒得跟你交流。

   2. 听不进去别人的意见建议的,总觉得自己的对的,甚至不想听别人讲的,总想抢着想讲自己观点的,一般比较难提高,因为别人懒得跟你争。 

   3. 埋头自己研究的、 也不关心别人,天天自己闭门研究的,一般需要研究个10年8年后才能研究透的,一般比较难提高,世界很大,很多问题别人早就解决好了。

   4. 最可悲的是,工作生活中,没遇到大师,没遇到高手,想交流,想切磋都没办法的,只能靠网络东学学西学学,再买几本书看看,系统掌握知识不容易。

 

    自己研究个啥明堂出来很不容易,通过有效的沟通交流,经过大师的讲解、解惑,可能只需要花费1/10的代价,1/5的努力,就可以达到同样的效果,最要命的是,大多内功修炼不够的家伙,冒充是大师,瞎指挥、瞎讲解、本来还不是很懂的,经过指点,更糊涂了,哈哈,就像我。

 

    拿来主义往往是见效最快的,有效的沟通交流,比自己努力强5倍以上是有的。现在我们整个国家都处于拿来主意、改革开放,开展全球性的合作交流,所以我们国内的程序员也需要更多的是拿来主义,更多的是“有效的沟通交流”, 别天天闷在哪里,只知道埋头写程序,多交流多沟通不会有坏处,天天交流,不干活儿,也不行,程序总不会靠吹能吹出来,还需要静心写一写,但是别忽视了沟通交流的重要性。

posted @ 2010-04-07 15:14  大树2  阅读(221)  评论(0编辑  收藏  举报