- 最新式的電腦，只不過是加速加重了人與人之間一直以來的問題，最終，溝通者要面對的，依然在於如何表達出自己要說的
- 技術債 (technical debt) 就像貸款，你可以為了時程決定「先快速做完」，而不是「做好」，你會在短期內得利，但在債務還清之前都必須支付利息。滿足一時的程式碼，會使新增功能與重構變得困難。時間越久，傷害越大。事實上，往往都是當事情糟到你不得不修正時，你才會真的回頭去解決當初的問題，但是這時候程式碼已經變得很難修正。
- 記得要儘快償還技術債 (technical debt)，否則會因為草率的行為而嚐到惡果。
- 我們常認為別人的想法和我們一樣，但事實上不是。心理學將此稱為共識偏誤（false consensus bias)。請直接去問使用者會怎麼操作，你不算是使用者
- 使用者傾向於只要有能用的方法就好，他們一旦找到一種可行的方法之後，就會一直用，不論這個方法是多麼迂迴。因此，最好準備一條明顯的道路，而不是給兩三種道路供選擇
- 你也會發現使用者所描述的，和他們實際做的往往有段落差。因此最好的方法是直接觀察使用者，花幾個小時觀察，比起花一整天想使用者到底要什麼，反而可以得到更多資訊
- coding standard 應該是靈活不死板的，隨著專案演進，需求改變，一些當初看似聰明的想法，在幾個月後已經不見得聰明了
- 柏拉圖曾說：風格之美、和諧、優美與節奏取決於簡約。美麗的程式的最低限度是簡單的程式碼。不只職責簡單，與系統的其他部分也要保持簡單的關係。簡單、乾淨、可測試的程式碼，可以提高可讀性、可維護性、開發效率。美，就在簡單中誕生，在簡單之中發現
- 在你重構前，你要思考：
- 從現有的程式碼與其對應的測試開始，從當前系統的錯誤中學到教訓
- 避免全部重寫的誘惑，重寫代表要放棄經年累月的測試
- 多次漸進式的修改會優於一次大量的修改
- 每次development iteration結束後，要確保現有的測試都必須通過
- 程式碼的結構與風格不符合你的喜好，不是重構的正確理由
- 新技術的出現不足以成為重構的理由
- 每個人都是會犯錯的，重構不保證新的程式碼一定比較好
- 童子軍有一條規則：『每次離開營區時，都要讓它比剛到的時候更乾淨』。也就是說，如果你發現環境髒亂，不管是誰造成的，你都要把它打掃乾淨，留給下一批露營者有更好的環境。相同的，你不必在 check in 前讓每個模組盡善盡美，只要讓它比當初 check out 的時候好一點點就可以，如改善了變數名稱、將一個過長的function拆成兩個小的function等。軟體開發團隊要互相幫助，互相清理程式碼。成員門遵循童子軍規則，不只是為了自己，而是因為這對每一個人都好。
- Debug 時，回想福爾摩斯的建議：「除去不可能的，剩下的即使不尋常，那也是真相。」
- 面對multi-thread 的系統，簡潔的設計非常重要，簡潔代表容易debug
- 程式碼的排版很重要，有研究指出，我們花在瀏覽和閱讀程式碼，找出哪裡該修改的時間，比實際修改的時間多更多。所以程式排版有三個優化措施：易於瀏覽、清楚的排版、緊湊的格式
- code review 不只是找出並修正程式錯誤，更重要的是分享知識，並建立普遍的coding方針。code review 的重點是在 review 的過程當中去學習、了解這些程式碼
- 採用表達力佳（但相對較短）的名稱來命名物件、型別與函式，讓程式碼本身具備如文件的說明能力
- 註解應該要說出程式碼所沒有表達、也無法表達的事情。如果程式自己可以說清楚的事情，你就不需要為它加上註解
- 外科醫生知道必須要切出傷口才能進行手術，也知道傷口是暫時的，會痊癒的。害怕改變程式碼導致癱瘓，可能正是造成系統落入癱瘓的起點。投入時間 refactor，對於專案的整個生命週期可以帶來數倍的價值，也因為有了處理病態系統的經驗，也成為了解系統應當如何運作的專家
- 無論你認為你的程式碼有多麼不可能出現錯誤，你也應該每一次都檢查並處理，即使你現在不做，你也不會省下時間，你未來還是要還債，而且累積越久，要還的債更多，未來會連本帶利要你償還
- 如果你忽視一項錯誤，選擇視而不見，假裝沒這件事情，你其實在承擔巨大的風險，你也無法預料這個巨大的風險會在何時向你反撲。
- 放著錯誤不管會造成
- 脆弱的程式碼且難以debug
- 不安全的程式碼
- 糟糕的結構
- 沒有開發經驗的專案經理會認為程式設計師做的事情很簡單，而沒有管理經驗的程式設計師，也認為專案經理做的事情很簡單
- 軟體的構成實體，應當對於擴充保持開放，但對修改保持封閉
- DRY ( Don’t Repeat Yourself ) 的原則，是指開發人員要學會便是重複的程式碼，也懂得利用更好的實踐和更適當的抽象化來消除重複，比起只知道用不必要的重複來污染程式的人，可以產出更乾淨的程式碼。DRY 原則，位開發人員提供基本指引，幫助開發人員所產出的程式變得更簡單、更容易維護且品質更好
- 假設有個物件，其典型的特色是需要先完成幾件事情才能開始使用，此時就可以使用abstract factory pattern or factory method pattern 來實現。如果某個物件有多種可變的行為，那麼這些行為可以用strategy pattern 來實作並放進物件，不該用一個巨大的 if-else 結構
- 當一個class 的containment (封裝）被破壞，常會看到其method 出現大量的if-then-else的結構，這樣的method 很容易崩壞且幾乎無法維護
No comments:
Post a Comment