自增人生

Read Code

我们码农是种非常神奇的生物。我们热爱写代码，但等到要阅读它的时候，我们就犯困了。毕竟，写代码是如此的欢乐，而读代码就太难了——有时几乎不可能。阅读别人的代码尤为困难。不一定是别人的代码就很烂，更又可能是和你解决问题的思维方式不同罢了。但你真的觉得阅读别人的代码对你的提高没有帮助吗？

下次你读代码的时候，停下来想一想。这段代码是难还是简单？如果它难读懂，又是为什么？格式化不好？命名反直觉或者不符合常识？同一段代码混合了多个事情？或许语言的选择阻止了代码的可读性。试着去学习别人的错误，你的代码就不会包含同样的错。你或许会收获惊喜。例如，依赖注入技术（原文dependency-breaking techniques）也许能很好地降低代码耦合，但它们有时会让代码变得难读。因此，有人称之为优雅的代码，有人称之为不可读。

如果代码容易阅读，停下来看看是否有你可以学习的地方。也许其中就包含你不知道的设计模式，或者之前不会的实现。或许这些方法比你的更简短且命名准确。一些开源项目完全就是如何写出绝妙可读代码的典范——而其他人则恰恰相反！签出他们的代码看一看吧。

读一读你以前的代码，比如你现在已经不在参与的项目的，也能从中有所启发。从最老的代码开始，逐步发展到现在。你很可能会发现它并不像你编写时那样可读。哪怕你最近写的代码也可能存在另你尴尬的娱乐价值，就像你昨天在酒吧喝醉后说过的话一样。看看你多年来是如何挖掘自己的潜力的——确实有激励作用。着重看看难读懂的代码是哪些，并反思一下今天是否还用相同的方式在写代码。

所以，下次感觉需要提升一下自己编程技能的时候，别着急看书。阅读代码吧。

Put the Mouse Down and Step Away from the Keyboard

你肯定有过花几个小时研究某个懊恼的问题，但始终没有个明确的解决方案。然后用力跺脚或者去题贩卖机，结果在回来的路上，灵光乍现。

这种情况请起来熟悉吗？有没有想过为什么会这样？其实是因为你一直在写代码，你大脑负责逻辑的区域被激活了，而负责创造的部分被关闭了。它不可能联想任何事情，直到你停止逻辑区域。

有个真实案例：我正在清理某段遗存的代码，并让其跑到了“关注”的方法里。它是设计用来校验一个字符串是否包含以hh:mm:ss xx格式的时间，其中hh表示小时，mm表示分钟，ss表示秒钟，xx表示AM或PM。

这个方法用以下代码将（表示小时的）两个字符转化为一个数字，并校验其是否在合法范围：

1
2
3
4
5
6

try {    Integer.parseInt(time.substring(0, 2)); 
} catch (Exception x) {
    return false;
}if (Integer.parseInt(time.substring(0, 2)) > 12) { 
    return false;
}

相同的代码出现了两次，而且测试分钟和秒钟也只是通过修改相应的字符偏移和上限。方法的最后是用来检查AM和PM的实现：

1
2
3

if (!time.substring(9, 11).equals("AM") & !time.substring(9, 11).equals("PM")) {
    return false; 
}

如果这些比较流出现失败，就返回false，否则返回true。

以上代码看起来冗长且难以理解，但别担心。我知道该怎么做——就是说我已经想到一些办法来简化它了。我重构了它，并编写了一个简单的单元测试来确保它正常工作。

完成后，我对结果感到满意。新的版本更容易读懂，而且只有之前一半大小，也更精确了，因为之前的代码仅测试了小时、分钟、秒钟的上限。

当第二天准备上班的时候，我的脑袋碰的一下：为什么不用正则表达式来校验这个字符串呢？敲了几分钟键盘后，我仅用了一行代码就实现了该功能。如下：

1
2

public static boolean validateTime(String time) {    return time.matches("(0[1-9]|1[0-2]):[0-5][0-9]:[0-5][0-9] ([AP]M)"); 
} 

