程序员如何做到:编程速度又快,Bug 数量又少?
最近看到一个Quora中的关于如何做到编程速度快,同时Bug 数量少的回答,Glyn Williams等的回答非常精彩,网友纷纷点赞。译文如下:
三个程序员被要求穿过一片田地,到达另一侧的房子。
菜鸟程序员目测了一下之间很短的距离,说:“不远!我只要十分钟。”
资深程序员看了一眼田地,想了一会,说:“我应该能在一天内过去。”菜鸟程序员很惊讶。
大神程序员看了一眼田地,说:“看起来要十分钟,但我觉得十五分钟应该够了。” 资深程序员冷笑了一声。
菜鸟程序员出发了,但只过了一会,地雷爆炸了,炸出了巨大的洞。这下他必须偏移预定的路线,原路返回,反复尝试穿过田地。最后他花了两天到达目的地,到的时候颤颤发抖,还受了伤。
资深程序员一出发就匍匐前进,仔细地拍打地面,寻找地雷,只有在安全的时候才前进。他在一天的时间内小心谨慎地缓慢爬过了这片地,只触发了几个地雷。
大神程序员出发之后径直穿过了田地,十分果断。他只用了十分钟就到了另一边。
“你是怎么做到的?”另外两个人问道,“那些地雷怎么没有伤到你?”
“很简单,”他回答道,“我最初就没有埋地雷。”
地雷从何而来?
与大神一起工作的时候就是这种感觉,也是我的第一印象「代码整洁而且没有地雷」。可是反过来想,为什么有的人就是习惯于埋雷呢?难道看不到后果吗?
以下为Glyn Williams 的回复,4.5 k 赞。
事实上,随着新的代码模块被加入到项目中,项目的复杂度会以某种指数形式上升,然而程序员精力有限,这些自己(或其他人)埋下的逻辑炸弹会让你的大脑最终会不堪重负,最终会淹没程序员。
这就是炸弹开始爆炸的时刻。有各种各样的炸弹:在遍历时修改数组,数组下标偶尔变成负数,另一个线程在你的函数执行的起点和终点中间改变对象的状态。轰,轰,轰……
所以,我认为最快捷可靠的程序设计还需要培养一种避免这些问题的风格。
编写明确表达行为的代码。选择有意义、准确、无歧义的符号名字。严格执行命名方案,不要用不同的单词描述同一个事物。
如果有,采用最简单的解决方案。不要为速度优化,而是为可读性和透明度优化。
如果你在最初编写代码时没有注意可重用性,不要欺骗自己相信代码可以很神奇地被重用。相反,应该从一种情形着手,保持代码的具体性。如果值得修改代码让它一般化,那么应该做好彻底重写的准备。
以下为William Emmanuel Yu 的回复:(5.5k 赞)
再深一层来讲,没人愿意给自己埋地雷,主要还是没有对习惯引起重视。培养起好的编程习惯是非常重要的。编程中的坏习惯,是很多程序员上升的天花板,十年原 地踏步的原因。
想要写出好代码,一定要常常问自己「我还能做的更好吗?」(好吧,这是算法课的口号)。只有想不断提升的人,才会注意去扣各种各样的细节, 使得自己做得比前一次好。
下面总结一下,常见的「地雷」主要有:
-
没有提前构建
-
没有规划完整系统的生命周期,内存泄露到处都是。
-
系统没有设计好,存在不少重复功能的类。
-
系统的行为没有定义好,接口设计不完整,写了创建不写删除。
-
没有重视代码的可读性
-
代码没有经过提炼,到处都是重复代码,改一个功能常常要改很多处代码。
-
缺少抽象,将具体实现暴露得到处都是。比如一个状态机在外部设置它的状态切换。
-
代码没有紧贴语义。
-
没有重视开发效率
-
到处都是繁杂重复的配置项,通过约定可以省去很多配置。
-
很多中间代码,比如解析xml、解析协议等等的工作,通过元编程可以将这些中间工作自动化。
-
没有重视数据
-
数据没有处理好,敏感数据要保护好,比如角色的属性,到处都是直接赋值的话,很容易出错,要把直接改变限制在少数的某几个函数里。
-
某些系统知道得太多,比如数据层就不应该知道显示层的东西,显示和数据掺杂在一起。
-
数据依赖于代码,比如写在C++的模板里面,没有为数据设计序列化文件。
最后,给习惯于埋雷的程序员两点建议:
记住一句话:“我不是什么伟大的程序员,我只是一个有着很多好习惯的程序员”—-Kent Beck
想明白一个问题:在《程序员修炼之道》里,第一条就是「关心你的技艺」。如果你不在乎能否漂亮地开发出软件,你又如何要耗费生命去开发软件呢?
本文由西安Java培训提供www.71admin.com