程序员到底该不该写好你的代码?

有人也许会以为,关于代码的书有点儿落后于时代——代码不再是问题;我们应当关注模型和需求。确实,有人说过我们正在临近代码的终结点。很快,代码就会自动产生出来,不需要再人工编写。程序员完全没用了,因为商务人士可以从规约直接生成程序。

扯淡!我们永远抛不掉代码,因为代码呈现了需求的细节。在某些层面上,这些细节无法被忽略或抽象,必须明确之。将需求明确到机器可以执行的细节程度,就是编程要做的事。而这种规约正是代码

我期望语言的抽象程度继续提升。我也期望领域特定语言的数量继续增加。那会是好事一桩。但那终结不了代码。实际上,在较高层次上用领域特定语言撰写的规约也将代码!它也得严谨、精确、规范和详细,好让机器理解和执行。

那帮以为代码终将消失的伙计,就像是巴望着发现一种无规范数学的数学家们一般。他们巴望着,总有一天能创造出某种机器,我们只要想想、嘴都不用张就能叫它依计行事。那机器要能透彻理解我们,只有这样,它才能把含糊不清的需求翻译为可完美执行的程序,精确满足需求。

这种事永远不会发生。即便是人类,倾其全部的直觉和创造力,也造不出满足客户模糊感觉的成功系统来。如果说需求规约原则教给了我们什么,那就是归置良好的需求就像代码一样正式,也能作为代码的可执行测试来使用。

记住,代码确然是我们最终用来表达需求的那种语言。我们可以创造各种与需求接近的语言。我们可以创造帮助把需求解析和汇整为正式结构的各种工具。然而,我们永远无法抛弃必要的精确性——所以代码永存。

你当然曾为糟糕的代码所困扰过。那么——为什么要写糟糕的代码呢?

是想快点完成吗?是要赶时间吗?有可能。或许你觉得自己要干好所需的时间不够;假使花时间清理代码,老板就会大发雷霆。或许你只是不耐烦再搞这套程序,期望早点结束。或许你看了看自己承诺要做的其他事,意识到得赶紧弄完手上的东西,好接着做下一件工作。这种事我们都干过。

我们都曾经瞟一眼自己亲手造成的混乱,决定弃之而不顾,走向新一天。我们都曾经看到自己的烂程序居然能运行,然后断言能运行的烂程序总比什么都没有强。我们都曾经说过有朝一日再回头清理。当然,在那些日子里,我们都没听过勒布朗(LeBlanc)法则:稍后等于永不(Later equals never)。

只要你干过两三年编程,就有可能曾被某人的糟糕的代码绊倒过。如果你编程不止两三年,也有可能被这种代码拖过后腿。进度延缓的程度会很严重。有些团队在项目初期进展迅速,但有那么一两年的时间却慢如蜗行。对代码的每次修改都影响到其他两三处代码。修改无小事。每次添加或修改代码,都得对那堆扭纹柴了然于心,这样才能往上扔更多的扭纹柴。这团乱麻越来越大,再也无法理清,最后束手无策。

做一个优秀的程序员,推荐阅读《代码整洁之道》

程序员到底该不该写好你的代码?_第1张图片

“阅读这本书有两种原因:第一,你是个程序员;第二,你想成为更好的程序员。很好,IT行业需要更好的程序员!”——罗伯特·C. 马丁(Robert C. Martin)

尽管糟糕的代码也能运行,但如果代码不整洁,会使整个开发团队泥足深陷,写得不好的代码每年都要耗费难以计数的时间和资源。但是,这种情况并非无法避免。

著名软件专家罗伯特·C. 马丁(Robert C. Martin) 在本书中为你呈现了革命性的视野。他携同Object Mentor公司的同事,从他们有关整洁代码的*佳敏捷实践中提炼出软件技艺的价值观,以飨读者,让你成为更优秀的程序员——只要你着手研读本书。

阅读本书需要你做些什么呢?你将阅读代码——大量代码。本书会促使你思考何谓正确的代码,何谓错误的代码。更重要的是,本书将促使你重新评估自己的专业价值观,以及对自己技艺的承诺。

你可能感兴趣的:(代码,程序员,程序人生)