情景:
我在一个多人的团队里, 开发基于windows的客户端程序. 这个程序的GUI是一个主要的开发点, 因为*产品狗*觉得每个release更改一下, 可以吸引/维持用户流量.
整个项目
所以, 现阶段, 这些feature主要是更改GUI, 无非有:
(1) 添加新的图片
(2) 改变/增加 控件响应的逻辑.
(3)
正文:
1. 何时添加新的代码?
(1) 首先,“线上”产品的是否具有相似的功能?(适用于功能比较小的情况)
有, 通过调试, 检查实现过程, 能”复用”就复用.
没有, 再考虑自己造(概率很小).
“空闲”时, 你该做些什么:
这里 “空闲” 是release发包前, 下个release开始做之前的 “空当”.
1. “关于bug” 的 现实3.
关于bug
2. 早发现bug, 早测试.
现实:
1.线上版本也存在bug
2. 在QA测试, 和develop过程中, 存在”真空”期, 会引入一些bug.尤其是,develop 新的 commits 处于 “无人测试”阶段.
3. 关注自己的feature plan, 看看哪些要做的, 给代码写UT, 向QA提bug.
教训: ( 按照流程 )
a. 开发新feature之前, 重点(也就是主要) 设计 test case 自己开发的功能相关区域,
develop 和 线上 最新版有什么区别.
原因: develop也是按照产品需求来做(整个过程中).
线上版本对应的develop已经有了多个提交.
因为项目没有UT, 所以无法保证着多个提交 不会引入新的bug. ( 客观”长期”存在, 短期内无法改变 )
潜在的bug, 会成为feature开发过程中, 新的bug.
这时候, 就会需要”回退”. 造成时间上的浪费. 在压力大的情况下, 会引起人的崩溃.
关键: 这本来应该是QA做的事情.
关于重构:
1. 重构branch 单独于新feature进行.
关于单元测试
关于debugging
编码过程中, 应该:
一个函数出口: 方便调试(不必在每个出口都添加 log/trace breakpoint).
动态源码分析:
设置 class point.
Trace Breakpoint 应该输出些什么?
经历了动态源码分析的阶段(其实和debug是参差进行的), 应该有了很多的 breakpoints.于是, 有了下面的内容:
针对一个完整的”事件流”,如果调试时, 这个事件流会”重复”很多次的话:
分隔符: 标志着一个事件”开始”和”结束”, 可以使用 “================= 事件开始 =================”来标识, 甚至可以添加一些 Date, 第n次 这样的信息.
函数进入/退出时的信息: 函数调用关系是”动态分析”的重要信息. Trace 时, 虽然可以直接”打印出堆栈”,但是, 大部分时候是不需要的, 这回占据整个output window, 让”事件流”变得很不清晰. 而通过在 enter/leave 时, 打印一些调试信息, 是可以”还原”一部分堆栈的(之所以一部分, 是因为有些trivial的调用可能不会输出 enter/leave信息).
底层的不要打印 CALLSTACK 反正我的8G台式机上直接挂掉了.
caller 和 callstack 都不会显示参数列表 而参数列表是在C++中寻找被overload的函数的唯一方法.
解决之道:
最好 : 函数命名(不同抽象层的方法: 接口, helper func 通过 命名区分开).
可以 : 模糊匹配每个candidate设置 trace point, 然后打印 行号.