evernote 有道_他们改写了Evernote

evernote 有道

I couldn’t resist commenting on this interview with Evernote’s CEO about the project to rewrite Evernote.

在对Evernote首席执行官的这次采访中，我无法抗拒关于重写Evernote项目的评论。

First, disclaimer. I managed the Microsoft OneNote dev team from 2003 on for about a decade and am still a huge fan with much of my life recorded in OneNote. I’ve also written about OneNote internals in a number of posts and am friends with many on the team.

首先，免责声明。 从2003年开始，我管理着Microsoft OneNote开发团队大约十年，仍然忠实拥护我的一生。 我还在许多帖子中写了有关OneNote内部的文章，并且是团队中许多人的朋友。

The interview referenced above describes the Evernote code base as a “monolith” that had grown “big and complex” and a “crufty, complex relic of a once-great app”.

上面提到的采访将Evernote代码库描述为“庞大而复杂”的“整体”和“曾经很棒的应用程序的粗糙，复杂的遗迹”。

I read those quotes through a couple different lenses. One lens is “Crowley’s Phases of Software Evolution” that I just made up. The pattern you often see in a software project is the first version gets built focused on delivering key functionality but the internals are a pile of crap. But it’s a small enough pile of crap with a small enough team that you can actually fix all the bugs and get the product delivered. Version 2 needs to get built quickly, so the team just keeps bulldozing that pile of crap along. By Version 3, the team is bigger and is still bulldozing that pile of crap but now the pile is much bigger and it’s spilling over the top of the cab and burying the team. Some teams never end up being able to ship Version 3 because the crap pile gets so big.

我通过两个不同的角度阅读了这些报价。 我刚刚写的一个镜头是“ Crowley的软件演进阶段”。 您在软件项目中经常看到的模式是构建第一个版本，专注于提供关键功能，但是内部却是一堆废话。 但这是一个很小的废话，只有一个足够小的团队，您实际上可以修复所有的错误并交付产品。 第2版​​需要快速构建，因此团队只需继续推销那堆废话。 在第3版中，团队变得更大，并且仍在推挤那堆废话，但是现在这堆变得更大了，它洒在了驾驶室的顶部并掩埋了团队。 一些团队永远都无法发布版本3，因为垃圾堆变得很大。

Apologies for the paleolithic references to versions “1, 2, 3” in our agile monthly release world. But significant new functionality takes time so call it “year 1, 2, 3” if that feels better.

在我们敏捷的每月发行版中，对旧石器时代版本“ 1、2、3”的引用表示歉意。 但是重要的新功能会花费一些时间，如果感觉更好，可以称之为“ 1、2、3年”。

Why does it seem that it is always the successful products that are such a pile of crap? Mostly it’s just selection bias. When a product is successful, the team has motivation to keep gunning the engine on that bulldozer, even if they’re getting buried in crap. For the failing products, the team just walks away and the code base dies out before it gets too big. Sure sounds like the Evernote team has been gunning the engine on that bulldozer for a while.

为什么似乎总是成功的产品这么堆烂？ 通常，这只是选择偏见。 当产品成功时，即使他们被埋在垃圾里，团队也有动力在那台推土机上开枪。 对于失败的产品，团队只是走开了，代码库在变得太大之前就消失了。 当然，听起来Ever Ever团队已经在那台推土机上开枪了一段时间了。

The second lens is the one I discussed in Complexity and Strategy. Basically, large products with lots of features are inherently complex. There are trade-offs and interactions and lots of different scenarios and features that need to be addressed. There is no magical refactoring that will make that complexity disappear. Ongoing development in such a code base is just harder than it is in the smaller, simpler code base of a smaller product. Applications that create sophisticated document artifacts are particularly complex and especially challenged by the need to remain compatible with all those valuable existing artifacts (and the user experiences and scenarios that have built up around them).

第二个镜头是我在“复杂性和策略”中讨论的镜头。 基本上，具有许多功能的大型产品本质上是复杂的。 存在权衡和交互以及许多不同的场景和功能需要解决。 没有神奇的重构可以使这种复杂性消失。 在这样的代码库中进行持续的开发要比在较小的产品的较小，较简单的代码库中进行开发困难。 创建复杂的文档工件的应用程序特别复杂，尤其是面临与所有这些有价值的现有工件(以及围绕它们构建的用户体验和场景)保持兼容的挑战。

The proactive and non-fatalistic response is to recognize that if real complexity is inevitable, you need to invest significant effort in reducing the accidental complexity that builds up over time. Any application that has survived for almost two decades and had to move from desktop to span the rise of web, mobile, cross-platform and cloud will have a lot of accidental complexity.

主动且非致命性的响应是要认识到，如果不可避免的是真正的复杂性，则需要投入大量的精力来减少随时间推移而累积的偶然性复杂性。 生存了将近二十年并且必须从台式机迁移到跨越Web，移动，跨平台和云的兴起的任何应用程序都将具有很多偶然的复杂性。

This would provide a much friendlier perspective on Evernote’s efforts than applying the lens of Joel Spolsky’s classic “Things you should never do” essay on their project. In fact, the description of the Evernote project in the interview sounds much more like a cleanup than it does a grounds-up rebuild.

与将Joel Spolsky的经典作品“您永远不应该做的事情”的镜头应用到他们的项目中相比，这将为Evernote的工作提供更为友好的观点。 实际上，采访中对Evernote项目的描述听起来像是一次清理，而不是进行彻底的重建。

The counter-argument is that if you really aren’t doing a rebuild, the discipline of continuous stability and continuous delivery is way too valuable to give up. After leading multi-year projects for decades at Microsoft, I became a true believer in this more “agile” approach as I led Office from multi-year ship cycles to monthly ship cycles. The team delivered deep new functionality (e.g. real-time co-authoring) while maintaining a continuous stability and delivery discipline. Once you drink that Kool-Aid, you don’t want to stop. In this sense, it looks like Evernote conflated a resource prioritization problem (they were continually failing to allocate enough resources for ongoing architecture and “technical debt” work in the face of demands for new features) with an engineering strategy (forgoing shipping until major architectural work was complete).

相反的论点是，如果您确实没有进行重建，那么持续稳定和持续交付的准则就太有价值了，因此不能放弃。 在Microsoft领导了数十年的多年项目之后，当我领导Office从多年的出货周期到每月的出货周期时，我坚信这种更为“敏捷”的方法。 该团队提供了深层的新功能(例如实时共同创作)，同时保持了持续的稳定性和交付纪律。 一旦您喝下了Kool-Aid，您就不想停下来。 从这个意义上讲，Evernote似乎将资源优先级问题(面对新功能的需求，他们一直无法为正在进行的架构和“技术债务”工作分配足够的资源)与工程策略(放弃运输直至主要架构)工作已完成)。

When we made the transition in Office, many in Microsoft thought that what we were doing was “impossible” until we did it and then doing anything else seemed crazy.

当我们在Office中进行转换时，Microsoft中的许多人认为我们所做的事情“不可能”，直到我们完成它，然后再进行其他任何事情似乎都是疯狂的。

翻译自: https://medium.com/@terrycrowley/yikes-they-rewrote-evernote-3c0ddae9a688

evernote 有道