聪明的程序猿和2b程序员的区别

接到产品需求后

聪明的程序猿：在接到需求后，聪明的程序猿会问为什么，会花大量的时间通盘考虑所有可能的解决方案和途径。这可以看作是延缓写代码，在没有完全理解问题前绝不动手写代码。先把问题理解清楚，确保将要写的代码能真正的解决问题，这将会避免之后写出大量无用的代码。（即懒惰式开发）

2b程序猿：喜欢立刻冲上去编程，喜欢在电脑前不停的敲代码，100%的时间都在盯着屏幕。（然而，《程序员开发效率悖论》说，在真正的软件开发中，只有5%的开发时间是有效率的）

面对烂代码

聪明的程序猿：如果代码整体上好的，那就重构代码。如果代码整体上有问题，那就重构代码。（追求完美！）

2b程序猿：不喜欢去修改已经写成的烂代码。相比起优化自己的代码，他们更愿意简单的增加更多的代码，以此来弥补之前的缺陷。

面对API或SDK接口的态度

聪明的程序猿：快递调用成熟的PaaS平台接口代码，自主开发集中在产品的主要功能上，比如短信验证码这种通讯小事就交给云之讯，节省开发时间十倍以上

2b程序猿：自己写通用代码，浪费开发时间。

沟通方式

聪明的程序猿： 喜欢分享，清楚跟团队中的其它程序猿或其他团队中的程序猿需要那些交互，如何交互。他们经常使用白板交流、画流程图(UML或Visio)与其他成员交流。

2b程序猿：不喜欢沟通，喜欢闭门造车。

对待下属的态度

聪明的程序猿：喜欢夸下属聪明，以此提高下属积极性，从而达到自己的更高目标。

2b程序猿：喜欢别人夸自己聪明，不懂得分享。

对其他部门同事的态度

聪明的程序：很谦虚，认为营销、市场、管理人员同样不简单，可以很好的和他们合作。

2b程序猿：非常自负，觉得自己很优秀，认为自己可以ControlEverything。

面对挑衅

聪明的程序猿：莞尔一笑，不会被对手激怒，用产品市场效果说话。

2b程序猿：容易恼羞成怒，喜欢一比见高低。

学习态度

聪明的程序猿：会 看书，会思考，会不满足，会努力提升自己，会经常浏览高科技公司的博客（Netflix Tech Blog，Oracle OTN，AWS Blogs，IBM Emerging Tech Blog）、浏览高科技公司的开发者网站（如Facebook for Developers，Twitter Developers，Amazon AWS）、在问答网站提出问题（如Quora，Stackoverflow）、在MOOC网站（Coursera，Udemy等）或YouTube频道学 习。

2b程序猿：一有时间就打游戏，看毛片。

对未来另一半的选择

聪明的程序猿：有情调，懂生活，寻找性格匹配的另一半，毕业没几年就过上老婆孩子热炕头的生活。

2b程序猿：生活在自己的幻想中，梦想有一天能找到一位天仙作为老婆，至今仍形单影只。

身体状态

聪明的程序猿：有一个长期的健身计划，并坚持实施，用健康的心态迎接任何挑战，创新方法来做事情。

2b程序猿：所有的时间都有在了电脑上，没时间锻炼身体，越来越胖，没时间收拾自己，在别人眼中头发永远都是油的…….

程序员老师傅的解决问题能力要比初级甚至是普通的程序员都要高出很多倍，所以每个软件公司都会在保留1,2个经验丰富的资深级软件工程师，这样在遇到项目或者产品难点的时候能够力挽狂澜，这种水准的程序员也是很多公司追求的对象，而且和年龄没有太直接的关系，编程最终的就是给出解决问题的方案，从解决问题的角度出发解决方案还是非常多，但是在不同的人会给出不同的解决方案，但是有经验的程序员在解决问题的时候就会思考的比较多，不容易导致引入新的问题。

编程能力最直接的表现不是写代码的能力，因为随着时间的推移时间积累够了代码能力自然就上去了，很多程序员在工作多年之后虽然代码能力得到极大的提升，但是还是不具备独立的框架或者功能复杂的模块设计能力，所以很多人在工作多年之后工资一直不能得到上涨，这是主要原因编程的关键还是思路问题，关键点还是在于有正确的解决问题的思路，思路的切实性是需要经过项目实战的积累。

所以优秀的程序员一定是身经百战的经历过项目的洗礼，只有经历过项目才能真正意义上懂得编程是怎么回事，而且每次经历的项目都能够获取足够多的营养出来，越是优秀的程序员经历过项目之后知识体系构建越是完善，越是老程序员越是觉得程序深奥之初，所以老程序员轻易不动手都会思前想后把事情搞明白之后才去真正动手，所以讲老程序员真正动手写代码的时间还是非常短，大部分的时间都是在构思其可行性，真正动手的时间会非常短所以大家看到老程序员大部分的时间都是在看代码或者看一些资料，甚至有些人很少看到老程序员在大块的时间写代码。

