
《clean code-代码整洁之道》
文章平均质量分 82
《clean code-代码整洁之道》读书笔记
仁希'
慢慢往前走
展开
-
clean code-代码整洁之道 阅读笔记(第十七章 终章)
类的方法只应对其所属类中的变量和函数感兴趣,不该垂青其他类中的变量和函数。可以在从不被调用的小工具方法中找到,也可以在永不会发生的switch/case条件中找到。如果某个模块依赖于另一个模块,依赖就该是物理上的而不是逻辑再上的。没有实现的默认构造器、没有用到的变量、从不调用的函数、没有信息量的注释等等,这些都是应该移除的废物。如果你有个已知并该在较高抽象层级的默认常量或配置值,不要将它埋藏到较低层级的函数中。只要把计算过程打散成一系列良好命名的中间值,不透明的模块就会突然变得透明,这很值得注意。原创 2024-07-09 15:43:44 · 1303 阅读 · 0 评论 -
clean code-代码整洁之道 阅读笔记(第十六章)
【代码】clean code-代码整洁之道 阅读笔记(第十六章)原创 2024-07-08 18:18:38 · 495 阅读 · 0 评论 -
clean code-代码整洁之道 阅读笔记(第十五章)
如此我们遵循了童子军军规。模块比我们发现它时更整洁了。不是说它原本不整洁。作者们做了卓越的工作。但模块都能再改进,我们每个人也有责任把模块改进得比发现时更整洁。本章将研判来自JUnit框架的一个代码例子。原创 2024-06-27 18:03:57 · 401 阅读 · 0 评论 -
clean code-代码整洁之道 阅读笔记(第十四章)
许多种不同类型,类似的方法——听起来像是个类。ArgumentMarshaler的概念就是这样产生的。对Args类所做的最主要的修改是在监测部分。随着代码腐败下去,模块之间互相渗透,出现大量隐藏纠结的依赖关系。能工作的代码经常会严重崩溃。首先,每种参数类型都要有解析其范式元素、从而为该种类型选择HashMap的方法。要编写整洁代码,必须先写肮脏代码,然后再清理它。换言之,采用TDD,不会允许做出破坏了系统的修改。没什么能比糟糕的代码给开发项目带来更深远和长期的损害了。——创建合适的空间放置不同种类的代码。原创 2024-06-26 17:49:29 · 620 阅读 · 0 评论 -
clean code-代码整洁之道 阅读笔记(第十三章)
就生成的字节码而言,对于在getNextId方法中执行的那两个线程,有12870种不同的可能执行路径。当然,多数路径都得到正确结果。这样一来,每个线程都像是世界中的唯一线程,没有同步需要。当存在一个主要为读者线程提供信息源,但只偶尔被作者线程更更新的共享资源,吞吐量就会是个问题。两个线程修改共享对象的同一字段时,可能互相干扰,导致未预期的行为。挑战之处在于平衡读者线程和作者线程的需求,实现正确操作,提供合理的吞吐量,避免线程饥饿。在另外的情况下,有可能复制对象,从多个个线程收集所有复本的结果,并在。原创 2024-06-25 16:06:44 · 709 阅读 · 0 评论 -
clean code-代码整洁之道 阅读笔记(第十二章)
提升内聚性,降低耦合度,切分关注面,模块化系统性关注面,缩小函数和类的尺寸,选用更好的名称,如此等等。这也是应用简单设计后三条规则的地方:消除重复,保证表达力,尽可能减少类和方法的数量。我们的目标是在保持函数和类短小的同时,保持整个系统短小精悍。所以,尽管使类和函数的数量尽量少是很重要的,但更重要的却是测试、消除重复和表达力。遵循有关编写测试并持续运行测试的简单、明确的规则,系统就会更贴近OO低耦合度高内聚度的目标。Kent Beck关于简单设计'的四条规则,对于创建具有良好设计的软件有着莫大的帮助。原创 2024-06-21 17:55:36 · 529 阅读 · 0 评论 -
clean code-代码整洁之道 阅读笔记(第十一章)
有一种强大的机制可以实现分离构造与使用,那就是依赖注入(Dependency Injection,DI),控制反转(Inversion of Control,IoC)在依赖管理中的一种应用手段。系统也应该是整洁的。领域特定语言(Domain-SpecificLanguage,DSL)是一种单独的小型脚本语言或以标准语言写就的API,领域专家可以用它编写读起来像是组织严谨的散文一般的代码。拥有模块化关注面的POJO系统提供的敏捷能力,允许我们基于最新的知识做出优化的、时机刚好的决策,决策的复杂性也降低了。原创 2024-06-20 18:29:48 · 873 阅读 · 0 评论 -
clean code-代码整洁之道 阅读笔记(第十章)
对类的任何修改都有可能破坏类中的其他代码。我们的Portfolio类不再依赖于TokyoStockExchange类的实现细节,而是依赖于StockExchange接口。如果我们构建一个依赖于外部TokyoStockExchangeAPI的Portfolio类,代表投资组合的价值,则测试用例就会受到价值查询的连带影响。在整洁的系统中,我们对类加以组织,以降低修改的风险。尽管讨论了这么多关于代码语句及由代码语句构成的函数的表达力,除非我们将注意力放到代码组织的更高层面,就始终不能得到整洁的代码。原创 2024-06-19 15:36:51 · 730 阅读 · 0 评论 -
clean code-代码整洁之道 阅读笔记(第九章)
代码中的测试展示了为测试构造一种面向特定领域的语言的技巧。我们没有直接使用程序员用来对系统进行操作的API,而是打造了一套包装这些API的函数和工具代码,这样就能更方便地编写测试,写出来的测试也更便于阅读。测试API中的代码与生产代码相比,有一套不同的工程标准。守规矩的开发者也将他们的测试代码重构为更简洁和具有表达力的形式。如果测试不干净,你改动自己代码的能力就有所牵制,而你也会开始失去改进代码结构的能力。测试与生产代码一起编写,测试只比生产代码早写几秒钟。和其他代码一样:明确,简洁,还有足够的表达力。原创 2024-06-18 18:09:05 · 915 阅读 · 0 评论 -
clean code-代码整洁之道 阅读笔记(第一章~第八章)
记住,好的软件系统是由一系列读起来不错的代码文件组成的。读者要能确信,他们在一个源文件中看到的格式风格在其他文件中也是同样的用法。数据、对象的反对称性:在任何一个复杂系统中,都会有需要添加新数据类型而不是新函数的时候。另一方面,也会有想要添加新函数而不是数据类型的时候。做到这一步,我们就能单独处理它,也极大地提升了代码的可维护性。在使用我们控制不了的代码时,必须加倍小心保护投资,确保未来的修改不至于代价太大。使用单独的块封装,主代码尽量只与封装的块交互。边界上的代码需要清晰的分割和定义了期望的测试。原创 2024-06-04 15:57:57 · 442 阅读 · 0 评论