程序员的“纪律性”(《程序员杂志》署名文章)

作者:travelhop 发布于:2014-11-18 10:46 分类:技术漫谈

这篇文章是我发表在《程序员》杂志2014.11期的一篇短文。现在文章已经见刊,所以转帖到这里来。和大家分享一下我的感受,欢迎讨论。


程序员的“纪律性”




国庆节长假前后,我和很多业内外的朋友们展开了关于“码农”的大讨论,作为这些讨论的延伸,一篇叫做《从“码农”说起》的文章从脑海中输出,最终展现在CSDN官网上。在文章中,我主张年轻的技术人们不应该接受社会舆论强加的“码农”属性,自己做有创造力的事情,要相信付出和智慧一定有回报。此文一出,得到了很多朋友的批评指正,令我颇为欣喜,因为有互动才会有头脑风暴,进而产生更多的新想法。

回顾当时那场大讨论,其中很多观点其实值得深入探讨,比如在讨论中,一位名为“@不动如山_”的朋友是这么说的:

对于软件是不是劳动密集性产业,你认为怎样合理是一会事,现实如何是另一回事。作为老程序员,老SE,我参加过上千人的团队协作,数年的开发周期。所有创造性的工作在预研阶段就必须结束。一旦进入开发,就只有纪律,没有创新。当然,个别高科技产品的原型软件例外


这席话给我很大触动,因为它触及了我进入IT行业之初时青涩经历的回忆。

多年前我刚刚加入不久的团队正在开发某个通信设备。有过开发通信设备的朋友们应该知道,其实嵌入式软件开发的技术核心是事件调度,因为通信设备总是处在繁忙的交换和命令事件处置的状态中,一个良好的事件调度机制是系统性能的灵魂,如果每次一个事件的到来都以新开一个线程的方式来应付,系统资源瞬间就会枯竭,设备也就崩溃了。

当时我们采用的是一种叫做zebra的架构,这是一个面向交换的开源项目,甚至有点像一个用户空间运行着的内核程序。

当时管理这个项目团队的项目经理正好是一个完全没有做过软件开发的职业文案写手,所以当主力开发人员把事件调度机制的框架整理完成之后,项目经理小眼滴溜溜一转,说道:

现在架构已经完成,下面就是大家分工,把各自的功能框架填充好了,我看了一下,一共有19个模块,大家分一下,一个模块每人一周时间…

这时一个资深的程序员打断了他,资深程序员让大家每个人把手头做的东西做一下单元测试,声称下一周他会给我们一个好东西。

果然这位资深程序员拿出一周时间用脚本写成的工具,把所有原来的功能模块直接处理填充到zebra架构内了。

每当我回忆这件事情的时候,想起外行项目经理的尴尬表情都会忍俊不禁。彼时的那位项目经理,其实也是一个年轻有为的人,但是对于软件开发的特点的确缺乏了解,想当然地以为自己抓抓纪律性就行,大家按部就班、出工出力就好。可是要知道如果真的按照他的计划,功能填充过程可能需要2-3个月,况且数百万行规模的代码中隐藏的BUG又需要一个测试周期来捉虫。


我把这个故事讲给朋友们,有的朋友就问当时假如没有这个用脚本写成的工具又当如何呢?我就会反问,那么假如我们没有找到zebra架构又当如何呢?难不成要我们几个菜鸟来写调度机吗?软件编程,是一个能走捷径就一定要走捷径的工作——有现成的可重用或者可借鉴的东西一定要重用和借鉴的,这样工作水准和工作效率才可能有保证。有现成的东西不用,一定是万不得已;推倒重来,则一定是出现了重大问题;动不动喜欢从头再来的程序员,肯定是涉世未深、不得要领的门外汉。


我曾经将软件工作比喻成人类这个物种的又一次进化过程,每次开发工作的成果都顺理成章地成为以后阶段项目的工具。既然学习制造和使用工具正是人和动物的区别,那么在软件工作领域,对走捷径持怀疑态度,对借鉴现成成果持抗拒心理,反对宁可停下进度也要先创造工具的开发者或管理者,就如同软件世界里的大猩猩。


