在这篇文章中，我将讨论我们的Scrum前端团队在从事一个体面项目的一年中遇到的问题。 我们开始使用React + Typescript技术栈从头开始开发项目。 回顾过去，我发现有数百万人被浪费，这仅仅是因为开发过程从一开始就设置不正确。 但这是有原因的。
首先，您必须中标。 为此，有必要快速提交最低价值产品。 这是为我们的客户付出可观成本的第一个错误。 听起来像是：迅速加薪MVP。 客户希望快速看到结果，但这意味着我们牺牲了良好的基础架构，可靠的体系结构，一年后得出的结论是，前端体系结构需要认真的重构。 大约几个月。 因此，我们泄漏了500,000卢布。
回顾过去，我可以自信地说，要做的第一件事就是考虑几年后客户希望看到的所有功能。 因此，我们可以避免采用“此体系结构无法满足此要求”样式的体系结构错误。 结果，每个主要芯片都需要认真重构。
为了赢得招标，我们公司派遣了没有设计大型应用程序和可靠的可扩展系统经验的开发人员。 明确的业务，招标不是命令，没有人希望分散好的人员。 但是在（类级别）缺少技术架构师的事实导致我们的应用程序变成了意大利面条式代码，并且不再满足SOLID要求。 这就是每个客户的错误。 不增加团队资源就不可能保持稳定的发展速度。 敏捷原则“投资者，开发人员和用户应能够无限期地保持恒定的节奏”，只有在从一开始就了解并解决了需求，整套功能，设计了可靠且可扩展的架构的情况下（总之，如果考虑到每个最终课程都考虑了每个类，系统功能）和明确定义的流程。 在看到产品之前，这必须在MPV中完成。 否则，随着时间的延长，应用程序的复杂度将成倍增长。 这意味着一年中的煤气特征将比开始时贵O（e（N））。
在我们团队中，唯一的设计师是一名远程员工。 这是一个严重的错误。 远程员工总是过着自己的生活。 他为自己绘制了一个设计，精美美观，客户满意。 但是所有这些魅力最终归结为以下事实：在相同的逻辑形式上，我们具有N种不同的样式和布局。 从一开始，就值得提出一个要求：风格化某个框架（我们拥有Ant Design）。 如果不存在，请执行存在的操作。 客户认为React是一个块构造器。 而且他仍然不明白为什么我们要在4天内看到原始形式。 React是一个构造函数，但是只有在开发的开始阶段我们就有一组类似的可重用组件（UI框架）。 没有设计经验的设计师永远不会自己做。 开发人员将永远不会告诉客户。 领导者应紧随其后。 因此，前端团队的负责人应该是过去的前端开发人员，而不是过去的后端。 因此，我们得出的结论是，一个功能齐全的敏捷团队应在其每个工作领域（FE，BE）都包括一位称职的领导者。 这些领导者必须具有较强的软技能，才能向客户传达我在本文中要描述的内容。 这是非常非常困难的。
当我们发布第一个版本时，我们意识到在演示之前的最后一天不断出现故障。 在整个开发年中，每个发行分支都变成了一套地狱拐杖（将其关闭，将其删除），然后神奇地结束于开发分支。 并且有一系列提交（将其打开，然后将其打开）。 一年后，我们得出结论，我们需要制定明确的分支机构政策。 但最重要的是，一个负责任的人将消除现有的混乱。 这意味着：要么缓和客户的混乱欲望，要么缓和混乱的bug，或者在每个展位都有自己的配置，以禁用某种图形功能或按钮。 将每个按钮包装在if语句中是很疯狂的。 我们得出的结论是，我们需要一个插件功能模块化前端架构（禁用-启用）。 我想了很长时间，想如何实现这样的架构。 但是我肯定知道一件事。 我们需要一个完整的背景。 因此js-beans库诞生了（https://www.npmjs.com/package/js-beans）。 每个摊位都有自己的json上下文。 插件通过代理模式收集在一个链（链）中。 因此，例如，我们有一个数据源作为一个单独的容器，并且作为可选的代理容器进行了各种转换，以替换该容器，但将其注入自身。 例如，如果您需要扩展数据模型以测试FPS性能，我只需添加一行即可在json文件中启用扩展插件。 生产出现了问题，但无法在本地播放，我用一根线打开了记录器，而没有重建架子（架子大约需要20分钟，而十几个架子并不足以满足所有人的需求）。 或者，如果由于模块可能被破坏而需要快速关闭某些模块（在上下文中禁用可选bean）。
随着时间的流逝，看台被关闭了一个星期。 在当地发展前沿是不可能的。 我们尚未在Mokas上提供自治架构。 我不得不用吱吱作响地使它喘不过气来。 现在回首，我会在一开始就做。 但是我们拥有MVP，因此我们不得不在不进行深度工程的情况下编写代码。 但是客户认为我们是专业人士，并认为我们应该立即编写代码而不会出错。 这是以下错误。 公司的名称并不代表团队的专业精神。 团队的专业精神取决于团队负责人的专业精神。 如果团队中没有技术主管，那么一年之内您的项目将陷入停顿。 因此，您将合并数百万。
我们有一个远程架构师。 但是关于他的只有一件事：他是。 弗拉基米尔·塔拉索夫（Vladimir Tarasov）表示，领导者发展的最后阶段。 在这一点上，我们的建筑师取得了完美。 错误编号N：您没有技术架构师在班级级别设计系统。 如果您处于停顿状态，则没有人寻求帮助。 客户告诉我们，请其他经验丰富的团队寻求帮助。 但是由于某些原因，其他团队却没有时间来帮助我们。 我们的公关已经暂停了第二个月。 我衷心希望有一个勇敢的人会虐待他。 结果，生命以各种形式的魔术和拐杖形式丰富了超自然现象，丰富了我们的代码。 只有一个失踪了。 特殊注释
Magic和@Kostyle。 下一个ES的好主意。
我们认为，更多的中间人和更少的人可以为该项目带来更多的利润。 现在我们换个角度思考。 如果预算有限，则需要聘请最昂贵的专家。 如果您像我们一样没有预算问题，则可以安全地节省专家费用，并将“代码审查”变成一场心理战。
我们认为我们会按季度完成任务。 现在我们换个角度思考。 简而言之，总的来说，我们需要重写项目。 最好是从头开始。 希望我们的客户永远不会知道。 毕竟，我们最近才有一个很棒的团队建设）
我们决定尝试缺乏专业知识的新技术。 他们被推荐给我们。 我们当然想获得经验。 现在，我认为最好只使用我经验丰富的技术。
我们根据每天8小时的工作时间进行估算。 实际上，应该以4小时的工作日为基础进行估算。 为什么没有人喝茶，讲有趣的故事，在导航仪上找到洗手间，打电话，通信，研究新技术，最重要的是，团队内部发生激烈的争执。 后者可能是最不可避免的，也是最昂贵的。 虽然，老实说，对于开放空间，您仍然需要花费几个小时。 经常说话会极大地降低注意力。 懂这一切的客户有福了！
我们的估计令人筋疲力尽，反正变成了乏味的技术争论。 集会的效果微乎其微。 但是我们找到了解决方案：美味的比萨。 当美味的气味刺激鼻子时，一个人开始更加清晰地表达自己的思想。
一开始我们只有一个小团队，然后是一个大团队。 计划花费了2-3个小时。 站立30分钟。 我尊重我们的PO，这是因为他决定将其分为许多小块，并在每个小PO中分配自己的迷你PO。 这可能是我们项目历史上最好的决定。
从一开始，我们就没有时间编写测试。 半年后，我们得出结论，仍然需要编写它们。 但是我们仍然没有时间为此。 优先级较高的技术债务已积累。 不要节省技术债务-这是乌托邦。 他将永远如此。
我个人的主观结论：
- 如果您的开发人员不了解IOC for FrontEnd的用途，那么很可能在他们了解时为时已晚。
- 如果您的开发人员不理解为什么FrontEnd需要OOP知识，那么几乎就无法支持您的代码。
- 较便宜的专家胜于利润更高的专家。
- 如果您有一位建筑师，则很可能还需要一位建筑师。
- 如果您看到的是MVP，请完成并更改项目。
- 如果您之前已经录制过MVP，请不要进入此项目。
- 如果您想赢得MVP，但又不想离开，很可能会改变主意。
- 如果您是zapilili MVP，并且希望您的项目继续存在，请从头开始重写它。
- 如果向客户展示此文章，您很可能会被解雇。
- 如果您从事敏捷工作，最有可能了解我。
即使阅读本文，您也不可能避免所有这些问题。 我的目标是向您表明这是不可避免的。 无论您多么努力，您都永远不会拥有理想的条件。 因此，为此做好准备。 而且在解雇之前，您可以安全地向客户展示此文章。 让他为此做好道德上的准备。
PS：Maxim，如果您读过这篇文章，就会知道我所描述的一切都是虚构的，与我们的项目没有相似之处。）但这一切并不重要，因为今天我要去度假。 艰苦的不定期工作一年中的第一个假期！ （作为FE主管）。