编码规范是技术上的遮羞布

每个程序员都知道,在一个软件公司里,你需要有一套严谨的编码规范。每个程序员也都知道,为了能按自己的编程习惯制订这套规范,每个程序员都在而抗争。刚进入一个新公司时,每个程序员都会内心里绝望,对那套由某些强势架构师独断指定的编码规范恐惧不已。

扔掉编码规范吧,让程序员自由发挥,你会得到更多的好处。从加强代码统一性上获得的这点胜利根本解决不了问题。编码规范就是技术上的遮羞布。在 nearForm 公司,我从来没有想过要制定一个这样的规范,因为我希望每个人都只需按照自己喜欢的方式编程。

编码规范是技术上的遮羞布

这世界太吵闹了。JavaScript的复兴要为此负全责。尤其有一个“特征”:可有可无的分号。无数的主张猜想反对声铺天盖地。停止,去实际写些代码好吗。你知道我在说谁。

本意是好的,各路程序员大仙发布各种JavaScript编码规范和风格指导。你们全错了。请停止这种要去拯救这个世界的行为。

编码规范从何来?过程是这样的:在你开始编码时,你跟本不知道会做出什么。这充满乐趣,这是一场游戏,直到你弄瞎一只眼睛。一旦你被自己垃圾的代码伤了太多次,你开始知道你是个菜鸟。于是你开始走上了通往编程大师的道路,你贪婪的咀嚼《代码大全》和《程序员修炼之道》。当然还有 Joel

之后,事情开始发生了。在通往朝圣的路上,你参透了真经。满腹的技艺让你成为了编程巨星。你的开发效率整整翻了一倍。现在,你要向世界传播。让你有今天成就的知识也同样能拯救他人。你笼络人心,你传道,你纠缠不休。你训导你的老板要采用最好的实践方法和开发规范。而最不可饶恕的,你竟然开始写博客了。

大多数程序员从来不发声。那些喜欢弄出声响的,都晋升了。你晋升了。你把你绝顶聪明的想法强加给他人。你编写了一套编码规范,你让它成为了法律。

可之后,一切如旧。同样苦干,同样最后期限迫在眉睫,同样bug无数,同样悲惨结局。银弹跟本不存在

几年后,你不再编码,你成为了管理者。你仍然认定编码规范,条律,制度的至关重要。关键就在于正确的实施。你从来都没有真正的做到过,但你坚持要实现这个目标。不仅如此,你变本加厉。代码量化标准!作为一个管理者,你成了痛苦的化身。

也许事情可能会向另外一个方向发展。也许你重新回去编程,或从未离去。经过一段时间,你发现自己如此无知,所有你的梦想都建立在沙滩上。你放弃了,你放弃了给程序员制订枷锁。这是另一层次的参悟。

至此,你认识到,人不是机器。人需要把智慧发挥到极致。你应该丢掉枷锁,获取最大创造。

可为什么那些最聪明的程序员的做法却完全的相反?为什么他们喜欢控制其它程序员?是什么让他们如此独裁?

首先,你想把你的经验传授给他人。但并非每个人的思维都跟你一样。人的大脑是十分怪异的

第二,控制别人的感觉良好。但这不可能真正有效的。你不能命令程序员去做什么。猫不是圈养出来的。

第三,你逃避责任。团队中的所有人都这样。我们遵守了规范!项目失败了。没错,可是我们是遵守了规范!

第四,好的意愿;最佳实践;很专业;很技术——诱人的开发过程。你仍在追逐你8岁时想摘到的那颗星星。但是,编程大师如何判断一件事的成败?看结果,这是唯一的标准。

第五,理想主义,你认为你理解整个世界,整个世界要尊崇你的意志。我们人类有些事情非常的在行….但那是在一万次的失败之后,一万次重复的失败。软件工程就是其中之一,不是有了规范就万事大吉的。

而最糟糕的不是这些。万恶之首是,只要你具有上面的任何一点,你最终就会制定出一套编码规范。

编码规范真正的罪恶在于,它们在伤你的心,伤整个团队的心。它们是一种耳语在说你不够优秀。他们不信任你。没有监管,你会搞的一团糟。

一年前我们开创 nearForm 公司,我们最在意的一件事就是要为客户写出最优秀的程序。在早先,我们尝试过所有的开发过程、方法、制度规范。所有都让人讨厌。没有一样真正起到作用。

于是我们开始实施这样的原则:相信我们的程序员是最有智慧的。这起作用了。

我希望所有人都能写出整洁优秀的代码。你自己判断这指的是什么。如果在代码脏乱、变量名不一致的情况下你还能安稳的睡大觉,这你自己决定。但你知道,也许这只是一个100行的用node.js写微型server,无关紧要。这你自己决定。

这你的责任,因为你一名程序员。

收藏 12 评论

相关文章

可能感兴趣的话题



直接登录
最新评论
  • Phoenix   2013/07/15

    同一种代码风格有利于阅读,并不是为了减少Bug!

  • madre   2013/07/15

    这货是不是从来没维护续开发过别人的代码!?
    规范神马时候是用来防止bug的?至少在我们公司里完全是为了让c、 python、java、php这些出身不同的程序员,在参与同一个项目时或者维护离职的某员工写的代码时,能在最快的时间读懂代码、续开发。
    这货肯定是没维护过用c和php风格写出来的让人吐血的python代码,才敢在这里狂言!

  • ttt   2013/07/15

    作者见的奇葩太少

    见过[[[node getChildById:6]getChildById:1]getChildById:5].visible=NO

    这样的程序么?

  • zz   2013/07/15

    必要的规范约束在团队协作开发中是有益的,代码更容易维护,但只是不该过重便是。

    人员多了,有规范约束,有利于有序协作!!

    作者看来是被编码规范伤害过了,但很可能只是某些个人作风问题..还是回到那句话,凡是有度,规范也不宜过重,需要适当留有发挥的空间,团队协作需要求同存异!

  • 我还以为作者要抨击现有的编程语言呢!
    希望作者开发出一个不用代码规范的语言。

  • 多蒙菜   2013/07/17

    评论比文章更有意思。

  • 喵喵喵   2013/08/02

    对于各楼的过度强调可读性的评论我只想说一句话
    你们读汉字是看别人字体拆开一笔一笔读的么
    不写成宋体就影响阅读效率了么
    那样这的话文字序顺和笔就画严重影阅响读效率才了是
    要快速读懂代码真不关规范的事,请看Code Reading: The Open Source Perspective

    • G   2013/08/02

      其实我也想说一句,我们看汉字不是一笔一笔的看的,但是一笔一划要写清楚,狂草读起来还是比较吃力的

      • 喵喵喵   2013/08/04

        其实我第一句话强调了是‘过度’强调,
        而且对于书家而言狂草是基本功,写也是要通过读来学习的,如果‘非常’吃力是学习不够,不能怪写字的人乱写(这句话有点偏非码农向。)。

        上面的引号都是强调。

  • 一句话,没有规范是不行的。
    只是“规范”要尽量避免“个人喜好”型的条款

  • frd   2013/10/30

    说的挺对, 尤其那些把排版风格当成编程风格的, 比如 { 的位置,
    缩进空多少, = 两边必须有空格,
    这些即使需要,应该交给软件自动化处理,而不是一边写代码,一边还得记着这些麻烦的教条

跳到底部
返回顶部