一个程序员的水平差，那到底能差到什么程度？
一个程序员的水平差，那到底能差到什么程度？元芳你怎么看？
当我们还处于菜鸟阶段，我们是这样的：别人分给我们什么任务，我们脑海中第一意识就是快速思索想着这个需求具体该用怎么技术实现？
更谈不上说站在产品经理的角度去思考（产品经理的需求不一定合理，他也有思维盲区），这个需求本质是要解决什么问题（满足企业服务的用户Or满足公司运营管理？），哪些功能点可做，哪些可做可不做，哪些功能纯粹是产品自嗨。
实现功能的时候，我们要么无脑的用别人已经搭建好的框架和具体对应技术，去堆代码。（谈不上设计，一上来就开始撸代码）
但当有一天你拿着这个项目，去参加面试，面试官问你：为什么你们要用这个技术？你被问得一脸懵逼，来一句是项目经理让用这个技术的，其实质是自己缺乏思考的表现。
有一些程序员喜欢用一些所谓的“高大上”的技术去炫技，很简单的应用场景硬是想着要引入什么某某中间件或框架、项目中业务场景没那么复杂却到处可见各种设计模式味道、方法内部各种线程池跑任务，引入什么DDD骨架结构等）。
殊不知在没流量、项目复杂度低的背景下，引入这些个所谓的中间件，用所谓的设计模式、所谓的领域建模去分析、组织代码，前期会给我们的项目带来非常大的复杂性，需要多出更多的时间去开发和维护。
如果业务的复杂度低，流量也少，传统的MVC架构搭配最简单的SSM框架简直就是香饽饽。
先把东西做出来，快速实现交付，这才是王道。我们要相信架构一定是可以迭代、演进的。
最后给大家贴一张“达克效应”图，想要说明的是，菜鸟程序员与那些你认为很牛的大神程序员本质的差距其实很多时候就是“认知”层面的差距。
最可悲的是什么？是你以为自己很牛逼、无所不知，但其实自己只是一个井底之蛙，碰到比你厉害的人抛出的理论或观点，自己什么都不懂一头雾水，一直停留在“不知道自己不知道”的阶段。
所以我们才会需要不断的学习，多问多请教比自己厉害的人，平时也可以多看看一些优秀、经典的技术书籍，去不断升级打破自己的认知...
OK，以上我发表了自己对于菜鸟程序员的几个认知与拙见，希望大家希望。
接下来，分享三则我们可爱的知友关于这个问题的精彩答复，灰常精彩，一定看到最后哦。
故事一
想起了一件十多年前的往事，有一次帮客户的Java项目组升级框架。入场之后屡次听到项目组的运维小哥抱怨war包过大，导致每次发布要等很久很久，用过WebSphere的童鞋可能知道我在说什么。
那么，这war有多大呢？接近2G！！！？？？富有求知欲的我于是下决心去研究下这鸽子，，不对，这war包为什么这么大？草草一挖，果然就在里面发现了宝贝。
原来war包里还藏着两个程序安装包。一个是JDK1.4；另一个是PES2006，，，，实....实况足球？！
根据SVN的提交记录，肇事的大哥很快就被找到了。
据说是在一个月黑风高的晚上，几个还在加班的码畜临时起意，决定一起找点乐子解解乏。这位带头大哥为了方便把自己的游戏分享给小伙伴，就想到了把它先提交到SVN上这样一个天才的主意。。。。
当然，按照他原本的计划，这个文件应该随后被删除的。。。可是，那晚他们玩的实在太尽兴了。。。。没人会料到这个文件竟会悄无声息的溜进war包，一路潜伏到生产环境，然后反反复复的摩擦了可怜的WebSphere和运维小哥近一年。
了解到真相之后，运维小哥表情差不多是这样的：
故事二
刚入职不久，组里的尼泊尔大哥离职了，我接了他的活。第一天就被三万行的文件震惊了，一个文件里有几十个class，命名不规范，缩进随心所欲，这些就算了。
这位大哥明显不知道什么叫做继承，写子类的办法是把父类复制过来再改一改…
后来我面对着三万行被重复定义了五十多次的变量和函数，果断选择重新写了，最后用了一千多行就写完了…
这个活作为我入职的第一个项目，给了我非常深刻的教育…
故事三
2020/02/27 更，出于大部分工程师都有的追求卓越的情节，我已经把1/2两个坑全踩了....准备找下家了....
我这代码写得真好......，把我自己都写没了
——————————————————————
有时候，水平差只是表象.....
