从小工到专家读书笔记
- 石头汤与煮青蛙 士兵渐进地欺骗村民，但他们所催生的变化对村民有利。但是，渐进地欺骗青蛙，你是在加害于它。当你设法催生变化时，你能否确定你是在做石头汤还是青蛙汤。
- 批判地思考你思考你读到的和听到的。你需要确保你的资产中的知识是准确的，并且没有受到供应商或媒体炒作的影响。警惕声称他们的信条提供了唯一答案的狂热者，那或许适用，或许不适用于你和你的项目。
- 不要低估商业主义的力量。Web搜索引擎把某个页面列在最前面，并不意味着那就是最佳选择；内容供应商可以付钱让自己排在前面。
- 我相信，被打量比被忽略要好。
- 正交性是从几何学借来的术语。如果两条直线相交成直角，他们就是正交的。用向量术语说，这两条直线互不依赖。沿着某一条直线移动，你投影到另一条直线上的位置不变。
- 我们想要设计自足的组件：独立，具有单一，良好定义的目的。如果组件上相互隔离的，你就知道能够改变其中之一，而不用担心其余组件。
这是痛苦的事：/看着你自己的烦忧，并且知道 /不是别人，而是你自己一人所致
好篱笆促成好邻居——《补墙》
- 发现了他人的 bug 之后，你可以花时间和精力去指责让人厌恶的肇事者。在有些工作环境中，这是文化的一部分，并且可能是疏通剂。但是，在技术竞技场上，你应该专注于修正问题，而不是发出指责。
- 找到问题的原因一种非常简单，却又特别有用的技术是向别人解释它。他应该越过你的肩膀看着屏幕，不断点头（像澡盆里上下晃动的橡皮鸭）。他们一个字也不需要说；你只是一步步解释代码要做什么，常常就能让问题从屏幕上跳出来，宣布自己的存在。
- 关于异常的问题之一是知道何时使用它们。我们相信，异常很少应作为程序的正常流程的一部分使用；异常应保留给意外事件。
- 间谍，反政府人员，革命者以及类似的人常常会组成小组，称为 cell。尽管每个最小组织单位内部的人员可能相互认识，但他们却不认识其他最小组织单位的人。如果某个最小组织单位被发现了，再多的麻醉药也无法使该最小组织单位外部的人姓名泄漏。切断最小组织单位之间的交往能保护每一个人。我们觉得这也适用于编码的好原则。把你的代码组织成最小组织单位，并限制它们之间的交互。如果随后出于折中必须替换某个模块，其他模块仍能够继续工作。
- 毛里求斯岛上的渡渡鸟不能适应人类和他们的家畜出现，很快就灭绝了。不要让你的项目或你的职业生涯走上渡渡鸟的道路。
- 假定副总裁来到你面前，想要你马上做一个应用，让她浏览存放在大型机的遗留数据库中的公司组织机构图。你只要编写一个读取大型机数据的包装程序，把它作为 TreeModel 给出，就成了：你有了一个完全可以浏览的树 widget。现在你可以变点花样，开始使用查看器类；你可以改变节点的绘制方式，使用特殊的图标，字体，或是颜色。当副总裁回来，说新的公司标准要求针对特定的雇员使用骷髅图标，你可以对TreeCellRenderer做出改动，而不用修改其他任何代码。
- 实现的偶然是那些只是因为代码现在的编写方式才得以发生的事情。你最后会依靠没有记入文档的错误或是边界条件。
时间压力常常被用作不进行重构的借口。但这个借口并不成立：现在没能进行重构，沿途修正问题将需要投入多得多的时间——那时将需要考虑更多的依赖关系。我们会有更多的时间可用嘛？根据我们的经验，没有。（说实话，看项目大小了）
其实挺没劲的。可能常看常新吧。后面看的也不是很仔细。
最可怕的是我在豆瓣上标记看过时，发现这本书我14年看过了。真的是一点印象都没有呀。记下来这么多东西也挺好的。真是常读常新呀。只是他娘的也真是讽刺啊。
- 解开谜题的关键在于确定加给你各种约束，并确定你确实拥有的自由度，因为在其中你将找到你的解决方案。
- 早测试，常测试，自动测试。
