程序员们有什么好的编程习惯?

优良的代码显然不是制作优秀软件的唯一要素,但是主要的要素之一。我们可能拥有世界上最好的产品和营销团队,部署了最好的平台,并以最好的框架来构建软件,但归根结底,一款软件所做的一切,都是因为有人写了一段代码才得以实现的。

孤立地看,工程师们每天编写代码时所做出的决策都很小,有时显得微不足道,但它们共同决定了软件的好坏。如果代码中包含了缺陷、配置错误或者无法恰当地处理错误情况,由此构建的软件就可能有许多缺陷,甚至无法正常工作。

代码质量的六大支柱如下:

● 编写易于理解(可读)的代码;

如果我们的代码可读性很差,其他工程师就不得不花费很多时间来解读它。他们很有可能错误地理解它的作用,或者遗漏一些重要的细节。如果发生这种情况,代码评审期间就不太可能发现缺陷,而在其他人修改我们的代码、添加新功能时,就有可能引入新缺陷。软件的功能都是基于代码来完成的。如果工程师无法理解代码的作用,也就几乎不可能确定软件能否正常工作。正如食谱一样,代码必须易于理解。

● 避免意外;

即便有着最好的意图,编写提供一些有用或者“聪明”功能的代码仍有造成意外的风险。如果代码做了某些意外的事情,使用代码的工程师不会知道也不会思考处理那种情况的方法。这往往会导致系统“跛行”,直到在远离问题代码的地方出现明显的古怪表现。或许,这只会产生一个有些恼人的缺陷,但也可能造成破坏重要数据的灾难性问题。我们应该提防代码中的意外情况,并尽可能避免。

〓● 编写难以误用的代码;

通过编写很难或不可能被误用的代码,我们可以最大限度地提高代码持续正常工作的概率。针对这个问题,有许多实用的解决方法。

〓● 编写模块化的代码;

软件系统和代码库与这些玩具非常相似。将代码分解为独立模块,其中两个相邻模块的交互发生在单一位置、使用明确定义的接口,往往是很有好处的。这有助于确保代码更容易适应变化的需求,因为一项功能的变化不需要对所有地方进行大量修改。

模块化系统通常也更容易理解和推演。因为系统被分解为容易控制的小功能块,各功能块之间的交互有明确的定义和文档。这增加了代码一开始就能正常工作,并在未来持续工作的可能性——因为工程师更不容易误解代码的作用。

〓● 编写可重用、可推广的代码;

编写可重用、可推广的代码,我们(和其他人)就可以在代码库的多个地方和场景中使用它们,解决不止一个问题。这能节约时间和精力,并使我们的代码更加可靠,因为我们往往重用已在外部经过考验的逻辑,其中的缺陷可能已经被发现和修复。

〓● 编写可测试的代码并适当测试。

如果代码不可测试,也就不可能对其进行“适当”测试了。为了确保我们编写的代码是可测试的,最好在编写代码时不断地问自己一个问题:“我们将如何测试这些代码?”因此,测试不应该是“马后炮”,而应该是编写代码各个阶段不可分割的基本组成部分。

其他工程师与代码契约

1、你的代码和其他工程师的代码

如果你以团队一员的身份编写代码,你所编写的代码很可能建立在其他工程师编写的代码层次的基础上,其他人也可能以你的代码为基础构建新的代码层次。如果你在工作期间解决了各种各样的子问题,并将其分解为清晰的抽象层次,其他工程师也有可能重用其中一些代码,去解决你可能没有考虑过的、完全不同的问题。

2、其他人如何领会你的代码的使用方法

当其他工程师需要利用你的代码或者修改一些对其有依赖的代码,就必须领会你的代码的使用方法及其功能。具体地说,他们必须理解如下要素:

〓● 在哪些场景下,他们应该调用你提供的各种函数;

〓● 你创建的类代表什么,应该在什么时候使用;

〓● 他们应该以什么值调用;

〓● 你的代码将执行什么操作;

〓● 你的代码可能返回什么值。

3、代码契约

工程师有时会发现,将关于代码契约的术语分成不同类别很有用。

〓● 先决条件——调用代码时应该满足的条件,例如系统应处在的状态和提供给代码的输入。

〓● 后置条件——调用代码后应该成立的条件,例如系统被置于某个新状态或者返回某些值。

〓● 不变量——对比代码调用前后的系统状态时应该保持不变的事物。

即便你不是有意地采用契约式编程,甚至从未听说过这个术语,你编写的代码也肯定存在某种契约。如果你编写了一个有输入参数、返回某个值或修改一些状态的函数,就创建了一个契约,因为你在代码调用者身上加注了一项义务:建立某种状态或者提供输入(先决条件),并给予他们关于将要发生的事情或返回值的预期(后置条件)。

当工程师不知道代码契约的某些或者全部条款时,就会出现问题。在编写代码时,重要的是考虑契约的内容,以及如何确保使用代码的每个人都了解并遵循契约。

