haoel

讀完需要

5

分鐘

速讀僅需 2 分鐘

譯文來源 CSDN 作者：haoel

在 Stack Overflow 上有這樣的一個貼子《What’s your most controversial programming opinion?》，翻譯成中文就是“你認為最有爭議的編程觀點是什么？”，由 Jon Skeet 在 2009 年 1 月提出。此人可不是無名小卒，C#社區大名鼎鼎的人物，多年微軟 MVP，所著《深入理解 C#》（英文版 C# in Depth）一書是 C#領域少數不可不讀的名著，現在 Google 英國公司任工程師。不過，在 400 多個主回貼，以及千把個子回貼中，好像并不是很有爭議，而是令人相當的茅塞頓開，下面羅列一些，并通過我自己的經歷和理解發揮了一些，希望對你有幫助。

1

? ?

The only “best practice” you should be using all the time is “Use Your Brain”.

唯一的“Best Practice”并不是使用各種各樣被前人總結過的各種設計方法、模式，框架，那些著名的方法、模式、框架只代碼贊同他們的人多，并不代表他們適合你，你應該更多的去使用你的大腦，獨立地思考那些方法、模式、框架出現的原因和其背后的想法和思想，那才是“Best Practice”。事實上來說，那些所謂的“Best Practice”只不過是限制那些糟糕的程序員們的破壞力。

2

? ?

Programmers who don’t code in their spare time for fun will never become as good as those that do.

如果你對編程沒有感到一種快樂，沒有在你空閑的時候去以一種的輕松的方式去生活，無論是編程，還是運動，還是去旅游，只要你在沒有從中感到輕松和愉快，那么你只不過是在應付它們。而你無時無刻不扎在程序堆中，這樣下來，就算是你是一個非常聰明，非常有才華的人，你也不會成為一個優秀的編程員，要么只會平平凡凡，要么只會整天扎在技術中成為書呆子。當然，這個觀點是有爭議，熱情和能力的差距也是很大的。不過我們可以從中汲取其正面的觀點。

3

? ?

Most comments in code are in fact a pernicious form of code duplication.

注釋應該是注釋 Why，而不是 How 和 What，參看《惹惱程序員的十件事》，代碼告訴你 How，而注釋應該告訴你 Why。但大多數的程序并不知道什么是好的注釋，那些注釋其實和 code 是重復的，毫無意義。

4

? ?

XML is highly overrated

XML 可能被高估了。XML 對于 Web 上的應用是不錯的，但是我們把其用到了各種地方，好像沒有 XML，我們都不會編程了。

5

? ?

Not all programmers are created equal

這是那些 junior 經理或是流程愛犯的錯，他們總是認為，DeveloperA == DeveloperB，只要他們的 title 一樣，他們以為他們的能力、工作速度、解決問題的方法，掌握的技能等等都是一樣的。呵呵。更扯的是，在某些時候，就算是最差的程序員，因為 Title，他們也會認為其比別人強十倍，這就是很表面的愚蠢的管理。

6

? ?

”Googling it” is okay!

不可否認，查找知識是一種能力。但 Google 只會給你知識，并不會教給你技能。那里只有“魚”，沒有“漁”，過度的使用 Google，只會讓你越來越離不開他，你越來越需要要它立馬告訴你答案，而你越來越不會自己去思考，自己去探索，去專研。如果 KFC 快餐是垃圾食品對我們的身體沒有好處，那么使用 Google 也一種快餐文化對我們的智力發展大大的沒有好處。因為我們過度地關注了答案，而不是尋找答案的技術和過程。

7

? ?

If you only know one language, no matter how well you know it, you’re not a great programmer.

如果你只懂一種語言，準確的說，如果你只懂一類語類，如：Java 和 C#，PHP 和 Perl，那么，你將會被局限起來，只有了解了各種各樣的語言，了解了不同語言的不同方法 ，你才會有比較，只有了比較，你才會明白各種語言的長處和短處，才會讓你有更為成熟的觀點，而且不整天和別的程序在網上斗嘴爭論是 Windows 好還是 Unix 好，是 C 好還是 C++好，有這點工夫能干好多事了。世界因為不同而精彩，只知道事物的一面是有害的。

8

? ?

Your job is to put yourself out of work.

你的工作不是保守，那種教會徒弟，餓死師父的想法，不但是相當短淺的，而且還是相當腦殘的。因為，在計算機世界里，你掌握的老技術越多，你就越沒用，因為技術更新的太快。你對工作越保守，這個工作就越來越離不開你，你就越不越不能抽身去學新的東西，你也就越來越 OUT 了。記住：If you can’t be replaced then you can’t be promoted!

9

? ?

Design patterns are hurting good design more than they’re helping it.

很多程序員把設計模式奉為天神，他們過度的追求設計模式以至都都忘了需求是什么，結果整個系統設計被設計模式搞得亂七八糟，我們叫這種編程為“設計模式驅動編程”，正如第一點所說，如果你不懂得用自己的大腦思考的話，知其然，不知所以然的話，那么你不但得不到其好處，反而受其所累。

10

? ?

Unit Testing won’t help you write good code

其實，Unit Test 的主要目的是，為了防止你不會因為一個改動而引入 Bug，但這并不會讓你能寫出更好的代碼。這只會讓你寫出不會出錯的代碼。同第一點，這樣的方法，只不過是防止糟糕的程序員，而并不是讓程序員或代碼質量更有長進。反而，程序員通常會借用“通過 Unit Test”來為自己代碼做辯解，而此時，Unit Test Report 成了一種托辭。

抗疫時期，分享不停

NEW

﹀

﹀

﹀

李捷，Elastic資深解決方案架構師

專注于Elastic Stack 的解決方案的設計和咨詢。13年軟件行業從業經驗，從嵌入式開發，到后端J2EE應用和前端界面開發。從爬蟲腳本，到區塊鏈和大數據分析。從開發工程師，到測試工程師和項目經理。擁有全棧開發經驗和豐富的項目實施經驗，同時也是一個活躍的知識分享者和社區活動者。

Kubernetes 和 Elastic: 從操作到可觀測性 網絡研討2020年4月1日15:00 線上分享

在本次網絡研討會中，您將了解 Kubernetes 和 Elastic 的新功能—特別是在簡化操作和 Elastic 可觀測性體驗方面。我們將討論 Kubernetes 操作模式以及 Elastic Cloud on Kubernetes(ECK)?是如何簡化部署和管理的。最后，我們將介紹Elastic Stack 的可觀測性如何使您能夠更好地了解應用堆棧，從而診斷、調試和解決應用中的問題。

亮點：

Elastic在CNCF云原生交互場景中的位置

在Kubernetes上運行?Elastic?Stack

演示：如何使用 ECK 部署、防護和升級 Elasticsearch

Beats?中使用?autodiscover?監測動態工作負載的入門知識

在Kubernetes上掌握可觀測經驗

報名方式：識別圖片二維碼或閱讀原文報名

想要加入中生代直播群的小伙伴，請添加群助手大白的微信

申請備注（姓名+公司+技術方向）才能通過哦！

總結

以上是生活随笔為你收集整理的StackOverFlow优选的十条编程观点的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。