代码整洁之道
文章平均质量分 92
haikuotiankongdong
这个作者很懒,什么都没留下…
展开
-
《代码整洁之道》阅读笔记 13并发(编写整洁的并发代码建议)
“对象是过程的抽象,线程时调度的抽象。”——James O Coplien1.为什么要并发1.并发是一种解耦策略,它帮助我们把做什么(目的)和何时做(时机)分解开2.相对于单线程的目的和时机的紧密耦合,解耦目的与时机能明显地改进应用程序的吞吐量和结构3.单线程程序许多时间花在等待web套接字I/O结束上面,通过采用同时访问多个站点的多线程算法,就能改进性能4.同时也存在一些副作用并发总能改进性能:只在多个线程或处理器之间能分享大量等待时间的时候管用编写并发程序无需修改设计:可能与单线程系统原创 2021-05-10 17:38:53 · 272 阅读 · 0 评论 -
《代码整洁之道》阅读笔记 12迭进
系统的迭代式演进1.通过迭进设计达到整洁目的运行所有测试不可重复表达程序员的意图尽可能减少类和方法的数量以上规则按其重要程序排列2.简单设计原则1:运行所有测试设计必须制造出如预期一般工作的系统,这是首要因素全面测试并持续通过所有测试的系统,就是可测试的系统,不可验证的系统,绝不应该部署上线只要系统可测试,就会导向保持类短小且目的单一的设计方案紧耦合的代码难以编写测试遵循有关编写测试并持续运行测试的简单、明确的规则,系统就会更贴近OO低耦合度、高内聚度的目标,编写测试引致更好原创 2021-05-08 16:02:12 · 278 阅读 · 0 评论 -
《代码整洁之道》阅读笔记 11系统
“Complexity kills. It sucks the life out of developers, it makes products difficult to plan, build and test.”(复杂要人命,它消磨开发者的生命,让产品难于规划、构建和测试)1.如何建造一个城市1.每个城市都有一组人管理不同的部分,有人负责全局,其他人负责细节2.深化出恰当的抽象等级和模块,好让个人和他们所管理的“组件”即便在不了解全局时也能有效地运转2.将系统的构造与使用分开原创 2021-05-06 16:35:10 · 372 阅读 · 0 评论 -
《代码整洁之道》阅读笔记 10类
SRP(单一职责原则)1.类的组织1 ) 类应该从一级变量列表开始,如果有公共静态变量,应该先出现,然后是私有静态变量,以及实体变量,很少会有公共变量2 ) 公共函数应该跟在变量列表之后3 ) 我们喜欢保持变量和工具函数的私有性,有时需要用到受保护变量或工具函数,好让测试可以访问到我们首先会想办法使之保有隐私,放松封装总是下策2.类应该短小1 ) 第一规则是类应该短小,第二规则是还要更短小2 ) 衡量方法,计算权责(responsibility)3 ) 类的名称应当描述其权责,如果无法为某个原创 2021-04-30 19:15:55 · 217 阅读 · 1 评论 -
《代码整洁之道》阅读笔记 9单元测试
FIRST规则(Fast、Independent、Repeatable、Self-Validating、Timely)单元测试想必大家都很熟悉,即便没有真正的做过单元测试,但肯定也听过单元测试以及单元测试的重要性。完善的而又规范的单元测试,不仅能够能够有助于自己写出简洁的代码,使代码变得可扩展、可维护、可复用,还能够极大的提到代码的健壮性。1.TDD三定律1.在编写能通过的单元测试前,不可编写生产代码2.只可编写刚好无法通过的单元测试,不能编译也算不通过3.只可编写刚好足以通过当前失原创 2021-04-30 09:29:27 · 184 阅读 · 0 评论 -
《代码整洁之道》阅读笔记 8整洁的边界
所谓的“边界”是指外来代码(三方程序包、开放源代码、其他团队打造的组件和子系统)和自己写的代码之间进行整合的连接区域1.使用第三方代码1.第三方程序包和框架提供者追求普适性,这样就能在多个环境中工作,吸引广泛的用户。2.我们建议不要将Map(或在边界上的其他接口)在系统中传递,把它保留在类或近亲类中,避免从API中返回边界接口,或将接口作为参数传递给公共API。比如应用程序可能构造一个map对象并传递它。我们的初衷可能是map对象的所有接收者都不要删除映射图中的任何东西。但map正好有一个clea原创 2021-04-29 16:48:40 · 275 阅读 · 0 评论 -
《代码整洁之道》阅读笔记 7错误处理
错误处理很重要,但如果它搞乱了代码逻辑,就是错误的做法整洁的代码中对错误的处理应当是被分离的关注点(不要跟正常的业务逻辑混杂在一起),而面向对象中的异常机制就是一种在不打乱原有业务逻辑的前提下处理掉程序在运行时发生的不正常状况的手段。1.使用异常而非返回码遇到错误时,最好抛出一个异常。调用代码很整洁,其逻辑不会被错误处理搞乱以前,没有异常处理机制时:(这类手段的问题在于,他们搞乱了调用者代码。调用者必须在调用之后即刻检查错误,不幸的是,这个步骤很容易被遗忘。)设置一个错误标识;返回给调用原创 2021-04-29 15:13:14 · 228 阅读 · 0 评论 -
《代码整洁之道》阅读笔记 6对象和数据结构
合理抽象,暴露行为,隐藏细节(实现过程)将变量设置为私有(private)有一个理由:我们不想其他人依赖这些变量。我们还想在心血来潮时能自由修改其类型或实现。那么,为什么还是有那么多程序员给对象自动添加赋值器和取值器,将私有变量公之于众、如同它们根本就是公共变量一般呢?1.数据抽象1.隐藏实现关乎抽象,类并不简单地用取值器和赋值器将其变量推向外部,而是 曝露抽象接口 ,以便用户无需了解数据的实现就能操作数据本体// 具象点public class Point { public doubl原创 2021-04-29 14:54:46 · 226 阅读 · 0 评论 -
《代码整洁之道》阅读笔记 5格式
用什么样的代码风格不是关键,关键是整个项目组的成员应当使用相同的代码风格,让多个人编写的代码看起来像一个人书写的。1.格式的目的1.代码格式关乎沟通,而沟通是专业开发者的头等大事。2.因为代码的可读性会对以后可能发生的修改行为产生深远的影响。2.垂直格式图中涉及7个不同项目: Junit、 FitNesse、 testNG、 Time and Money、 JDepend、Ant 和 Tomcat贯穿方块的直线两端显示这些项目中最小和最大的文件长度。方块表示在平均值以上或以下的大约原创 2021-04-28 14:58:45 · 250 阅读 · 0 评论 -
《代码整洁之道》阅读笔记 4注释
"Comments Do Not Make Up for Bad Code."(注释不是对劣质代码的补救)。事实上好的代码即便没有注释也拥有良好的可读性,但恰当的注释会让代码变得更可读、可维护性更高。1.注释不能美化糟糕的代码1.带有少量注释的整洁而有表达力的代码,要比带有大量注释的零碎而复杂的代码像样得多2.与其花时间编写解释你搞出的糟糕的代码的注释,不如花时间清洁那堆糟糕的代码2.用代码来阐述用代码解释你大部分的意图,很多时候,简单到只需要创建一个描述与注释所言同一事物的函数即可// ch原创 2021-04-27 22:44:11 · 414 阅读 · 0 评论 -
《代码整洁之道》阅读笔记 3函数
"Function should do one thing. They should do it well. They should do it only. "(函数只应该做一件事情,把一件事情做好,而且只由它来做这一件事情)1.短小1.函数的第一规则是要短小,第二条规则是还要更短小 。20行封顶最佳。2.if语句、else语句、while语句等,其中的代码块应该只有一行,该行大抵是一个函数调用语句 ,块内调用的函数应拥有较具说明性的名称。(从而增加了文档上的价值)3.函数不应该大到足原创 2021-04-27 17:31:38 · 316 阅读 · 0 评论 -
《代码整洁之道》阅读笔记 2有意义的命名
第二章主要说一下命名的一些要遵循的小标准。1. 名副其实1.变量、函数或类的名称应该已经答复了所有的大问题,如果名称需要注释来补充,那就不算名副其实int d; // 消逝的时间,以日计名称d什么也没说明,没有引起对时间消逝的感觉,更别说以日计了。应选择指明了计量对象和计量单位的名称int elapsedTimeInDays;int daysSinceCreation;int daysSinceModification;int fileAgeInDays;2.代码的模糊度:即上下文在原创 2021-04-27 11:34:04 · 451 阅读 · 0 评论 -
《代码整洁之道》阅读笔记 1整洁代码
这一章主要就是说了一些作者们自己对于写代码的一些思想和理解,以及他们想对我们说的话。主要是说了几个混乱代码造成的后果,然后引出了优美的代码能带来的好处。1.什么是代码将需求明确到机器可以执行的细节程度,就是编程要做的事情,而这种规约叫代码。2.混乱的代价勒布朗法则:稍后等于永不1.有些团队在项目初期进展迅速,但有那么一两年的时间却慢去蜗行。对代码的每次修改都影响到其他两三处代码2.花时间保持代码整洁不但有关效率,还有关生存3.程序员遵从不了解混乱风险经理的意愿,也是不专业的做法3.什么原创 2021-04-26 22:07:08 · 225 阅读 · 0 评论