• Home
  • Categories
  • WIKI
  • LANGUAGE: en
    • 为什么有些影响使用又好修复的问题不立刻发布更新呢？
    Experiences and Insight 2918 views · 77 replies ·
    Tofloor
    poster avatar
    走钢丝
    deepin
    2019-07-12 17:32
    Author
    为什么有些影响使用又好修复的问题不立刻发布更新呢？非要等到下一次大更新？其实快速更新的内容，也可以列在下一次大更新的列表内啊，用于那些未更新的用户。或者也搞一个更新体系吧，对更新需求分级，有需要紧急更新的，有需要实时更新的，有半年更新一次的，可以设置不同的策略。




    Reply Favorite View the author
    All Replies
    1 / 4
    To page
    avatar
    君子爱财取之以道
    deepin
    2019-07-12 17:54
    #1
    身为程序猿的我，非常理解深度没有及时更新的做法，更新一次简直要脱一层皮，那种心惊胆战只有经历过的人才知道
    Reply View the author
    avatar
    aida
    deepin
    2019-07-12 18:00
    #2
    是的 楼上说的非常有道理
    Reply View the author
    avatar
    走钢丝
    deepin
    2019-07-12 18:09
    #3
    https://bbs.deepin.org/post/180559
    是的 楼上说的非常有道理

    这么说还是因为人手不够，各个环节责任不清晰，耦合重，导致程序员背上各种痛苦，所以不愿轻易发布喽？
    Reply View the author
    Comments
    aida
    2019-07-12 19:22
    不是这样的
    avatar
    走钢丝
    deepin
    2019-07-12 18:12
    #4
    本帖最后由 lidanger 于 2019-7-12 10:26 编辑

    国内人也是，一般都是责任心太重，不太会与别人争吵，不太会甩锅，这也是个问题。系统的完善应该由制度和流程控制来保证，不应由某些人背锅，不会抓漏子甩锅、耍赖对个人长期生活和发展很没好处。
    Reply View the author
    avatar
    duanyao
    deepin
    2019-07-12 18:47
    #5
    https://bbs.deepin.org/post/180559
    这么说还是因为人手不够，各个环节责任不清晰，耦合重，导致程序员背上各种痛苦，所以不愿轻易发布喽？ ...

    不是的，大公司的产品可能发布更慢。

    按我的经验，主要是要走流程，即任何修改都要经过测试才能发布，而编码和测试两个部门各自有独立的节奏，不是说编码的先修完了，测试就会立马完成测试并发布的。即使编码的认为自己的修改很简单，不会有问题，不用详细测试，但测试不会认同的，“怀疑一切”也算是测试人员的必要素质吧。

    紧急更新确实可以打破常规流程，但是这也必然产生扰乱，影响整体效率，所以并不常用，通常只用于安全更新之类的严重问题。
    Reply View the author
    avatar
    走钢丝
    deepin
    2019-07-12 18:59
    #6
    https://bbs.deepin.org/post/180559
    不是的，大公司的产品可能发布更慢。

    按我的经验，主要是要走流程，即任何修改都要经过测试才能发布，而 ...

    我知道啊，但有些更新是很小的改动，测试应该很快就结束了。再说，这些轻重缓急的事怎么处理应该都包含在公司流程中才对，偶尔打破流程也是考虑在内的。
    Reply View the author
    avatar
    duanyao
    deepin
    2019-07-12 19:23
    #7
    https://bbs.deepin.org/post/180559
    我知道啊，但有些更新是很小的改动，测试应该很快就结束了。再说，这些轻重缓急的事怎么处理应该都包含在 ...

    我不是说了吗，在测试部门眼里不存在“很小的改动”，所有的改动都是一样的，有改动就要走流程，而流程的时间与改动的大小基本无关。测试不是针对一个单独的改动，而是对产品整体进行测试，你要考虑多个改动之间可能的互相影响。所以测试一般都是周期性进行的，快不起来。
    Reply View the author
    avatar
    duanyao
    deepin
    2019-07-12 19:24
    #8
    https://bbs.deepin.org/post/180559
    我知道啊，但有些更新是很小的改动，测试应该很快就结束了。再说，这些轻重缓急的事怎么处理应该都包含在 ...

    你如果一定要测试部门快速反应，那么就要大大增加测试的人手，甚至测试比编码的人多，但是没有紧急更新的时候，测试部门就会闲出鸟来。我想deepin没有土豪到那个程度。
    Reply View the author
    avatar
    走钢丝
    deepin
    2019-07-12 19:27
    #9
    https://bbs.deepin.org/post/180559
    我不是说了吗，在测试部门眼里不存在“很小的改动”，所有的改动都是一样的，有改动就要走流程，而流程的 ...

    我知道你的意思，我是说，更新策1略应该多样化。现在的策略是一条流1水1线，当然像你说的那样了。不过这是公1司的设1计和规1划，是可以改变的。
    Reply View the author
    avatar
    走钢丝
    deepin
    2019-07-12 19:31
    #10
    https://bbs.deepin.org/post/180559
    你如果一定要测试部门快速反应，那么就要大大增加测试的人手，甚至测试比编码的人多，但是没有紧急更新的 ...

    这么说当然也可以，不过不一定就非要增加规模，也可能只优化流程就能实现。最终看公司的决策吧，我也只是提个建议。
    Reply View the author
    avatar
    WENWEN
    deepin
    2019-07-12 20:41
    #11
    操作系统的复杂度 远远高于哪些app web ==   更新必须花时间
    Reply View the author
    avatar
    duanyao
    deepin
    2019-07-12 20:51
    #12
    https://bbs.deepin.org/post/180559
    这么说当然也可以，不过不一定就非要增加规模，也可能只优化流程就能实现。最终看公司的决策吧，我也只是 ...

    最优化的流程当然是按固定的步点前进，任何紧急任务的插入都会降低总体效率，这不难理解吧？
    Reply View the author
    avatar
    走钢丝
    deepin
    2019-07-12 21:05
    #13
    https://bbs.deepin.org/post/180559
    最优化的流程当然是按固定的步点前进，任何紧急任务的插入都会降低总体效率，这不难理解吧？ ...

    发布一个更新之后就什么也不管了，去进行下一个版本的开发了，不等等看有什么问题需要修复没？我想成熟的流程至少应该是先等几天看看吧。
    Reply View the author
    avatar
    duanyao
    deepin
    2019-07-12 21:13
    #14
    https://bbs.deepin.org/post/180559
    发布一个更新之后就什么也不管了，去进行下一个版本的开发了，不等等看有什么问题需要修复没？我想成熟的 ...

    编码和测试人员当然是并行工作的，发布一个更新之后编码人员自然是去开发下一个版本了，要修复的bug如果来得及就在下一个版本修复，来不及就往后推。
    Reply View the author
    avatar
    走钢丝
    deepin
    2019-07-12 21:18
    #15
    https://bbs.deepin.org/post/180559
    编码和测试人员当然是并行工作的，发布一个更新之后编码人员自然是去开发下一个版本了，要修复的bug如果 ...

    这也算是个建议吧，看官方怎么决定。咱也只能吐吐槽，发泄下情绪，别的没什么招。
    Reply View the author
    avatar
    牧野
    deepin
    2019-07-12 21:19
    #16
    https://bbs.deepin.org/post/180559
    我知道啊，但有些更新是很小的改动，测试应该很快就结束了。再说，这些轻重缓急的事怎么处理应该都包含在 ...

    不是更新大小的问题，问题这是个完整的产品，出厂必须要过检验这一关，不管你修改了什么，测试要保证你这次发布的所有东西都是正常的，因为很多情况下，各个模块之间是有耦合的，改了这边，可能影响那边，所以每次都要完整的走一遍测试流程。
    Reply View the author
    avatar
    st******ra@outlook.com
    deepin
    2019-07-12 21:30
    #17
    说明还是质量管理体系不完善。
    不要说什么要确保万无一失才发布更新，这怎么可能呢？谁敢说真正发布出来的更新或者版本是万无一失的么？要不然就不会有更新和持续更新了。
    只能说在目前的试验或者测试标准下没有问题，那就可以发布更新了啊！所以说，不及时发布简单更新的最大原因只能是心里没底：担心、担心、担心改了一点点之后引发更多更大未知的问题。
    为什么这么担心呢？就是开头提到的，质量管理体系不完善，没有完整、完善的测试标准、流程、方案，没有拍板的底气，所以退而求其次，小的变更就干脆等着跟着大的变更一起发布，反正就算出了问题也是当次的大更新出了问题，没有那么醒目。
    说实话，无论是对于操作系统还是其它产品，正式发布上线了的或者量产了的产品，修补漏洞应该是非常积极、及时才对，以解用户燃眉之急，只有发布新特性之类的更新才应该按部就班，否则只会因为漏洞缺少修补而失去用户，不会因为按部就班的新特性而吸引到用户。
    Reply View the author
    avatar
    duanyao
    deepin
    2019-07-12 22:48
    #18
    https://bbs.deepin.org/post/180559
    说明还是质量管理体系不完善。
    不要说什么要确保万无一失才发布更新，这怎么可能呢？谁敢说真正发布出来的 ...

    不是干软件这行的就别说大话，任何其它行业的经验都不适用于软件开发。
    Reply View the author
    avatar
    BLumia
    deepin
    2019-07-12 23:37
    #19
    修复问题 A 是可能引入问题 B 的，如果只对修复问题 A 的提交进行了 A 相关的单元测试，是不能测出来 B 出问题的，老哥应该了解一下集成测试和全量测试相关的概念。

    另外正如你所说，“系统的完善应该由制度和流程控制来保证”，而越复杂严谨的流程体质就越会导致开发周期越发变长和人均工作效率的降低（好处就是工程化的管理导致宏观上的稳定），流程越简单，也就开发周期越短，开发过程也就越敏捷，而整个体系则越不稳定，比如意外导致的影响会变大。
    Reply View the author
    avatar
    st******ra@outlook.com
    deepin
    2019-07-13 00:18
    #20
    https://bbs.deepin.org/post/180559
    不是干软件这行的就别说大话，任何其它行业的经验都不适用于软件开发。 ...

    你这种务虚的说法就没必要拿出来了吧。
    不管是想强调更新之前需要多少多少严格的测试，或者多少多少周全的考虑，不要想当然地以为就软件开发才严谨，其他做产品的都是应付了事。
    看清楚帖子题目问的是什么问题，什么是好修复的漏洞。如果这样的漏洞修补起来的时候也是整天想得到想不到的测试个没完、担心个没完的话，只能说明这个软件的基本框架就是有缺陷的，从一开始的Ｌａｙｏｕｔ就先天不足。这种情况还拿测试辛苦、繁重来说事，只能说南辕北辙太严重了。
    Reply View the author
    1 / 4
    To page