編程相對來說是一門專業性非常強的技術工種，全世界也有大量的編程人員，每天都有人討論什么編程語言最好，優秀程式員的標準等，接下來讓我們來看看那些爭議最大的編程觀點，
?
1. 業余時間不會為了好玩而編程的程式員，永遠比不上那些以編程為樂的同學，
我認為即使是最聰明、最有才華的人，如果只是將編程作為作業，也永遠成不了真正優秀的程式員，以編程為樂的人會在業余時也搞些小專案，或者弄弄各種不同的編程語言和編程思想，
2. 單元測驗無助于撰寫優秀代碼，
撰寫單元測驗的唯一理由僅僅是確保已經能作業的代碼不會出問題，先寫測驗或者按測驗來寫代碼是無比荒謬的，如果在代碼之前寫測驗，你都不知道邊界情況是什么，雖然能讓代碼通過測驗，但是在沒有預見到的情況時還是會出問題，而且，好的開發人員會盡量降低內聚性，新增代碼不可能使已有的出問題，
3. 唯一能放之四海而皆準的最佳實踐，是"用腦子思考"，
太多人喜歡追逐眾多時髦技術，想方設法把各種方法、模式、框架用到不適合的地方，新技術和名人大牛的觀點并等于適用于實際情況，
4. 大多數代碼中的注釋實際上都是代碼重復的惡性表現，
給代碼加注釋是必須的，但不是每一條都要加上注釋，糟糕、錯誤、過時和誤導性的注釋還會造成更壞的結果，很多人認為應該把精力放在提高代碼的可讀性上，許多教材還在宣揚什么注釋甚至比代碼還重要，結果導致了大量廢話連篇的注釋，其實在代碼中具備特殊意義的，或者相對較復雜的，需要加注釋說明，簡單的代碼，很簡單一眼就能看懂的，就沒必要再加注釋了，
5. 依賴Google沒什么錯，
這種言論肯定會讓那些學富五車的飽學之士畝訓，但是誰都需要查資料不是？正確答案就是正確答案，管它是來自哪本秘籍或者私相傳授，還是Google出來的呢？重要的是能真正理解，并給出成功的編程解決方案，讓客戶和老板滿意，
6. 程式員不是生而平等的，
經理往往認為程式員A==程式員B，因為他們的年頭差不多，實際上，一個開發者的效能可以是另一個的十倍甚至百倍，
7. 我實在不能理解為什么C語言是最適合大學教學的第一門語言，明明它都已經過時了，
之前某網站上就有人有這樣的疑問，并因為提問方式有引戰嫌疑，被知乎管理員重新編輯發布，
?
編輯前
?
編輯后
大學教育，尤其是 985、211 這種國內最頂尖的一批高校，應該注重通識教育而不是專項教育，在專業上更要注重基礎、底層、偏向原理，只有掌握了最核心的東西，學起那些偏技能的東西才會很快很輕松，
時間能夠證明一切，C 語言已經走過了四十多年的歷史，但是在今天，任然常年霸占 TIOBE 編程語言排行榜前三，甚至榜首，這足以說明它是一門經久不衰的語言，
?
8. 如果你只會一門語言，無論多么精通，仍然不是優秀的程式員，
有人認為，只要精通了C#、Java或者其他什么你學會的第一門語言，就足夠了，
任何人只局限于一種語言，都無法充分發揮自己的潛力，而且缺乏求知欲和探索意愿，都不符合優秀程式員的特質，
現在也有很多人往全堆疊工程師發展，很多人不明白，其實全堆疊的真正意義并不在于多學了幾門技術，而在于說，你擁有了將一個想法完整的轉化為一個產品的能力，這種能力讓你從一個不能脫離生產線的螺絲釘、不能離開公司獨立生存的雇員，變成了一個對自己的作業，對自己的生活，對自己的事業擁有選擇權的一個人，
9. 偶爾寫寫垃圾代碼也無妨，
前面我還分享過代碼整潔之道，今天就跟你們說寫垃圾代碼了，但是有時候一些特定任務，快而臟的代碼能搞定就行了，打工人誰不想偷個懶呢，模式、ORM、SRP（單一職責原則）啥的算了吧，
10. print陳述句是有效的除錯方式，
我認為用 System.out.println 之類的輸出陳述句除錯代碼挺好，這經常比正式的除錯要快，而且可以比較不同運行的輸出結果，但是投入生產環境之前一定要洗掉這些陳述句，或者將它們放入日志陳述句中，
11. 你的作業是要把自己摘出來，
前面說了我們寫注釋是方便他人也方柏霓自己，你寫的軟體都應該讓其他任何開發人員花一點時間就能理解并接手，軟體應該設計優雅，代碼清晰和一致，格式干凈，檔案合適，每日構建，有恰當的版本管理，你越這樣做，你對公司的價值越大，不要害怕被別人頂替，如果你教會別人到代替你的職位，那現有位置就沒有你的位置，你就只能升職啦~
12. getter和setter被極度濫用了，
成千上萬的人都說公共欄位是罪惡的，應該設為私有，提供getter和setter，我覺得其實沒啥不同，除非程式是多執行緒的，或者訪問方法中有業務或者展示邏輯（這可夠怪的），我并不是贊成用公共欄位，只是反對用訪問方法或者屬性包一下，就號稱封裝、資訊隱藏了，
13. SQL也是代碼，請等而視之，
SQL和C#, Java或者其他物件、程序語言沒什么不同，請注意代碼的格式、可讀性和可維護性，
14. UML圖被高估了，
有些圖當然是有用的，比如Composite模式的類圖，但許多UML圖都毫無價值，
15. 可讀性是代碼最重要的方面，
比正確性還重要，可讀的代碼也容易修正，容易優化、修改、理解，而且其他開發者也能從中獲益，
16. XML被大大高估了，
很多隨波逐流跳上XML這黑船的人都沒過腦子，XML用于Web應用不錯，因為它本來就是干這個的，此外的問題定義、設計思路應該盡量不用XML，
?
17. 軟體開發只是一份作業而已，
作業不是全部，為什么會有“打工人”詞出現，就是因為這個詞代表的含義符合大眾的心理，但是很多人都忘了，我們不是為了作業而作業，作業是為生活的美好服務，許多開發者也忘記了寫程式不是最終目的，它只是為我們提供條件，去高高興興地做生命中最重要的事情，
18. 開發人員就應該能夠寫代碼，
這個都成了有爭議的觀點了嗎……
19. 設計模式弊大于利，
軟體設計，尤其是好的軟體設計千變萬化，沒法有意義地用模式去總結，尤其是那些大家記得住的幾個模式，而且這些模式也太抽象了，其實沒幾個人真正記得住太多，所以設計模式其實沒啥用，而另一方面呢，又有太多的人為設計模式的概念迷住，想方設法到處用——結果代碼中往往除了一些毫無意義的單例和抽象工廠之外，幾乎找不到什么設計，
20. 代碼少少益善，
冗長繁雜的代碼是沒有必要的，少而精才是目的，
其他不同的觀點還有：
21. 性能真的很重要，
22. 企業應用很滑稽，需要n年經驗是胡扯，計算機科學學位課程純忽悠，
23. 單元測驗無助于撰寫好代碼，軟體工程大多數所謂的最佳實踐都是為了防范爛程式員搞太多破壞，
24. 每個程式員都應該熟悉現代計算機的體系結構，
25. 撰寫小方法，
26. PHP真爛！
27. C++是有史以來最差的語言之一，
28. 大多數職業程式員都很爛，
29. 要想成為程式員，你得先學會打字，
30. 編程之外的各種流程規矩越多，代碼質量越差，
31. 計算機科學專業應該只作為輔修學位，
32. 新程式員還沒有弄懂分解問題和將解決方法變成代碼之前，就給他們介紹面向物件是大錯特錯，
33. 復雜的編譯器優化幾乎都沒什么價值，即使能得到更快的代碼，它們會大大降低編譯速度而且很可能產生難以處理的bug，使性能問題的處理更加困難，
34. 不能允許沒有十年編程經驗的人撰寫供他人使用的庫，忽略此條，抱憾終身，
35. 代碼丑陋與否無關緊要，有沒有格式與代碼是否作業、可靠沒什么關系，可以讓自動化工具來整理格式，
36. 純函式式編程沒啥用，但在命令式代碼里雜用一些效果不錯，
37. 軟體工程的既定思維反而會阻礙你做出偉大作品，
你的看法是什么呢？來評論區留言跟我說說吧~
C語言是每個想要學習編程的小伙伴首要學習的語言~如果你也想成為程式員，想要快速掌握編程，這里為你分享一個學習基地！
里面有資深專業軟體開發工程師，在線解答你的所有疑惑~ C語言入門“so easy”資料包含：編程入門、游戲編程、課程設計、黑客等， 點擊進入學習基地
?
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/206081.html
標籤：其他