文摘加感悟：中年程式設計師給年輕程式設計師的忠告
開發流程
-
好程式碼就是能夠自解釋的程式碼。沒有註釋，程式碼就是最好的註釋。但是做到這一點，很難。 Keras 之父 Francois Chollet 說過：程式碼不僅僅是用來執行的，也是團隊交流的一種方式，是向他人描述問題解決方案的一種方式。 所以命名很重要，避免使用過於籠統的名稱，避免使用過於冗長的命名，避免歧義。 儘量使用業內常見的命名。
-
寫程式碼要避免功利性，應該專注於解決問題。 如果你的程式碼對於這個產品想要達到的目標沒有明顯的幫助，就不要新增進去。
-
以簡潔為美。用最少的程式碼實現功能。
-
要時刻提醒自己：我們真的應該這樣做嗎？ 僅僅因為有人要求做某個特性，並不意味著你就應該這麼做。
-
必須從整個專案的角度出發，兼顧整體性和原則性。 使用者關注的僅僅是他們自己的特定應用場景。你應該考慮總體影響。 在保證軟體可用性的同時，你要採取措施來解決這些問題。
-
構建正確的基礎設施，才能不斷地持續整合，完整的單元測試覆蓋。
-
先試點，再推廣。 事先不要急著計劃好一切，先試一下看看結果如何，這樣可以儘早對錯誤的選擇進行回退。
-
使用最簡單的解決方案，避免不必要的複雜性。 問題看起來很複雜，並不意味著解決方案必須很複雜。好的軟體使複雜的事情變得簡單。 做任何事情都要有本源思維。什麼是本源思維？
-
明確說明開發規則，與團隊共享。避免隱式規則。避免衝突。 複雜的事情簡單化，簡單的事情自動化。
API 設計
-
要站在使用者角度思考問題。API是有使用者的，要考慮使用者體驗。
-
大道至簡：儘量減少使用者的認知負荷。 減少引數，封裝細節，設計簡單一致的工作流。 使得使用者無需查詢教程和文件，即可完成工作。
-
簡單的事情不要複雜化，複雜的事情要簡單化。 不要為了少量特殊的應用場景而增加普通應用場景的認知負荷。
-
API 要與使用者的心智模型相匹配。 API 的設計不要整一些高大上的新概念，應該符合業內常識，人家一看就能明白。 選擇適合其領域的資料結構。
-
引數應該是面向使用者的、面向問題的。大家一看就能明白。 而不是面向底層實現、面向內部細節，讓大家不知所云。
-
好的 API 應該是模組化和層次化的：易於使用，並具有表現力。 最強大的心智模型是模組化和層次化的：在高層次上很簡單，在細節上很精確。
-
設計端到端工作流，而不是一組原子特性。 什麼是端到端工作流？ 什麼是原子特性？ 不要提供一堆功能讓使用者選擇，應該針對使用場景設計最佳工作流。 不要因為有人可能需要它，而新增某個功能。
-
要謹慎地設計 API 的錯誤訊息。 互動性和反饋是使用者體驗的一部分。
-
高質量的文件，能帶來高回報。 最好的程式碼就是不需要文件的程式碼，只對業內人士有效。 對於小白使用者，高質量的文件就很重要了，業內人士也會喜歡的。 文件不要討論程式碼是如何工作的，而應該展示如何使用 API，示例程式碼非常重要。
職業生涯
-
關鍵不在於形式，而在於實質。 事業的進步不在於你管理了多少人，而在於你產生了多大的影響，具體地說是你的勞動成果具有多大的影響力。 或者你掌握的技術具有多大的影響力，比如給公司帶來多大的業績增長。
-
善於合作 軟體開發是團隊作戰，不僅關乎技術能力，而且關乎人際關係。 工作過程中，要保持溝通，有效溝通。
-
把你的價值觀融入你的作品中。 任何產品都不是中立的，都可能對世界產生影響，而這種影響是有道德導向的。 在軟體產品中看似無害的技術選擇可能會影響使用動機、有人受益、有人受害。 所以技術選擇也是倫理道德選擇，你要慎重和明確選擇支援的價值。
-
自我管理：要掌控你的工作和環境。 活如逆水行舟，不進則退。職業選擇不主動，就會很被動。
-
尋找機會拓寬你的生活經驗，更好地看到世界需要什麼。 認知決定了人的發展速度和質量。有用的東西才會發展起來。 應該創造世界所需要的產品，而不是閉門造車出門不合轍。
-
雖然快速決策和執行的生產力很高，但是錯誤決定的代價大於等待的代價。 方向正確越快越好，方向錯誤越快越糟。
-
經驗是生產力的關鍵，更高的生產力將提供更多的經驗：這是一個良性迴圈。 所以，不要原地踏步，不要故步自封，妹妹你大膽地向前走啊，向前走。。。
最重要的忠告
- 多運動，注意身體！多運動，注意身體！多運動，注意身體！