摘录自《代码整洁之道》不过改了几处表达方式。
代码可以有,代码必须有
有人也许会以为,关于代码的书有点儿落后于时代-代码不再是问题;我们应当关注模型和需求。确实,有人说过我们正在临近代码的终结点。很快,代码就会自动产生出来,不需要再人工编写。程序员完全没用了,因为商务人士可以从规约直接生成程序。
扯淡!我们永远抛不掉代码,因为代码呈现了需求的细节。在某些层面上,这些细节无法被忽略或抽象,必须明确之。将需求明确到机器可以执行的细节程度,就是编程要做的事。而这种规约正是代码。
我期望语言的抽象程度继续提升。我也期望领域特定语言的数量继续增加。那会是好事一桩。但那终结不了代码。实际上,在较高层次上用领域特定语言撰写的规约也将是代码!它也得严谨、精确、规范和详细,好让机器理解和执行。
那帮以为代码终将消失的伙计,就像是巴望着发现一种无规范数学的数学家们一般。他们巴望着,总有一天能创造出某种机器,我们只要想想、嘴都不用张就能叫它依计行事。那机器要能透彻理解我们,只有这样,它才能把含糊不清的需求翻译为可完美执行的程序,精确满足需求。
这种事永远不会发生。即便是人类,倾其全部的直觉和创造力,也造不出满足客户模糊感觉的成功系统来。如果说需求规约原则教给了我们什么,那就是归置良好的需求就像代码一样正式,也能作为代码的可执行测试来使用。
记住,代码确然是我们最终用来表达需求的那种语言。我们可以创造各种与需求接近的语言。我们可以创造帮助把需求解析和汇整为正式结构的各种工具。然而,我们永远无法抛弃必要的精确性-所以代码永存。
代码是怎么被写烂的
最近我在读Kent Beck著Implementation Patterns(中译版《实现模式》) 一书的序言。他这样写道:"……本书基于一种不太牢靠的前提:好代码的确重要……"这前提不牢靠?我反对!我认为这是该领域最强固、最受支持、最被强调的前提了(我想Kent也知道)。我们知道好代码重要,是因为其短缺实在困扰了我们太久。
20世纪80年代末,有家公司写了个很流行的杀手应用,许多专业人士都买来用。然后,发布周期开始拉长。缺陷总是不能修复。装载时间越来越久,崩溃的几率也越来越大。至今我还记得自己在某天沮丧地关掉那个程序,从此再不用它。在那之后不久,该公司就关门大吉了。
20年后,我见到那家公司的一位早期雇员,问他当年发生了什么事。他的回答叫我愈发恐惧起来。原来,当时他们赶着推出产品,代码写得乱七八糟。特性越加越多,代码也越来越烂,最后再也没法管理这些代码了。是糟糕的代码毁了这家公司。
你是否曾为糟糕的代码所深深困扰?如果你是位有点儿经验的程序员,定然多次遇到过这类困境。我们有专用来形容这事的词:沼泽(wading)。我们趟过代码的水域。我们穿过灌木密布、瀑布暗藏的沼泽地。我们拼命想找到出路,期望有点什么线索能启发我们到底发生了什么事;但目光所及,只是越来越多死气沉沉的代码。
你当然曾为糟糕的代码所困扰过。那么-为什么要写糟糕的代码呢?
是想快点完成吗?是要赶时间吗?有可能。或许你觉得自己要干好所需的时间不够;假使花时间清理代码,老板就会大发雷霆。或许你只是不耐烦再搞这套程序,期望早点结束。或许你看了看自己承诺要做的其他事,意识到得赶紧弄完手上的东西,好接着做下一件工作。这种事我们都干过。
我们都曾经瞟一眼自己亲手造成的混乱,决定弃之而不顾,走向新一天。我们都曾经看到自己的烂程序居然能运行,然后断言能运行的烂程序总比什么都没有强。我们都曾经说过有朝一日再回头清理。当然,在那些日子里,我们都没听过勒布朗(LeBlanc)法则:稍后等于永不(Later equals never)。
混乱的代价 == 挥刀自宫
只要你干过两三年编程,就有可能曾被某人的糟糕的代码绊倒过。如果你编程不止两三年,也有可能被这种代码拖过后腿。进度延缓的程度会很严重。有些团队在项目初期进展迅速,但有那么一两年的时间却慢如蜗行。对代码的每次修改都影响到其他两三处代码。修改无小事。每次添加或修改代码,都得对那堆扭纹柴了然于心,这样才能往上扔更多的扭纹柴。这团乱麻越来越大,再也无法理清,最后束手无策。
随着混乱的增加,团队生产力也持续下降,趋向于零。当生产力下降时,管理层就只有一件事可做了:增加更多人手到项目中,期望提升生产力。可是新人并不熟悉系统的设计。他们搞不清楚什么样的修改符合设计意图,什么样的修改违背设计意图。而且,他们以及团队中的其他人都背负着提升生产力的可怕压力。于是,他们制造更多的混乱,驱动生产力向零那端不断下降。
程序员起义
最后,开发团队造反了,他们告诉管理层,再也无法在这令人生厌的代码基础上做开发。他们要求做全新的设计。管理层不愿意投入资源完全重启炉灶,但他们也不能否认生产力低得可怕。他们只好同意开发者的要求,授权去做一套看上去很美的华丽新设计。
于是就组建了一支新军。谁都想加入这个团队,因为它是张白纸。他们可以重新来过,搞出点真正漂亮的东西来。但只有最优秀、最聪明的家伙被选中。其余人等则继续维护现有系统。
现在有两支队伍在竞赛了。新团队必须搭建一套新系统,要能实现旧系统的所有功能。另外,还得跟上对旧系统的持续改动。在新系统功能足以抗衡旧系统之前,管理层不会替换掉旧系统。
竞赛可能会持续极长时间。我就见过延续了十年之久的。到了完成的时候,新团队的老成员早已不知去向,而现有成员则要求重新设计一套新系统,因为这套系统太烂了。
假使你经历过哪怕是一小段我谈到的这种事,那么你一定知道,花时间保持代码整洁不但有关效率,还有关生存。
分享到:
相关推荐
【程序员之路———关于代码风格】的探讨主要集中在代码风格的重要性、代码行极限、缩进方式、折行原则以及空格和空行的使用。这些规范对于任何程序员来说都是提高代码可读性和团队协作效率的基础。 1. **代码行...
本项目“关于代码自动生成的项目demo”显然是一个专注于此领域的实践示例,它可能包含了一个完整的代码生成框架。下面将详细介绍这个项目及其相关知识点。 1. **数据库连接配置**: - 数据库连接是任何应用程序与...
Matlab Simulink 中关于代码生成(RTW) Matlab Simulink 是一款功能强大的模型设计和仿真工具,广泛应用于自动控制、信号处理和仿真分析等领域。在 Matlab Simulink 中,Real-Time Workshop(RTW)是一款强大的...
《代码之美》这篇文章深入探讨了如何提升代码质量,使其不仅具备功能完备性,还具有可读性、可维护性和高效性。以下是对文章内容的详细解读: 1. **代码规范与风格**:良好的代码风格是代码美的基础。遵循一定的...
而“代码统计”是指对源代码进行分析,获取关于代码结构和规模的数据。作为“Tool”,这个应用程序是开发者工具箱中的一员,旨在帮助程序员更好地理解和管理他们的代码库。 在压缩包文件名称列表中,我们看到一个名...
在Matlab上实现DTMF,但没有注释,如果你想,你可以问我关于代码的问题_Project_tha_DTMF
关于代码移植的初步探讨与类似经验02-以stm32的SDIO接口同SD卡(tf卡/SDHC)的交互为例
本报告是关于代码审核的详细报告,涵盖了代码的编写格式、注释风格、变量命名、常量定义、数据类型、参数定义、注释的重要性、安全性等多个方面。 一、代码编写格式 代码的编写格式是否一致?是否有助于代码的维护...
总的来说,VB代码统计器是软件开发过程中的一个重要辅助工具,它能提供关于代码质量和工作量的量化信息,从而帮助开发团队更好地管理项目,提升代码质量,降低维护成本。通过持续地使用这样的工具,可以促进代码的...
Java代码审查表中关于代码风格和格式规则的重要性激活级别检查项有: * 代码段落是否被合适地以空行分隔?(Y20) * 是否合理地使用了空格使程序更清晰?(20) * 代码行长度是否在要求之内?(20) * 是否折行是否...
它们还可以提供关于代码结构、复杂性和重复性的洞察,帮助开发者优化代码,提高代码质量和可维护性。 常见的代码量测算工具有很多,例如CLOC(Count Lines of Code)、SLOCCount、NCSS(Non-Commenting Source ...
"代码量统计工具"就是这样一个实用的工具,它能够帮助我们对各种编程语言的代码进行统计分析,提供关于代码行数、空行和有效代码行的详细信息。下面我们将深入探讨这个工具的功能、应用及其重要性。 首先,代码统计...
描述进一步揭示了该工具的功能,它能够分析VC(Visual C++)项目,提供关于代码、注释和空格的详细统计,并且可能包含一些附加功能。 标签“源代码”和“统计”进一步确认了这个工具的主要用途,即对编程项目中的源...
总结来说,"org.holon.statistic.lines_1.0 2.0"是一款强大的Eclipse插件,它为开发者提供了关于代码行数和注释行数的详细统计,有助于提升开发效率,确保代码的可读性和可维护性。在软件开发的各个环节,这样的工具...
关于代码的提交,模板规定了具体的标准。如果代码总量超过3000行,你应该仅提交六十页的代码样本。这包括前30页的前1500行代码和后30页的后1500行代码,每页展示50行,确保最后一页是一个完整的代码模块的结尾。为了...
下面将详细介绍关于代码统计工具的相关知识点。 首先,代码统计工具可以分为两类:命令行工具和图形化界面工具。命令行工具如CLOC(Count Lines of Code)和SLOCCount,它们通常更轻量级,适合自动化集成到构建流程...
《代码重构》一书由Martin Fowler编写,是软件开发领域中关于代码质量提升的经典之作。书中详细阐述了重构代码的必要性、重构的时机以及如何安全地重构代码。重构指的是在不改变软件外部行为的前提下,改进其内部...
在实际应用中,这样的工具不仅可以提升开发效率,也有助于项目管理,通过量化的方式提供关于代码质量和团队生产力的数据支持。使用SourceCounter这样的代码行统计工具,开发者可以更好地理解和优化他们的代码库,...
用户只需将待检测的Java源代码目录作为参数传递给这个JAR文件,即可得到关于代码注释率的报告。 `resource.jar` 文件可能包含了一些运行时所需的资源文件,如配置文件、图标或者本地化文本等。这些资源在检查过程中...