我也不知道是为什么，就是突然很想看这本书，但是文言文真的好难啃啊，于是这几周就一直在读这一本书……
《孙子兵法》这本书很有意思，读完之后发现，其中最著名的几句话，也是对其误读最深的几句话，比如“兵者，诡道也”，比如“置之死地而后生”。本来是打算把这本书当作一本故事书读着玩的，结果哪里知道，这本书讲的全然不是什么诡道，特别的平实，满满的正能量，他教我们怎样做事，怎么管理企业和团队，怎么样评估风险控制预算，等等等等。真的没想到几千年前讲的东西，哪怕是到了现在都非常的实用。也许不管时代怎么变，科技怎么发展，人，终究还是人吧……
另外一个有意思的地方就是，其实《孙子兵法》有很多内容甚至核心思想也都不是其原创，而是更早的人发明了之后流传下来的。这个人便是黄帝身边的宰相，叫做风后。没错，就是《一人之下》里风后奇门的风后。除了因为风后是最早发明这些兵法的人，还因为风后留下来到现在著作《八阵图》和《握奇经》里面详细描述了如何运用八卦进行阵法布置，所以就有了《一人之下》里面的风后奇门的演绎了。
好了，让我们说回正题——《孙子兵法》吧。
在现在这个遍地996福报的年代，人们的生活压力越来越大，沟通的便捷让工作几乎侵占了生活的各个角落，老板们周末在微信群里的胡言乱语，同事们随意发送的“有空吗”的垃圾信息，在家办公导致工作更加没有边界，这些都让我们的生活越来越疯狂。然后，2020年下半年，重来3出来了，给我们描绘了一个安居乐业的美丽新世界！这本书的目标只有一个，那就是帮助我们打造一个冷静的公司，拒绝加班，拒绝没必要的压力。虽然在这个军备竞赛的年代不知道什么时候才能真正做到，但是我们每个人都可以开始慢慢从点滴做起，毕竟每周40个小时的工作制是前人们拿性命换回来的，别就这样随手又还给了资本家。
虽然没有加班的世界确实很美好，但是这并不意味着大家可以任意摸鱼，也不意味着公司无所求的无限付出。为了实现这个美丽新世界，我们需要先来了解一下它的大前提，这些虽然在重来3里被一笔带过，但是作者其实是用了《重来1》和《重来2》两本书来解释的。
首先，最重要的就是人，真正优秀的人！重来2花了一整本书来介绍远程办公的可行性，其原理就是创建一个正向的反馈，因为远程办公带来的跨时空的便利性，所以公司可以不受约束的寻找最优秀的人才，而这些优秀的人也让远程办公变得更加可行。一旦正向反馈被创建起来，公司就能走向正轨，可是如果员工利用便利天天摸鱼，那很快公司就会完蛋。那我们要寻找什么样的员工呢？重来2中也给出了答案：
这本书很有意思，成书于2014年，豆瓣上现在只有7.2分。很多热评都是在五六年前留的，嘲笑这本书上不切实际的评论铺天盖地。结果呢，去年新冠爆发，科技公司的员工基本全都开始了在家办公，硬生生的把大家狠狠的推了一把！一开始我没做好准备，各种不适应，可是谁也没想到最后的结果却是，效率比在办公室来的更高了，周围的人以前看不出来的各种才华也开始显现了，画画的，跳舞的，甚至出唱片的，百花齐放，而真的有机会见面的时候就更加开心了，一种老友相见的感觉，唠不完的磕～
这个时候再回头看这本书，觉得作者真是先知，每一条都戳在我的痛点上，看完感觉真的学到了不少，于是继续做个笔记，也给大家强烈推荐这本书，别因为豆瓣低分就错过了～
这本书的作者之一是Ruby on Rails的创始人，David Heinemeier Hansson (DHH)，就和书里面说的一样，这本书应该是DHH他们创业之后的副产品 —— 一本讲如何创业的书。虽然如此，但是其不仅仅只对创业有用，对平时的工作也有很帮助。
书里面讨论了创业时心态和方法的方方面面，但我觉得这本书的核心观点归根结底就是作者之一Jason Fried的座右铭：“It's simple, until you make it complicated.”
如果你打算创业，那么首先你得为自己卸负。灵感稍纵即逝，有了好的点子，就应该立刻放手去实现，不要为自己找借口。团队小并不是一件坏事，因为它足够灵活，非常适合前期探索和试错。一开始没有投资也不是什么坏事，拉来的投资也就意味着丧失了话语权。另外，行动前，向成功学习成功的经验，而不是失败；
In the last post, we discussed the reasons for writing tests, principles and how to write code that is easy to test. In this post, we'll discuss more on how to write good tests.
First, let me repeat the important thing: Test is a not a silver bullet. Adding a few tests won't help us improve the code quality that much. If you haven't read the part 1 yet, it is highly recommended to read it first.
We are finally here! Let's talk about writing tests! Making code easy to test is only the first step, and to write good tests we will need some more skills.
We know that there are various types of tests. And here are some examples:
"Please write a UT for this change." is one of the most frequent comments I leave in the code review. And I am seeing people tend to write minimum tests just for having something to pass the review.
Well, I kind of understand writing tests is annoying sometimes, but tests are extremely helpful and there are things could help us writing them too. So let's talk about test!
"Hey! It compiles! Ship it!"
When talking about writing tests, many people find it annoying for simliar reasons:
All these questions and complaints are basically because we don't understand the real intention of testing, and finally fall into the misunderstanding of writing test for the sake of writing tests. And when we are forced to do something, we are never going to feel it will benefit us, even if it really does.
上篇中，我们主要讨论了写测试的理由，原则和如何写出易于测试的代码。这一篇里，我们会来真正讨论如何写出好的测试。
这里重要的事情再重复一遍：测试不是一剂万能药，加几个测试并不能帮我们改善多少代码质量，把代码本身写好才是根本。如果还没有读过上篇，这里强烈推荐先阅读上篇～
现在，我们终于可以开始写测试了！好的代码只是我们实现好测试的第一步，要写出好的测试我们还需要更多的一些技巧：
我们知道测试的类型多种多样，有且不限于如下一些类型：
最近在做一个多团队合作的项目，需要将我们的服务的配置管理和自动化部署流水线从一个平台迁移到另外一个平台，但是这个项目很要命的是，另外一个团队的成员一心只想赶快完成任务，代码的改动从来就不加测试，每次做了两行修改就开始在自己的分支上创建Official build，然后上运营环境测试。劝了好几次也无动于衷，总觉得测试是一件麻烦的事情，拖了他们的后腿。其实这个项目本来并不复杂，偏偏他们做了两年都没做出来，还弄出不少线上事故，真的是事百倍功半，所以这次就想单独写一点关于测试的事情。
"Hey! It compiles! Ship it!"
每次提到写测试，很多人会觉得很烦，原因都大同小异：
有上面这些疑问和抱怨，基本上都是因为没弄明白测试的真实意图，最后陷入了为了测试而测试的误区。而当我们被迫做一个事情的时候，我们是永远都不会觉得做这个事情有什么好处的，即便它真的有。
最近在一次分布式系统的线上交流中，发现居然有那么多种不同的一致性模型，而且因为种类太多，大家理解上也有很多不同，看了一些资料，虽然很多讲的很好，但是过于复杂或者书面，难以理解，所以在这里尝试着为每一个模型做一句话总结，希望可以帮助大家理解。如果我的理解有误，也请大家指正～
一致性虽然是我们非常常用的一个词，但是非常不幸的是，这个词有太多的含义，在使用的非常容易混淆。所以在讨论一致性之前，我们需要先来看一下一致性的定义：
首先是我们常说的Consistency。这个词经常在两个地方出现：分布式系统的CAP和数据库的ACID。虽然其中“C”都叫一致性（Consistency），但是其含义却截然不同：
然后是Coherence。这个词虽然也翻译成一致性，但是它和上面的一致性截然不同。Coherence指的是多实体或者多层级的数据之间是否一致，比如：缓存一致性（Cache Coherence，缓存中的内容是否和原始内容保持一致）。而Consistency指的是一个单实体本身是否一致，比如上面提到的同一个数据库里的外键关系或者同一个服务不同节点之间的同步状态。
好了，在简单探索完基础类型之后，我们就来看一下我们最关心的Struct吧！
我们先从最简单的开始，先定义一个简单的结构体，里面错落的放一些大小不一的字段：
1 | type A struct { |
然后定义一个变量a，再用上篇文章中的DumpObject函数来看一下其内存布局：
1 | Var Type Address RootOffset LocalOffset Size |