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

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

1.Bug 還沒修復，軟件能不能上線？

 

1. 軟件發(fā)布前，應該編寫完整測試，充分調試，盡量修復所有bug。

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

    

    

2.容易出錯的特性，是否應該用在程序中？

 

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

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

    

3.新的語言或語法是否應該有所限制？

 

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

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

    

    

4.靜態(tài)檢查是否必要？

 

1. 編譯器的安全檢查很重要，不能進行靜態(tài)檢查的代碼通常是不可接受的。

2. 代碼應該短小精悍，靜態(tài)檢查工具可能會讓代碼變得又臭又長。

    

    

5.數(shù)據(jù)是否一定要有格式定義？

 

1. 數(shù)據(jù)必須遵循事先定義好的格式。比如，關系型數(shù)據(jù)庫必須滿足第三范式或UML，XML都必須有DTD，NoSQL數(shù)據(jù)庫必須有單獨的格式定義（標明所有允許的鍵，以及相應的值類型）。

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

    

    

6.公共接口是否應該靜態(tài)化？

 

1. 公共接口必須嚴格建模。數(shù)據(jù)絕不可以是無類型的，所有的輸入輸出實體都必須完整顯式地定義為可以靜態(tài)檢查的模型。

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

    

    

7.是否可以留有方便修改的后門？

 

  A.生產(chǎn)系統(tǒng)里絕不允許存在危險或有風險的后門。想要通過調試器、SSH、或任何接口，連接到工作中的生產(chǎn)系統(tǒng)，去修改運行時的代碼或數(shù)據(jù)，應該是不可能的。
  B.系統(tǒng)的靈活性，有時能決定客戶或合同是歸你還是歸對手。至于生產(chǎn)系統(tǒng)的安全隱患，可以通過日志、監(jiān)控、審核等手段來緩解。事實證明，很多有最高權限后門和Shell 接口的大型系統(tǒng)，都做到了在控制風險的同時具備運行靈活性。

 

 

8.急需的但有安全隱患的系統(tǒng)，是否可以上線？

 

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

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

    

    

   
   

9.代碼運行較慢，是否要去解決？

 

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

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

    

    

10.你最認可的語言是哪一個？

 

A. C++、Java、C#、D、Go、Clojure、Ada、Ocaml、Eiffel、Clojure、Erlang、Pascal、Haskell、SML。
B. C、Objective-C、JavaScript、Visual Basic、Lua、Scheme、Python、Common Lisp、Smalltalk/Squeak、Perl、Ruby、PHP，Bash。

 
結論

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

 

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

 

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