越是老程序员对于编程语法看的越是淡薄，编程语言到了一定层面就是工具般的存在，就是为了编程思想服务，如果还在为了编程功能实现代码而烦恼证明了还在初级的学习阶段，度过了这个阶段之后就要考虑如何驾驭架构以及如何锤炼自己的编程思想了，编程的学习过程是需要循序渐进的不要觉得距离自己老程序员有非常遥远的距离，从开始入行就要慢慢去积累不断打磨自己的思想，希望能帮到你。

25年老程序员，20年CTO，来解答一下：

1、经验、教训使然，所谓亏吃多了，也就不吃亏了。

2、长久工作，养成了一定良好的习惯。

3、代码量到一定程度，自然而然会更熟练。

4、一些非技术的经验知识，还是需要时间来积累。

5、老程序员的思维经过多年的训练，更有利于直达本质。

6、他们的方案可行性更高，这样减少返工。

7、代码质量高，测试通过率高，考虑的因素更周全。

8、代码改起来更容易，找问题也相对容易。

9、对任务的理解更全面，能够从更多的角度去设计程序，权衡效率、速度、性能、扩展性等各方面的因素。

10、也不是所有的老程序员都能这样，这个还是跟这人的学习能力有关系，所以大家是能3年变成老程序员，还是10年，就看自己的个人努力了。

在IT编程开发的过程中，老程序员开发的效率会非常高。比如：一个网站模板，新程序员可能要花上一个星期的时间才可以完成，而老程序员却可能只需要1-2天就可以做好。这是为什么？莫非他们天生就有神相助。非也，这所以会这样，据我分析，主要有以下几点。

1、经验丰富。

因为长期的编写代码，所以，会碰到非常多的问题，然后就会去解决这些问题，这就让老程序员有了丰富的实战经验。反观新程序员，碰到一个问题，因为以前没碰到过，所以要花大量时间去解决。而老程序员碰到问题，因为以前解决过，所以，很快就会弄好。

2、做好记录。

在IT编程中，很多的代码都是可以用来搬运的。因为长期的工作，老程序员会把一些功能代码记录或储存下来，以备后期使用。也就是说，他们就像记笔记一样，把一些功能代码记下来，以备不时之需。所以，在新的编程中需要用到时，他们就可以直接拿来就用，自然效率就高，开发就快。

3、良好习惯。

老程序员在编写代码时，一般都会对代码的规范和格式比较重视，使用代码清晰有条理，阅读代码时就不费力气，而且还会做好每个功能代码的注释。这样，不管是对现有开发，还是对后期维护，都是非常有利的。如有代码出现bug，可以很容易地找到，这同样节省了大量的时间。

4、有大局观。

老程序员在编写代码时，会先从大处着手，把大的框架给弄好，然后，再对整个编程的细节有针对性地编写。这就好比开发一个高楼大厦，开发商会先把主体框架搭建好，然后，再一层一层地去弄每一层楼的细节。这样，往往目标会更加清晰，只要按步就班地执行计划，就可以很快完工。

熟能生巧

为什么老程序员的效率如此高？

首先， 敲代码的效率 != 工作效率

并不是老程序员效率就高，而是程序员要提高效率需要一些方法，这些 方法的学习和掌握需要一定的时间 ，结果就是老程序员的效率会相对要高一些。

所使用的编程语言的熟练程度

我经常会看到一些新手程序员在写代码的时候需要频繁的去查看文档或者是百度搜索各种接口的用法，有时写一个功能要查个几十次，很多时间都浪费在了搜索上，真的写代码的时间很少。

而一个在这门语言浸淫了几年甚至是十几年的程序员，对这些接口了若指掌，使用的时候信手拈来，还知道接口里面的实现机制，可能会碰到哪些坑也一清二楚，减少了很多bug的出现。

你是不是有把那些接口拿出来反复琢磨，去研究它的源码，认真地了解它呢？

对编程工具的掌握程度

工欲善其事，必先利其器。

一个好的编程工具有很多可以帮助程序员减少工作量的功能，比如代码重构、自动格式化、语法检查、代码提示和补完等等，掌握这些也能大大提高开发效率。

随着IDE的发展和进步，现在很多工具都不需要太复杂的学习就可以 *** 作，所以这个是一个投入小而回报很高的事。

业务需求的熟悉程度

代码是为业务服务的，我们首先得理清楚业务逻辑，才能知道要怎么写代码，而新手对业务不熟悉的时候，光是弄明白业务需求是什么可能都需要不少时间，有时候还可能会错误理解需求，导致写出的代码文不对题，只能重写。

所以多思考，多问，多讨论，不会花太多时间却会减少很多时间的浪费。

