每个程序员都应该知道哪些最基本的常识？

Quora平台，可以看成是美国的知乎。在Quora平台上，曾经有人提出过这样一个问题：

What are some of the most basic things every programmer should know？

每个程序员都应该知道哪些最基本的常识？

这个问题只有64个答案，并没有很多人愿意给自己的答案。排名第一的答案7.9k点赞（up-vote），来自一位有故事的光头大哥（文章附录有分享他的故事），2017年写的；排名第二有1.6k点赞，来自新加坡公司PropertyGuru的高级软件工程师，也是2017年的答案。其他的答案点赞的很少。所以我们就看看前两名的答案吧。

光头大哥的答案

光头大哥的答案共25句话，附上原文、译文和一些评论。

1. 

If it's not tested, it doesn't work.

如果没被测试过，那它就不能正确运行。

评：测试自己的代码是一名程序员的基本良心。

2. 

Source control is your friend - make sure you use it.

代码版本控制是你的朋友——请确保你使用它。

3. 

Just because you wrote it doesn't mean you own it — don't beoffended if someone else on your team has to change your code.

仅仅因为你写了代码不代表你就拥有它——如果你团队里的其他人必须更改你的代码，请不要生气，感觉自己被冒犯了。

4. 

Don't reinvent the wheel, library code is there to help.

不要重复制造轮子，库代码就是为了这个存在的。

5. 

The fastest code is code that's never executed — look for early outs.

最快的代码是从未被执行的代码——查找早期的输出。

6. 

Just because you didn't write it doesn't mean it's crap.

你没写过这样的代码不代表这是垃圾。

7. 

Source code is just a hint to the compiler about what you want to do, it won't necessarily do it (e.g. You might declare a function as inline but the compiler doesn't have to obey).

源代码只是提示编译器你想做什么，但它未必会去做。例如，你可能声明了一个内联函数，但编译器未必会服从。

8. 

Code that's hard to understand is hard to maintain.

难以理解的代码也难以维护。

9. 

Code that's hard to maintain is next to useless.

难以维护的代码近乎没用的代码。

10. 

“Whilst I'm editing this file I’ll just…” is a great way to introduce feature creep and bugs.

“下次我编辑这个文件的时候，我就会……”，是一个引进功能退化和bug的好方式。

11. 

The neater your code layout, the easier it is to read. The easier it is to read, the easier it is to understand and maintain.

代码布局越整洁，就越容易阅读。越容易阅读，就越容易理解和维护。

12. 

Code is not self documenting. Help others by adding comments to guide them. You may understand it now but what about in 5 years time?

代码无法自描述。请添加注释去帮助别人理解。再说，你可能现在还能理解，但五年之后呢？

13. 

Bad Code can and will come back to haunt you.

糟糕的代码会回来困扰你的。

评：珍惜生命，别留下糟糕的代码。

14. 

There is no such thing as a 5 minute job. It'll always take at least half a day.

哪有5分钟的工作！？这至少要花半天的时间！

评：人间真实。

15. 

Magic numbers are bad.

使用"神秘数字"不好。

16. 

Constants don't take up storage, they're compile time text substitutions.

常量不占用存储空间，它们会在编译时文本替换。

17. 

‍‍‍

Project management will always want you to do twice as much in half the time.

项目管理总是希望你用一半的时间做两倍的事情。

18. 

If there is a bug, the user will find it.

如果有bug，用户会发现的。

19. 

A code review is not a criticism.

代码审核不是批判会。

20. 

It's not the quantity of code that matters, it's the quality. Any idiot can bang out 40kloc but that doesn't make it fit for purpose.

代码数量无关紧要，重要的是代码的质量。任何一个白痴都能敲出4万行代码，但这并不意味能适合于目标。

21. 

The true cost of poorly written code is in the maintenance.

写得不好的代码的真正成本在于维护。

22. 

Eat your own dog food — fixing bugs in your own code helps you code better and improves your understanding.

使用你写的dog food——修复你自己的代码能帮助你更好地写代码和提高你的理解。

23. 

Code rots over time.

代码会随着时间腐烂。

24. 

If the user didn't ask for a feature, don't add it.

如果用户没要求某个功能，那就不要添加它。

25. 

If it's not tested, it doesn't work (yes, I know I've included that twice but it's really important).

如果没被测试过，那它就不能正确运行。（是的，我知道我说了两遍，但它确实重要。）

---

光头大哥作为老派程序员，虽然转行了，但观点还是挺接地气的。

