源代码管理和脚本化构建

• SCM的基本操作指令(check out\checking in\add\modifiy\remove)
• 疑问：web服务很大程度上基于数据库，然而数据库随着需求的改变会作出变化，这时候版本库里的老版本存储是否还有意义?
• 要等到功能特征已经过确认可用后，才迁入代码。代码和测试的质量会直接影响到团队的生产力。
• 遵循“不破坏构建”的惯用法，必须把实现分解为诸多小修改，在每个小修该完成后，就进行迁入。
• 这里的脚本化构建我理解是类似于开源软件源代码包中的configure, 主要是编译，由此我也想到python的setuptools是否没有好好的使用，现在的应用中，确实有一部分同数据库联系很紧密，但是有些是可以作为库的形式切出来的，如果把这些部分切出来，然后作为独立的子项目迁入版本库，并使用工具作自动化的构建（至少可以满足unix系统和非unix系统的快速构建），就能使得开发过程变得更加迅速（更多的人可以加入进来作开发）。
• 构建脚本需要在一个干净的机器里定期作测试。

自动化测试

• 单元测试、集成测试、验收测试、可执行的规约测试、性能测试、负载测试、故事测试、测试驱动开发、测试先行的开发、行为驱动的开发。
• 自动化测试可以作为如何实际使用代码API的活生生的文档。
• 当针对API编写测试时，设计上的任何不足会特别明显的暴露出来，因为这时候你已经变成这个API的用户了；并且修改起来会很快。
• testable（代码的可测试性）的表象特征属性（低耦合、最小化依赖、封装）。
• 单元测试

import random
import unittest

class TestSequenceFunctions(unittest.TestCase):
    def setUp(self):
        self.seq = range(10)

    def test_shuffle(self):
        random.shuffle(self.seq)
        self.seq.sort()
        self.assertEqual(self.seq, range(10))

if __name__ == "__main__":
    unittest.main()

• Mock和Stub： Stub实际上是为了xx循环依赖而采用的一种方式，我的理解是如果采用测试驱动开发，Stub就相当于只有简单返回值而不做任何事情的函数或者方法。Mock可以假装成是一个子系统的实例，内部有一些特定的逻辑，实质是Stub的集合。
• 集成测试的实例?
• DAL的好处是很容易根据DAL层作Mock，这样上层调用的时候就可以寻找数据库的替代了，我好奇自己现在应用中作的DAL层是否是标准的。
• 对于遗留代码，作者提出“遗留代码可以被稳步替代和逐步改进，使之随着时间的推移变得更好，而不是让它慢慢腐烂掉，所谓‘更好’， 是指可以更容易、xxx和呃嗯小成本去改变它”。

持续集成

• CI让我想到了SVN的自动化脚本?
• 端到端的构建包括(单元测试和集成测试、数据库初始化、性能和负载测试…)(SVN+Trac+bitten)