对于有经验的人，我们的建议似乎很明显。但对于初学者，我们强烈建议阅读。花时间将这些想法转化为您的项目，这样您以后就不必再花费更多精力进行无休止的重构了。
类似的想法几乎可以在开发的任何领域表达，但是我们将以React中的项目为例来讨论它们。
从头开始项目，您会考虑如何最好地组织所有内容，以免以后由于无休止的返工而造成极大的痛苦。在个人宠物项目中，您可以围起来想要的任何东西，然后自己生活。但是在团队合作中，您需要采取一种使同事更容易理解本质并深入细节的方式行事。那些。不要重新发明开发方法-最好遵循公认的，行业认可的做法。
考虑打字
不管开发语言有何自由，静态类型对大型长期项目都是非常有用的。如果由于某种原因不可能在这样的项目上使用静态类型，那么即使是JSDoc也将大大有助于保持代码的质量。
但我们不会强烈建议您始终使用键入。在大型项目上面保留一点也不是白费，因为打字首先是对团队的帮助。但是其组织和维护（根据后端的更改而进行相同类型的更改）需要某些资源。在一个只有1-2人工作的小型短期项目中，这项投资毫无意义。但是，当团队规模很大并且会扩展时，它们是必需的。
如果可以合理地使用类型，我们建议您从一开始就创建类型，否则您将不得不花更多的时间在这项工作上。即使您尚未准备好任何API，也不知道数据模型，也至少要进行存根处理，以使通用类型不会出现在任何地方。
随着项目的发展，即使所有的最后期限都花了很长时间，也必须坚持打字。然后，您将感谢自己的这种完美主义。
将代码分成块，突出逻辑
不应将代码混在一起。值得考虑项目结构中的层次结构-将代码分为模块和块，将组件分为聪明和愚蠢的部分。与在一大堆中寻找这种逻辑的粒子相比，维护和开发这样的结构更为方便，特别是如果这些粒子相互连接。也许此建议不仅适用于前端。
在我们最近写过的有关大型表单的项目中，很明显可以看出该原理的实用性（https://habr.com/ru/company/maxilect/blog/511322/）。在该项目中，最初将块检查和这些块的可见性链接在一起。但是，当我们将所有字段的通讯收集到一个地方时，跟踪逻辑更改变得容易得多。最重要的是，我们能够在新的类似项目中重用代码。
项目的结构没有统一的标准-在这里您必须依靠自己的知识。有两种方法可能适用于许多项目：文件类型优先和功能优先。
要找到适合您的结构的起点，我们建议您参考文档。通常在此处介绍最佳做法。例如，React和Redux在其文档中提供了用于组织项目逻辑和文件结构的标准。如果有一定的经验，可以让您尝试解决特定项目的一些限制，则可以尝试并偏离标准，但是在大多数情况下，这不是必需的。并且，当然，不要忘记诸如SOLID这样的“基本”原则。关于如何在React中应用这些原理的不错的文章：https://habr.com/ru/company/ruvds/blog/428079/。关于清洁架构的好文章：https : //habr.com/ru/post/499078/。
关于React中代码库的组织和相关问题，有很多很好的资料，尽管已经很长时间没有更新了：https : //github.com/markerikson/react-redux-links/blob/master/project-structure.md。
制定编码约定
最初根据应用程序的开发路径来计划项目的架构师必须牢记某些模式。值得以项目护照的形式明确地表达它们，并以编写代码的规则作为补充，例如，在单独的模块中可以包含和不能包含的内容（通常，这是一个相当哲学的问题）。这样的“护照”将帮助开发人员提前确定如何编写，以便以后不再重写。这可以减少审查时间并有助于标准化编码方法，这在远程工作者或分布式团队正在处理项目时尤其有用。
坚持选择的范例
如果一开始您决定采用某种方法，例如原子网页设计，那么您不应在截止期限开始后立即放弃它。最初对范式的支持和放弃有时几乎比其完全消失更为糟糕。如果稍微“放松控制”，恢复秩序将非常困难-您将不得不花时间回到范式上。由于项目中已经形成了无形的混乱，因此您将无法快速“跳转”到另一个。
为了时间或其他因素而拒绝范式就像在十字路口换马。这很痛苦，不建议使用。但是，如果没有出路，则需要使用测试覆盖大多数应用程序。在这里，我们继续下一个技巧...
记住测试
对项目的测试并不仅限于此。他们必须工作。并且有必要在开始的第一阶段就将它们包含在项目中-一旦开发开始。否则，您可以在某个时候更改应用程序中的某些内容，然后脱离发布期限，恢复项目不同部分的性能，这些性能仅由手动测试覆盖。
在开始时让测试很小，根本不要检查任何东西。但是，随着功能的发展，开发它们要比花一周的时间偿还这种“技术债务”要好得多。就花费的时间而言，第一种方法更为有效。顺便说一句，许多人都清楚这一点，但仍将测试留给以后。
我还要提到集成和端到端测试。
每次修复错误或添加新功能时，都应运行集成测试，以确保所做的调整不会影响任何内容。在我们的项目中，我们尝试在上传工作结果时自动启动它们（我们通过挂钩实现了这一点）。测试尚未完成-您不应将更改上传到项目。首先，您需要修复所有问题。
但是集成测试仅涉及前端。端到端测试较慢，并且测试应用程序与所有相关项的交互。这些测试模拟用户操作。在这里，我们没有嘲笑任何东西，而是使用赛普拉斯真正地等待后端响应并检查项目整个生态系统中的交互（我们也可以推荐Puppeteer作为模拟对象）。
升级前要三思而后行，但不要放弃
在前端世界中，一切都发生了非常迅速的变化-框架版本相互替换，出现了更成功的库。值得让他们保持最新，但不要狂热。
就像我们上面提到的打字一样，任何更新都会消耗资源（即间接地花费金钱）。但是，有些事情使得无法完全退出更新。
首先，对最成功的库的支持有时也会终止。在这种情况下，您将不得不寻求更有前途的类似物。
其次，使用旧技术栈很少会激发开发人员的灵感。如果您意识到团队无法保持在尘土飞扬的主干网上，或者您发现过时的堆栈严重影响了新开发人员的涌入，则必须进行更新。
茶点应视为事物自然秩序的一部分。但是在更改库或更新框架之前，您应该始终进行一些研究。
新版本适合您吗？一般如何组织过渡？当然，您需要提前计划所有事情。
如果项目没有测试，则更新非常困难。即使是很小的日期库也可以覆盖项目的许多不同部分，对其进行更新将导致全面的回归测试。随着项目的发展，仅在军械库中进行手动测试就不可能高效地进行。
你现在过得好吗
衡量项目开发效率的标准可以是开发新功能所花费的时间与错误所花费的时间之比。根据方法的不同，此指标可能会有所不同，因此我们将不承诺设定“目标”水平。您自己可以比较任何转换前后的情况。
除了诸如“开发人员对项目的满意度”之类的非数字特征外，还有一个指标，例如新人加入该项目的时间。它是通过文档，测试和编码约定清楚描述项目的良好程度的一个特征。
请记住，最好留下比以前更好的代码。不要产生技术债务，否则会阻碍以后的项目开发。
也许您有自己的秘诀？留下评论！
PS：我们在Runet上的多个站点上发表了文章。订阅我们在VK，FB，Instagram或Telegram频道上的页面，以了解我们的所有出版物以及Maxilect的其他新闻。
PPS最近举行的Playhouse竞赛的标题图片。