苹果的iOS 13和Catalina的Bug如此多的六个原因

  • M
    Macd10
    推荐的文章《苹果的iOS 13和Catalina的Bug如此多的六个原因》
    O网页链接
    https://tidbits.com/2019/10/21/six-reasons-why-ios-13-and-catalina-are-so-buggy/


    作者David曾经是苹果的软件工程师,在苹果有18年之久,参与了iPod、Apple Watch和Apple的Bug跟踪系统Radar的研发,内容可信度还是很高的。他在文中列举了6个主要原因。

    第一个原因:功能列表中要做的功能太多

    苹果一直积极的在即将推出的产品中加入新的重要的功能,并且对于现有产品发布的时间表是很严格的,这就意味着随着截止日期的临近,不可避免的要将一些功能放到未来的版本。

    如果是一个运行良好的项目,进度延后的不重要的功能会被砍掉,这样开发工程师就可以集中精力投入到其他更重要的功能开发和Bug修复工作中。但是有时候经理们扮演者“schedule chicken”的角色,因为没有人原因承认自己负责的项目延后了,相反的是,他们希望与之对接的其他项目的进度延迟,这样他们就不必为进度延迟背锅了。但如果都这么做的话,工程师根本就无法完成那么多开发任务,最终必然推迟!

    本来苹果可以通过不在每个版本中加入太多功能来改善这个问题,但是这和苹果的文化不符。那些还没有发布时间表的产品可以一拖再拖,直到质量可靠为止。但是像iPhone和Mac,这些按年度发布的产品,都必须在9月份上市发布。

    (其实按照软件工程的知识,参考时间范围成本和质量的关系,每年固定发布版本,时间固定,范围过大,最终就可能影响质量。)

    第二个原因:Crash Reports(崩溃报告)无法识别出非系统崩溃的Bug

    苹果内置的Crash Reports可以自动讲应用程序或者系统崩溃后的错误信息包括堆栈信息发给苹果,这样程序员就很容易定位出问题在哪。然而很多Bug不是Crash Reports能检测出来的,比如说 iCloud照片不能同步、无法从Mac同步iPhone的联系人信息、Time Capsule备份损坏等这类问题就无法通过Crash Reports收集。

    苹果还在用一种传统的方式跟踪那些不能用Crash Reports收集的Bug:用测试工程师手工测试,自动化测试,以及第三方开发人员和通过苹果官方网站提交Bug。不能说这些方式没有效果,但是要有效识别出那些不能用Crash Reports收集的Bug还是相当有难度的!

    第三个原因:那些不严重的Bug会被分类但一直被往后推延

    在开发过程中,苹果公司像大多数软件公司一样,对Bug进行分类和评级,比如有些Bug会被标记为紧急重要,有些则标记为不紧急不重要。

    在Alpha版本之前,工程师可以自己去Backlog选择修复任何想要修复的Bug,但是在Alpha版本之后,对Bug的修复就是一件很慎重的事情,因为每修复一个Bug可能会导致更多新的Bug产生,所以在Alpha版本之后,就只会修复一些紧急重要的Bug,而其他没那么重要的Bug就会被推演到后续的版本中修复,日积月累这些不那么重要的Bug会越积越多,也许永远不会得到修复。

    第四个原因:属于Regressions(回归)的Bug会马上修复,而历史Bug会被无视

    苹果特别关注新产品新版本中的Bug,如果新版本中发现Bug,在日常回归测试中发现影响回归测试的Bug,那么会很高优先级修复。

    如果一个Bug在以前的版本也存在,按照苹果的逻辑,既然一个Bug已经存在那么久了,说明没有那么重要,那么就会标记为“not a regression(非回归Bug)”,意味着可能没有人会去处理。

    并非所有组会这样做,但是绝大部分组都是这样的,甚至有一个组做了“Not a Regression”的T恤。

    这就是为什么像iCloud无法上传照片、联系人无法同步这类历史Bug永远不会得到修复的原因。

    第五个原因:自动化测试应用的太少

    除了一些特定领域,苹果很少做自动化测试,高度依赖手工测试。

    苹果在自动化测试应用最重要的地方是对电池性能的测试,确保电池性能不会降低。另外Safari的自动化测试做的很好,每次Commit代码都会触发性能测试,如果导致性能指标降低,将无法合并。

    作者认为如果增加自动化测试的比例应该能有效改善苹果的软件质量。

    第六个原因:系统复杂度越来越高

    苹果遇到的另一个难题是系统越来越庞大越来越复杂,早年苹果只有Mac系统,大多数是单线程的,一个系统的代码可能就是十万行的级别,而现在苹果操作系统代码已经上千万行了!

    到现在苹果的产品已经比过去复杂太多,使得开发和测试越来越困难。这也是Bug越来越的的一个主要原因。

    在文章的最后,作者也对苹果的未来有一些美好的期待,认为苹果在iOS 13发布时,直接宣布了iOS 13.1版本,侧面反映出苹果承认了在软件质量上存在的严重问题。苹果有丰富的资源和大量优秀的工程师,相信能解决好这些问题。

    我作为一个苹果资深用户,对于苹果的新功能已经没那么期待了,也不期望苹果每年一个大版本更新,两年一个版本更新,少点新功能,多花点时间解决一些历史遗留问题,还一下技术债务,对用户的价值会更大。
  • M
    Macd10
    一和六深有感触

    复杂性那里译文不是很完整

    Complexity Has Ballooned

    Another complication for Apple is the continually growing complexity of its ecosystem. Years ago, Apple sold only Macs. Processors had only one core. A program with 100,000 lines of code was large, and most were single-threaded.

    A modern Apple operating system has tens of millions of lines of code. Your Mac, iPhone, iPad, Apple Watch, AirPods, and HomePod all talk to each other and talk to iCloud. All apps are multi-threaded and communicate with one another over the (imperfect) Internet.

    Today’s Apple products are vastly more complex than in the past, which makes development and testing harder. The test matrix doesn’t just have more rows (for features and OS versions), it also has more dimensions (for compatible products it has to test against). Worse, asynchronous events like multiple threads running on multiple cores, push notifications, and network latency mean it’s practically impossible to create a comprehensive test suite.

    ------

    特别是异步的时候,外部的结果不回来,有时候本地一大堆东西都要等,烦得要死。
  • z
    zeroxia
    大多数软件都符合这里说的问题。
  • M
    Macd10
    是的,大多数软件公司都中标。真希望作者再仔细谈谈苹果是怎样解决这些问题的,肯定有过人之处啊,要不然世界上遍地都是苹果了。
  • 哈利波特大
    微信官方都叫你们别升级系统了还肯定有过人之处,过人之处是卖壳子
  • 卫星
    新上的功能越多,系统的复杂性越多,debug的难度就越高,因为你既不知道bug是新加的哪个功能引起的,也不知道会不会是哪些功能相互冲突之后导致的。

    在有那么点远的未来,测试会越来越重要。 iOS fly ~
  • z
    zhaozhao123
    苹果开发都不用TDD的?