《編程珠璣(續)》計算機科學箴言

時間 2019-12-07

標籤編程珠璣(續) 計算機科學箴言简体版

原文原文鏈接

因爲搜索引擎收錄及編輯問題，從https://taceywong.github.io/遷移至此.git

如下爲原文：
程序員

真真是字字珠璣，因此我全抄了。github

剽竊便是最誠懇的恭維算法

——佚名編程

編碼

若是好沒想清楚，就用蠻力算法吧。
不要使用反正弦和反餘弦函數——你總能用優美的恆等式，或者是計算向量點積來更好地解決這些問題.
在存儲日期的年份的時候，請使用四位數字：千禧年快要到了。（我挺心疼日本和中國的程序員的）
避免不對稱結構
代碼寫的越急，程序跑的越慢
你用英語都寫不出來的東西就別期望用代碼寫了。（此處英語指代人話、天然語言）
注意細節
若是代碼和註釋不一致，那極可能二者都錯了
若是你發現特殊狀況太多，那你確定是用錯方法了
先把數據結構搞清楚，程序的其他部分自現（對於一個多個組件的系統，現把通訊「協議」搞清楚）

用戶界面

【最小驚異原則】儘量讓用戶界面風格一致和可預測
計算機生成的輸入一般讓一個本來設計接受手工輸入的程序不堪重負
手工填寫的表單中有20%都包含壞數據
80%的表單會要你回答不必的問題
不要染過那個戶提供那些系統已知的信息
全部數據集的80%中，有95%的信息量均可以用清晰的圖表示（對於人類大腦，有時一圖勝千言）

調試

在我全部的程序錯誤中，80%是語法錯誤，剩下的20%裏，80%是簡單的邏輯錯誤。在剩下的4%中，80%是指針錯誤。只有剩餘的0.8%纔是困難的問題
在系統測試階段找出並修正錯誤，要比開發者本身完成這一工做要多付出2倍的努力。而當系統已經交付使用以後找出並修正一個錯誤，要比系統測試階段多付出9倍的努力，所以，請堅持讓開發者進行單元測試吧。
不要站着調試程序，那會使得你的耐心減半，你須要的是全神貫注
別再註釋裏陷得太深——註釋極可能會誤導你，你要調試的知識代碼
測試只能證實程序有錯誤，而不能證實程序沒有錯誤
新系統的每個新用戶均可能發現一類新的錯誤
東西沒壞，就別亂修
【維護者箴言】若是咱們沒能力修好它，咱們就會告訴你它壓根沒壞
修正程序錯誤的第一步是先重現這個錯誤

性能

【程序優化第一法則】不要優化。【程序優化第二法則——進隊專家適用】仍是不要優化
對於那些快速算法，咱們老是能夠拿一些速度差很少可是更容易理解的算法來替代他們
在一些機器上，間接尋址比基址尋址要慢，因此請把結構體或者記錄中最經常使用的成員放在最前面(這個在現今這個時代除非是核心部分，基本沒有必要這麼苛刻了)
在一個非I/O密集型的程序中，超過一半的運行時間是花在不足4%的代碼上的
在優化一個程序以前，請先用性能監視器工具找到程序的「熱點」
【代碼規模守恆定律】當你爲了加速，把一頁代碼編程幾條簡單的指令時，請不要忘了增長註釋，以使源碼的函數保持爲一個衡量（😁哈哈😄）
若是程序員本身模擬實現一個構造比編譯器自己實現那個構造還要快，那邊一塊兒的做者也是太失敗了
要加速一個I/O密集型的程序，請首先考慮全部的I.O，消除那些沒必要要的或冗餘的I/O，並使餘下的部分儘量的快（有些I/O沒辦法消除，起碼在工程上消除會形成很大的麻煩）
最快的I/O就是不I/O
那些最便宜、最快並且可靠性最高的計算機組件壓根兒就不存在
大多數的彙編語言都有循環操做，用一條機器指令進行一次比較並分支；儘管這條指令視爲循環設計的，但在作普通的比較時每每也能聽派上用場，並且頗有效
【編譯器做者箴言——優化步驟】把一個原本就錯了的程序變得更糟糕毫不是你的錯
電每納秒傳播一英尺
Lisp程序員知道全部東西的值，殊不知道那些東西的計算成本

文檔

【否認測試】若是一句話反過來就必然不成立，那就根本不必把這句話放進文檔
當你試圖解釋一條命令、一個語言特性或是一種硬件的時候，請首先說明它要解決的問題（嗯嗯，深覺得然）
【一頁原則】一個「規格說明、設計、過程、測試計劃」若是不能再一頁信紙上寫明白，name這個東西別人就沒辦法理解
紙上的工做沒有結束，整個工做也就還沒結束

軟件管理

系統的結構反映出構建該系統的組織的結構
別堅持作那些沒用的事
【90-90法則】前90%的代碼佔用了90%的預訂開發時間，餘下的10%代碼又花費了90%的預訂開發時間
只有不到10%的代碼用於完成這個程序表面的目的，餘下的都在處理輸入和輸出、數據驗證、數據飢餓否維護等家務活
正確的判斷來源於經驗，然而經驗來源於錯誤的判斷
若是有人基本上作出了你想要作的東西，你就不必本身寫一個新程序。就算你非邪不可，也請儘量多地利用現有的代碼
代碼能借用就借用
與客戶保持良好的關係可使生產率加倍
把一個現有成熟程序轉移到一種新語言或者新平臺，只須要原來開發的十分之一的時間、人力、成本
那些用手作就已經很快了的事情，就不要使用計算機去作了（~~~~）
那些能用計算機才迅速解決的問題，就別用手作了
我想寫的程序不僅是程序，並且是會寫程序的程序
【Brooks原型定律】計劃好拋棄一個原型，這是早晚的事
若是開始就打算拋棄一個原型，那恐怕你得拋棄兩個
原型方法能夠將系統開發的工做量減小40%
【Thompson望遠鏡學徒定律】先作一個4英尺鏡片的望遠鏡，再作一個6英尺的鏡片的，這比直接作6英尺鏡片的更省時間。
拼命幹活沒法取代理解
作事應該先作最難的部分。若是最難的部分沒法作到，那還在簡單的部分上浪費時間幹嗎？一旦困難的地方搞定了，那你就勝利在望了。作事應該先作最簡單的部分。你開始所預想的簡單部分，作起來多是頗有難度的。一旦你把簡單的部分作好了，你就能夠全力攻克最難的部分了