zhangyunfeihhhh的博客

编写整洁的并发程序很难-非常难，即使并发代码表面上看来有问题，但依然容易在不经意间产生无法预料的问题，并发代码主要存在难测试，难重现的问题，本章主要讨论并发编程的需求及困难之处，并给出了一些对付这些难点，编写整洁并发代码的建议。1.为什么要并发并发这么难，而且容易出现意料之外的问题，那为什么我们依然需要把多线程编程作为我们需要掌握的重点技能呢？其实，并发是一种解耦策略，它帮助我们把做什么和何时做分解开来，相对于单线程的目的和时机的紧密耦合，它能明显的改进应用程序的吞吐量和结构。并发确实能带来很大的性

通过迭进设计达到整洁的目的，本章主要介绍了四条简单的规则，用以帮助你更轻易的实现代码的良好的设计已经更轻松的应用SRP和DIP等原则，这四条规则是 运行所有测试 不可重复 表达程序员的意图 尽可能减少类和方法的数量 以上规则按其重要程度排列1.运行所有测试如前面章节所介绍的，拥有良好的单元测试覆盖率，并且持续运行，会使你的代码更容易遵守一些规则，因为你会努力去编写易于测试的代码，进而更注重代码的设计，去编写低耦合高内聚的代码。2.重构有了测试，你就能保

整洁的代码帮助我们在较低层的抽象层级上达成项目代码简洁有力的目标，但是我们任然需要在较高的抽象层级-系统层级上保持整洁，就像一栋大楼，我们既需要内部装修的优美，也需要整个大楼各个部分责任明确、协调的工作。1.将系统的构造和使用分开构造和使用是非常不一样的过程，软件系统应将启始过程和启始过程之后的允许是逻辑分开，在启始过程中构件应用对象，也会存在互相纠缠的依赖你关系。也许这句话还够清晰，但是如果我们结合spring的依赖注入和控制反转所起到的作用就可以很好的理解这个思想了，这么看来，spring的DI

即使我们能写出足够整洁，具有表达力的代码语句及由代码语句构成的函数表达力，但如果无法在更高的代码组织层面进行处理，就始终得不到整洁的代码。一、类的组织类应该从一组变量列表开始，如果有公共静态常量，应该先出现，然后是私有变量，以及私有实体变量。公共函数应该跟在变量列表之后，推荐将公共函数调用的私有工具函数紧跟在该公共函数后面，准守自顶向下的原则，使程序读起来就像一篇报纸文章。二、类应该短小和函数一样，我们强调类应该短小，尽量短小，如何判断类多小合适呢，我们该如何将一个大类重构为精炼短小的类呢？

在开发系统过程中，我们总是需要购买第三方或使用开发源代码，有时我们也会依赖公司其他团队的组件或者子系统，不管哪种情况，我们都需要处理好本系统和第三方之间的边界问题，本章主要介绍一些保持软件边界整洁的实践手段和技巧。1.使用第三方代码在接口提供者和使用者之间，存在与生俱来的张力，接口提供者追求普适应，而接口使用者追求特定需求的满足，两者之间的矛盾就是导致系统边界的问题根本原因，以Map为例，Map提供了丰富的函数，可以对映射图中的数据进行灵活的操作，但是如果Map的使用场景只想来进行数据的存取，但是在

在代码开发过程中，由于大量的错误处理代码和正常的业务处理逻辑代码交杂在一起，导致代码凌乱不堪，逻辑不清，错误处理很重要，但是如果错误处理代码扰乱了代码逻辑，那这样本身就是错误的。本章主要讲述了如何雅致地处理错误代码的一些技巧和思路。1.使用异常而非错误代码以前，在处理错误时，要么设置一个错误标识，要么返回给调用者检查的错误码，但这会严重搞乱调用者代码，调用者必须在调用之后即可检查错误，但这个步骤很容易被遗忘，所以，遇到错误的时候，最好抛出一个异常，由上层代码捕获异常，统一处理，这样就可以很好的将错误

对象和数据结构之间是截然对立的，它们之间存在着二分原理：使用数据结构的代码便于在不改动既有数据结构的前提下添加新的函数，面向对象代码（接口）便于在不改动既有函数的前提下添加新类。因为数据结构代码，在添加新的数据结构的时候，必须修改所有的函数，面向对象的代码难以添加新的函数，因为必须修改所有的类。 //数据结构，直接暴露内部数据 public class Point(){ public double x; public double y; }

当有人查看底层代码实现时，我们希望他们为其整洁、一致及所感知到的对细节的关注而感到震惊。我们应该保持良好的代码格式，选择一套管理代码格式的简单规则，然后贯穿这些规则。如果在团队中工作，则团队应该一致同意采用一套简单的格式规则，所有成员都要准从。一、垂直格式像报纸那样，我们的代码也应该重上到下，层层递进，细节往下渐次展开，给人一种像读报纸一样，内容短小精悍，次序谨然。1、使用空白行进行概...

什么也比不上放置良好的注释来的有用，什么也不会比乱七八糟的注释更有本事搞乱一个模块，什么也不会比陈旧、提供错误信息的注释更有破坏性。工作中，我们总会听到比如：这代码什么注释都没有，完全看不懂，这是谁写的垃圾代码，一行注释都没有，但是我们好像从来没有听到谁说：这谁的代码，这么多注释，久而久之，我们都开始尽量多写注释，因为领导也这么要求，大家也都说这是对的，但是有时候我们写注释可能只是为了掩盖那糟...

如何写好一个函数，我觉得，一个好的函数的标准就是能让人一眼就能知道它是做什么的，这么做的，而不是上下不停的滑动，来找前后代码的关联1.短小函数的第一规则就是短小，第二条规则是还要更短小2.只做一件事，每个函数一个抽象层级判断函数是否只做了一件事就是看能否再拆出一个函数，该函数不仅只是单纯的重新诠释其实现。要确保函数只做一件事，函数中的语句都要在同一个抽象层级上，函数中混杂不同抽象层...

一、命名的意义命名，一个随处可见的操作，就像你有一个名字，我也有一个名字一样，看见马，你就能知道是指在草原驰骋的俊秀，看到猫，你就能想到是那个在家等你回去撸的小可爱，在项目中，从项目的创建到函数的实现，每一步都一命名为起点，我们需要给变量、函数、参数、类和封装包命名，这些名字出现在代码的每个角落，随处可见，名字就好像项目的指路牌，也是项目的第一道门面，如果整个项目始终贯穿着一个好的命名规范，就...

本章主要举例说明了混乱代码的代价以及说明是简洁代码。一、混乱代码的代价书中主要通过叙述一个包含混乱代码的项目生命周期以及挣扎过程来说明我们需要为混乱代码所付出的代价，这个举例让我感觉不仅真实，而且熟悉。混乱代码走向如下：1.系统迭代由于代码的混乱，每次修改，都是牵一发而动全身，而为了完成修改任务，而不得不往上堆积更多的混乱代码，一次次迭代，混乱代码越来越多，每一次修改牵涉的混乱代码...