这个故事的重点不用我用一行代码就替换了原本的30行代码。重点是直到我离开电脑之前，我都自认为第一次的尝试就是问题的最佳解决方案。

所以，下次你碰到让人恼火的问题时，帮自己个忙。一旦你理解了这个问题，就去做一些可以激活你大脑创造力区域的事情——勾勒出问题，听一些音乐，或者去散个步。有时为了解决问题，你可以做的最好的事情或许是，放下鼠标，离开键盘。

Put Everything Under Version Control

把你项目中的每件事情都放到版本控制下。你可能需要用到这些工具：比如免费的Subversion、Git、Mercurial、以及CVS；足够大的硬盘；有性价比的服务器；无所不在的网络；甚至还需项目托管服务。当你安装完这些版本控制软件后，为了将你的工作放进仓库里，你所需要做的就是在一个包含你代码的干净目录中用发出相应的命令。之后你只有两个基本的操作要学：将你改变的代码提交到仓库，将你工作的版本更新到仓库版本。

一旦你的项目处理版本控制下，你就可以很直观地追踪其历史，看到是谁写什么什么样的代码，并通过ID去指向文件或项目版本。更重要的是，你可以放心大胆地去修改代码——不必为了将来可能需要它就暂时注释掉代码，因为它们依旧安全地存放在仓库的旧版本中。你可以（也应该）用一个符号名来标记软件发行版本，以便于将来可以追溯用户所运行软件的确切版本。你还可以创建并行的开发分支：大部分项目都有一个活跃的开发分支，以及一个或多个维护分支，用于积极地支持发行版。

一个版本控制系统能最大程度地降低开发者之间的摩擦。程序员们各自开发软件的独立部分，然后魔法般地整合到一起。当他们相互冲突时，系统会发出通知，并允许他们解决冲突。通过一些附加的设置，系统还可以通知到每一个已提交过的开发者那里，从而对项目进展达成共识。

当你的项目启动后，不要小气鬼：将所有项目相关的内容都放入版本控制。除了源代码，还包括文档、工具、构建脚本、测试用例、工艺、甚至是库等。将整个项目完整的塞进这个（定期备份的）仓库中，让磁盘或数据丢失的风险降至最低。在新机器上搭建开发环境只需要简单地从仓库签出即可。这简化了在不同平台上的分发、构建以及测试代码：在每台设备上，每条更新指令都能保障其软件是当前版本。

一旦你见识到使用版本控制系统工作的美妙，遵循下面几条规则就会让你和你的团队变得更有效率：

• 将每次逻辑变更都进行单独的提交操作。将很多的变更集中到一次性提交的话，会使它们在功能上变得很难被分解。这在你进行项目范围的重构或改变风格的时候尤为重要，会很容易掩盖其他的修改。
• 每次提交都伴随一条解释信息。要简短地描述你做了什么改变，但如果你想记录一下改变的缘由，也最合适放在此处。
• 最后，避免提交的代码会破环项目的构建，否则你会受到项目组其他开发者的鄙视。

版本控制系统的人生多么美好呀，不用废止就能轻松避开错误。

The Professional Programmer

何为职业程序员？

职业程序员最重要的一个特点就是个人责任感。职业程序员会为他们的事业、估算、承诺、错误、技能等负责到底。职业程序员不会将这些责任推诿给其他人。

