文章首發公衆號:CoderMrWu ,每週分享優質技術文章和經驗,歡迎你們關注,共同交流。java
最近特別喜歡看傳記經驗類的文章,由於能夠從中找到一些本身正在經歷或即將經歷的問題的答案。以史爲鑑,就是這個意思。下邊是一個程序員自我提醒的清單,摘了些本身覺着比較有價值的整理翻譯分享給你們。英文好的能夠去看原文:Notes to Myself on Software Engineeringpython
代碼不僅是要執行。代碼也是跨團隊交流的一種手段,是一種向他人描述問題解決方案的方式。可讀代碼不只僅是一種良好的編碼習慣,它應該是編寫代碼的基礎要求。這其中包括清楚的分解代碼、選擇意義明確的變量名和對任何隱式代碼添加註釋等。程序員
不要問你提交的程序能爲你下次的營銷活動帶來什麼,要問你的程序能爲你的用戶羣體帶來什麼,要避免以「顯式的貢獻(conspicuous contribution)」爲目標。若是不能知足你產品最初的設計目標,寧願不添加任何新功能。golang
品味這個詞一樣能夠拿來形容代碼。經過對知足對簡單性的要求來知足本身的品味,這個是一個約束知足問題(constraint-satisfaction process)。保持對簡單性的偏執追求。安全
有時候,某人要求一個功能時,並不意味着你必定要去作這個功能,你徹底能夠說「不」。有不少超出最初設計預算(維護成本、文檔成本和用戶的認知成本)的功能,這時候你要問「咱們真的須要這樣作嗎?」,答案每每是「徹底沒有必要」。markdown
當你打算支持一個新的用例(use case)請求時,記住不要僅僅從表面上去實現用例功能。用戶的請求,每每都是站在他們本身的特殊我的的角度。你應該整個項目構架和將來規劃上考慮。通常,正確的作法是擴展該功能,而不是簡單修改。數據結構
把更多的精力投入到持續集成,爭取更多的單元測試覆蓋率,確保本身在一個有安全感的編碼環境中。模塊化
能夠不提早計劃全部事情,根據事情的進展看結果。可是要及時糾正錯誤的事情,讓本身處在一個正確的軌道上。oop
好的軟件,可使困難的事情變得簡單。事情一開始看起來很難,並不意味着它的解決方案就很難或很複雜。工程師常常會使用反射解決方案,這種每每會使問題複雜化(添加 ML、構建新的 APP、添加區塊鏈)。在編寫任何代碼時,確保使用了最簡單的方案。要用最根本、最簡單的方式來處理問題。單元測試
在軟件設計過程當中,你應該考慮軟件的總體影響,而不只僅是某個功能模塊。除了監控相關指標外,你的軟件對用戶,乃至社會有什麼影響?有沒有你不但願看到的負面影響?這些你是否能夠採起必定措施來解決掉?
Design for ethics. Bake your values into your creations.
你的 API 也是有用戶的,即也有用戶體驗一說。因此,在你作任何決定時,都要考慮到你的用戶。要站在用戶的角度,無論他們是菜鳥仍是經驗豐富的老手。
在用戶使用你的 API 時,儘量下降用戶的認知難度。隱藏複雜不重要的部分,減小用戶的使用成本。設計聽從簡單一致思惟模式和工做流程。
參數的含義應該是在不瞭解上下文的時候就能很好的理解的。參數應該和用戶對問題的思惟模型有關,而不該該與代碼的實現細節有關。API 應該與解決的問題有關,而不該該與後臺的工做方式有關。
好的思惟模型是模塊化和分層的:從高層上來講很簡單,可是細節也很精準。一樣,好的 API 也是模塊化和分層的:易於實現,但表現力又強。
你的 API 的實現是你的一個實現選擇,特別是數據結構,你應該選擇和天然領域專家思惟模型貼近的直觀結構。
設計 API 時,應該是一組原子功能。確保以最簡單的方式知足上層用例工做流,而不是由於「可能用到」而添加沒必要要的功能。
錯誤消息,是 API 與用戶交互的一個反饋,交互性和反饋是必不可少的。
文檔是用戶體驗 API 是的核心,高質量的文檔,會使用戶有高質量回饋。你的文檔,不該該討論軟件的工做方式,而應該是使用方法。更多的實例代碼會使文檔更友好、實用。
Productivity boils down to high-velocity decision-making and a bias for action.
職業生涯的進步是不你管理多少人,而是你有多少影響力;
軟件開發是一個團隊合做的工做;社交能力和技術能力同樣重要。成爲一個好的隊友,和其餘人保持良好的聯繫。
技術永遠不會中立,在作選擇的時候,有受益者,也會有受害者。將你的價值觀融入到設計中,保持謹慎和明確。
自省,是生活滿意度的關鍵。確保你對你的工做和生活的徹底掌握。
做者介紹:碼農吳先生,專一python/golang/java/devops等技術的學習經驗及資源分享~ 學習路上,讓咱們共同前行,相信每一段路,都是一個故事~