4、检查和断言

使用编译器强制代码契约的一种替代方法是使用运行时强制。这通常不像编译时强制那么健全,因为代码契约漏洞的发现取决于一项测试(或者一个用户)运行代码时遇到的问题。这与编译时强制形成了鲜明对比,后者从一开始就在逻辑上消除了违反契约的可能性。

尽管如此,在有些情况下,没有切合实际的手段能用编译器强制实施一个契约。发生这些情况时,以运行时检查强制实施契约好于没有强制手段。

以上内容摘自《好代码 ,坏代码》第一章,第三章。

好代码 ,坏代码

程序员们有什么好的编程习惯?_第1张图片

Google开发工程师从零讲解高质量代码,整合作者及团队多年的软件开发实践经验,通过50+条锦囊妙计、100+个案例,帮你轻松理解和掌握编程技能。

本书分享的实用技巧可以帮助你编写鲁棒、可靠且易于团队成员理解和适应不断变化需求的代码。内容涉及如何像高效的软件工程师一样思考代码,如何编写读起来像一个结构良好的句子的函数,如何确保代码可靠且无错误,如何进行有效的单元测试,如何识别可能导致问题的代码并对其进行改进,如何编写可重用并适应新需求的代码,如何提高读者的中长期生产力,同时还介绍了如何节省开发人员及团队的宝贵时间,等等。


养成好的编程习惯,一定要必备这两本程序员经典书。

重构:改善既有代码的设计(第2版)

程序员们有什么好的编程习惯?_第2张图片

本书是一本为专业程序员编写的重构指南。我的目的是告诉你如何以一种可控且高效的方式进行重构。你将学会如何有条不紊地改进程序结构,而且不会引入错误,这就是正确的重构方式。

按照传统,图书应该以概念介绍开头。尽管我也同意这个原则,但是我发现以概括性的讨论或定义来介绍重构,实在不是一件容易的事。因此,我决定用一个实例作为开路先锋。第1章展示了一个小程序,其中有些常见的设计缺陷,我把它重构得更容易理解和修改。其间你可以看到重构的过程,以及几个很有用的重构手法。如果你想知道重构到底是怎么回事,这一章不可不读。

第2章讨论重构的一般性原则、定义,以及进行重构的原因,我也大致介绍了重构面临的一些挑战。第3章由Kent Beck介绍如何嗅出代码中的“坏味道”,以及如何运用重构清除这些“坏味道”。测试在重构中扮演着非常重要的角色,第4章介绍如何在代码中构筑测试。

从第5章往后的篇幅就是本书的核心部分——重构名录。尽管不能说是一份巨细靡遗的列表,却足以覆盖大多数开发者可能用到的关键重构手法。

代码整洁之道

程序员们有什么好的编程习惯?_第3张图片

本书大致可分为3个部分。前几章介绍编写整洁代码的原则、模式和实践。这部分有相当多的示例代码,读起来颇具挑战性。读完这几章,就为阅读第2部分做好了准备。如果你就此止步,只能祝你好运啦!

第2部分最需要花工夫。这部分包括几个复杂性不断增加的案例研究。每个案例都清理一些代码——把有问题的代码转化为问题少一些的代码。这部分极为详细。你的思维要在讲解和代码段之间跳来跳去。你得分析和理解那些代码,琢磨每次修改的来龙去脉。

你付出的劳动将在第3部分得到回报。这部分只有一章,列出从上述案例研究中得到的启示和灵感。在遍览和清理案例中的代码时,我们把每个操作理由记录为一种启示或灵感。我们尝试去理解自己对阅读和修改代码的反应,尽力了解为什么会有这样的感受、为什么会如此行事。结果得到了一套描述在编写、阅读、清理代码时思维方式的知识库。

如果你在阅读第2部分的案例研究时没有好好用功,那么这套知识库对你来说可能所值无几。在这些案例研究中,每次修改都仔细注明了相关启示的标号。这些标号用方括号标出,如:[H22]。由此你可以看到这些启示在何种环境下被应用和编写。启示本身不值钱,启示与案例研究中清理代码的具体决策之间的关系才有价值。

如果你跳过案例研究部分,只阅读了第1部分和第3部分,那就不过是又看了一本关于写出好软件的“感觉不错”的书。但如果你肯花时间琢磨那些案例,亦步亦趋——站在作者的角度,迫使自己以作者的思维路径考虑问题,就能更深刻地理解这些原则、模式、实践和启示。这样的话,就像一个熟练地掌握了骑车的技术后,自行车就如同其身体的延伸部分那样;对你来说,本书所介绍的整洁代码的原则、模式、实践和启示就成为了本身具有的技艺,而不再是“感觉不错”的知识。

你可能感兴趣的:(数据库,java,开发语言,代码规范,程序人生)