• 如果你是职业的，你就会对自己的事业负责。你有责任阅读和学习。你有责任了解最新的行业技术。很多程序员觉得应该是他们的雇主来培养他们。抱歉，这是大错特错。你会认为医生是这样过来的吗？你会认为律师是这样过来的吗？非也，他们都是利用自己时间和精力来自我培养。他们会花大量的业余时间来阅读期刊和决策，让自己保持最前沿。所以我们也必须如此。你和你雇主的关系在劳动合同里有很好的阐述：雇主承诺付给你薪水，而你承诺做好一份工作。
• 专业人士为他们所写的代码负责。除非他们确认运行正常，否则就不会发布他们的代码。试想一下，如果你愿意发布一份自己都不确定的代码，你又怎么敢认为自己的职业的呢？职业程序员会希望QA团队找不出任何问题，因为在他们没有完成测试过代码之前是不会发布它们的。当然，QA总能找出些问题，毕竟人非圣贤。但作为一个职业者，我们的态度是必须消除QA找出的一切问题。
• 专业人士是团队的玩家。他们为整个团队的输出负责，而不仅限于自己的工作范围。他们帮助他人、教导他人、从他人身上学习，甚至在必要时替他人掩护。当某个队友栽跟头时，其他人就介入进来，因为他们知道自己有一天也会变成需要被掩护的那一个。
• 专业人士不会容忍大bug表。一个庞大的bug列表就是草率的。在问题跟踪库里包含了数千条问题的系统就是粗心大意的悲剧。确实，对多数项目而言，极度依赖问题跟踪系统就是一种粗心的态度。只有最庞大的系统才应该配备问题列表，以便于自动化管理它们。
• 专业人士不会去捣乱。他们以自己的技能为傲。他们保持代码的简洁、良好的结构、以及可读性。他们遵循公认的标准和最佳实践。他们从不焦躁。想象一下你元神出窍来观察一名心脏外科医生在给你做手术。这名医生有了一个deadline（就是字面意思）。他必须在心扉旁路仪损耗你过多血红细胞之前完成手术。那你希望他怎么做？你会希望他像一个典型的软件开发者一样，焦躁并乱搞一通？你会希望他说：“我过会儿再来修复”？还是说你会希望他恪守纪律，抓紧时间，确信自己的方案时他可以做到的最佳方案。那么，你是希望他捣蛋，还是职业化。

职业是一种责任感。他们为自己的事业负责。他们会为自己的代码正常工作负责。他们会为自己的技能质量负责。他们不会在截止时间逼近就亲言放弃。确实，当压力越来越大时，专业人士会纪律严明地坚持自己学识的正确性。

Prevent Errors

错误消息是用户和系统其余部分之间的最关键交互。它们往往发生在用户和系统间的通信快要断开时。

由用户输入错误而引起的错误是很容易理解的。不过人们犯错是可预测的，是有规律的。因此，就像调试系统和其他组件一样，“调试”用户与系统间的通信也是有可能的。

例如，假设你想让用户输入一个合法范围的日期。相对于让用户输入任意日期，不如提供一个仅显示合法日期的列表或日历的设备。这就消除了用户范围之外的日期的可能性。

格式化错误也是另一种常见问题。例如，用户使用“日期”文本字段输入了一个明确的日期“2012年7月29日”，结果被简单粗暴的给拒绝了，就因为它不是首选格式（如DD/MM/YYYY）。更糟糕的是还会拒绝“29 / 07 / 2012”，因为它们当中包含了空格——这种问题简直让用户怀疑人生，因为他们给的日期似乎在所需格式里呀。

发生这种错误是因为，相对于解析三四种常见日期格式，直接拒绝这些日期要更容易。这些错误会让用户觉得烦躁，继而失去专注导致更多错误。所以，尊重用户的输入习惯，而非数据本身。

另一种避免格式错误的方法是给出提示——例如，在字段标示上展示所需格式（“DD/MM/YYYY”）。另一种提示则是让字段分为2-2-4字符长度三个文本框。

提示和说明是有区别的：提示更倾向于暗示；而说明则是一种详述。提示出现在交互时；而说明出现在交互前。提示仅用于上下文，而说明则强调如何使用。

一般来说，说明是无法阻止错误的。用户会假设界面将按照他们过去的经验工作（“难道每个人都明白‘July 29，2012’是什么意思？”）。因此使用说明从来不读，而提示才可以让用户远离错误。

还有一种避免错误的方法是提供默认值。例如今天、明天、我的生日、截止日期、我上次输入表格的时间等，都是用户的典型输入。根据上下文。其中之一将会是明智的默认选项。

