关于scratchpad修改所想到

今天花了将近一天的时间修改一个低优先级的CR，不是coding太慢，而是自己在两种解决方案中徘徊，开始选择一种方案，但是后来发现这种解决方案，给目前系统带来了很大的不确定性，虽然可以很好的解决问题，但是修改太多，其中很多逻辑都要发生变化，需要将很多测试用例重新测试一遍，可能导致引入更大的风险。直到下午3点才放弃，改用打patch的方法对它进行修改。一个很小的CR，本来是可以比较快的解决，却花了将近一天的时间，其中有很多需要自己注意的地方，总结有一下几点：

1.在产品将要出货的时候，尽量不要做大的修改，所谓大的修改，可以从两个方面来考虑，

   a.代码修改量

   b.修改之后需要重新测试的测试用例

  如果分析这两个方面需要修改很多，就应该放弃方案求其次，出货期间稳定大于一切

2.修改CR步骤：

   a.重现CR

   b.找出CR出现的原因

   c.根据CR出现的原因写对应的测试用例，其它可能出现此CR的情况。这些测试用例应该写入到需求文档中

   d.根据这些测试用例，再找解决方案

   e.最后才是coding解决问题

3.编写code的时候，尽量按照正常的逻辑来做，不要因为中间又很多可以删改的地方就放弃，这样的code虽然很紧凑，但是不好扩展，如果需要进行修改，那将是致命的，很有可能需要动结构。

4.在针对需要将item index作为数据处理参数时，最好能够将item index作为参数传入消息响应，而不应该在winmanage中查找选中的item，这样就容易出现这次CR的情况，按power键关掉所有dialog时而不能提示用户改如何处理。

关于程序开发

《妈的，不能上传图片，真他妈的日》

在需求阶段，应该尽量穷尽测试用例

设计框架根据已有的测试用例来设计框架，如果这个过程中还需要进行修改，应该及时反馈到需求阶段，写下相应的测试用例

Programe阶段，应该设计好模块之间接口，以及主要函数的参数形式，因为编码问题而导致需求变化（有些不是硬性的需求，可完成也可不完成，可以自己来度量）

最后才是具体编码

将来出了问题可以采用这些测试用例来测试code，及时找到错误，所谓的测试驱动开发