最新版本中，我们对 Ulysses 中一处在实践中可能产生会引起故障的地方进行了重新修订： 写作会话历史。 负责该功能的开发人员 Götz 在这篇文章中阐述了他如何发现这个问题，找出解决方案并付诸实现的过程。
每个设有组目标的小组均可查看其写作会话历史。通过写作会话历史你可以查看过去几天内这个分组的写作进度： 总共写了多少字符、字、页数、日平均数、“最高分” 以及你本周的目标完成进度。
此外，写作目标这个功能也是基于写作历史会话的。 你可以给自己设定一个每日写作目标，例如：“每天1000字”。 你可以借此培养写作或是记日记的习惯，亦或是借此迫使自己每天完成定量的小说创作、论文或是你任何正在进行的写作项目。
在很多情况下，会话历史的每日计数是不准确的，而这也影响了历史记录及每日目标。例如： 当你将大量的文稿在各个分组之间迁移时；或是在 iOS 为了释放内存将文稿从本地储存中删除并通过 iCoud 重新添加时。
而这个问题是由文本统计数据计算和保存的方式导致的。在原本的计算方式中，所有的文本数据将以组为单位被收集，并在汇总后以组为单位被保存。而在刚刚谈及的情况下，这些数值有可能因此发生出现错误。例如：若 iCloud 系统服务由于内存问题删除了某组中的一篇文稿，但是在第二天用户重启 Ulysses 后，系统会自动重新下载这个文稿。在这种情况下，原本的写作会话历史会将这篇文稿的内容算作今日的写作进度，这明显是错误的。
新的会话历史以单个文稿为单位，单独储存每个文稿的所有统计数据：字/词/页/…。 现在当用户查看小组写作会话历史时，这个数据是根据各个文稿的会话历史动态计算出来的。也就是说，现在为了计算每个组的写作会话历史，需要先查看其包含的文稿的会话历史，并进行汇总，然后才会生成组会话写作历史。这样就方案中的问题就迎刃而解了。
当然，这个解决方案也有存在一些折中的的地方。例如， 当文稿被删除时，它对应的写作会话历史也会从组写作会话历史中被删除；当文稿被拖拽至其他分组时，其写作会话历史也会被转移到新的分组会话历史中。这可能是用户的目的，也可能不是。总而言之，我们认为新方案的好处是远远超过删除或是移动文稿时带来的短暂的混乱的。
首先，我们需要收集所有已知问题出现的所有情况，也就是说，在哪些情况下，写作历史会出现无效值？ 我们是否可以通过调整解决这些问题？或是我们需要重新制定计算方式？ 很明显，原来的计算方式是存在缺陷的，我们需要将统计数据的保存从组为单位改为文稿。很快我们也意识到，这是明智的选择。
在经历了各种需要考虑的可能和不可能的情况后 （之前提及的移动和删除文稿，还有处理素材文稿以及普通文稿，重设每日计数，复制文稿等等情况）实施阶段开始了。 我们删除了旧的代码，设置新的计算方式，并进行测试，之后就是代码审查。最后，我们将新的版本进行公测，检测一切是否正常，以及解决一些我们之前没有考虑到的小问题。并在最近的一次更新中推出了新的会话历史 （Ulysses 23）。
修复 Bug 是 Ulysses 开发团队的日常任务，Bug 的来源可以归纳为以下几种情况：
作为一款日常写作工具，保证 Ulysses 的日常运行是至关重要的。粗略估计，维护 Ulysses 占比我们的总工作内容的 50%。 这些年来，随着 Ulysses 的更新，功能的更新迭代，这款应用程序也变得愈加复杂，从而维护成本也在不断增加。此外，我们一直在认真对待每次 Bug 和崩溃报告以及每次用户反馈，我们一直努力想呈现一款优质的软件给我们的用户。
Ulysses 团队每天都在同时进行多个任务，这些任务的复杂程度和内容不一。目前我的重点是与两位同事一起准备为最新操作系统更新 Ulysses: macOS Monterey和 iOS 15。 此外，我们还希望将一些功能整合到 Ulysses 中，例如 macOS 上的快捷键的支持。一如既往，我们需要在保证 Ulysses 简洁的界面和沉浸式写作体验不会被破坏的前提下，进行更新与支持所有的设备功能。
编译：超凡
若你对 Ulysses 团队感兴趣，想了解更多，可以阅读我们 走进「Ulysses 团队」这篇文章
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。