无论什么原因，系统都应该有容错能力。你可以通过多级别的撤销来简化这些操作——尤其是可能破坏或修改用户数据的操作。

记录并解析撤销操作也可以突出显示界面，将用户吸引到无意识的错误上。例如连续的点击“错误”按钮。这些错误通常是由于有误导性的提示或交互序列引起的，你可以重新设计以阻止它们。

不论你选择何种方案，大部分错误都是系统性的——都是用户与软件之间误解的结果。理解用户的想法，对信息的解释，做出的决定，以及输入的数据都将帮助你更好地调试软件与用户间的交互方式。

Prefer Domain-Specific Types to Primitive Types

1999年9月23日，由于地球上的软件错误，价值3.276亿美元的火星气候轨道器在进入火星轨道后失联。该错误后来被称为度量混淆。地面航天站采用的单位是“磅”，而航天器采用的是“牛顿”，导致了地面站将推进器的功率低估了4.45倍。

这只是众多案例之一，如果采用更多更健全的领域专用类型就可避免的软件故障。这也是Ada语言众多特性背后的原理的一个示例，其设计的首要目标之一就是实现嵌入式安全关键软件。Ada拥有强大的类型功能，可以对原始类型和用户自定义类型进行静态类型检查：

1
2
3
4
5
6

type Velocity_In_Knots is new Float range 0.0 .. 500.00;
type Distance_In_Nautical_Miles is new Float range 0.0 .. 3000.00;
Velocity: Velocity_In_Knots;
Distance: Distance_In_Nautical_Miles;
Some_Number: Float;
Some_Number:= Distance + Velocity; -- 此处将会被编译器捕获一个类型错误。 

在要求较低的领域中，开发者也能通过应用领域专用类型获益，否则他们就会继续使用语言或库提供的原始数据类型，如strings或floats。在Java、C++、Python以及其他现在语言，抽象数据类型被理解为class。采用诸如Velocity_In_Knots和Distance_In_Nautical_Miles的累定义会给代码质量方面增添价值：

• 由于不是简单的Float或String，领域的概念可以得到体现，这样的代码变得更可读。
• 由于代码封装了易于测试的行为，这样的代码更具备可测试性。
• 这样的代码促进了跨平台或系统间的复用性。

这个方法对于静态或动态类型语言的用户也同样有效。唯一的区别是，静态类型语言的开发者可以从编译器获取一些放逐，而那些拥抱动态类型语言的开发者更多的需要依赖于他们的单元测试。检查的方式或许不同，但所展现的初衷是一致的。

其寓意是为了开发高质量软件而开始探索领域专用类型。

Pair Program and Feel the Flow

【译注】：根据我现有的认知，文中的“流”（flow）表示一种心理状态，比如近期比较火的“心流”是指极度冷静、沉稳、专注的做事情的状态。所以这里的流应该是要表达特别顺畅的意思。

想象一下你完全被正在做的事情吸引住——专注、一心一意、全情投入。你会发现时光飞逝。那种感觉肯定很好。你正在经历体验流（experiencing flow
）。对于一个团队的开发者而言，要达到并维持这种流是很困难的，因为它会被非常多的中断任务、交流、以及分心给轻易打破。

如果你有过结对编程的经验，那么你很可能熟知结对是多么有助于达到这种流状态。如果你还没试过，我们希望通过自己的经验促使你赶快行动起来！为使结对编程取得成功，团队中的个体以及团队本身都不得不付出一些努力。

作为团队的一份子，你要对经验不足的开发者有耐心。也不要被比你强的开发者吓倒。要明白人所不同，各有千秋。意识到你自己以及团队其他人的长处和短处。你就会惊讶自己可以从同事身上获益良多。

作为团队，引入结对编程来促进技能和知识在整个项目中的合理匹配。你应该配对任务，并经常轮换配对和任务。商讨出一个轮换规则，放一边，在必要时再进行调整。我们的经验是，在轮换到下一个结对前你也不是非要完成现有任务。中断当前任务将其留给下一组结对者听起来可能会反直觉，但我们发现这样做照样运转正常。

