[写在之前]纸上得来终觉浅，绝知此事要躬行
本书罗列了很多tips，与其草草读之而束之高阁，却不如动手实践，一周或者一月实践个2、3条，几番下来，想来所获匪浅。
注重实效的哲学
提供选择，而非借口
如果坏事情发生，提供解决方法，而不是找蹩脚的借口。如果要辩解，请先在头脑中预演一遍，然后对着你的猫说。
不要容忍破窗户
及时修复“破窗户”-低劣的设计、错误决策或是糟糕的代码。
记住大图景并做变化的催化剂
时时留心周围的变化，并在需要的时候先拿出“石头”（石头汤）来吸引更多的资源加入。
使质量成为需求问题
快速迭代，先交付“毛边”软件，让用户参与反馈，继而迭代更新。
注重实效的途径
DRY-不要重复你自己
同一个事物只出现在一处，而不是出现在多处从而难以修改。
让复用变的容易
正交性-消除无关事物之间的影响
正交性可以提高生产率（局部改动，提高复用性与自由组合）与降低风险（容易测试，错误只影响一小部分）。
用若干技术维持正交性：让你的代码保持解耦；避免使用全局数据；避免编写相似的代码。
可撤销性-不存在最终决策
设计灵活的架构，易于更改；
不要以某种假定编程，要做好接口，抽象。
曳光弹-用曳光弹找到目标
曳光弹代码是产品代码的一部分，先端到端完成基本功能，再慢慢进行功能扩充。
曳光弹方法优点：
1.用户能够及早看到能工作的东西；开发者构建了一个他们能在其中工作的结构；你有了一个集成平台，你将每天进行集成，而不是尝试大爆炸式的集成；你有了可用于演示的东西；你将更能感觉到工作进展。
原型-为了学习而制作原型
原型代码用户即弃，而曳光弹代码虽然简约，但却是完整的，并且构成了最终系统的骨架的一部分。
估算-通过代码对进度表进行迭代
估算能力可以练习。
靠近问题领域编程
实现小型语言
基本工具
我们要乐于超越IDE所施加的各种限制，而唯一的途径是保持基本工具集的“锋利”与就绪。
用纯本文保存知识
利用shell的力量（e.g.powershell）
用好一种编辑器(e.g.VScode)
总是使用源码控制
调试
修正问题，而不是发出责难；
不要恐慌；
对着小*鸭讲代码思路；
不要假定，要证明。
文本操纵-学习一种文本操作语言(e.g.python,powershell)
编写能编写代码的代码-主动代码生成器，被动代码生成器
注重实效的偏执
没有完美的软件。我们平时要进行防御性地编程。不仅要对别人的输入进行检查，也要对自己有怀疑精神。
通过合约进行设计-语义不变项
早崩溃
断言式编程-如果它不会发生，用断言确保它不会发生
异常不应包含正常处理程序
配平资源-资源申请、释放要匹配
弯曲，或折断
保持代码灵活。编写代码时要模块化，并降低模块间的耦合度。
元程序设计
将抽象放进代码，细节放进元数据
要配置，不要集成
分析工作流，以改善并发性
用服务进行设计
创建的不是组件，而不是服务-位于定义良好的、一致的接口之后的独立、并发的对象。
用黑板协调工作流
当你编码时
编码时要有批判精神，随时准备“重构”以及“测试”。
不要靠巧合编程
不做历史的奴隶-重构阻碍的代码-早重构，常重构
估算你的算法的阶测试你的估算
不要使用你不理解的向导代码
为测试而设计-测试你的软件，否则用户就得测试
在项目开始之前
如果你发现处理的问题很棘手，可能走错了路，不妨问以下几个问题：
有更容易的方法吗？
你是在设法解决真正的问题，还是被外围的技术问题转移了注意力？
这件事情为什么是一个问题？
是什么使它如此难以解决？
它真的必须完成吗？
它必须以这种方式完成吗？
与用户一起工作，以像用户一样思考
找出用户为何要做特定事情的原因、而不是他们目前做这件事的方式
抽象比细节活得更长久
好的需求文档会保持抽象。需求不是架构，不是设计，也不是用户界面。需求是需求。
使用项目词汇表
倾听反复出现的疑虑-等你准备好再开始
若分不清是良好的判断还是拖延，那从对觉得困难的地方构建原型开始。
昂贵的工具不一定能制作出更好的设计
不要做形式方法的奴隶对有些事情“做”胜于“描述”
最后，书中提到了管理程序员的知识资产与金融资产非常相似：
定期投资-定期为知识资产投资，作为习惯
多元化以及管理风险-掌握多门技术以及单门技术的各种特性
低买高卖-在新兴的技术流行之前学习它
应周期性地重新评估和平衡资产-技术更新
未煮熟的白菜