.
前言這些守則是怎麼來的?如果你不認同這裡的守則,該怎麼辦?守則1 | 越簡單越好、但也不能太過於簡單守則2 | Bug 是會傳染的守則3 | 取個好名字,本身就是最好的說明守則4 | 先找出三個例子,才能改用通用的做法守則5 | 最佳化的第一課—別去做最佳化 插曲:針對前一章內容的一些批評守則6 | 程式碼審查有三大好處守則7 | 消除掉各種會出問題的狀況守則8 | 沒在執行的程式碼,就是會出問題守則9 | 寫出可收合概念的程式碼守則10 | 把複雜性局限在局部範圍内守則11 | 有比之前好兩倍嗎?守則12 | 大型團隊一定要有很強的約定慣例守則13 | 揪出引發雪崩的那顆小石頭守則14 | 程式有四種風格守則15 | 拔草囉守則16 | 要從結果往回推,別從程式碼往後推守則17 | 有時大問題反而好解決守則18 | 讓程式碼自己講故事守則19 | 以平行方式進行改造守則20 | 還是要用數學算一下守則21 | 有時你就是得去做一些敲釘子的工作 結論:制定出你自己的守則附錄A | Python程式設計師如何看懂C++附錄B | JavaScript程式設計師如何看懂C++
全棧測試|交付高品質軟體的實務指南 資料治理技術手冊 流暢的 Python|清晰、簡潔、高效的程式設計 第二版