站在一名技能工程师的角度来看，「一款完美的应用程序，并不是指一切功用一应俱全，现已没有什么新功用能够增加进来，而是指一切功用版块都非常重要且活跃度很高，现已没有什么能够删去了」。
曾在 Twitter 担任软件工程师的AakashN S，于2019年出来创业后，开发了一款软件开发和数据科学的学习渠道Jovian，现在他也是这家公司的创始人兼 CEO。近日，他做了一个大胆的决议方案，削减自己所开发渠道的“功用债”，即删代码。
所以，服务器硬件知识,他用了3天的时刻删去了生产环境中的5万行代码。成果出乎意料的是，web应用服务器,这款应用程序不仅没有遭到损坏，还得到了功用释放，变得简略易用。在这篇文章中，Aakash N S 带来了他的阅历共享，也希望能对很多 App 开发者有所裨益。
以下为译文:
上周，我从 Jovian 的代码库中删去了50，000多行代码。一切被删去的代码之前都是在生产环境中运行的，这些代码支撑着 Web 应用程序每日处理十万个用户请求。
这一次删去的代码约占咱们前端代码库的70%，它们首要是用 JavaScript、React 和 Next.js 编写的。
令人惊喜的是，服务器的配置,我能够在不损坏应用程序的前提下，用短短三天删去超过三分之二的代码。一起，这个过程中简直没有丢失任何主功用，让应用程序更轻且更易于运用，以及代码库也变得简略易读。
自2019年以来，咱们一直在致力于构建 Jovian ，该渠道也阅历了各个演变阶段。随着公司规模的扩大，咱们不断增加新功用、页面、按钮和设置，但咱们很少考虑删去某些内容（谁会这样做?），咱们有意识地努力坚持应用程序简略易用，但它仍然积累了大量“功用债”。
我曾在某个地方读到过一句话——典型软件应用程序中超过80% 的功用简直从未被运用过。我也在某个地方看到过一个截图，显示了微软 Word 中可用的一切工具:
图片
话说 Jovian 的情况并没有这么糟糕，但拥有杂乱的应用程序和庞大的代码库确实使得更改、升级库和增加或许真正重要的新功用变得困难。
起先，我仅仅想要重写网站
几周前，我起先的主意是对 Web 应用程序进行尝试性重写，相当于推翻之后重头来过。不过，服务器版操作系统,这款 Web 应用程序采用了最新版别的 Next.js 构建，并部署到 Cloudflare Pages。
我很快意识到从头开端全面重写是行不通的。由于重写整个应用程序不仅需要几个月的时刻，并且简直肯定会充满数百个过错。
全面重构 Web 应用程序简直永久不会成功。即使咱们这样做了，所花费的时刻也比方案的要长得多。之前我在 Twitter 作业时亲身阅历了这一点，在那里我花了几个月的时刻将代码从 Ruby on Rails 搬迁到 Scala。
然后，我又开端考虑运用渐进式搬迁的方法。在这个过程中，也呈现了一系列的应战。举个比如，我创立的新页面在结构和内容上都非常简略，而咱们应用程序中的现有页面包括了多个交互式选项卡、按钮和小部件。咱们现有的 Web 应用程序运用由 Python 后端提供服务的 REST API，而我想运用服务器操作直接从 Next.js 与咱们的数据库进行交互，以使应用程序更快，一起消除托管后端的本钱。这需要将数百个包括数万行事务逻辑的 API 端点从 Python 搬迁到 JavaScript，而我并不期待这样做。
一时之间，好像现已没有办法脱节这种僵局了。该应用程序及其代码库看起来就像一头巨大的大象，只能缓慢、小步行进，并且根本不愿意移动。
每次在 VS Code 中打开代码库时，我都会遇到很大的阻力，由于触及的作业量实在是太多了。
给 Web应用程序“瘦身”
然后，几天前，我突然意识到，通过“瘦身”我能够走得更快。
我能够从屏幕上删去不必要的小部件和按钮，将其搬迁到新堆栈（幸运的是，Next.js 支撑渐进式搬迁），然后再增加回删去的元素。
接下来的工作，只能用“残杀”来形容:
图片
图片
我并没有打算删去三分之二的代码库。我想删去足以开端搬迁一个模块的内容。
所以，我在 Google Analytics 中查找了曩昔30天内每个模块的页面拜访量，以确认从哪里开端。
尽管我知道某些页面的拜访频率低于其他页面，但我惊奇地发现有些模块占页面拜访量的比例不到0.1%。这意味着我能够彻底删去它们，而不会影响99.9% 的用户。我能够删去包括数十个文件和数千行代码的整个目录。
当我从应用程序的其余部分中删去很少运用的模块及其入口点时，慢慢地发现应用程序变得越来越简略，选项卡、页面和菜单项越来越少。删去未运用的代码也感觉很好。
随着代码库变小，我对搬迁所阅历的阻力和焦虑也开端削减。开始我对删去咱们花了几周或几个月构建的模块感到难过，但我知道我总能从 Git 历史记录中取回我将来需要的任何内容。
删去很少运用的整个模块后，我持续删去占流量不到0.5% 的各个屏幕和弹出窗口。我再次惊奇地发现能够删去数百个文件而不影响99.5% 的用户。现实上，这对他们产生了很好的影响。五个选项卡变成了三个，然后是两个，然后是一个，此时，选项卡能够从页面中彻底删去。现在许多页面都有更简略的结构和单一的首要操作。更少的 API 调用导致更快的页面加载和屏幕转化。感觉棒极了!
删去一切不必要的模块和页面后，我开端在 Google Analytics 中进一步挖掘，以确认剩余页面上的功用的运用频率。
我发现了一些很少运用的功用、简直从未点击过的按钮以及从未见过的菜单项。所以，我开端删去它们。我拿走的越多，我就越喜爱剩余的。我删去了几个侧边栏、下拉菜单、按钮、小部件、弹出窗口以及支撑它们所需的内部应用程序状况和条件逻辑。这也使得代码更简单理解，这应该会进一步简化搬迁。开始看似需要几个月的努力，现在感觉就像我能够在几周内完结的工作。
总结
淹没本钱谬误和丢失厌恶是人类的成见，使咱们很难抛弃不再需要的东西。
我仍然忧虑我或许拿走了太多或删去了一些重要的东西，但分析表明现实并非如此。正如今日拜访该网站的用户数量与整理之前一样，他们能够（并且正在做）简直他们之前所做的一切工作。新用户无疑会发现该渠道更易于导航且更易于运用。
我有多少其他应用程序或许会获益于每隔几年删去70% 的代码。它将降低维护开销，使他们能够更快地移动，削减加载时刻，并运送更小的软件包，一起改进用户体验并改进他们的软件。
“完美的完成不是在没有什么能够增加的时分，而是在没有什么能够删去的时分”——Antoine de Saint-Exupery