我们接着看第二个答案，感觉来自一位从业3-5年的程序员。

1. 

Your code will never work the way you want, the very first time you code it up. Accept that. Move on.

刚完成代码的时候，你的代码永远不会按你想要的方式工作。请接受这个情况，并继续请进。

评：所以，写完代码必须自己先测试。

2.

Frustration. That’s your best buddy from now on. Get to know each other well.

挫折，从现在开始是你最好的朋友。请相互好好认识了解。

3. 

If patience is not your virtue, well ... better make it one! You are going to need it a lot.

如果耐心不是你的美德，好吧……你还是最好拥有它。你会非常需要它的。

4. 

Debugging. Learn it soon. Coz you shall be spending more time debugging than coding. If only there is something that converts our designs into bug-free code…

调试。你要快些学习它。因为你将花费更多时间在调试而不是编码。要是有什么东西能把我们的设计转换成无bug（bug-free）的代码就好了……

5. 

Stay out of the battles like Tabs vs Spaces, Vim vs Emacs, Windows vs Linux, C++ vs Java vs Python, Atom vs Eclipse vs Sublime vs … X!

远离技术选择优劣对比的战争，比如Tabs vs Spaces, Vim vs Emacs, Windows vs Linux, C++ vs Java vs Python, Atom vs Eclipse vs Sublime vs，等等。

评：没有最厉害的技术或工具，只有自己当下最合适的技术和工具。

6. 

People are going to look upto you to help them code. And look down at you to fix their PC.

人们会指望你来帮助他们编码；然后，他们低下头看你在修他们的电脑。

7. 

Do not bother with premature optimization. If people can code in languages like Python, a few microseconds shaved off, is not that big a deal.

不要为不成熟的优化而烦恼。如果人们会用Python之类的语言去开发，也就省下几毫秒。这没什么大不了的。

---

读完之后，你认同这些观点吗？

整体来说，我觉得他们的观点都挺好的，接地气。从质量和范围看，光头大哥的略胜一筹。

我的答案是什么？

过去写过《平凡却又深刻的编程理念》系列的文章，算是当初我能给出的模糊答案，重新描述的话，即

1. 先运行起来再改善（Make it Work then Make it Better）。

2. 程序就是现实世界的数字世界的抽象。

3. 一切事物都有其生命周期。
   

4. 迭代即速度和质量。
   

过去读张一鸣的一篇文章——《越是高级人才，越要看一些基本素质》，我增加了另一条关于程序员成长的观点：技术知识决定了你的起点和速度，而技术修养决定了你的加速度！

第一，你的职业起点和发展速度，极大地取决于你的技术知识。而且，越难或者需要越久才能理解的技术知识，越是有价值。如果你拥有的技术知识，别人能看一篇文章或者花几个小时甚至几天就能掌握，那么这样的技术知识没什么竞争力的。

第二，你的持续发展能力更多取决于你的技术修养。如果技术修养较差，那也是会减缓甚至停滞了你的发展。

特此共勉！

最后，你的答案会是什么？欢迎在留言区留下你的答案。

---

附录：光头大哥的故事

光头大哥叫Gavin Thornd，从发量看，想必是一名超级资深的程序员！然而，点击他的简介页面，发现他是一位摄影师！而且没有一个关键词表示他和程序员有什么关系啊！同时，从自我介绍上看出来这大哥还有点小幽默。

我想，他一定是一个有故事的人！

于是我简单搜索一下他。在bing.com搜索他的名字，第一个结果是他的个人网站 https://gavinthorn.com/。然后，在网站介绍了发现光头大哥的故事——一个技术人跨界转型的励志故事。

简单地翻译介绍他的经历：

他自小热爱摄像。在18岁生日收到一台单反相机后更是激发了他的创作热情，之后投入大量时间和金钱搞摄影。然而，在面临职业选择的时候，他还是听从周围人的意见，选择了一个“好”工作，最后成为了一位通信系统工程师。然而，工作多年之后，他觉得自己还是更爱摄像，而且当时的工作已经让他心力交瘁了——身体快被压力弄垮了，没时间陪伴家人也让他很苦恼。于是他辞职了，弄摄影了，每天可以多陪伴家人，身体也恢复健康了，慢慢走向人生巅峰。

嗯，看来过去的程序员日子也不好过啊。

而且，从这位大哥的经历看，人还是得有点兴趣爱好的。万一哪天不想在现在的职业发展了，还能有一条后路。