流可能被很多情况打断，以下是一些保持流的方法：

• 降低“卡车因子”。这是个略微消极的观点，但是在团队无法完成最终交付之前，有多个成员不得不被卡车撞到呢？换而言之，你的交付有多依赖于团队中的某些成员？知识是私有的还是共享的？如果你采取结对方式轮换完成任务，那就总有人具备完成这项工作的知识。你的团队流也就不会受“卡车因子”的影响。
• 高效地解决问题。如果你在结对编程中遇到了挑战，总是有人可以和你一起探讨。相对于你一个人在那困扰，这样的对话更有解决的可能性。随着工作的轮换，你们的解决方案会被下一组结对回顾和反思，因此即使刚开始选择的不是最有解决方案也没关系。
• 平滑整合。如果你们当前的任务需要调用他人的代码片段，你当然希望其方法名、文档、以及测试都有充分的说明好让你掌握它。否则，直接与编写此代码的开发者结对工作，也能给你更好的概述并更快地整合到你的代码中。此外，你还能借这次讨论的机会改进命名、文档和测试。
• 缓解中断。如果其他人来问你问题，或者电话响起，或者不得不回复某个紧急邮件，又或者不得不去开会，与你结对编程的伙伴将继续编码。当你回来后，你的同伴仍然在流中，而你也能迅速地同他参与其中。
• 更快地培养新人。通过合理的轮换组队和任务的结对编程，新来的人能快速地掌握代码，以及认识团队成员。

流，可以让你变得难以置信的高产。但它也非常脆弱。尽力达到这种状态并维持着！

这一生要经历多少低谷？

这一生要熬过多久磨难？

面对生活，年轻气盛的你随口甩出一句“未来可期”，生活却以为你是在期待被它蹂躏，当然要卯足了劲地玩你！等你终于扛不住了，终于承认自己的矮小了，终于说出那句“我太难了”…像是在乞求怜悯的时候，生活会回答你的，“乖，摸摸头，未来继续可期😁”。

人生海海，没办法，谁还没有过血气方刚的时候，动不动就要胜天半子。

人生海海，没办法，我们已经到了枸杞续命的年纪，就让一切随缘吧…

可是，偏偏就有这样一种人，当看清生活的真相后依然热爱生活，朴实而机械地执着，似乎永远看不到头，但他从来不会放弃，像只打不死的小强，一天一天和生活较量着。

人生海海，敢死不叫勇气，活着才需要勇气！

《人生海海》是一部非常用心的小说，讲述了一个村一群人的往事，以第一人称视角“偷窥”或见证了几个主要人物的一生。当然，男一号毕竟只有一个——上校。

上校本是村里的木匠，之后加入了国军，亲历了抗日战争，当过军医，做过军统特务，而后又转到共军，参加过抗美援朝。他是军队里的上校，又是救死扶伤的金一刀，更是村民流言蜚语的太监。后来还成了文革期间的大汉奸，公安局要抓的逃犯，日本寡妇的玩物，监牢里的囚犯…

上校这辈子沧海桑田，人生多面，每次起起落落都足以摧垮一个人，而他却依然能我行我素地活着。诚然，上校的性格是一方面，但我觉得更重要的是他为了坚守肚皮上的耻辱所作出的牺牲。试问哪个男人愿意承认自己曾是卖国贼的玩具，这也许便是上校与生活抗争的勇气。

。。。。。。

坦白说，我难得会遇到一部小说，读完之后没有半点想要总结归纳的心思，大概是这部小说太有感染力了吧！

管它的，我很感激这样的年纪能读到这样的故事，让我明白人的一生还会如此凄惨，原谅我的幸灾乐祸，这大概也是我在不如意的生活里，寻找到的一丝丝慰藉。（自找的矫情，呵呵！）

Own (and Refactor) the Build

在一个团队里，纪律严明地开展编程实践而忽视构建脚本的情况并不罕见，他们认为那些只不过是无关紧要的细节或者害怕其中的复杂度，倾向于让狂热的版本发行工程师去做此事。而那些带有重复和错误的构建脚本所导致的问题，与那些糟糕的代码一样需要严重。

