这些东西都是我看博客看到的，整理一下，以便以后来看。
没有牺牲，就没有胜利！
不是需求变更驱动着软件的不断更改，而是“软件可以随意更改”的这种特性刺激了不断的需求变更。“拥抱变化”绝不是一句口号，这是一种胸怀。
是迫不得已，才用设计模式来解决一些特定的问题，而不是说正常的代码就应该这样写！最容易理解的就是“适配器模式”，因为出现了接口的冲突，所以我们不得不进行适配。但一个很自然的问题就是：为什么不直接改接口让他们自然融洽呢？这不是一种更自然更直观的解决方案吗？设计模式之类的东西是润滑剂是黏合剂，他们的作用是弥补架构的局部缺陷，更好的支撑架构。设计模式是药，没病就不要吃药！
架构的一个天然目的就是：让代码更智能让程序员更傻瓜。换一张说法就是，架构要“创造便利，让程序员更关注业务”。一个良好的架构，就应该是让每一个普通开发人员，都是一个个尽量廉价随时可以替换的螺丝钉，这样才能保证系统永远健康正常的运行下去。（见架构之路（一）：目标）
在绝大多数情况下，当性能和可维护性相冲突的时候，性能让位于可维护性。我们采用其他办法来弥补代码性能不够高的问题。过早的优化是万恶之源。开发过程中，很多的“优化”，其实只是你的想当然。与其这样想当然的优化，不如在拿到性能测试结果之后再有的放矢的进行优化。
可读性更强的代码总是更好优化。（见架构之路（二）：性能）
你的工作并不只是把代码写出来而已！还有单元测试。但是，从某种程度上讲，写单元测试比写开发代码还难。写好单元测试可以把你的代码里面潜在的问题在项目发布前一个个都解决。
需求文档可测试化。可以理解为：把需求文档像测试文档一样写。如：这份需求/测试文档，交发包方审核确认；之后验收，就严格按该文档逐项进行，所有测试通过，验收合格。如果需要加需求，一般都得加测试；加测试，那不用说，我们就来谈谈时间费用的问题。
面向对象或者领域驱动，最重要的一点就是要忘记数据库！