你好 最近，我为学生们做了一份报告 ，介绍通过进行现代Web开发可以填补哪些障碍。 我们在开发过程中做出的各种决定如何相关，技术的选择如何影响团队的规模，团队的规模如何影响测试的方法，测试的方法如何与整个公司的结构相关....

事实证明，这就像是一项具有分布式选择的任务：从哪种编程语言中选择哪种语言，以及向谁雇用最好的团队来打造有史以来最有用的产品。 我建议您阅读这篇文章，选择您的选项，完成任务并讨论痛苦的事情。

upd-向kat添加了一些文本。

从构思到原型

假设我的朋友瓦莱拉（Valera）和我决定创业。 Uber for X或类似的东西。 聚集在酒吧里，讨论了这个想法，很酷的话题。 必须做。 三个月没睡觉，没吃饭，没离开屋子。 发达。 他们开始意识到没有人需要它。

悲伤 让我们再试一次。 这次我们研究了市场，研究了用户的需求，哪些问题。 我们很快在两个晚上免费在膝盖上完全制作了某种原型。 原型起飞了。 酷，继续前进。

选择技术

现在，我们可以从原型中提取大型应用程序并进行开发。 但是为此，我们需要采取更认真的方法来选择将要使用的技术。

语言能力

为了。 要写什么语言？ 您可以使用时髦的功能：Haskell，Erlang，Lisp（在70多岁的祖父中非常时髦）。 或另一个很酷的杀手级JS，它很酷，已编译为JS，具有所有必要的功能。 但是最有可能的是，我们将在一年内没有人要雇用，因为下一个杀手级JS不会起飞，并且必须重新学习或重写项目。

尝试第二。 您可以按时间检查一些东西。 例如，PHP。 这是一门好语言，有时会流行起来，它有缺点，但是很容易在上面做业务逻辑，它足够快，扩展性好，您可以随时随地雇用员工。 但是他不是很有生产力。 因此，就像Facebook或VK一样，我们需要大量的资源或编写我们自己的编译器。

还有更多选择吗？ 您可以选择Perl，但是昨天没有人可以雇用。 还有吗
爪哇 Java是规范。 从我的主观观点来看，它不是一种语言，但是JVM是一台出色的虚拟机，一切正常，运行速度很快，但仍需要大量硬件。 而且，当我们用Java编写策略工厂的抽象生成器时，用户没有选择功能，而是转向竞争对手。

好了，我们还有Python。 原则上，一切都很好。 但是我们使用Python运行该应用程序，它使用56的一个内核，否则...一切正常。 或者，您可以采用一些现代的东西：Go，Rust等。 但是它们太低级了，我们只是做了很长时间的功能...我们仍然必须选择某种语言。 最后让它成为JS，下来吧。

资料库

基地 没有文档库的JS-钱花了。 文档库具有其优势。 它们使我们能够快速开发原型，而不用反复研究该计划和来回香肠数据。 有很多优点，只有一个：数据中的稀饭。 当我们有十个，二十个或四十个集合而不是三个集合时，如果我们尝试在没有计划的情况下从它们中粘贴好东西和易于消化的东西，那么变得越来越困难。 再次，我们做了很长一段时间的功能。

好的，让我们建立一个关系基础。 MySQL，PostgreSQL或Oracle（如果您有足够的钱）。 使用关系数据库，您有一天可以上班，并在事务和存储中陷入困境。 我们的项目不一定会发生这种情况。 但是，如果发生这种情况，那么将无法测试这些复杂的逻辑。 即使突然达到了托管数据库的大型金牌服务器的垂直限制，也很难将它们分开。 我们做功能很久了。

知道了 他们采取了一些基础措施，ORM紧紧抓住它，以使从一种SQL迁移到另一种SQL更容易。 有一天（破坏者：永不）。

建筑学

采用哪种架构？ Habré上的人写道微服务很棒。 Oleg Bunin说：“采用微服务”。

如果您从微服务开始，那么边界的错误率将达到百分之八十，因为它们没有充分考虑领域模型，并且对切入何处以及切忌在何处知之甚少。 另外，它们都采用微服务，在整个集群中批量部署它们，一个月后出现了一个问题：“我现在如何测试所有这些？” 服务已在生产中运行，但我们不对其进行测试。 使用熟悉的方法（测试金字塔，手动集成测试，端到端测试），很难测试微服务。 因此，我们一直在做功能。

好吧，让我们猛击巨石。 这是创业的正确想法。 您可以与一个巨大的整体生活很长时间，并且没有任何问题。 但是，如果我们决定扩大团队规模，那么我们必须谨慎。 整体缩放正常，而开发人员分别为20、30、50。此外，功能交付的速度成倍下降，并且我们失去了用户。

从哪里开始项目？