迷信“纪律性”的管理者,通常都以“战斗力”为口头禅,可惜开发产品毕竟不是战争,软件编程也不是你死我活的肉搏,软件工作其实就是一次又一次把自己的好想法,好创意凝结在编程语言上的过程,好的代码精辟如诗歌一般,其简练高效令人读起来拍案叫绝;好的软件架构巧夺天工,资源节约,鲁棒性强,这些都是经过反复思索和反复斟酌的结果,这样的工作状态和“纪律性”以及“团结就是力量”的状态其实完全是南辕北辙。


软件的灵魂是数学和逻辑,开发过程本身就是一种创造,一种与数学逻辑的对话。纪律性的灵魂是服从,是听话,是个人意志服从集体意志,集体意志服从长官意志。这两件事情的联姻肯定不是自由恋爱,而是指腹为婚。

我觉得在团队合作中,编程规范是极为必要的,用约定的编程规矩来撰写程序是开发者应该共同维护的良好开发氛围。但这就是所谓纪律的边界了,纪律的覆盖范围,不应该逾越这个边界。


       这些年敏捷开发、结对编程等新兴软件开发模式的兴起,从一个侧面强化了我的这种认识,那就是:软件工作的重要方式,就是创造一个可以酝酿好点子的环境,让好想法源源不断的产生出来,形成代码。软件活动应该回归本源,就是激发有创造力的人性。

按照这个思路,我常常建议一些嵌入式软件工程师能够在工作之余学习一下java,学习一下脚本语言,awk也行,tk也行,perl也行。很多人会很诧异,觉得自己面向硬件,甚至面向驱动,为什么要学习那么多表示层的东西?


我认为嵌入式系统软件开发常常因为设备处理能力以及开发环境限制只能使用面向过程的C,但是在软件工具已经逐渐丰富起来的现在,底层代码是完全可以通过脚本语言帮忙处理的,大量繁重的比对工作和代码迁移工作完全可以用脚本来执行,高效而且准确。

单纯从项目开发的效率来讲,团队里面有这样的软件多面手,有能够提出这样想法的人,比一个外行领导者对于开发者纪律性的要求要有意义,也有效的多。


这又要说到我曾经参与的另一个项目,也是某一种通信产品的开发工作。这一次是给设备开发北向接口。所谓北向接口,实际上就是开放给管理系统的管理监督接口。我们当时采用的是MIB方案,以SNMPv2为接口规范。同样的问题再次光临:一个带有庞大从属终端数量的局端设备,其MIB是非常复杂的,由于管理数据的节点已经细致到每个终端下面的每个网口的出入口速率和VLAN之类的细节内容,所以数据管理异常繁琐。

有了之前的经验,这一次我们也都把眼光投向脚本工具,果不其然,我们直接找到了一个开源项目,专门针对MIB开发了一套基于perl脚本的处理工具集,把这个工具集稍加调整,就能快速生成满足MIB访问要求的底层数据形态,并且生成的代码有良好的可维护性,冗余度也在可接受的范围内。

我印象非常深的是,在做完这个项目的庆功宴上,项目组的技术大牛,也就是之前说到的那位资深程序员曾有这么一句感慨:“真正做可靠的嵌入式软件开发,以后就应该是架构设计配合代码生成工具,资浅程序员的工作就是一边做点小修小补,一边学习架构,这样利于成长,也对项目进展最有利”。

此言听闻已有将近8年,言犹在耳。


前面“@不动如山_”的那段话虽然出自一人之口,但是这样的观点,在国内却绝不是少数,没有编程背景的管理人员更是对这样的观点敞开怀抱,如获至宝。很多国内的公司在软件部门里面都依然秉承着“人月”状态,就是把员工人数和工作时间的乘积作为公司的生产力,然后把具体的工作按照“人月”或者“人日”乃至“人时”进行度量,进而把一项任务切分出去。看到这里,读过《人月神话》的朋友们应该都会会心一笑。