为什么要自律的原因是，熟练的开发者会把构建器作为他们的第二要务。另一个原因就是构建不算是真正的“代码”。还有些现实情况要面对，大部分开发者喜欢学习新语言，而构建器是用来给开发者生成可执行文件的，以及终端用户用来测试和运行的。没有经过构建的代码毫无用处，构建器被定义为应用程序的组件架构。构建是开发过程中必要的一环，并决定了构建过程中能够制造的代码，以及更简单的编程。

用错误的方法编写的构建脚本难以维护，所以更重要的是，它需要被完善。花点时间去理解正确的方法以做出改变是非常有价值的。Bug会在应用程序采用错误的版本以来构建或错误的构建时间配置时浮现出来。

传统上，测试总是留给“质保”团队的事情。而现在我们意识到，边写代码边测试有很必要的，可传递出预测价值。因此，构建过程需要被开发团队掌握。

理解构建（原理）可以使整个开发生命周期变得简单并降低成本。一个易于执行的构建起也能让一个开发新人快速轻松地上手。构建中的自动配置也可以实现多人协同项目时结果的一致性，从而避免了“它在我电脑上运行正常”的尬聊。很多构建工具都可以让你得到一份代码质量报告，让你更快地感知到潜在问题。所以，花点时间了解一下如果制作个你自己的构建起，帮助你的同时也帮助了团队里的每个人。你也可以专注功能开发，让相关利益者受益，让工作更愉快。

充分学习你的构建过程，明白何时以及如何做出改变。构建脚本是代码。它们太重要了以至于必不可少。在被构建之前，应用都不算开发完成。在我们交付软件工作之前，编程任务就不算结束。

凡是少的，就连他所有的，也要夺过来。凡是多的，还要给他，叫他多多益善——《新约·马太福音》

我是个穷人吗？不知道…

我有一份还算体面的工作，一个还算安稳的家庭。当然，我还是一个负债百万的房奴。生活里没有太多糟心的事，但也不敢去奢望那些人生巅峰。

我倾向于认为自己是一个穷人，理由很简单：我没有富人思维。

正是出于此，我翻开了这本《贫穷的本质，我们为什么摆脱不了贫穷》，本书由2019年诺贝尔经济学将得主所著。当然，书中并没有太多宏大的经济论调，但说不上为什么，总是给我一种非常死板的感受，或许是经济学家都喜欢算帐吧😁。

既然没有富人思维，那至少应该要理解一下什么是穷人思维，客观地认识自己，这就是我阅读本书的目的。不过在读完前半部分后才发现，作者所说的穷人和我没太大关系。

作者研究的对象，是那些每天生活费不足0.99美元的穷苦人家（那是真穷啊），对于这些人的生活境遇，书中给出了一个总结——贫穷陷阱。

什么是贫穷陷阱

当一个人或家庭非常贫困时，他们不得不想尽办法榨干每一分钱用于基本的生活开销，以至于根本不可能留有剩余，作为明天讨生活的本钱。

就好比一个人每天至少吃两个馒头才有力气干活，而他的收入只够每天买一个馒头，导致他越来越没力气，越没力气干活挣的就越少，挣的越少馒头就更少，恶性循环…营养不了的他随之生病了，又没钱看病。

越穷越见鬼！

有多少人处于贫穷陷阱

如前文所说，每天生活费不到0.99美元的人就处在陷阱当中，作为还能上个网看看新闻的我们而言，一天折合人民币6、7块钱的开支确实难以想象——这种人应该是极少数吧？

10亿！是的，全球约有10亿人在贫困线上挣扎着。

当然，生在当下的中国，对这个数字的吃惊是可以理解的，毕竟想要过上一天不足10块钱的日子还是比较难的，因为国家有各种低保和特殊群体照顾。所以这些人普遍集中在一些亚非极度落后地区，或者中东战乱国家。

