第八章：注意力对思考以及行动的限制 模式一：我们专注于目标而很少注意使用的工具 目标才是重点，你写字的时候不会注意手中的笔，也不太会注意写字的纸的颜色。 只有工具会影响你目标时，专注被打断了，才会注意到工具。 一个好的工具，能让你注意被转移之后，回来能继续下去，让你知道之前进行到哪了。 模式二：我们能注意到更多与目标相关的东西 非注意盲视 当我们的思维被任务、目标或是某种情绪完全占据时，有时会无视所处环境中那些平时能注意到并记住的其他物体和事件。 变化盲视 人们常常会忽略关注点之外的变化。 因此需要把界面的变化显性…

第一章：我们的感知存在偏差 经验影响感知 比如默认卧室会看到床，厨房看到厨具 环境影响感知 上下两条线一样长 目标影响感知 只专注于目标而忽略其他。 例如“鸡尾酒会”效应，当你在拥挤的酒会与某人聊天，会过滤周围的对话。当对对话内容感到乏味时，多半就能听到周围的谈话了。 设计时将感知的影响因素考虑在内 避免歧义 确认所有用户对信息的理解是一致的（反例就是环境影响认知中的线条）。当无法消除歧义，要么依靠标准或惯例，要么提供说明。 保持一致 保持惯性。相同功能控件在每一页都保持相同位置、颜色等。 理解目标 用户是带着目标…

第一章 转换思路 向麦肯锡学习逻辑思维 解决问题的根本就是逻辑思考力。 逻辑思考力不是依赖经验，以前怎么做可以成功，现在也怎么做。 逻辑思考是依靠数据观察现象，提出假设，然后再求证。 不要把假设和结论混为一谈。分析数据整理出来的是现象，是假设，而不是结论。要透过现象看到本质的原因。能解决问题的才是结论，否则是现象。 “全方位努力”的想法是错的。大部分的问题都是由少部分原因造成的。 ps：这属于扩散？ 验证假设时不要忘了对比实验的要求：每次只能改变一个因素。比如调查不同年龄段对消费的影响，要限制区域，不能A区域青年和…

焦油坑 过去几十年的大型系统开发就犹如这样一个焦油坑，很多大型和强壮的动物在其中剧烈地挣扎。 它们挣扎得越是猛烈，焦油纠缠得越紧，没有任何猛兽足够强壮或具有足够的技巧，能够挣脱束缚，它们最后都沉到了坑底。 人月神话 缺乏合理的时间进度是造成项目滞后的最主要原因： 对估算技术缺乏有效的研究 隐含地假设人和月可以互换 没有持续进行估算工作 对进度缺少跟踪和监督 进度偏移时，下意识的反应是增加人力。 乐观主义 系统编程的进度安排背后的第一个假设是：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。 但是进度正常的…

第二章 潜意识 任何痛苦事件都不会自动消失，哪怕再小的事情也是如此。要想不受其困扰，唯一的办法就是正视它、看清它、拆解它、化解它，不给它进入潜意识的机会，不给它变模糊的机会；即使已经进入潜意识，也要想办法将它挖出来。所以，当你感到心里有说不清、道不明的难受的感觉时，赶紧坐下来，向自己提问 。 到底是什么让自己烦躁不安？是上台演讲、会见某人，还是思绪纷乱？ 具体是什么让自己恐惧担忧？是能力不足、准备不够，还是害怕某事发生？ 面对困境，我能做什么？不能做什么？如果做不到或搞砸了，最坏的结果是什么？ 禁止心猿意马，做一件…

个人读书笔记，有些地方用词不够严谨（欢迎评论指正），见谅。书籍链接 笔记是个人理解，与书籍可能有偏差，建议看书。 问题： 什么样的数据适合图数据库？ 社交关系？网页数据？地图数据？ mysql有没有事务重试？ 更新数据时，是按行更新还是按页更新？ 更新数据时，是采用copy on write还是直接修改? 第一部分 数据系统的基石 第一章：可靠性、可扩展性、可维护性 可靠性 硬件故障：机房断电、硬盘崩溃等 软件错误：数据库异常、缓存异常等 认为错误：业务bug、运维失误等 允许部分服务可不用（不影响整体系统），最后…

以下是本人在阅读《Effective Java》期间记录的笔记，未经整理。有兴趣的可以看看，有问题可以探讨。 第二章 创建和销毁对象 1. 考虑使用静态工厂方法代替构造方法 优点： 静态方法可以命名（见名知意） 单例模式（减少创建对象的开销） 可以返回当前类的子类而不是当前类 根据参数不同返回不同实现类 类不需要存在，可以反射生成（比如数据库的DriverManager） 缺点： 没有公共或受保护构造方法的类不能被子类化？？？ 程序员很难找到它们 2. 当构造方法参数过多时使用 builder 模式 比如4个或者以…