必須知道的程序員思惟

時間 2019-11-08

標籤必須知道程序員思惟欄目快樂工作简体版

原文原文鏈接

在博客閱讀：https://ssshooter.com/2019-04...javascript

工做

寫程序不是爲了炫耀本身的技術，是要給公司創造價值，要確實幫助使用這個程序的人。以及以前說過的，當程序員就是爲了提升社會效率。前端

寫高效的代碼是每一個程序員的追求，寫易懂的代碼是每一個程序員的美德。vue

易懂的代碼首先是有規範的，從目錄結構到代碼風格，在項目創建初就應該肯定，能夠寫進項目文檔中，文檔用於給初見項目或是接手的程序員一個概覽,介紹一下總體結構，技術棧，以及一些坑。java

技術選型注意不要選擇沒人用的（找不到幫助）、無人維護的（發現 bug 會讓你很痛苦）、很難用的（你本身懂也有可能要方便被人懂，選擇框架尤爲注意，這也是 Vue 熱門的緣由吧）。node

控制代碼風格可使用 eslint 和 prettier。前者用於代碼規範控制，後者用於格式化代碼。統一的格式化工具配置也是十分必要的，尤爲在協做的時候，若是兩邊的格式化格式不一樣的話，diff 也是地獄般的體驗。webpack

編碼不規範，維護兩行淚

在有規範以後，還要注意不要爲了追求極簡寫些難懂的代碼，你必須控制簡潔和可讀性間的平衡，例如ios

i = i ? (i < 0 ? Math.max(0, len + i) : i) : 0

而有時候，hack 是迫不得已的事情，這個時候必須作好註釋。可是須要注意，註釋描述的不是作什麼（what），而是爲何（why）。git

一段可讀性過關的代碼中徹底能看出它在幹嗎，看不出來作什麼的代碼很大概率是不及格的代碼了。程序員

可讀性主要由命名入手，變量名稱對整段程序理解的重要性不言而喻；另外，對於一些功能不太好看出來的幾個語句的集合，即便不會複用，也能夠將其包裝成函數，經過函數命名告訴讀程序的人（而不是電腦）這一段代碼的做用。github

/* 還有一個例子是把對象綁到 vue 的 this，而後不 import 直接用
   對於這個作法...看你喜歡吧
   毫無疑問對於模塊化的項目，一個模塊就不該該掛在其餘地方
   （雖然這麼掛上去可能會省掉 webpack 的模塊調用，讓你的程序快一丁丁丁丁丁丁丁點）
   若是你真的懶到不寫 import
   請必定要在綁定的變量加上 $
   至少你這個時候全局搜索仍是很容易找到來源的
*/
Vue.prototype.$axios = Axios

有了規範的編碼，仍不足以讓整個代碼庫足夠簡單，控制代碼複雜度是下一個目標。

必定要理解你的所作系統的需求，不然只會在誤解和錯誤的惡性循環中越陷愈深，浪費珍貴的時間。

我最近就接手重構一個先後端耦合的項目，業務邏輯非常複雜，理解需求這一步毫不能逃避，只能一個個細節問清楚。

不要看到大佬提什麼需求都一股腦加進去，即便所提的需求很簡單，但你須要有足夠的時間評估這個功能。

新增需求和需求修改上也是一個道理，不能破壞之前的功能，保證整個系統的純潔。

因此優雅地添加功能真的很耗時間。

至於真的不可行的需求，請勇敢說不。若是對結構影響很大的需求最好不要改了。~~不過這是理想，中國程序員好像沒有什麼地位~~

在工時預估方面，能夠嘗試拆分任務，而且要假設一切都會更花時間。

拆分任務不只可讓你更準確地估計實現時間，還能讓你的工做更有條理。

至於優先度，還請結合上司指令和實現難度本身衡量吧。

總之，一個完美的系統不是一步就能造好的。

對於將來的功能，你能夠留個後路，但不要提前瞎作「自覺得須要」的功能。否則到時候寫了一堆沒用的代碼都是浪費時間，還可能讓提升程序複雜度。

優化方面，參考著名的「不要過早優化」。讓正確的程序更快，要比讓快速的程序正確容易得多。開發和優化看成兩個獨立的步驟來作。

Premature optimization is the root of all evil.

維護是軟件開發重要而困難的一環。不過若是你按着上面所說的作，我相信...維護不會是難事。

可是若是你的代碼寫得很噁心，你會爲之付出代價。

答應我：寧願在實現功能時很痛苦，也不要在維護的時候更痛苦。

平常

重複的輪子
偉大的開源模式讓整個編程界發展加速。

能夠站在巨人肩膀上，就別重複造輪子。

除非你真的很閒（~~工做不飽和哦～~~）,或者你找到的輪子實在不合心意（如老舊、不優雅、功能太繁雜）
重複的工做
「重複」是程序員最大的敵人！

計算機就是負責給你作重複的事情，程序員爲何還要作哦？教計算機作就行了！

你能夠依賴 node.js 寫處理程序處理你的文檔，在編輯代碼的時候能夠活用快捷鍵修改代碼。
自我開發
程序員拒絕 996，可是在家不意味着閒着，你仍須要爲本身的腦子投資。

這一行變化還挺快，雖然我也真的徹底不會看將來走向，不懂什麼語言和技術會在之後更有價值，可是儘可能不要侷限與學習單個語言，也不要由於是前端就徹底不學後端。

我以爲這樣才能當一個有格局的程序員。
解決問題

If you can't explain something in simple terms, you don’t understand it. — Richard Feynman

若是你不能流利解釋一個問題，那說明你仍是沒懂，也就是還沒真正解決這個問題。如果沒真正解決問題，便不能觸類旁通解決更多相似問題。

解決問題要明白問題如何產生，先思考，後行動。行動無解能夠到谷歌搬救兵，搜索不到的話……

最終方案就是到對應社區提問，可是提問一樣是一個學問，請看 How To Ask Questions The Smart Way。
生產力

不是代碼越多生產力越高，程序員應該都懂，至於老闆怎麼看，就不得而知了 😂

One of my most productive days was throwing away 1000 lines of code. — Ken Thompson