到了这个时候, 真想破口大骂了. 为什么开发模式是如此的粗放?  每个版本之间的特性传承体现在哪里?  上一个版本所犯的错误为什么在这个版本又要栽跟头撞得头破血流?

为什么一拨又一拨的兄弟那么辛苦?

        根据目前的开发状态, 本人有几个疑惑:

        1) 特性的技术承传是怎么体现的?  比如IC特性. 在R14包括R15版本, IC特性所涉及的方案性的问题不断被发现不断被纠正, 那么这些被发现和纠正的东西在下一个版本是如何体现的? 比如老版本有一个方案问题, F板所在的资源组集中对消单板只能存在一块, 此资源组不能存在既有板间IC又有板内IC的场景, 否则会存在SLC小区. 但是, 这个问题在R15.1依然在重复上演. 还有多少个老版本的方案性的问题, 在新的版本开发上没有对齐?  IC涉及的通道/时延的东西很多, 本身十分复杂, 在小区模型变动如此之大的情况, 不采取相关措施, 质量堪忧.

          2) 如何实施真正意义上的One Track方案? 如果把One Track仅仅理解为一个主干而非以前的狂拉分支, 那么也认识的太肤浅了. 如果One Track是一条渠道的话, 那么它应该是干净清澈地流淌着溪水, 需要时按需所取就行.  如果这条渠道流的都是浑浊的,臭气熏天的脏水, 即使这条渠道修得再漂亮, 也只会让人掩鼻而过. 此时的One Track也不过是一个漂亮的口号罢了.

         3)  DT(Bug Testing)是如何实施的? 在BBIT的第一周, 基本上处于版本不可用的状态. 为什么? 因为出现各种小区建不起来的现象.导致测试无法往后执行.这就涉及到一个问题, DT该如何跟进? 我了解的情况是, SIG和UL的代码在开发后从来没有上过单板跑过. 个人的建议是,  是否可以像冒烟测试一样, 测试人员参与之前, 自己的最基本用例要确保是能够通过的?  哪怕是一个用例, 第一个用例其实要测成功, 是非常不容易的, 包括小区建立不起来/电话无法打通/串口有满屏满屏的Assert打印, 都是能够扫除一些很低级的bug的.