- 博客(15)
- 收藏
- 关注
RSS订阅原创 十七章《味道与启发》
运行所有测试 减少重复代码 提高表达力 类和方法都只做好一件事 尽量减少类和方法的数量 努力，让营地比你来时更干净。让代码比你签出时更干净。
2022-02-23 21:46:02
157
原创 十四章《逐步改进》
总结， 如此我们遵循了童子军军规。模块比我们发现它时更整洁了，不是说它原本不整洁，作者们做了卓越的工作，但模块都能再改进，我们每个人都有责任把模块改进得比发现它时更整洁。
2022-01-22 21:33:23
332
原创 十三章《并发编程》
并发是一种解耦策略，他帮助我们把做什么（目的）和何时做（时机）分解开。在单线程应用中，目的与时机紧密耦合，很多时候只要查看堆栈追踪即可断定应用程序的状态。调试这种系统的程序员可以设定断点或断点序列，通过查看到达哪个断点来了解系统状态。 解耦目的与时机能明显地改进应用程序的吞吐量和结构。从结构的角度来看，应用程序看起来更像是许多台协同工作的计算机，而不是一个大循环。系统因此会更易于被理解，给出了许多切分关注面的有力手段。 建议将并发相关代码与其他代码分离开来。 两个线程修改共享对象的同一字段时，可能互
2022-01-17 08:51:15
70
原创 十二章《迭进》
通过迭进设计达到整洁的目的，本章主要介绍了四条简单的规则 运行所有测试 不可重复 表达程序员的意图 尽可能减少类和方法的数量 运行所有测试 拥有良好的单元测试覆盖率，并且持续运行，会使你的代码更容易遵守一些规则 不可重复 想要创建简洁的系统，需要有消除重复的意愿 表达力 对于费解的代码，会严重影响代码维护的效率，也许在写代码时，你觉得代码易于理解，那是因为你正在深入其中，但是当对代码进行维护的时候，你就会觉得难以理解了，所以，为了代码的易于维护性，我们需要将代码写的简单而具有表达力，比如，通.
2022-01-05 22:31:13
264
原创 十一章《系统》
一开始就做对系统”纯属神话。 反之，我们应该只去实现今天的用户故事，然后重构，明天再扩展系统、实现新的用户故事。这就是迭代和增量敏捷的精髓所在。 系统也应该是整洁的。侵害性架构会湮没领域逻辑，冲击敏捷能力！ 在所有的抽象层级上，意图都应该清晰可辨。 无论是设计系统或单独的模块，别忘了使用大概可工作的最简单方案。 ...
2022-01-05 22:19:16
210
原创 第十章《类》
类应该短小，在设计类时，第一条规则就是类应该短小 单一权责原则，类或模块应有且只有一条加以修改的理由。 类应该只有少量实体变量。类中的每个方法都应该操作一个或多个这种变量。 当类丧失了内聚性，就拆分它！ 将大函数拆分成许多小函数，往往也是将类拆分为多个小类的时机。程序会更加有组织，也会拥有更为透明的结构。 重构后的程序更长的原因：其一，重构后的程序采用了更长、更有描述性的变量名。其二，重构后的程序将函数和类声明当作是给代码添加注释的一种手段。其三，我们采用了空格和格式技巧让程序更可读。 ...
2021-12-27 22:54:34
186
原创 第九章《单元测试》
测试代码和生产代码一样重要。脏测试会让测试越变越糟，维护代价增大。故测试代码和生产代码一样重要。 整洁的测试有什么要素？有三个要素：可读性，可读性和可读性。 每个测试都清晰地拆分为三个环节。第一个环节构造测试数据，第二环节操作测试数据，第三部分检验操作是否得到强的结果。 测试保证和增强了生产代码的可扩展性、可维护性和可复用性。保持测试的整洁，让测试具有表达力并短小精悍。 ...
2021-12-27 22:42:14
257
原创 第八章《边界》
1.在软件开发的过程中，难免会引入第三方程序包或者是开源代码，然后整合进自己的项目代码中。我们可能会花上几天时间阅读文档，决定如何使用。然后，我们会编写使用第三方代码，看看是否如我们所原地工作。我们会陷入长时间的调试，找出在我们或者他们代码中的缺陷，这可不是什么稀罕事。 学习第三方代码很难，整合第三方代码也很难，同时做这两件事难上加难。 有什么好的做法呢。 不要再生产代码中实验新东西，而是编写测试来遍览和理解第三方代码。这种方法叫“学习性测试”。学习性测试是一种精确试验，帮助我们增进对API的理解。当
2021-12-09 23:43:26
289
原创 第七章《错误处理》
1.千万别返回null值，返回null值基本上是在给自己增加工作量，也是在给调用添乱。 2.如果你打算在方法中返回null值，可以抛出异常 3. 不要把null值传递给其他方法，如果会有null值情况。应对空值预先判断。 ...
2021-12-09 23:20:53
288
原创 第五章《格式》
每个函数之间，都应该有一个空行隔开。每个空行都是一个线索。标识出新的独立概念。 垂直向上原则。则是靠近上方代码没有空行隔开。则说明它们之间有紧密联系。 垂直举例 的必要性。关系密切的函数要放到一起。 垂直顺序。被调用的函数应该放到执行函数的下面。 横向格式。保持一行代码的短小。不应过长。 水平区隔，比如赋值加空格，加强了强调的目的。 缩进。 一组成员都应该采用大家认同的统一风格。 ...
2021-11-27 15:04:53
275
原创 第四章《注释》
要写好简洁的代码，简洁的代码不需要注释。注释过多的程序说明程序很糟糕，需要过多的注释来解释。 注释不能美化糟糕的代码。 有些注释是必须的也是有利的。唯一真正好的做法是想办法不去写注释。 注释要有 提供信息，对意图的解释。或者警示性的注释。 注释可以用来放大某种看来不合理之物的重要性。 过程中注释是无畏之举，不要写多余注释，在方法开始注释说明方法用途便可， 不要写误导性注释。不要写过多的信息。写重点。 ...
2021-11-11 19:09:34
78
原创 第三章《函数》
函数要短小，代码块有缩进。 一个函数只做一个目的一件事。要做好。尽量不要做多件事。 自顶向下读取代码的顺序编写，使用具有描述性的名称。 参数尽量用 0和1 再其次是2 。函数参数不要过多。 避免重复。 ...
2021-11-08 20:25:26
59
原创 第二章《有意义的命名》
避免误导，做有意义的区分，简单易读，可搜索性 避免使用编码，I和O 字母独立出现，容易和数字混淆 每个概念一个词。添加有意义的语境，关键词的运用。比如get , is ,delete 等。 使用源自所涉及问题领域的名称。命名要简单明了。避免过长和无意义的修饰词。 ...
2021-11-02 22:57:53
68
原创 第一章《整洁的代码》
避免糟糕的代码，解决通用性，避免个性化需求过多。造成后续混乱代码的堆叠，程序员是最了解代码的人，不能盲目听从多数经理人和领导的意愿和想法。程序要是遵从了不了解混乱风险经理人的意愿，也是不专业的做法。 有多少程序员，就有多少对整洁代码的定义，并且也没有绝对的整洁代码的定义。也会随时间的改变不断的变化。每个新团队都会抱怨旧系统程序难以理解和读取不变，谁都想加入重做团队像一张白纸的程序写出一套华丽的设计，但开发时间久。新系统要实现究系统的所有功能，还得跟得上旧系统的持续改动，开发完成后。新成员的老员工可能早已不
2021-10-25 21:14:17
120
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人