开发时, 我都在想些什么

情景:

我在一个多人的团队里, 开发基于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, 然后打印 行号

原文地址:https://www.cnblogs.com/permanence-practice/p/3945252.html