首先，最重要最需要强调的是，排版是一个信息量极大的工程。字体，格式，对齐方式，页眉页脚，都只是排版的冰山一角，可以说，一个人是没有办法完全控制一个印刷文件里面的所有排版细节的，就好像人们可以挑选衣服的颜色，款式，但是人们却对“编织手法，扣子是材质”之类的问题疏于关注，这是因为这些细节没办法全部被考量，人类的大脑接受不了这么多的信息。
由此就衍生出了排版里面我最看重的一个概念，就是“缺省”。正是由于人们没有办法关注到每一个细节，所以对于用户没有办法关注到的细节，软件开发者就必须提供“默认设置”，也就是“缺省”。当然理想的缺省是没有任何问题的，人们可以随意修改自己关心的缺省设置为自己的设置，而对于自己不关心的设置就采用“默认设置”。
但是事实似乎并不是这样的，修改缺省设置并不是简简单单的，我曾经为了在word中将目录调成人能看的样子，查阅各种资料查了一个小时，最后手敲的目录。由此就引出了一个基本的问题：似乎缺省设置侵犯了用户排版的权利。而我评价一款排版编辑工具的好坏，最重要的就是看它在我看重的的设置中修改的难度。
当我们讨论芯片的性能的时候，我们到底在讨论什么？我觉得我们讨论的是理想的优秀。所谓的“高性能”，就跟“成功”一样，是一个绝对正确的概念，有人会说“有钱”好，有人会说“有钱”不好，有人会说“有媳妇”好，有人会说“有媳妇”不好，成功有很多的标准，但是作为最终目标的“成功”，是绝对褒义的，没有人会说“成功”是不好的。
“高性能”这个概念跟“成功”一样，没人会拒绝“高性能”。但是跟“成功”一样，每个人对“高性能”的定义是不一样。为了方便之后的整章对性能的理解，我们这里引入一个贯穿全篇的类比 — 一个饭店。一个饭店好不好，站在消费者的角度，出菜快就是好的，但是在掌柜的角度，出菜快只是一个方面，如果一个饭店只有一张桌子，一个厨子，哪怕这个厨子是厨神，做菜又快又好吃，饭店盈利状况也可能不好，毕竟厨子也是凡人，做菜再快一快不到哪里去，换句话说，这个饭店的客流量的上限是很小的，那么对于掌柜的来说，这个饭店就是不好的。
啰嗦了这么多，只是想说，对于“性能”评价，是一个很困难而且复杂的事情，是一个需要从多方面分析的事情。我们去做体系优化的时候，或许只能优化一个方面，或许优化这个方面会导致另一个方面的下降，就好比厨子应付一些，出菜速度会提高，但是菜品就不一定好吃了，所以根据需求的不同，优化的思路和方向就会不同。承认“性能”的不可度量性，就跟承认“成功”的不可度量性一样，是我认为比较成熟的标志。
这已经是我第三遍学Git相关操作了，可以说这个玩意是真的狗，因为确实用不到，不知道下个学期会不会用到，直到现在我刚刚学完，处于知识水平的巅峰，知道Git的具体功能，我也觉得真没啥必要学。我一开始学Git，是因为以为这个跟Github有啥关系似的，其实对于个人来说，使用Github完全没有必要学习Git。
这就引出了Git最重要的一个认识了，就是Git的基本上所有的功能都是为了团队协作开发的，而不是所谓的版本控制（当然也可能是，反正我理解的不是）。Github上面那些看似唬人的branch，tag，respository，ssh key，token之类的概念，其实都是为了团队协作设计的，而不是为了版本控制，或者其他啥目的，简而言之，就是与我现在的需求无关。
对于Git的学习，大致分为两个部分，即版本控制和团队协作。之后会详细介绍。