2012-02-05 31 views
2

我一直認爲防禦性編程是邪惡的(我仍然這樣做),因爲通常我的經驗中的防禦性編程總是涉及基於不可預知的結果的某種不合理的犧牲。例如,我看到很多人試圖對自己的同事進行防守編碼。他們會做些事情「以防萬一」代碼稍後以某種方式改變。他們最終會以某種方式犧牲表現,或者在任何情況下都會採取一些銀彈。這是防守編程嗎?

這個具體的編碼習慣是否被視爲防禦性編程?如果不是,這種做法會被稱爲什麼?

維基百科防禦性編程定義爲軟件的不可預知使用保護,但並不說明針對其他程序員的代碼完整性防禦性編程策略,所以我不知道這是否適用,也沒有人知道這就是所謂的。

基本上,我希望能夠與這樣做,並告訴他們自己在做什麼是錯的,以專業的方式將人們爭辯。我希望能夠客觀地反駁這一點,因爲它有害無益。

+0

執行代碼複審,當其他成分發生變化,我相信,被稱爲「依賴注入」,總稱「模塊化」下下降有一個在編碼標準.... – 2012-02-05 04:28:52

+0

甚至使你的代碼工作的同意,並且是一個好想法。 – bdares 2012-02-05 04:47:51

+1

如果您對自己的同事進行防禦性編碼,則問題將無法通過編寫代碼來解決。我會建議召開一次會議。 :) – 2012-02-05 05:03:59

回答

2

「過度工程」是錯誤的。

「防禦性編程」很好。

這需要智慧,經驗......也許頻繁的代碼審查的常設政策...分辨。

+4

PS:我會考慮「檢查返回值」和「驗證輸入」爲「防禦性編碼」。我認爲,「僅僅在我的同事可能終有一天會改變他的代碼的機會上,額外的代碼纔會變得愚蠢而且沒有生產力」。 – paulsm4 2012-02-05 04:36:46

1

這一切都取決於具體情況。如果您正在開發可供其他程序員重複使用的軟件,那麼至少要進行一些防禦性編程是有道理的。例如,您可以記錄所有需要的輸入要求,但有時您需要測試輸入實際符合要求以避免災難性行爲(例如銷燬數據庫)。這通常涉及(微不足道的)性能問題。

在另一方面,防禦可能的方式有些過頭。也許這就是通知你的觀點。一個或兩個具體的例子將有助於區分正在發生的事情。