小测试:你是”保守派程序员”还是”自由派程序员”

最近,我在阅读 Steve Yegg 的文集《程序员的呐喊》。这是一本非常有趣的书,里面甚至包含了一个小测试,区分一个程序员到底是保守派还是自由派。

下面一共有十个问题,每个问题都有 A 和 B 两个选项,请选择你的答案。

1、Bug 还没修复,软件能不能上线?

    1. (A)软件发布前,应该编写完整测试,充分调试,尽量修复所有bug。
    2. (B)不管多努力,bug 总是无法避免的,如果性质不是很严重,可以先上线,根据反馈再调试和修补。

2、容易出错的特性,是否应该用在程序中?

    1. (A)很多语言的高级特性都是很容易出错和危险的,应该禁止用在代码里。没有这些特性我们一样可以进行开发,代码也会因此变得更安全。
    2. (B)聪明的程序员有学习动力,知道怎么可以解决问题。为了避免出错,就立下一堆规矩,完全不可取。

3、新的语言或语法是否应该有所限制?

    1. (A)公司里可以使用的语言数量应该受到限制,这样万一系统在半夜或是圣诞夜挂掉的时候,值班的人就不需要去临时抱佛脚学习新语法了。另外,也应该禁止改变语言原始定义的语法,比如严格限制操作符重载和元编程。
    2. (B)程序员的学习能力是惊人的,没必要"保护"程序员远离新语法,只要有需要,他们自然能学会。

4、静态检查是否必要?

    1. (A)编译器的安全检查很重要,不能进行静态检查的代码通常是不可接受的。
    2. (B)代码应该短小精悍,静态检查工具可能会让代码变得又臭又长。

5、数据是否一定要有格式定义?

    1. (A)数据必须遵循事先定义好的格式。比如,关系型数据库必须满足第三范式或UML,XML都必须有DTD,NoSQL数据库必须有单独的格式定义(标明所有允许的键,以及相应的值类型)。
    2. (B)严格的数据定义只会妨碍灵活性,延缓开发进程。更好的策略是写一些注释,或者只定义一部分,甚至先略过它。因为在大量用户案例出现之前,没人知道数据可能会是什么样,代码先行才是正确的做法。

6、公共接口是否应该静态化?

    1. (A)公共接口必须严格建模。数据绝不可以是无类型的,所有的输入输出实体都必须完整显式地定义为可以静态检查的模型。
    2. (B)公共接口应该尽量简单,向前向后都兼容。建模时太过缜密的话,其实只是在猜测接口会怎么演化。

7、是否可以留有方便修改的后门?

    1. (A)生产系统里绝不允许存在危险或有风险的后门。想要通过调试器、SSH、或任何接口,连接到工作中的生产系统,去修改运行时的代码或数据,应该是不可能的。
    2. (B)系统的灵活性,有时能决定客户或合同是归你还是归对手。至于生产系统的安全隐患,可以通过日志、监控、审核等手段来缓解。事实证明,很多有最高权限后门和Shell 接口的大型系统,都做到了在控制风险的同时具备运行灵活性。

8、急需的但有安全隐患的系统,是否可以上线?

    1. (A)假如一个组件的安全性存在任何疑虑,那它就不能发布上线,团队怎么哀求都没用。
    2. (B)企业要保持竞争力,唯有不断有意识地去承担风险。就算不去冒险,其他系统急需这个系统,线上可能还是会出问题,既然如此那还不如冒险一试。

9、代码运行较慢,是否要去解决?

    1. (A)快比慢好。没人喜欢慢的代码,所以代码的性能一定要好。从一开始,就要有性能意识,那些比较慢的语言和库都应该避免使用。
    2. (B)不要过早优化,代码先跑起来再说。正确性比性能重要,而原型的快速迭代又比正确性更重要。只有当客户将性能列为首要问题时,再进行优化。

10、你最认可的语言是哪一个?

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

分享这篇文章:

5 Responses to 小测试:你是”保守派程序员”还是”自由派程序员”

  1. 宁颖 says:

    我想我可能是开放派

  2. b 对这篇文章的反应是笑死了
  3. lee 对这篇文章的反应是标题党
  4. 网赚助手 says:

    网赚助手评论引流博客大全已经收录了您的网站

发表评论

电子邮件地址不会被公开。 必填项已用*标注

壹加壹等于