对于他们的境遇我深表同情，只可惜眼泪无法填饱肚子，让世间不再有饥饿是全人类共同的目标。但，10个亿呀，试问有谁能解决这么多张吃饭的嘴，以及贫穷给他们带来的连锁反应。

穷人为什么穷

本书用10个章节从不同面阐述了贫穷的原因，我大致总结了一下：

• 吃不饱饭，导致发育迟缓，输在起跑线上
• 卫生习惯差，导致非常容易生病，又没有价美物廉的医疗资源
• 没有良好的教育环境，老师不负责，孩子不听话，家长不在乎
• 就业难度极高，只能打临工，工资低，基本处于半失业状态
• 连做小生意的本钱都没有，也无法从银行贷款，只能借高利贷
• 没有存钱意识，或者说压根就没钱可存
• 没有风险意识，一旦来个小的天灾人祸，基本就是毁灭性打击
• 政府政策落后，加之公职人员的贪腐，进一步恶化生存环境

由此可见，穷，是一个非常复杂的命题。俗话说救急不救穷，毕竟穷是由多方面因素共同作用的结果，救10个人可以，救10亿…

那穷人就真的无药可救了？

穷人之所以穷

当然，我们会习惯性的开始骂爹骂娘，把责任都推给执政者的不作为。但我读完本书后觉得，贫穷似乎更多源于人的主观思想——短视！

不过这种短视并非穷人的专属，而是人性使然。我们往往只看得到投资的直接回报，所以很少选择具有间接但高价值回报的投资。

书中在描述穷人境遇时引入了很多案例，比如：

政府为了抵抗疟疾，向民众发放蚊帐，可蚊帐再便宜穷人也不买，如果免费了吧，他们把蚊帐改成丝巾抹布之类的。不得不继续投入资金去宣传教育。

如果某个人突然打工挣了一点钱，够他勉强吃半个月天了，但实际上他会去买更高级的食物烟酒，或者消费娱乐，不出两三天钱就花光了。

穷人喜欢生更多小孩，认为东方不亮西方亮，然而随着家庭人口的增加导致生活水平的骤降，每个小孩分得的资源就会更少，进一步恶化小孩的成长空间。

穷人似乎不太在乎孩子的学业，认为那是学校的事情，而老师又觉得既然家长都不关心，我又瞎操心个毛，喝茶看报吧。

一般情况下，穷人不大可能主动接种疫苗，但他们会想尽办法凑钱治病。他们也不太会给自己的耕地买保险，如果恰好今年丰收，更是会觉得保险费打水漂了。

穷人可以精打细算到榨干每一分钱，但主要用于生活支出，很少考虑把它当作来年做事的本钱。他们也会在被逼无奈时去找民间贷款，高额的利息进一步恶化了他们的生活条件。

真的，穷不可怕，可怕的是穷人心态！

但是，还是要强调，本书研究的对象都是那些落后地区或战争国家，他们生来就比别人落后一大截，他们需要花费比发达国家多出10倍的努力恐怕都无法勉强赶上那里的人民。更何况，很多时候的选择，都是人性使然。

如果我们单纯从第三方的角度去审视穷人，甚至某些国家的论调，都会觉得，环境那么恶劣，自身还不努力，烂泥扶不上墙——没救了！

中国人说：授人以鱼不如授人以渔。

要让10亿人脱离贫穷陷阱，纯粹的发钱或者慈善事业显然是不够的。中国曾经也穷过，但中国人的理念就是勤劳致富、自强不息，所以这个国家很快变强大起来。

脱贫，靠政府推动和政策支持是必不可少的，在改善穷人生活环境的同时，不论政策引导，或是宣传教育，让穷人真正认识到贫穷的本质除了客观条件，还有自身原因也是非常重要的。

（😒为什么我会写出如此…那啥…的一段话）

我是穷人吗？

我是！看完这本书后，这个答案已经非常明确了。

不仅如此，从思维上来说，我和那些穷人也有很多相似的地方。不同的是那些他们的贫穷更多是环境导致的。而导致我的贫穷是…

哎～😂