引言
本文摘錄《程式設計守則》一書的要點。
內文摘錄
越簡單越好、但也不能太過於簡單(As Simple as Possible, but No Simpler)
簡不簡單怎麼衡量呢？
有時候簡化問題比簡化解法更重要。
別破壞故事的流暢性。
所有守則都要遵守的守則。
Bug是會傳染的(Bugs Are Contagious)
不要指望你的使用者。
別太信賴前來調用的那一方。
取個好名字，本身就是最好的說明(A Good Name Is the Best Documentation)
不要混用不同的約定慣例做法。
先找出三個例子，才能改用通用的做法(Generalization Takes Three Examples)
過早採用通用做法真正的危險之處ー你不但會去實作出一些永遠用不到的功能，而且你所採用的通用做法，實際上還會給你限定出一個難以改變的方向。
最佳化的第一課ー別去做最佳化(The First Lesson of Optimization Is Don’t Optimize)
第二課，口說無憑，有測試才有真相。
第1步驟：測量並找出慣式碼與處理器時間的關係；
第2步驟：確認一下已經沒有什麼bug了；
第3步驟：衡量一下你所要處理的資料；
第4步驟：做計畫、建立原型設計程式碼；
第5步驟：進行最佳化，並重複以上步驟。
最佳化已經沒有第三課了。
程式碼審查有三大好處(Code Reviews Are Good for Three Reasons)
你可以找出一些bug。
每個人都會更加理解程式碼。
大家都會去寫出讓自己樂於分享的程式碼。
消除掉各種會出問題的狀況(Eliminate Failure Cases)
關於你自己的設計，你一定要問自己一個很關鍵的問題，那就是：「我究竟讓這個功能或界面的使用者，有多麼難以搬石頭砸自己的腳？」
沒在執行的程式碼，就是會出問題(Code That Isn’t Running Doesn’t Work)
去找出一些已經被孤立的程式碼，然後放心地把它刪除掉吧！
寫出可收合概念的程式碼(Write Collapsible Code)
如果你的程式碼能善用團隊裡每個人都能理解的抽象或模式，相較於自己去發明新的抽象或模式，前面的做法肯定更容易閱讀。
把複雜性局限在局部範圍內(Localize Complexity)
如果真的無法消除複雜性，那就把它隔離開來。
有比之前好兩倍嗎？(Is It Twice as Good?)
往前邁進的三條道路：忽略、調整、重構。
大型團隊一定要有很強的約定慣例(Big Teams Need Strong Conventions)
格式上的約定慣例。
程式語言使用上的約定慣例。
解決問題的慣例做法。
在有效率的團隊裡，大家想的東西都很像。
揪出引發雪崩的那顆小石頭(Find the Pebble That Started the Avalanche)
這裡所要談的是，如何寫出比較容易進行除錯的程式碼。
程式碼有四種風格(Code Comes in Four Flavors)
| 簡單的問題 | 困難的問題 | |
| 簡單的解法 | 可以預期 | 可以追求 |
| 困難的解法 | 真的非常糟糕 | 可以接受 |
拔草囉(Pull the Weeds)
比喻裡的雜草，究竟是指什麼東西呢？它指的就是那些很容易修正、但也很容易被忽略的小問題。
定義你所發現的問題是否為雜草，主要的考慮就是安不安全。如果你能很安全地修正這個問題，那它應該就是要被拔掉的雜草。
要從結果往回推，別從程式碼往後推(Work Backward from Your Result, Not Forward from Your Code)
程式設計的目的，其實是為了幫相隔的兩邊搭起一座橋梁。你總有一些想解決的問題，也有一堆程式碼和技術可供使用。這兩者總是被分隔在兩邊。你可以試著擴展手中的程式碼，用新的方式把它一點一滴重新組合起來，為兩邊搭起一座橋梁，一次解決一點問題，直到完全解決為止。
有時大問題反而好解決(Sometimes the Bigger Problem Is Easier to Solve)
一些比較簡單、無聊的做法，卻「幾乎」總是最好的做法。
「通用解法就是更簡單的解法」這樣的例子，全都是「在視角上必須做出重大改變」的情況。
讓程式碼自己講故事(Let Your Code Tell Its Own Story)
不要講不真實的故事。
確保你所說的故事是有意義的。
好好說出一個故事。
以平行方式進行改造(Rework in Parallel)
我們並不會直接就地改動系統，而是先打造出一個平行的系統。當其它人的工作還在進行時，新的系統就會被簽入進來，不過只有參與新系統相關工作的小團隊，才有能力去「啟用」這個新的系統(透過執行階段的一個開關)來繼續他們的工作。團隊裡大多數的人都還是繼續使用老系統，並不會接觸到那些新的程式碼。如果新的系統準備就緒了，我們就可以利用這個執行階段的開關，讓每個人都去啟用這個新系統。一旦每個人都可以順利使用這個新系統，我們才會把老系統從專案裡刪除掉。
還是要用數學算一下(Do the Math)
程式設計者所做出的決定，有很多是模模糊糊而沒有那麼明確的。
有時你就是得去做一些敲釘子的工作(Sometimes You Just Need to Hammer the Nails)
不要再跳過苦差事了。
參考文獻
https://www.gotop.com.tw/books/BookDetails.aspx?Types=o&bn=A741
https://www.oreilly.com/library/view/the-rules-of/9781098133108
沒有留言:
張貼留言