所有这些都需要在某个地方启动。 2018年，在云中执行此操作的最合乎逻辑的选择。 不要在云端运行它-男孩们会笑。 但是，首先，存在联邦法律152，该法律极大地限制了可以托管的云提供商的选择。 其次，很容易意外地向您在Github上的Amazon帐户提交私钥，然后肯定有人会花光您的所有钱。 如果这没有发生，那么在某些时候云收费将使您破产。

您可以租用数据中心。 也许一开始资源利用率不是很高，但是从长远来看，它可能比在云中托管便宜。 但是这里我们需要支持它的人。 以我的经验，那些喜欢它并且知道如何做的人并不真正喜欢与其他人交流，因此他们是在部门中组织的。 而且部门是分裂主义。 我的意思是，与管理员团队交流经验会更容易，但是将来这可能会无法很好地工作。 在同步处理其他同事的任务时，会有一些问题。 其他专家将不知道支持我们数据中心的部门内部正在发生什么。
总的来说，分离主义不适合我们。 从逻辑上讲，我们转向招募团队的问题。

团队

发展历程

假设我们确定了语言，数据库以及在何处托管项目。 现在该招募团队了。 您可以带一些很酷的人来解决所有问题：百分百的开发人员，后端忍者。 也许会搭便车。 但实际上，受邀的明星很可能会：

• 有毒的家伙不会做任何事情，并在团队中造成不良气氛，
• 或理想主义者一点一点地建立起无懈可击的架构，将ORM置于您无需改变的基础之上...

最后...是的，我们已经进行了很长一段时间的功能。 另一种选择是让普通的女孩和男孩只写代码，做得很好。 但是，如果您聘用了许多经验丰富，背景不同的开发人员，他们可以以不同的风格编写代码，以不同的方式做事，并且在团队规模足够大的情况下，每个人都会局促不安，每个人在彼此的pull-quest中都会花括号。 这不是很有效。 如何解决呢？ 老板可以阅读所有代码。 我可以阅读所有拉动任务，然后我的朋友和联合创始人Founder Valera将第二次重新阅读（以防万一，您永远都不会知道）。 显然，这无法扩展，所有功能都在缓慢制造。

一个更正确的选择是为公司定义代码样式。 对于许多语言，它已经存在，您可以简单地遵循它。 或者，如果有人真的想要，您可以拿一个现成的，然后将其拉起一点，然后看一下拉取任务，说花括号不存在，根据代码样式，花括号应该在那里。 您不能用这样的说法来争论，但实际上，它并没有比以前的版本好多少，无论如何我们正在缓慢地开发功能。 所有现代语言的正确选项是自动检查。

好啦 我们给开发人员打了分，无花果代码。 但是我们开始在生产中发布功能，我们需要以某种方式确保在没有错误的情况下滚动它们，并且一切都不会消失。

质量保证

可以说，我们不需要质量检查专家。 许多这样做，有时可行。 但并非所有开发人员都喜欢编写测试。 他们可以理解。 最好激励他们编写测试，但是现实是残酷的：单元测试不能捕获所有错误。 而且，如果某些开发人员不喜欢编写测试并且仍然开始编写测试，那么很可能将是单元测试。

此外，还有一些方法可以最大程度地减少两次故障之间的平均时间而不是平均恢复时间。 两次失败之间的平均时间是质量检查专家说：“我们不会发布，我的天赋不好，会有错误，让我们在两周内推出。” 恢复的平均时间是当您滚动某件东西时，您会立即根据度量标准发现某件东西已损坏，两分钟后，所有内容都被还原，修复并且一切正常。 但是，为了在两分钟内回滚该项目，您需要使用正常的指标来覆盖所有内容，但这并不总是琐碎的。 而且，如果指标处于令人遗憾的状态，并且我们发布了一个错误的版本，那么在所有用户将我们留给竞争对手之后，我们才能找到答案。

另一种选择：仍然设置质量检查部门。 您还记得：该部门不是很好，这是分裂主义，不适合我们。 分离主义可以在跨职能团队的帮助下解决。 是的，他们解决了我们的管理员分开坐的问题，测试人员分开了。

但是它们会带来其他问题。 随着跨职能团队的开发人员，测试人员和所有其他成员开始在团队内部进行更多的交流并解决以前的问题时，他们在工作中与同事的交流减少了：其他后台人员和测试人员开始重新发明轮子，并行地做同样的事情，团队之间的隔离。 锥子用肥皂：曾经有一种分裂，后来又变成了分裂。

如何解决呢？ 与爱好小组的同事进行沟通。 在某个地方被称为行会，在某个地方是社区。 如果我们通过跨职能团队扩大团队规模，以使他们不会变得自成体系，我们只会组织一群后端，功能语言，安全性的粉丝...

总结

实际上，并非一切都那么糟糕。 您可以找到解决任何情况的方法，找到解决方案。 可能不理想，但最适合这种情况，问题最少。 妥协总是可能的。

但是-所有这些都很有趣。 解决某人已经解决的问题很有趣；解决新问题更有趣。 分享知识很有趣。