想让技术水平提高得最快？你需要找高手，给你做几次测试验收，给你代码来个深入的点评，很容易有一次质的飞跃

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

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

 

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

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

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

 

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

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

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

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

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

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

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

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

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

  

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

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

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

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

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

 

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

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

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

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

 

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

 

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