學習筆記之三十年軟件開發之路 - Things I Learnt The Hard Way (in 30 Years of Software Development)

三十年軟件開發之路

• https://mp.weixin.qq.com/s/EgN-9bIHonRid1DM0csQDw
• https://blog.juliobiason.net/thoughts/things-i-learnt-the-hard-way/
• 【CSDN編者按】「千帆過盡仍少年」，對於程序員來講，保留技術初心、不斷提高實力是夯實本身的不二法則。而本文的做者，做爲一名有着三十多年開發經驗的「老」程序員，就在本文中詳細總結了本身這些年踩過的坑和實踐得出的真理，談到了包括軟件開發、團隊工做、我的成長等方方面面。

---

• 軟件開發
  • 先明確問題，再開始寫代碼
  • 將步驟寫爲註釋
  • Gherkin是幫助你瞭解指望（expectation）的好幫手
  • 單元測試很好，集成測試更好
  • 測試可讓API更好
  • 作你知道如何在命令行上運行的測試
  • 時刻準備好扔掉你的代碼
  • 好的語言生來帶有綜合測試
  • 將來思路是垃圾思路
  • 文檔是寫給將來本身的情書
  • 功能文檔是份合同
  • 若是一個函數的描述包含「和」，這就是不對的
  • 不要使用布爾型變量做爲參數
  • 注意界面的變化
  • 好的語言自帶集成的文檔
  • 一門語言毫不僅僅是一門語言而已
  • 有時候，寧願讓應用程序崩潰也不要什麼都不作
  • 若是你知道如何處理該問題，那麼就處理它
  • 類型決定你的數據是個什麼東西
  • 若是你的數據具備模式（schema），請使用結構（structure）來保留它
  • 理解並保持cargo cult的方式
  • 不要管所謂的「合適的生產力工具」，你只須要盡力去push進程
  • 「正確的工具」比你想象的更明顯
  • 不要跟你項目以外的事情糾纏
  • 數據流動比模式更重要
  • 設計模式是用來描述解決方案的，但它不能找到解決方案
  • 學習函數式編程的基礎知識
  • 認知成本是可讀性的殺手
  • Magical Number 7 ，正負二（7+-2的範圍內）
  • 走捷徑挺nice的，但只是在短時間內如此
  • 抵制「輕鬆」的誘惑
  • 老是在你的日期中使用時區
  • 老是使用UTF-8
  • 從笨辦法開始
  • 日誌用於事件，而不是用戶界面
  • Debugger們被高估了
  • 始終使用版本控制系統
  • 每次提交一個更改
  • 當你過分交換時，「git add -p」是你的朋友
  • 按數據/類型組織項目，而不是功能
  • 建立庫
  • 學會監控
  • config文件是個好東西
  • 命令行選項很奇怪，但頗有幫助
  • 不單單是功能組成，還有應用程序組成
  • 即便是作APP，也要從原始的東西開始
  • 優化是面向編譯器的
  • 經過懶惰（評估）
• 在團隊/工做上
  • code review並非爲了彰顯風格
  • 代碼格式化工具還能夠，但它們也不是無往不勝的
  • 代碼風格：遵循它就是了
  • ...除非代碼樣式是Google Code樣式
  • C / C ++只有一種編碼風格：K＆R
  • Python只有一種編碼風格：PEP8
  • 顯式優於隱式
  • 公司想要專才，但全才在公司待的時間更長
  • 心中有用戶
  • 處理用戶數據的最佳安全方法是壓根不捕獲它
  • 記下來那些「讓我花了一個多小時才解決的愚蠢失誤」
  • 若是它沒法在你的計算機上運行，那麼你就有麻煩了
• 我的生活
  • 該停下來的時候，就停下來吧
  • CoC保護的是你，而不是別人
  • 學會說不
  • 你負責你代碼的使用
  • 當還沒完成時，不要說「已經完成了」
  • 你將從痛苦中瞭解你自身
  • 人們之因此會對代碼/架構感到生氣/煩惱，是出於關心
  • 從你的煩惱中學習
  • 注意人們對你的反應
  • 學會識別那些人格有毒的人，並遠離他們
  • 謹防微觀侵略
  • 不，我不認爲這樣的人是「會改正的」
  • 只有當你意識到本身是那類有毒的人/微侵略者時，纔有可能本身改正
  • 英雄項目：總有一天你必須作的事情
  • 不要混淆「英雄項目」與「英雄綜合症」
  • 知道什麼時候該果斷辭職
  • IT世界是一個很是小的「蛋」
  • 紙質筆記實際上頗有幫助
  • Trello很是酷，但Post-it更好
  • 在博客中記錄你笨手笨腳的解決方案仍然比什麼都不寫要好
  • ...但請關閉評論
  • 把你的笨手笨腳的解決方案發布到網上
  • 列出「我不知道的事情」