由Bug延伸的一点有关“兼容与重构”思考

今天在解决 Bug00174317 时有一点思考， BUG是个小问题，就是在2.5.2的时候新增了需求，在码率为64K纯音频会议时，会议信息框中的清晰度显示为：“纯音频（64K）”，而不是“标清（64K）”，跟踪检查了一下原因，原因是平台传过来的结构体中有关清晰度的描述只有

 

u8        byConfMode;//会议模式：0-高清、1-标清、2-流畅、3-自定义

 

四种类型，没有音频类型，其实这个BUG在上层根据会议码率来判断，也能够解决，但是还是跟终端与平台沟通了一下，看能不能添加一个4-音频标识。

在沟通后，因为以前旧终端版本的显示兼容问题，就决定不加此标识，由TrueLink局部修改。

这让我有点踌躇，在开发过程中，我们要如何解决这个“兼容与重构”命题，这个名字起得有点大，不过我想大的问题，也是由这样一个个小问题抛出，更大一点还可以说是“稳定与发展”的关系。

 

在系统设计的初期，依据架构师的经验，来尽可能得设计简单，高效，可扩展的模型，但是也不太可能面面俱到，何况面对后续纷繁更新的需求，更难以企及。而我们在遵循前人设计的基础上，总时不经意之前遇到这样的细小问题，这种小问题应该如何处理。在处理这些问题时应该秉承一种什么态度。

一般的看法是，这种小问题，在终端层修改即可，这样代价最小，兼容性高，也确实如此。

而就这个问题上，我的看法是增加一个类型，这样的好处显尔易见。往近了看，能够良好地搞定此Bug，稍远点看，这样终端在判断清晰度时，就会码率与清晰度的耦合降低，而是一种单独的清晰度类型来决定，更况且我们已经有了这样的字段。比如说高清，如果按照码率来判断，可能今年768以上的算是高清，H265出来后，可能明年业内普遍认通的是1080，甚至2160以上才是高清，那如果按照之前的逻辑，直到老的架构被推翻，新的架构推出来的那天前，这个永远都无法更改。

 

     如果在解决问题的同时能让结构朝着合理的方向改变，一定是种欣然的感觉。在历炼的道路上，总要做出一点取舍，如果觉得方向是向前的，Why not?