转载

“把程序写好”这回事

  文/余晟

  刚领证的著名程序员狗叔(@Googollee),前几周提出了很好玩的问题:“把程序写好的知识,是从哪里学来的呢?”。

  我和狗叔回忆,我们好像都没有正经上过什么“把程序写好”的培训班,也没有《九阴真经》之类的宝典。但是我们又都看到,很多程序员写的程序是不合格的,大量基础规范都没有遵循(更可怕的是这样的程序很可能还在服务我们每天的生活)。那么,优秀的程序员,是从哪里学到把程序写好的知识的呢?

  这个问题我想了很久,有几点结论可以分享给大家。

  首先,必须要正视“写代码”这回事

  有很多人虽然做着程序员的工作,其实内心是看不起写程序的。对他们来说,写代码只是不得不经历的初级阶段,等到职业生涯发展了,就可以脱离这种单调无聊的工作了。但是,这种想法是错的,有这种想法只能说明对计算机和程序的认知还相当肤浅。写代码绝不是简单无聊的劳动,程序员首先必须了解计算机的运行原理,然后需要把现实问题建模,并在计算机的世界里精确地还原出问题的解决方案。既然代码要交给功能强大的计算机去严格执行,程序员要担负的责任就相当大,因为代码的任何一点差异,都有可能影响程序最终的运行结果——因为程序的细小缺陷导致航天任务失败的例子已经有好几次了。

  反过来说,程序员能掌握的权力相当大,成为“合格程序员”的门槛也相当高,虽然这种门槛并不为许多人所知。前段时间有很多人叫嚷“我万事俱备,只差一个写代码的”,恰恰是因为他们把写程序看成简单机械的劳动,但以自己的聪明才智又学不会这种“简单机械”的劳动。这种矛盾,恰恰说明写程序是有门槛、有要求的。所以,要想成为称职的程序员,必须正视写代码。

  其次,必须读过一些基本的书籍

  学校里通常会安排编程语言的课程,但不会教“怎样把程序写好”的课程。许多人对计算机的理解还停留在“科学与理论”的角度,只要程序能“对”,能输出正确结果就可以;却不知道如今与计算机相关的大量工作,其重心已经转移到实践和工程意识的方面了。这种错误的理解,导致很多程序员在工作之后相当长的时间里,学习的内容还局限于钻研理论和算法,一直忽略了“把程序写好”的补习。

  其实市面上已经有一些教人“把程序写好”的书籍,认真读完这些书,认真落实其中的规范,至少能保证把程序写“合格”,不会有明显的缺陷,为将来把程序写好奠定坚实的基础。从我和身边朋友的经验出发,我觉得《代码大全》、《重构》、《编程珠玑》、《程序员修炼之道》这几本书都是很不错的,如果能耐心读完并认真思考,写程序的水平会有相当的保证。

  要保持好奇心,多借鉴其它项目的内部实现

  我们时常开玩笑说,现在很多程序员的工作,就是从网上下载一些开源项目,然后改改参数。其实这并非玩笑,而是很多程序员工作的真实写照。充其量,他们还要做一些穿针引线的工作,把这些项目粘合组装起来。

  这看起来确实是简单机械的劳动,也不会给人多少提升。但事实并非如此。很多好的程序员就在这个过程中学会了把代码越写越好。因为他们保持了好奇心,去探究这些开源项目的内部实现,把应用的过程当成了学习的途径。在使用一个现成方案之前,先想想如果自己去解决要怎么办,再看看其他人的现成代码,确保自己懂得了这些代码蕴含的思维。甚至比较相类似的几个开源项目的源代码,分析其优劣,在自己的工作中注重借鉴其长处,避免其短处。久而久之,写程序的水平自然会有大的提升。

  在写程序时,要懂得在工程与理论之间求得平衡

  在谈到写程序时,经常有人引用奥卡姆剃刀原则,说“如无必要,勿增实体”;也有人引用爱因斯坦的话,“要足够简单,但不应该过于简单”。由此证明,好的程序应当是足够简单而且非常优雅的。

  在大方向上,我认同这种说法。但在具体的问题上,它未必正确。因为编程是与工程密切相关的工作,与工程密切相关就意味着大量的权衡、取舍。无论奥卡姆剃刀原则还是爱因斯坦的话,原本的主题都是针对理论的,所以两者并不能严格划等号。

  在实践中我见到过很多过份迷恋简单、美感的程序员,我称之为“玩套路”——他们太在意程序的形式美感,为了刻意追求那种严谨整齐的感觉而忽略了现实,也不懂得针对现实做出取舍,最终把自己套了进去。结果,用户明明需要的一亩菜地,他们交付的却是一份盆景,还振振有辞地指责用户不懂技术。这样的人,往往既当不好程序员,也成不了软件开发工程师。

  坦然接受其他人对自己代码的批评

  Code Review 是提高代码质量的有效手段,这一点大家公认。但是在很多场合,Code Review 很难推行起来,原因之一就是程序员内心难以接受其他人对自己代码的批评。

  这种现象倒也情有可原,因为写程序这回事,大家多少认为是有绝对标准,可以分出高下的。对大多数人来说,潜意识里也确实很难区分“对我的工作的批评”和“对我的批评”。所以面对其他人对自己代码的批评,除非是来自上级,否则多少有些面子上挂不住,天然有争辩的冲动。我自己就遇到过好几次这样的情况,本来讨论理论和方案一切正常,只要涉及到“看某人的代码”,气氛就随之大变。

  我们需要明白,不经历挑战和批评,人是很难提高的。其他人的批评,只要不是恶意的,总是能提供不一样的视角,帮助我们更深入或者更全面的认识问题,这是很好的成长机会。相比起来,“丢面子”更多只是一闪而过的,甚至根本只是自己觉得很丢脸,其他人完全不在意的。为了怕“丢面子”而排斥其他人的批评,实在是得不偿失。

  另一方面,团队领导也应当营造平等合理的协作气氛,倡导“对事不对人”的价值观。这样,才能让更多的成员坦然接受对自己代码的批评。

  程序员需要有对荣誉感的追求

  归根到底,“荣誉感”是驱动个人不断追求更高境界的源动力。对没有荣誉感的程序员来说,“把程序写好”充其量是不得已背上的负担;而对于具有荣誉感的程序员来说,“把程序写好”是需要不断追求的目标。

  在我看来,程序员的荣誉感主要体现在两个重要的方面。第一是对质量的追求,好的程序员一定会对自己交付的程序的质量负责,力求做到没有缺陷,所以不会依赖 Code Review 来发现代码的缺陷,也不会依赖测试来发现功能的缺陷…… 甚至要向上游扩展了解问题的起因和目的,向下游扩展了解程序运行的状态和行为——这已经是“全栈工程师”的雏形了。

  第二是对“用技术更好解决问题”的不断思索和追求。程序与现实不完全相同,所以很多时候并不受现实的严格限制,程序能不能突破这些限制,如何突破这些限制,靠的就是程序员的荣誉感。现实中很多时候确实“鱼与熊掌不可兼得”,但是在程序的世界里,在某些情况下,鱼与熊掌是可能兼得的。现实中“菜刀用来杀人”似乎是无解的,但在程序的世界里,有些菜刀就可以做到不能用来杀人。普通人或许囿于现实生活经验无法想想“鱼与熊掌兼得”、“菜刀不能杀人”,但想把程序写好的程序员,一定不能就此止步。

  最后我想说的是,程序员应当属于德鲁克说的“知识工作者”。对于知识工作者,我们就不能像对待机器和工人那样去严格约束工作的过程,只能要求结果,或者说“找到合适的人,提供合适的环境,期待美好的事情发生”,这也是很多程序员享受的方式。但是,如果程序员不在乎自我驱动和追求,把写程序当场不需要任何想象力和创造力简单重复劳动,那么“血汗工厂”的工作方式可能更能保证生产效率。

正文到此结束
Loading...