我构建大型应用程序的坎坷历程

我一直想写一篇类似的文章，回顾一下我构建大型网络应用程序时遇到的各种障碍，而我其实根本不应该涉足这个领域。

我想先说明一下，有些错误看起来似乎显而易见，而且我的建议也绝非万能灵药。这些建议是我根据个人经验回顾总结出来的。

那就开始了！

一些背景信息

时间回到2017年，那时我还是个经验尚浅的开发人员。我之前就职的一家公司需要重建一个已有15年历史的多供应商电商应用。由于团队规模小，同时还要处理很多项目，我也被安排参与了这项工作。当时的我万万没想到，自己会阴差阳错地成为技术负责人。

虽然我在技术和专业方面经验不足，但我渴望在公司晋升，提升自己的职业生涯；而且当时经济拮据，第二个孩子也即将出生。不过，我一直按时上班，这算是我的优势之一。最终，这个项目花了超过一年的时间才启动，其中有五六个月是紧张的冲刺阶段。

1. 了解业务

我的错

我刚加入这个项目时，以为自己可以迅速上手。我知道这是一个使用电商平台的电商网站，所以使用与平台相匹配的术语和结构是理所当然的。

我的现实

这是一个根深蒂固的遗留应用程序，其历史可以追溯到公司内部。它诞生于电子商务术语尚未形成任何正式标准之前，其中一些术语甚至是凭空捏造的。这两者的结合导致了应用程序内部以及讨论中大量的混乱。

我的建议

花点时间了解一下这个行业的运作方式和现有情况。之后，你再决定是该如何坚持自己的术语更胜一筹，还是该向领导妥协。最终，至少大家都能达成共识，你的应用也会更加规范统一，而你也不用再翻词典了。

这个例子可能有点特殊，但与企业保持步调一致非常重要。

2. 提出问题

我的错

在应用开发的最初阶段，我基本上是尽力完成分配给我的每一项任务和要求。我并没有过多考虑这可能会带来的更深远影响，也没有仔细思考这项功能究竟有多大用处，或者他们想要实现什么目标以及原因。

想要一个<div>标签来嵌入产品轮播图？没问题！
想要一个<div>标签来嵌入整个产品目录，并根据所选筛选条件进行动态筛选？小菜一碟！
想要把这些功能整合到一个可以设置选项来显示不同变体的组件里？……当然可以！想要
内容创作者能够用预先编写好的静态 HTML 代码块创建完整的页面？我真心希望你不要这么做，但我会给你这个权限。

我的现实

我举了一些例子，说明一些必要的功能最终是如何被过度使用、误用或完全废弃的。这导致代码债务立即产生，依赖于一个有缺陷的产品，并且失去了对重要展示元素的控制。

我的建议

如果你对某个需求有任何异议或困惑，请询问其目的是什么以及这样做的好处。从对方的角度理解这一点，将有助于你提出更优雅的解决方案，建议其他可能的选择，或者干脆像个大佬一样毫不犹豫地拒绝它。

无论讨论结果如何，最终你可能会得到一个对双方都更有利的产品。或者，你可能还是会无奈地离开，继续做着自己不想做的事情，但至少你努力过了，不是吗？

3. 同行评审很重要

我的错

这可能是团队工作流程中的一些错误造成的，但我本可以很容易地纠正这个问题。

我基本上拿到了这个代码库的完全控制权。我是维护者，没有任何东西能阻止我把我的代码推送到任何我想推送的地方。那是一段无比辉煌的时光。

我的现实

我当时往那个代码仓库里上传了各种各样的垃圾代码。不过，值得肯定的是，我确实努力保持代码风格、语法和应用程序结构的一致性。

然而，很容易忽略一些事情，或者过于严格，坚持一些根本不值得坚持的事情。

身边还有其他工程师，这种做法简直愚蠢至极。能有积极的导师和同事一起工作，并从中获得反馈，是多么宝贵的财富。

我的建议

如果你的团队目前还没有定期进行代码审查，我强烈建议你们开始这样做。当你在修复 bug 或开发新功能时，很容易忘记你写的代码不仅仅是你一个人的，它也是整个团队的。

考虑到这一点，你的团队不仅可以就集体代码库的新增内容提出建议或提出问题，还可以了解其他地方正在发生的事情，这难道不是理所当然的吗？

但这不仅仅是审查你自己的代码！你可以从团队成员身上学到很多东西，而且你也要审查他们的代码。所以我真正想说的是，每个人都可以互相讨厌对方的代码，互相憎恨，但这话可不是我说的。

4. 检查代码债务

我的错

你看，我得赶着完成一些功能，因为这个项目迟早要发布。我得全力以赴，不能回头；当然，除非它出了问题。改进或者完善它需要花费太多时间和精力，所以我会在发布之后再做。

我的现实

随着时间的推移，各种功能层层叠加。一些主要功能的发展甚至变得难以管理。我们使用的模块和框架也陆续发布了更新，这些更新对应用程序非常有益。不幸的是，所有这些更新都堆积在一起，使得我们很难进行那些迫切需要的更改。

这也适用于代码块的编写方式。回顾某些代码区域，要么是代码演变成了原本不该有的功能，像是拼凑而成；要么是实验性的尝试最终成为了解决方案，并在此基础上不断发展完善。

我的建议

找出你可能草率完成且不够完善的部分。抽出时间重新审视这些部分。花点时间检查一下应用程序的一些旧组件，看看它们是否需要升级到现代标准（如果你是前端开发人员，那么每周需要升级的标准都不一样）。

这一点可能有点棘手，但在一个预发布期很长的大型项目中，我在这方面吃过太多亏了。

综上所述

项目最终顺利完成并上线生产环境。发布过程比我预想的要顺利得多，这主要归功于我成功说服管理层接受的早期到中期的技术栈变更。

整个经历有好有坏，我会尽量总结一下。

好东西

• 我学到了很多东西。
• 我为公司做出了重大贡献。
• 我参与了一个相当大的实际应用项目，并有机会署名。
• 影片发行一段时间后，我得到了晋升。

坏东西

• 由于我最初缺乏经验，申请过程相当混乱。
• 有些错误已经根深蒂固地融入到管理工作流程中，无法重构。
• 那段时间压力非常大。
• 我加班加点，却没有得到任何报酬或休息时间。
• 发布后导致我精疲力竭。
• 我从来不喜欢把自己的名字署在商业和设计领域。

我希望我的这些絮絮叨叨能对初学者有所帮助，也能提醒一些资深人士一些需要思考或注意的事情！勇于尝试、努力钻研是成长的好方法，但也要小心别在过程中失足受伤！