在博客閱讀：https://ssshooter.com/2019-04...
工作
寫程序不是爲了炫耀自己的技術，是要給公司創造價值，要確實幫助使用這個程序的人。以及之前說過的，當程序員就是爲了提高社會效率。
寫高效的代碼是每個程序員的追求，寫易懂的代碼是每個程序員的美德。
易懂的代碼首先是有規範的，從目錄結構到代碼風格，在項目建立初就應該確定，可以寫進項目文檔中，文檔用於給初見項目或是接手的程序員一個概覽,介紹一下整體結構，技術棧，以及一些坑。
技術選型注意不要選擇沒人用的（找不到幫助）、無人維護的（發現 bug 會讓你很痛苦）、很難用的（你自己懂也有可能要方便被人懂，選擇框架尤其注意，這也是 Vue 熱門的原因吧）。
控制代碼風格可以使用 eslint 和 prettier。前者用於代碼規範控制，後者用於格式化代碼。統一的格式化工具配置也是十分必要的，尤其在協作的時候，如果兩邊的格式化格式不同的話，diff 也是地獄般的體驗。
編碼不規範，維護兩行淚
在有規範之後，還要注意不要爲了追求極簡寫些難懂的代碼，你必須控制簡潔和可讀性間的平衡，例如
i = i ? (i < 0 ? Math.max(0, len + i) : i) : 0而有時候，hack 是無可奈何的事情，這個時候必須做好註釋。但是需要注意，註釋描述的不是做什麼（what），而是爲什麼（why）。
一段可讀性過關的代碼中完全能看出它在幹嘛，看不出來做什麼的代碼很大機率是不及格的代碼了。
可讀性主要由命名入手，變量名稱對整段程序理解的重要性不言而喻；另外，對於一些功能不太好看出來的幾個語句的集合，即使不會複用，也可以將其包裝成函數，通過函數命名告訴讀程序的人（而不是電腦）這一段代碼的作用。
/* 還有一個例子是把對象綁到 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
最後，請讓上面的思維銘刻於心中，工作時條件反射地記起 😜
參考鏈接
Learn the fundamentals of a good developer mindset in 15 minutes