写这篇文章,也主要是想对初入这个行业或者怀有志向即将进入这个行业的年轻的技术者们说点我的心里话:堆代码永远不是软件行业的核心竞争力,设计能力才是,尽管很多公司还以代码行数作为绩效来考评;做一个听话的孩子在这个行业里也很难快速提升自我,因为创造力是要靠自己勉励自己才能不断展现的;安排很多人做重复体力活的规划,其实是因为没有人去尝试创造便捷的工具,这样的所谓的“纪律性”的团队里你肯定也学不到什么东西。多问几个为什么一定要这样和为什么不那样,对一个年轻人,尤其对一个有技术追求的年轻人永远有好处。


评论:

nosolu
2014-11-18 14:32
文章写的很好,但总觉得思维过于发散,论点不够清晰。建议楼主梳理一下思路,像软件开发一下,将所要表述的内容,拆解为一个一个的主题。例如:
为什么要多问为什么?要做怎么才能多问为什么?
为什么会有那么多外行领导者?这种现象合理吗?是不是有更深层的社会因素?遇到外行领导者的话,我应该怎么办?是奋起反抗,是默默忍受,还是另起炉灶?
技术人员最重要的特质是什么?对技术的热爱和孜孜追求?对未知的好奇?对自我的挑战?为什么大多的技术人员没有这么做?社会问题?教育问题?还是其它什么原因?
等等…
其实工程管理远比技术本身复杂,且不在一个数量级上。在现实的实践过程中,每个人都可以看到并提出一大堆的问题,但很少有人能给出解决方案,这才是最大的挑战。
或许可以借鉴技术研发的思路,将复杂问题模块化,拆解为简单问题,再一一突破。但对于这种牵涉到社会、教育、经济、文化等因素的复杂问题,要如何处理,需要所有有理想的技术人深思。
travelhop
2014-11-18 15:17
@nosolu:现在这个年月,喜欢长篇大论的人越来越少,之余怎么才算合理,应该如何反抗之类的,可能5年前的我会反复纠结,但是现在不会了。

遇到不合理的机制和团队,其实及早离去比说服教育更有意义。

遇到感觉不合理,却又能够取得成绩,能够生存的机制,我常常会感慨其实人性的复杂超出我的想象。

社会问题和教育问题,提出来大家聒噪一番,然后归于沉寂,没能解决什么,只不过搞坏了心情,耽误了时间。

社会责任的确需要有人来肩负,但是主力军不应该是技术人。技术人的专业是技术,不要以为技术思想就能解决各路问题,技术思想在实际工作中连销售问题都难以解决,还是不要盲目以为技术思想能胜任很多不同领域的东西。

“纪律性”这个概念,如果纯粹只是外行们嘴里的外行话,其实完全可以忽略无视;但是当很多从业者,技术人自己也开始接收和崇拜这个概念时,就值得警醒和反思。仅此而已。技术人毕竟是做技术的,做技术其实是需要创造力的,这就是我想说的。

至于其他的很多牵扯,生活原本复杂,我不太建议总以条分缕析来面对生活,有点空闲给自己就好。

写文章,目的如果是为了自己的观点滴水不漏,其实就会变成空洞的说教。

我写我所想,有些局限是如今的我可能突破不了的,而如今的我又确实在过去的我的基础上做了哪些突破,把这些写清楚,我觉得就够了。
puppypyb
2014-12-02 14:50
@nosolu:这位仁兄是做工程管理的吧, 要不太浪费了!

人月人日一书的作者无非就是将管理学科的方法论强加于软件行业之上,拼命的鼓吹其魔力,以至于扭曲、变形,以至于成书。
对项目的良好管理肯定是胜过杂乱无章的各自为政,软件行业需要的是根据其特性借鉴一些好的管理方法,这是合理的、科学的。但如果将其神化,抛弃了本身的特性,我认为是物极必反。
到后来,搞酒店管理的可以来做项目管理,地产商也可以来做软件项目管理,当然XX会所的经理更是能够胜任。对这些project manager来说,都是人月人日,没什么不同...
travelhop
2014-12-09 09:19
@puppypyb:人月神话一书作者在观点上是否定人月的……

发表评论:

Copyright @ 2013-2015 蜗窝科技 All rights reserved. Powered by emlog