有个梨UGlee
2019-12-02 00:00:00 发布
tdd最合适那些在依赖树的叶子上的机制模块，使用成熟设计，对接口稳定性和可拓展性都有足够的信心。前面花一点时间把这类周边清扫一下都测好，然后开始写那些有态的逻辑，quick and dirty，以最快速度实现外部接口，每种使用方式都跑一个例子，以此检查核心有态模块的状态、依赖性、数据流、构造、观察、销毁等等是否都fit，如果发现不fit查找设计原因。
如果前面的周边很多bug，这个quick and dirty根本quick不起来，会很伤神的调试底层错误；如果这个quick and dirty没有覆盖到足够多的使用场景和三百六十度的全方位检查，就可能出现吭哧吭哧的写了一大堆代码和测试最终发现有些用例下设计不合理只能推到重来，代价惨烈。
在写这种中等规模的集成模块时，写大量的在使用者角度的“假”代码很重要。假代码的意思是不去管实现和内部，站在使用者角度看，希望怎么样使用这个模块，如何构造，如何观察，如何销毁。
因为设计首选是关于接口的，其次是关于关系的，完全bottom up一层一层写上去很容易写出最终极其难用，关系复杂到谁也搞不明白，构造需要高超技巧，拆毁是闭上眼睛祈祷的集成模块。
所以好的开发方式是从两头squeeze出来的，bottom up写一点，top down写一点，最终双向的挤压会让你理解如何解耦关系，如何保证构造简单拆除方便，如何让依赖性和数据流向清晰明了。一般的问题里都会遇到一两个关键设计最终让结构相对简单容易实现容易使用容易测试。如果发现做不到。那不要急着写代码了，先把问题想清楚，如何解耦和分拆责任。
2019-12-02 00:00:00 发布
tdd最合适那些在依赖树的叶子上的机制模块，使用成熟设计，对接口稳定性和可拓展性都有足够的信心。前面花一点时间把这类周边清扫一下都测好，然后开始写那些有态的逻辑，quick and dirty，以最快速度实现外部接口，每种使用方式都跑一个例子，以此检查核心有态模块的状态、依赖性、数据流、构造、观察、销毁等等是否都fit，如果发现不fit查找设计原因。
如果前面的周边很多bug，这个quick and dirty根本quick不起来，会很伤神的调试底层错误；如果这个quick and dirty没有覆盖到足够多的使用场景和三百六十度的全方位检查，就可能出现吭哧吭哧的写了一大堆代码和测试最终发现有些用例下设计不合理只能推到重来，代价惨烈。
在写这种中等规模的集成模块时，写大量的在使用者角度的“假”代码很重要。假代码的意思是不去管实现和内部，站在使用者角度看，希望怎么样使用这个模块，如何构造，如何观察，如何销毁。
因为设计首选是关于接口的，其次是关于关系的，完全bottom up一层一层写上去很容易写出最终极其难用，关系复杂到谁也搞不明白，构造需要高超技巧，拆毁是闭上眼睛祈祷的集成模块。
所以好的开发方式是从两头squeeze出来的，bottom up写一点，top down写一点，最终双向的挤压会让你理解如何解耦关系，如何保证构造简单拆除方便，如何让依赖性和数据流向清晰明了。一般的问题里都会遇到一两个关键设计最终让结构相对简单容易实现容易使用容易测试。如果发现做不到。那不要急着写代码了，先把问题想清楚，如何解耦和分拆责任。