• 【代码整洁之道】读书笔记


    1、整洁代码

    1.1、Why:学习整洁代码的目的

    软件质量 = 架构质量 + 项目管理 + 代码质量。

    代码质量与代码整洁成功成正比。 干净的代码,质量较为可靠,也为后期维护升级奠定了良好的基础。

    1.2、What:什么是整洁代码

    各家之言不尽相同,但总结下来,有如下方面:优雅、高效、易读、易改、逻辑直接了当、减少依赖关系、走心。

    读到简洁代码的感觉是:原该如此。

    简洁代码符合简单设计4原则(优先级从高到低):
    1、通过所有测试
    2、无重复代码
    3、尽可能清晰(体现系统中的全部设计理念)
    4、尽可能少的元素

    1.3、How:如何做到

    美国童子军规:让营地比你来时更干净。

    代码保持整洁的方法:每次签出时,都比签入时更加整洁。

    如何能做到呢?1、通过读书学习别人的经验(原则、思想、工具、技术、思维过程),2,练习。

    本书即代码整洁之道的规则。

    学习记忆的要点:知和行。你应当习得有关原则、模式和实践的知识,穷尽应知之事,并且对其了如指掌,通过刻苦实践掌握它。

    2、命名规范

    原则:写人能读懂的代码,而不是写机器能读懂的代码。

    做法:
    1、名副其实,实事求是的命名为此变量说表达的含义。
    2、使用读得出来的名称,这样更容易理解和记忆,尽量不要自造词、缩写词。
    3、使用便于搜索的名称。这就是为啥不用魔鬼数字。还有两个词之间有部分联系,如果有公共部分,也会更容易联想或搜索到。
    4、不用匈牙利命名法等前缀命名法 
    5、类名是名词或名词短语,方法名是动词或动词短语
    6、每个概念只对应一个词,不要一会儿叫fetch,一会儿叫get
    7、避免把一个单词用于两种含义
    8、使用解决方案领域名词

    3、函数

    规则:
    1、短小
    2、只做一件事,判断是否只做一件事的方法:能否再拆出一个函数
    3、函数中的语句要在同一抽象层次上。
    4、参数越少越好,如果确实需要三个以上的参数,应该封装为类了。
    5、分割指令和询问。也就是要么查,要么做。不可二者兼做。
    6、使用异常替代错误码。

    4、注释

    几个TIPS:
    1、优先使用自解释的代码。
    2、注释的恰当用法是秘密不我们用代码表达意图时遇到的失败。
    3、注释不能美化糟糕的代码,如果想写注释说明下代码,先看看能否重构之。
    4、用版本管理工具而不是注释记录历史和作者。
    5、合适使用注释的场景:法律信息,解释意图,警示,TODO,javadoc

    5、格式

    就讲了些编程规范。

    6、对象和数据结构

    就讲了封装和隐藏。

    7、错误处理

    讲了几个事情:
    1、优先用异常。
    2、受检异常会使调用链都需要添加这个受检标识,不太适合这种经过长调用链后才处理的异常,只适合一出错就立刻处理的那种。
    3、对于抛出很多种类的异常的操作,可以先封装成一个内部大异常,防止到处拷贝异常处理代码。
    4、尽量不要返回或传入null,而是使用空对象、空列表。

    8、边界

    边界就是接口而已,这章讲的就是面向接口编程。

    9、单元测试

    要点:
    1、测试用例的目的是保证修改、重构时的安全。
    2、所以要保证测试用例的整洁,否则以后测试用例腐化后,就无法保证1。进而导致生产代码腐化。
    3、整洁测试的规则:快速、独立、可重复、自足验证、及时。

    10、类

    1、What.什么是类

    封装。

    2、Why. 为什么要类

    为了方便修改。

    3、How. 如何写类。

    要短小( 单一职责、内聚 )。

    11、系统

    写的乱七八糟的知识点。

    1、将构造和使用分离,方法:工厂模式、IOC。
    2、如何扩容。演进式设计。
    3、aspect、AOP、java代理。
    4、测试驱动架构
    5、延迟决策
    6、领域语言。

    12、跌进

    通过跌进实现代码整洁的目的。 
    跌进的方法就是简单设计4原则:
    1、通过测试
    2、消除重复
    3、表达清楚
    4、较少的元素

    其中1:表示功能。2-4:表示实现,也就是重构的过程。

    13、并发编程

    并发防御原则:单一权责。
    推论1:限制数据的作用域。
    推论2:使用数据副本。
    推论3:线程尽可能独立。

    同步原则:
    1、警惕同步方法相互依赖。
    2、保持同步区域微小。

    17、味道与启发

    其实就是《重构》书里面的代码坏味道及小扩展。

    注释
    1、不恰当的信息(本该由代码、DTS、git等维护的信息不该出现在注释里)
    2、废弃的注释
    3、冗余注释(代码复读机)
    4、注释掉的代码
    5、随意写的不规范注释

    环境
    1、构建难度
    2、测试难度

    函数
    1、过多的参数
    2、输出参数违反直觉
    3、标识参数标识函数职责不单一
    4、废弃函数

    一般性问题
    1、一个源文件中存在多种语言
    2、明显的行为未被实现
    3、不正确的边界行为
    4、忽视安全
    5、重复
    6、在错误的抽象层级上的代码
    7、基类依赖于派生类
    8、信息过多
    9、死代码
    10、变量声明和使用过于远
    11、前后不一致
    12、人为耦合
    13、特性依恋
    14、意图不明确
    15... 太啰嗦了

    18、读后感

    对我来说,这本书不是一本好书。

    1、没条理,不系统,作者想到啥写啥。
    2、重复、啰嗦。
    3、里面的观点90%以上我已经非常清楚了。

  • 相关阅读:
    Struts1、Struts2的线程安全问题
    java基础系列——线程池
    Memcached基础
    Git基本应用
    Angular UI框架 Ng-alain @delon的脚手架的生成开发模板
    .NET CORE 框架ABP的代码生成器(ABP Code Power Tools )使用说明文档
    角落的开发工具集之Vs(Visual Studio)2017插件推荐
    【52ABP实战教程】0.3-- 从github推送代码回vsts实现双向同步
    【52ABP实战教程】0.1-- Devops如何用VSTS持续集成到Github仓库!
    【52ABP实战教程】0.2-- VSTS中的账号迁移到东亚
  • 原文地址:https://www.cnblogs.com/aoyihuashao/p/10454718.html
Copyright © 2020-2023  润新知