每個程序員都應該知道哪些最基本的常識？
[導讀]Quora平臺，可以看成是美國的知乎。在Quora平臺上，曾經有人提出過這樣一個問題：Whataresomeofthemostbasicthingseveryprogrammershouldknow？每個程序員都應該知道哪些最基本的常識？這個問題只有64個答案，并沒有很多人愿意給...
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.最快的代碼是從未被執(zhí)行的代碼——查找早期的輸出。
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?代碼無法自描述。請?zhí)砑幼⑨屓椭鷦e人理解。再說，你可能現在還能理解，但五年之后呢？
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，用戶會發(fā)現的。
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).如果沒被測試過，那它就不能正確運行。（是的，我知道我說了兩遍，但它確實重要。）
光頭大哥作為老派程序員，雖然轉行了，但觀點還是挺接地氣的。我們接著看第二個答案，感覺來自一位從業(yè)3-5年的程序員。
1.?Your code will never work the way you want, the very first time you code it up. Accept that. Move on.剛完成代碼的時候，你的代碼永遠不會按你想要的方式工作。請接受這個情況，并繼續(xù)請進。評：所以，寫完代碼必須自己先測試。
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!遠離技術選擇優(yōu)劣對比的戰(zhàn)爭，比如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.不要為不成熟的優(yōu)化而煩惱。如果人們會用Python之類的語言去開發(fā)，也就省下幾毫秒。這沒什么大不了的。
讀完之后，你認同這些觀點嗎？整體來說，我覺得他們的觀點都挺好的，接地氣。從質量和范圍看，光頭大哥的略勝一籌。
我的答案是什么？過去寫過《平凡卻又深刻的編程理念》系列的文章，算是當初我能給出的模糊答案，重新描述的話，即
過去讀張一鳴的一篇文章——《越是高級人才，越要看一些基本素質》，我增加了另一條關于程序員成長的觀點：技術知識決定了你的起點和速度，而技術修養(yǎng)決定了你的加速度！第一，你的職業(yè)起點和發(fā)展速度，極大地取決于你的技術知識。而且，越難或者需要越久才能理解的技術知識，越是有價值。如果你擁有的技術知識，別人能看一篇文章或者花幾個小時甚至幾天就能掌握，那么這樣的技術知識沒什么競爭力的。第二，你的持續(xù)發(fā)展能力更多取決于你的技術修養(yǎng)。如果技術修養(yǎng)較差，那也是會減緩甚至停滯了你的發(fā)展。特此共勉！
最后，你的答案會是什么？歡迎在留言區(qū)留下你的答案。
附錄：光頭大哥的故事
光頭大哥叫Gavin Thornd，從發(fā)量看，想必是一名超級資深的程序員！然而，點擊他的簡介頁面，發(fā)現他是一位攝影師！而且沒有一個關鍵詞表示他和程序員有什么關系??！同時，從自我介紹上看出來這大哥還有點小幽默。
我想，他一定是一個有故事的人！于是我簡單搜索一下他。在bing.com搜索他的名字，第一個結果是他的個人網站 https://gavinthorn.com/。然后，在網站介紹了發(fā)現光頭大哥的故事——一個技術人跨界轉型的勵志故事。
簡單地翻譯介紹他的經歷：
程序員小灰" data-alias="chengxuyuanxiaohui" data-signature="一群喜愛編程技術和算法的小倉鼠。" data-from="0">
這個問題只有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.最快的代碼是從未被執(zhí)行的代碼——查找早期的輸出。
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?代碼無法自描述。請?zhí)砑幼⑨屓椭鷦e人理解。再說，你可能現在還能理解，但五年之后呢？
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，用戶會發(fā)現的。
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).如果沒被測試過，那它就不能正確運行。（是的，我知道我說了兩遍，但它確實重要。）
光頭大哥作為老派程序員，雖然轉行了，但觀點還是挺接地氣的。我們接著看第二個答案，感覺來自一位從業(yè)3-5年的程序員。
1.?Your code will never work the way you want, the very first time you code it up. Accept that. Move on.剛完成代碼的時候，你的代碼永遠不會按你想要的方式工作。請接受這個情況，并繼續(xù)請進。評：所以，寫完代碼必須自己先測試。
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!遠離技術選擇優(yōu)劣對比的戰(zhàn)爭，比如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.不要為不成熟的優(yōu)化而煩惱。如果人們會用Python之類的語言去開發(fā)，也就省下幾毫秒。這沒什么大不了的。
讀完之后，你認同這些觀點嗎？整體來說，我覺得他們的觀點都挺好的，接地氣。從質量和范圍看，光頭大哥的略勝一籌。
我的答案是什么？過去寫過《平凡卻又深刻的編程理念》系列的文章，算是當初我能給出的模糊答案，重新描述的話，即
- 先運行起來再改善（Make it Work then Make it Better）。
- 程序就是現實世界的數字世界的抽象。
- 一切事物都有其生命周期。
- 迭代即速度和質量。
過去讀張一鳴的一篇文章——《越是高級人才，越要看一些基本素質》，我增加了另一條關于程序員成長的觀點：技術知識決定了你的起點和速度，而技術修養(yǎng)決定了你的加速度！第一，你的職業(yè)起點和發(fā)展速度，極大地取決于你的技術知識。而且，越難或者需要越久才能理解的技術知識，越是有價值。如果你擁有的技術知識，別人能看一篇文章或者花幾個小時甚至幾天就能掌握，那么這樣的技術知識沒什么競爭力的。第二，你的持續(xù)發(fā)展能力更多取決于你的技術修養(yǎng)。如果技術修養(yǎng)較差，那也是會減緩甚至停滯了你的發(fā)展。特此共勉！
最后，你的答案會是什么？歡迎在留言區(qū)留下你的答案。
附錄：光頭大哥的故事
光頭大哥叫Gavin Thornd，從發(fā)量看，想必是一名超級資深的程序員！然而，點擊他的簡介頁面，發(fā)現他是一位攝影師！而且沒有一個關鍵詞表示他和程序員有什么關系??！同時，從自我介紹上看出來這大哥還有點小幽默。
我想，他一定是一個有故事的人！于是我簡單搜索一下他。在bing.com搜索他的名字，第一個結果是他的個人網站 https://gavinthorn.com/。然后，在網站介紹了發(fā)現光頭大哥的故事——一個技術人跨界轉型的勵志故事。
簡單地翻譯介紹他的經歷：
他自小熱愛攝像。在18歲生日收到一臺單反相機后更是激發(fā)了他的創(chuàng)作熱情，之后投入大量時間和金錢搞攝影。然而，在面臨職業(yè)選擇的時候，他還是聽從周圍人的意見，選擇了一個“好”工作，最后成為了一位通信系統(tǒng)工程師。然而，工作多年之后，他覺得自己還是更愛攝像，而且當時的工作已經讓他心力交瘁了——身體快被壓力弄垮了，沒時間陪伴家人也讓他很苦惱。于是他辭職了，弄攝影了，每天可以多陪伴家人，身體也恢復健康了，慢慢走向人生巔峰。嗯，看來過去的程序員日子也不好過啊。而且，從這位大哥的經歷看，人還是得有點興趣愛好的。萬一哪天不想在現在的職業(yè)發(fā)展了，還能有一條后路。
下載文檔
