資訊專欄INFORMATION COLUMN
摘要：以及之前說過的，當程序員就是為了提高社會效率。寫高效的代碼是每個程序員的追求，寫易懂的代碼是每個程序員的美德。讓正確的程序更快，要比讓快速的程序正確容易得多。我覺得這樣才能當一個有格局的程序員。
在博客閱讀：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。
生產力
不是代碼越多生產力越高，程序員應該都懂，至于老板怎么看，就不得而知了
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/103526.html
摘要：由于文章內容較長，所以我把它分成兩篇小文章，在第一篇優秀架構師必須掌握的架構思維中，我會先介紹抽象分層分治和演化這四種應對復雜性的基本思維。另外，上面的算法是兩路歸并，也可以采用多路歸并，甚至是采用堆排序進行優化，但是總體分治思路沒有變化。 showImg(https://segmentfault.com/img/bVbeYpP?w=642&h=400); 介紹 架構的本質是管理復雜性...
摘要：由于文章內容較長，所以我把它分成兩篇小文章，在第一篇優秀架構師必須掌握的架構思維中，我會先介紹抽象分層分治和演化這四種應對復雜性的基本思維。另外，上面的算法是兩路歸并，也可以采用多路歸并，甚至是采用堆排序進行優化，但是總體分治思路沒有變化。 showImg(https://segmentfault.com/img/bVbeYpP?w=642&h=400); 介紹 架構的本質是管理復雜性...
摘要：也就是說我們只是知其然，并沒有知其所以然。相反，那些牛人就不會忘記自己設計的算法。劉未鵬在知其所以然三為什么算法這么難中探索了編碼的思維歷程，值得一看。之后，將當前入棧，更新棧內的遞增序列。 原文地址 相信大部分同學曾經都學習過快速排序、Huffman、KMP、Dijkstra等經典算法，初次學習時我們驚嘆于算法的巧妙，同時被設計者的智慧所折服。于是，我們仔細研讀算法的每一步，甚至去證...
摘要：下面就是我的另一篇文章你真的了解和嗎中的思維導圖。但是托尼布贊并沒有沉淪，而是尋找解決方法，最終發明了思維導圖。本節的思維導圖就是典型的折中型思維導圖。安排合適的間隔合適的間隔能夠很大程度提高思維導圖的審美性。 天下事有難易乎？為之，則難者亦易矣；不為，則易者亦難矣。——《為學》 引言 我猜發布文章的同學肯定都有一個目標，那就是獲得更多的推薦。推薦越多，表示得到別人的認同越多，自我滿...
摘要：下面就是我的另一篇文章你真的了解和嗎中的思維導圖。但是托尼布贊并沒有沉淪，而是尋找解決方法，最終發明了思維導圖。本節的思維導圖就是典型的折中型思維導圖。安排合適的間隔合適的間隔能夠很大程度提高思維導圖的審美性。 天下事有難易乎？為之，則難者亦易矣；不為，則易者亦難矣。——《為學》 引言 我猜發布文章的同學肯定都有一個目標，那就是獲得更多的推薦。推薦越多，表示得到別人的認同越多，自我滿...
閱讀 662·2021-11-24 09:39
閱讀 2315·2021-11-22 13:54
閱讀 2197·2021-09-23 11:46
閱讀 3246·2019-08-30 15:55
閱讀 2679·2019-08-30 15:54
閱讀 2403·2019-08-30 14:18
閱讀 1546·2019-08-29 14:15
閱讀 2732·2019-08-29 13:49
