程序员小测试：保守派 vs 自由派

问题一：Bug 还没修复，软件能不能上线？

（A）软件发布前，应该编写完整测试，充分调试，尽量修复所有bug。

（B）不管多努力，bug 总是无法避免的，如果性质不是很严重，可以先上线，根据反馈再调试和修补。

问题二：容易出错的特性，是否应该用在程序中？

（A）很多语言的高级特性都是很容易出错和危险的，应该禁止用在代码里。没有这些特性我们一样可以进行开发，代码也会因此变得更安全。

（B）聪明的程序员有学习动力，知道怎么可以解决问题。为了避免出错，就立下一堆规矩，完全不可取。

问题三：新的语言或语法是否应该有所限制？

（A）公司里可以使用的语言数量应该受到限制，这样万一系统在半夜或是圣诞夜挂掉的时候，值班的人就不需要去临时抱佛脚学习新语法了。另外，也应该禁止改变语言原始定义的语法，比如严格限制操作符重载和元编程。

（B）程序员的学习能力是惊人的，没必要“保护”程序员远离新语法，只要有需要，他们自然能学会。

问题四：静态检查是否必要？

（A）编译器的安全检查很重要，不能进行静态检查的代码通常是不可接受的。

（B）代码应该短小精悍，静态检查工具可能会让代码变得又臭又长。

问题五：数据是否一定要有格式定义？

（A）数据必须遵循事先定义好的格式。比如，关系型数据库必须满足第三范式或UML，XML都必须有DTD，NoSQL数据库必须有单独的格式定义（标明所有允许的键，以及相应的值类型）。

（B）严格的数据定义只会妨碍灵活性，延缓开发进程。更好的策略是写一些注释，或者只定义一部分，甚至先略过它。因为在大量用户案例出现之前，没人知道数据可能会是什么样，代码先行才是正确的做法。

问题六：公共接口是否应该静态化？

（A）公共接口必须严格建模。数据绝不可以是无类型的，所有的输入输出实体都必须完整显式地定义为可以静态检查的模型。

（B）公共接口应该尽量简单，向前向后都兼容。建模时太过缜密的话，其实只是在猜测接口会怎么演化。

问题七：是否可以留有方便修改的后门？

（A）生产系统里绝不允许存在危险或有风险的后门。想要通过调试器、SSH、或任何接口，连接到工作中的生产系统，去修改运行时的代码或数据，应该是不可能的。

（B）系统的灵活性，有时能决定客户或合同是归你还是归对手。至于生产系统的安全隐患，可以通过日志、监控、审核等手段来缓解。事实证明，很多有最高权限后门和Shell 接口的大型系统，都做到了在控制风险的同时具备运行灵活性。

问题八：一个系统是急需的，但有安全隐患，是否应该允许上线？

（A）假如一个组件的安全性存在任何疑虑，那它就不能发布上线，团队怎么哀求都没用。

（B）企业要保持竞争力，唯有不断有意识地去承担风险。就算不去冒险，其他系统急需这个系统，线上可能还是会出问题，既然如此那还不如冒险一试。

问题九：代码运行较慢，是否要去解决？

（A）快比慢好。没人喜欢慢的代码，所以代码的性能一定要好。从一开始，就要有性能意识，那些比较慢的语言和库都应该避免使用。

（B）不要过早优化，代码先跑起来再说。正确性比性能重要，而原型的快速迭代又比正确性更重要。只有当客户将性能列为首要问题时，再进行优化。

问题十：你最认可的语言是哪一个？

（A）C++、Java、C#、D、Go、Clojure、Erlang、Pascal、Scala、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，你就属于保守派程序员。你非常重视软件安全和可靠性，厌恶风险，提倡严格管理，认为有效的规章制度是软件质量的保证。

如果你的答案有超过一半的 B，你就属于自由派程序员。你重视软件开发的灵活性，提倡给予程序员足够的自由，只要新功能顺利上线，可以接受一定的风险和瑕疵。

保守派或自由派，都没问题，都是可取的。问题是一支和谐的团队最好是由单一人群组成，要么全是自由派，要么全是保守派，免得双方不停地发生理念上的冲突。