程序員(程式設計師)小測試:保守派 vs 自由派

程序員(程式設計師)小測試:保守派 vs 自由派

程序員(程式設計師)小測試:保守派 vs 自由派


資料來源:http://www.ruanyifeng.com/blog/2016/09/conservative_vs_liberal_programmer.html

下面一共有十個問題,每個問題都有 A B 兩個選項,請選擇你的答案。

問題一:Bug 還沒修復,軟件能不能上線?

A)軟件發布前,應該編寫完整測試,充分調試,盡量修復所有bug

B)不管多努力,bug 總是無法避免的,如果性質不是很嚴重,可以先上線,根據反饋再調試和修補。

問題二:容易出錯的特性,是否應該用在程序中?

A)很多語言的高級特性都是很容易出錯和危險的,應該禁止用在代碼里。沒有這些特性我們一樣可以進行開發,代碼也會因此變得更安全。

B)聰明的程序員有學習動力,知道怎么可以解決問題。為了避免出錯,就立下一堆規矩,完全不可取。

問題三:新的語言或語法是否應該有所限制?

A)公司里可以使用的語言數量應該受到限制,這樣萬一系統在半夜或是聖誕夜掛掉的時候,值班的人就不需要去臨時抱佛腳學習新語法了。另外,也應該禁止改變語言原始定義的語法,比如嚴格限制操作符重載和元編程。

B)程序員的學習能力是驚人的,沒必要保護程序員遠離新語法,只要有需要,他們自然能學會。

問題四:靜態檢查是否必要?

A)編譯器的安全檢查很重要,不能進行靜態檢查的代碼通常是不可接受的。

B)代碼應該短小精悍,靜態檢查工具可能會讓代碼變得又臭又長。

問題五:數據是否一定要有格式定義?

A)數據必須遵循事先定義好的格式。比如,關系型數據庫必須滿足第三范式或UMLXML都必須有DTDNoSQL數據庫必須有單獨的格式定義(標明所有允許的鍵,以及相應的值類型)。

B)嚴格的數據定義只會妨礙靈活性,延緩開發進程。更好的策略是寫一些注釋,或者只定義一部分,甚至先略過它。因為在大量用戶案例出現之前,沒人知道數據可能會是什么樣,代碼先行才是正確的做法。

問題六:公共接口是否應該靜態化?

A)公共接口必須嚴格建模。數據絕不可以是無類型的,所有的輸入輸出實體都必須完整顯式地定義為可以靜態檢查的模型。

B)公共接口應該盡量簡單,向前向后都兼容。建模時太過縝密的話,其實只是在猜測接口會怎么演化。

問題七:是否可以留有方便修改的后門?

A)生產系統里絕不允許存在危險或有風險的后門。想要通過調試器、SSH、或任何接口,連接到工作中的生產系統,去修改運行時的代碼或數據,應該是不可能的。

B)系統的靈活性,有時能決定客戶或合同是歸你還是歸對手。至於生產系統的安全隱患,可以通過日志、監控、審核等手段來緩解。事實證明,很多有最高權限后門和Shell 接口的大型系統,都做到了在控制風險的同時具備運行靈活性。

問題八:急需的但有安全隱患的系統,是否可以上線?

A)假如一個組件的安全性存在任何疑慮,那它就不能發布上線,團隊怎么哀求都沒用。

B)企業要保持競爭力,唯有不斷有意識地去承擔風險。就算不去冒險,其他系統急需這個系統,線上可能還是會出問題,既然如此那還不如冒險一試。

問題九:代碼運行較慢,是否要去解決?

A)快比慢好。沒人喜歡慢的代碼,所以代碼的性能一定要好。從一開始,就要有性能意識,那些比較慢的語言和庫都應該避免使用。

B)不要過早優化,代碼先跑起來再說。正確性比性能重要,而原型的快速迭代又比正確性更重要。只有當客戶將性能列為首要問題時,再進行優化。

問題十:你最認可的語言是哪一個?

AC++JavaC#DGoClojureAdaOcamlEiffelClojureErlangPascalHaskellSML

BCObjective-CJavaScriptVisual
Basic
LuaSchemePythonCommon
Lisp
Smalltalk/SqueakPerlRubyPHPBash

結論

如果你的答案有超過一半的 A,你就屬於保守派程序員。你非常重視軟件安全和可靠性,厭惡風險,提倡嚴格管理,認為有效的規章制度是軟件質量的保證。

如果你的答案有超過一半的 B,你就屬於自由派程序員。你重視軟件開發的靈活性,提倡給予程序員足夠的自由,只要新功能順利上線,可以接受一定的風險和瑕疵。

保守派或自由派,都沒問題,都是可取的。問題是一支和諧的團隊最好是由單一人群組成,要么全是自由派,要么全是保守派,免得雙方不停地發生理念上的沖突。

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *