看到塑造犯错环境这节，想起了桥水基金创始人达利欧对待犯错的态度。

他允许员工犯错，强调每个人应反思错误，不容许一错再错。并在公司内部建立了一个“错误日志”，用来记录每人犯过的错误和造成的不良后果，这样可以追根溯源，系统化的解决问题。

我们技术人也可以建立自己或团队的“错误日志”，在错误中成长。

总是粗心大意导致出现bug，甚至一些低级的条件语句发生错误。
自我总结：
1. 做好单元测试。
2.做好代码走查，在写完代码后，在今进行从新构思审查。
3.对于代码改动影响的所有代码进行测试。
4.提交测试，同时提交改动范围，改动代码所影响的所有功能。

程序之术这部分 笔记 (期待支持markdown)

# 总览
主要是讲解程序员技能的锤炼。
主线：设计、开发、bug处理 (按正常的功能开发流程介绍的)
* 设计
    * 认知设计。架构与实现，他们的连接与分界；框架和模式的区别
    * 如何来设计。从哪些维度来思考(多维度视图)
* 编码
    * 工业级编码包含哪些内容 (功能、控制、运维)
    * 编码的两种方式：粗放和精益
    * 编码的态度：炫技和克制
    * 编码的三阶段：调试、编码、运行
* bug处理
    * bug按特性进行的分类以及各分类介绍。空间特性和时间特性
    * bug出现的原因分析，以及降低bug的方法



# 05 架构与实现：它们的连接与分界
架构：做的是顶层设计，技术、框架选型，边界划分。熵尽量小。设计和实现做取舍
实现：交付代码，尽量简。围绕架构做的程序时间。
连接：
架构师：关注系统边界、关键点、战略性细节点

# 07 多维与视图：系统设计的思考维度与展现视图
理解或表现系统的视角。
组成视图：描述组成系统的子系统、服务、组件。便于总体了解系统服务组成，以及其职能。服务切分原则：高内聚，职能单一；正交化，同一个功能只有一个服 务提供
交互视图：系统组成部分中各部分的依赖、被依赖关系。整体的流转。
部署视图：系统如何来部署的。关于服务、中间件、使用者之间的网络传输，确认IO瓶颈，从高维度看系统设计的合理性
流程视图：功能逻辑流
状态视图：状态的变化流
我的理解：组成、交互、部署视图，适合描述顶层设计。流程、状态视图，适合描述具体的功能

# 08 代码与分类：工业级编程代码的分类与特征
总结：
对于最终需要交付运行的程序代码，
从代码的用途(or使用场景)上将作者代码分为三种：功能代码、控制代码、运维代码。
功能代码，满足于用户需求，为实现特定的业务功能而开发。
控制代码，对代码执行流的控制，如并行、异步、限流、熔断、超时控制等。RPC、中间件、代理服务器等，应该是对代码执行流的控制。控制代码的需求，是从众多(已有的或预见的)功能开发中提炼而来，基于一些共性的特征抽取。源于功能而高于功能。
运维代码，用于解决运行过程中出现的问题，或者为解决问题提供必要的信息。

结合工作，我们做的防重组件，是控制代码。基于pinpoint实现链路跟踪，是对业界已有的运维代码成果的使用

# 09 精益与粗放，编程的两种思路与方式
介绍编程的两种思路，完美型和现实型。
看这篇文章，脑海中想到了两件事情，一是卖油翁的故事；二是态度(吴军老师写的)一书中提到的一些观点：最好是更好的敌人(或者说进步一点比什么都不做好)、做事情时境界要高。
陶器制作第一组的同学，可以说是熟能生巧；陶器制作第二组的同学以及课程设计的同学，境界是比较高的，但在其事情落地上执行方式有点问题，因为没有找到完美的方案而踌躇不前，最终没有输出满意的成果。
套用到我们自身的工作，以及绝大多数程序员身上，大量的开发(+用心理解)可以提升我们的水平，我们要求输出的成果有deadline，设计时我们格局可以大一些，考虑后来的扩展，实现时可以分步来执行，多次的改进让我们朝着目标前进，甚至超过原有心中的完美方案。

# 10 炫技与克制：代码的两种味道与态度
炫技：能简单处理的采用了复杂的方式
克制：不随性。第一层意思是采用了简单的方案处理合适的问题；第二层意思是看到不好的代码、设计，克制立刻修改的冲动，了解整个逻辑后，在合适的时机进行重构。

# 11 三阶段进化：调试，编写与运行代码
介绍的是两种写代码的方式：一是走一步算一步，边写边调；二是先整理清楚整个思路，然后再动手。


# 12、13、14 bug分析
技术性bug，根据特征分为两类：
空间：环境过敏
时间：周期规律
环境过敏，像人到一个新环境过敏一样，程序运行在不同的环境，因为环境的差异而导致程序运行遇到问题。如磁盘故障，网络带宽低等，原本(在次品正常、网络带宽高机器上)运行正常的程序，运行出现了问题。

bug出现的原因分类：
粗心大意
认知偏差，和理解需求出现了偏差
熵增问题 (系统复杂度变高)

降低bug出现次数的方法：
粗心大意，可以通过流程和工具减少；
认知偏差，可以通过团队和技术手段来纠偏
熵增问题，重构，如使用业界更好的模式、框架等来降低复杂度
塑造环境。塑造一个正视错误、改正错误的环境。