调试的效率

写出来的代码还需要经过测试，如果有bug就需要调试了。

很多新手只重视写代码的工作，对于怎么调试却忽略了，有的人甚至只会使用打印功能一步步通过排查找bug，并且对写出来的代码没有概念，连bug大概可能在什么地方也不清楚。

老练的程序员不只是靠打印，有时候只看报错信息就能知道bug大概在什么位置，配合上打印还有断点功能很快就可以找到bug的位置，更不要说他们很清楚怎么写出容易调试的代码。他们会在写代码的时候就对可能出问题的边界条件进行检查，并且会利用自动化测试来减少工作量。

写代码之前的构思

新手很容易犯的一个错误就是拿到功能需求马上就开始写代码，可能写到一半会发现前面的代码有问题需要推翻重来，或者是写错了方向。

老程序员写代码之前会先进行构思，把功能需求拆解，分成不同的小模块，甚至会在纸上把这些想法画下来，基本上在这一步就把问题已经解决了，写代码只是把解决方案用代码表达出来而已。

所以，如果你也想做一个十倍程序员，记得不要只是埋头写代码，还要刻意去练习这些提高效率的好方法！

在写代码前，代码差不多已经刻在脑子里了，写代码的时候，总觉得双手敲键盘的速度赶不上脑子的速度，写出的代码几乎不需要调试，你说效率高不高？

因为老程序员经历多了，一些常规性的BUG基本不会出现，对用户需求也能做到最大的完善，还有对需求增加和修改有个大概了解，会提前预留接口和模块，还有对用户的硬件有了解，在程序上会有相对优化。所以老程序员写的程序不一定美观，也不一定最简化，但是可能是最合适的，可惜中国的程序员刚成熟就要面临失业。年轻的程序员啥都不懂，片面追求性能，美观简洁的程序，在兼容性和实用性上大打折扣，不顾用户的使用情况和硬件情况，项目一上线问题多。

老程序员分为两种，一种是年纪老，常常被换做“老X”，一种是能力老，常被人换做“x老师”。

老程序员之所以效率高，离不开几点：

程序员是一份高强度的脑力工作，能成为老程序员者，智力，体力无一不是同龄人中佼佼者。能够更加效率的工作自然是理所应当，方符合家有一老，如有一宝的普世价值。

祝广大码农早日修炼成为这样的老程序员。

老程序员，码代码速度并不见得比年轻人快。但老程序再面对需求时，能很快抓住技术关键点，难点，重点，如何突破都了然于胸。当出现问题，老程序员有经过实践的诊断定位排错的逻辑思路与手段 。其实这些熟能生巧是一方面，学习与实践 领悟是另外的方面。年轻人观察能力强 悟性高，也会青出于蓝

老成员就是图书馆，硬盘存满了各种经过调试且运行过的程序，只需要复制粘贴，效率肯定高

不过，最近Shahar Yair和Steve McConnell指出了该方法的一系列重要缺陷。首先，使用代码行数之和无法有效评估一个项目的实际进度，因为它更注重行为而不是结果。最终产品在多大程度上依赖于代码的性能和质量，这也是代码行数无法说明的。因此，聚焦于此实际上是非常有限的工作效率测量方式。

SLOC无法表明要解决的问题的复杂性，也不能以可维护性、灵活性、扩展性等等因素来说明最终产品的质量。说到质量，它反而可能起到负面作用。通过重构、使用设计模式会减少代码行数，同时提升代码质量。代码量大，可能意味着有更多不必要的代码、更高不必要的复杂性、更加僵化难懂。

他指出，有些问题可以通过测量度量功能点数解决掉。那么决定程序大小的因素就变成了输入、输出、查询和文件的数目。不过这种方式也有其缺陷。McConnell提出一些 *** 作性上的问题，比如必须要有一个大家认可的功能点测量机制，而且要想把每个功能点映射到程序员身上也不容易。Daniel Yokomizo是一位经过认证的功能点专家，他在评论中明确指出了这种方式的其他问题：缺少测量功能点复杂度的工具；还需要考虑诸如代码共享、框架、程序库之类的事情。这些都会影响到完成一个功能的时间。

有很多人参与了对于测量方式的讨论，他们都同意这些做法有其局限，不过他们都觉得衡量开发人员的绩效还是有必要的。实际上，不少人认为SLOC可以作为基础，在其之上通过考虑多种不同因素来进行更复杂的分析。McConnell提出了四条分析开发人员工作效率的必备指导原则，他们也都同意。这四条原则如下：

1、不要指望单一维度的工作效率测量方式能告诉你每个人的真实情况。

2、不要指望任何测量方式可以在很小的粒度上区分出每个人的工作效率差异。这些方式可以为你提出问题，却不会告诉你答案。

3、牢记：趋势总是比单独一点的测量来得重要。

---