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

作者: 阮一峰

日期: 2016年9月 8日

最近,我在阅读 Steve Yegg 的文集《程序员的呐喊》

这是一本非常有趣的书,里面甚至包含了一个小测试(原文),区分一个程序员到底是保守派还是自由派。

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

问题一: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、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,你就属于自由派程序员。你重视软件开发的灵活性,提倡给予程序员足够的自由,只要新功能顺利上线,可以接受一定的风险和瑕疵。

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

(完)

珠峰培训

stuQ

留言(40条)

看来,我是完全自由派...答案全是 B。

保守派的路过.

AABBBBBBBB, 偏自由派

从选项看,所谓保守派或自由派,更多的是在说,面对不同的开发场景所采用的开发策略吧。在大团队中开发需求变更少,性能要求高的关键组件时采用保守的开发风格来确保开发质量,在小团队或个人的非关键作品中采用自由的开发风格来快速响应客户才是明智的考量。做龙袍和做童装应该不太一样吧。

老师,我有个疑问啊,为啥最后一个测试题目里把 Clojure 放在保守派语言中,是因为它是 JVM 上的语言所以划在 Java 阵营么?还是说从语言的特性上就是保守派的?另外,最后一个测试题中 Clojure、Erlang、Pascal 这三种语言重复出现了,应该是写重复了。

在阅读了给出的“原文”链接后找到了答案。文中说“可后来我发现Clojure社区可谓极端保守。”哈哈。于是就把它划做保守阵营了。

各一半。。。。。。

心中的信仰

最简单的就是,经常要善后维护代码的,做的东西能延续几个版本的,A的多;其他做一个项目基本黄一个的,经常玩新玩意的,还可以经常跳槽涨工资的,B的多。

babaaabbab
完蛋,一半一半

the big B

引用dd的发言:

最简单的就是,经常要善后维护代码的,做的东西能延续几个版本的,A的多;其他做一个项目基本黄一个的,经常玩新玩意的,还可以经常跳槽涨工资的,B的多。

这个才是真的……

大部分都是B,可能是因为小公司小团队的缘故吧,没办法按照A的流程来。

我也是跪了。。。

BAAAA
ABBBB

每种理由单独看起来都是如此的充分 无法拒绝

A B B A A
B B B B B

B A B A A
B B B B A

一半一半,然后发现最后一条我用的语言都是A啊,汗

完全的保守派

在公司干活保守派,接私活自由派

悲剧
BAAAB
ABBBA

九个 B 一个 A ,必须的自由派

BAAAA ABB-A

第九题实在中立,无法有明确立场

完全自由派。。

全是B

5 5 开。。。

保守派……

为什么非此即彼呢?

看来我就是个保守派
哈哈

for #5, isn't there auto type in c++????

A A A B A B A A A A

同保守派!

作为一个完全的自由派实践者,我不太同样第10题的答案。自由派应该更喜欢语法严格,容易重构的语言。例如java。不用太多设计,需要变更设计时随时重构。

自由派额

根据自己性格做选择题的话,几乎全部是A,妥妥保守派。但现实开发中,尤其是私活小项目,可能不允许做充分的优化和测试,所以蛮多B情况。

为什么没一个返回顶部的按钮!???????

您提到自由职业者的经营模式和创业家的经营模式不一样,能不能详细说一说?

引用rbq的发言:

这个才是真的……

我其实就像点个赞,阮老师可以追加这个功能的说。一般情况下,A的偏多,毕竟线上安全,稳定是第一生产力的话遍布各个技术公司。面对快速原型开发和好似坐在火山口上的客户来讲,必然的会放弃一些BUG,一些瑕疵,赶紧上线,然后慢慢改(PS:虽然他们从来都不改)。我们一般A的情况都是看着2-3年前的代码,尤其是像我这种强迫症的,都在谩骂前人的代码,然后一行行整齐的加注释加退格....那真是一种折磨。虽然我同意大部分B的观点,但是我相信这种界限模糊的观点往往每个人心中衡量的标准都不一样,我觉得这是一个可怕而且不可控的事儿。

全是B。。。

100% 的 B 选项 0.0

我要发表看法

«-必填

«-必填,不公开

«-我信任你,不会填写广告链接