引起程序员争吵的8个编程问题

最近看了一遍文章，总结了 StackOverflow 上面20个最有争议的编程观点，挑了8个跟大家分享一下我自己的一些解读。

1

业余时间不写代码的，都不是优秀的程序员

其实“业余”这个词就已经给业余时间产出的代码定性了。

国内大部分程序员多少都想搞点副业，而一身的编程技能是他们能快速利用的，常见的比如接外包。

但我所见过的大部分有副业的优秀程序员，几乎都是把业余时间写代码当成工作来做，或者说为了锻炼自己的编程技能，目的也是为工作更好地服务，提高效率。

我认为业余时间写不写代码和是否优秀并无关系，当然如果能以提升和实践的角度去不断练习，这无疑是一个对自我能力有要求的程序员。

2

只会一门语言的程序员，不是优秀的程序员

这个观点的作者提到，自己所学过的每种语言都能让他收获不同的新知识，并能把这些语言有效地结合应用。

在他看来，这是人的一种探究和试验精神的表现，优秀的程序员就应该要具备这种研究素质。

我比较认同他的观点，从国内互联网发展环境来说，程序员去学习、去适应变化是常态，java程序员学个python开发并不是什么新鲜事。

3

不要对“垃圾代码”有偏见

有时候完成一个特定的工作任务，或许一段“垃圾代码”就可以快速解决，但这种代码看起来可能是不符合规范的，或者后续无法延用的，又或者是难维护的，但它却是当下能快速解决问题的。

很多程序员喜欢花很长时间想一个完美的技术方案，但对于特定场景的短期小问题，或许也可以尝试用“垃圾代码”先解决问题。

在解决问题前，先不要带有主观偏见。

4

代码的“可读性”是最重要的

有人认为代码的可读性比正确性还重要。可读性强意味着后续维护成本低，其他人接手也能快速理解，测试和修改成本也相对更低。

常见的比如一个程序员新人入职，让他去看高级开发写的代码，大部分时候脑子是乱的，因为每个人都在各自的逻辑里，理解维度不一样，这时候“可读性”就变得很重要。

5

设计模式对优秀设计的弊大于利

人们对设计模式的记忆是有限的，但优秀设计的变化是无限的。

很多程序员习惯找一些“通用”的设计模式，试图去匹配任意场景。这限制了优秀设计的产生，代码也有局限性。

我个人比较认同这个观点，设计模式大部分时候确实是个高效选择，但局限性也源于此。

6

经验不等于技术实力

很多初级程序员认为，只要工作年限达到了，经验就有了，自然就会成为资深程序员。在他们看来，技术大佬也是这么炼成的。

但实际情况是，国内很多互联网大厂在清除“老白兔”，那些只涨年龄不涨技能的程序员，最后都要被年轻又好学的新人接替。

我之前带过的一个团队里，也有这样的“落差”存在。同是工作3年，出身大厂，985学历，但俩人的技术实力差距就是很明显，其中一人的工作性能是另一人的10倍以上。

俩人做的工作差不多，功夫主要在平时。

7

Java是大学授课的最好的“第一编程语言”

作者认为，第一种编程语言应该强调学习控制流和变量，而不是对象和语法的需要。

那些对C/C++不了解的人，也无法深入理解到Java的精髓。

拿我自身来说，我在大学接触的第一门编程语言就是C语言，从一些基础的语法到慢慢上手写出一整段代码，这个过程是很有成就感的。

大家对于哪门语言是核心语言一直争论不休，但这个本就没有定论，适合你的、你感兴趣的，就是最好的。

8

代码“少胜于多”

这几年看过不少互联网公司的奇葩操作，比如按照代码量给程序员评绩效。

这样做的直接后果就是：程序员不再致力于寻找简洁高效的实现方式，而是想着怎么把一个简单的东西复杂化，什么实现方式会增加代码量，就按什么方式来。

这样下去，技术团队会“垮掉”。代码越多，理解、修改、测试、维护等成本也随之增加，时间久了，没人敢动这坨又垃圾又长的代码。。。

要想体现工作量和工作价值，还有其他更多更好的方式。靠堆积代码，大可不必！