易于测试的代码:
1、软件 IC 是人们在讨论可复用性和基于组件的开发时喜欢使用的比喻。意思是集成电路芯片可以很容易的进行组合，我们希望软件开发也能达到这个效果。芯片的设计有完善的测试，同样的软件开发也可以做同样的事情。
2、针对合约进行测试及为测试而设计，即 TDD 测试驱动开发。
3、编写单元测试，对比较大的项目，将每个测试都放进一个子目录。
4、使用测试装备。构建一套完善的测试体系，它能够记录测试状态，分析输出结果是否符合预期，以及选择和运行测试。
5、推进测试文化，尽可能完善地测试你的软件，否则你的用户就得替你测试。
邪恶的向导:
1、这里的向导指的是那些用于帮助我们构建程序自动生成的代码，通常他们还被称为脚手架。为什么称向导（wizard）是邪恶的呢，这是因为通过工具生成的代码，很容易被我们忽略，在这种情况下你编写的过程更倾向于靠巧合编程。
2、这里不是抵制向导代码，而是在强调，不要使用你不理解的向导代码。如果使用，一定要清楚它的机制。
3、开发每天都在使用不完全理解的事物，比如集成电路的工作原理，处理器的中断结构、用于调度的算法、各种系统库的工作机制等。需要注意的是，这些属于底层依赖，他们也是向导，但不是应用本身的一部分，我们可以对这部分有所了解，但他们不属于邪恶的向导。
面对这个我就恰好有这种经历，面对开发时，网上那些所谓的框架就极大减少了我们项目的代码量，我其实不是很懂原理，只是在使用，知道简化后的代码如何使用能和之前的代码最终起到同样的作用。我感觉就是在不断地简化开发中，最终是否应该采取这样的方法进行开发我也不知道。
需求之坑：
1、完美，不是在没有什么需要增加，而是在没有什么需要去掉时达到的。这句话的一种解读时，不要搜集需求，需求太多，容易让我们抓不住重点，更应该深挖需求，围绕核心功能不断打磨。
2、挖掘需求，需要我们与用户一同工作，像用户一样思考。
3、制定需求文档。看待用例的一种方式是强调其目标驱动的本质，它强调的是要重视需要做成什么以及需要什么条件。需求文档最好配一些UML用例图。
4、需求的制定不能太具体，要保持一定的抽象。需求不是架构，不是设计，需求只是需要。这个有点类似于开发中的面向接口而不是面向具体实现编程。
5、维护词汇表。“客户”和“顾客”，可能表达不同的含义，但如果混用会让人迷惑，我们可以维护一个词汇表，专门用户描述他们的具体含义。
6、把需求文档发布到内网，参与人员都可以随时查看和提出意见。
我们进行了团队项目的开发，最重要的不是最后成品的结果。这有点出乎我们的意料之中，我们以为的项目成功就是最终完成要求。其实我们最应该完成的是客户的需求，我们在做项目的时候也是换位思考，做之前先把自己当作顾客，我究竟需要的是什么，然后我们再去进行开发，开发完成后，再以顾客的身份来判断是否是满足需要，如果需要改进，那么应该如何进行改进。