第二章从内容上叙述了以下"一般原则"内容：
原则一：质量第一
原则二：质量在每个人眼中不同
"质量"的定义不同，可能是优雅的设计或者代码。也有可能是响应的时间，更有甚者是低开发成本。我觉得这个放在现在是适用的。所以这个原则好像说了什么东西，又好像什么都没说。但是从开发角度上说。我觉得质量其实就是大家写的代码过程质量与线上质量。这就是红线。
原则三：开发效率与质量密不可分
强调开发效率会导致质量的降低。
原则四：
高质量软件是可以实现的
对应白话："都可以做，就是需要时间"。
原则五：不要试图改进质量
不太理解。现在咱们都在重构。如果从可维护性、可靠性、适应性、可测试性、安全性等等方面想提高。那为啥不能算是提高过程质量与线上质量了。
原则六：低可靠性比低效率更糟糕
哪怕你效率高点，但是你的代码可靠度得高点，不然后面一些问题的修复成本都会耗费较多的成本。
原则七：尽早把产品交给客户
"将这个原型交付给客户，收集反馈，然后编写需求规格说明、并进行正规的开发。"。理解上就是给客户先把大饼画好。
原则八：与客户/用户沟通
好建议。把我们自己当作客户。能足够的熟悉这个产品的功能，就能打磨出更好的产品。
原则九：激励开发者与客户对齐
意思就是跟客户谈好交付事项与细节。尽可能的双方都能够妥协一点。
原则十：做好抛弃的准备
就是要做好随时推倒重来的准备。但是我们可以把主要框架设计的更前沿一些。
原则十一：开发正确的原型
说的就是前面给客户的是原型，后面给的才是真正的实现。步骤不能乱。
原则十二：构建合适功能的原型
构建合适的原型，如果前面交付给客户的原型更偏向于"原型图"的话，这里指的是应该是项目框架设计的原型。
原则十三：要快速的开发一次性原型
赞同！在原型设计阶段没法做到太具体的细节实现。所谓的知行合一。我更倾向于先快速的有一次性原型。后面实现过程中再优化补充。
渐进地扩展系统；
看到越多，需要越多；
开发过程中的变化是不可避免的；
只要可能，购买而非开发；
让软件只需简短的用户手册：
每个复杂问题都有一个解决方案；
记录你的假设：学会去试错。
不同的阶段，使用不同的语言；
技术优先于工具；
使用工具，但要务实；
把工具交给优秀的工程师；
CASE工具是昂贵的；
“知道何时”和“知道如何”同样重要；
实现目标就停止；
了解形式化方法；
和组织荣辱与共；
跟风要小心；
不要忽视技术；
使用文档标准；
文档要有术语表；
软件文档都要有索引；
对相同的概念，用相同的名字；
研究再转化，不可行；
要承担责任；
=========================
自己对于重构的一些思考～
.....