通常，应用程序是通过许多小的改进来开发的，但是有时会在许多细节中构建出完整的图片，而实现这些细节需要进行高质量的大规模更改。 在这里，仅一个好主意是不够的。 问题的组织和技术组成部分同样重要。 如何在工作系统中准备和实施体系结构更改？ 我们
想谈谈全局重构，提高系统性能，优化代码，使用数据库的方法以及许多其他事情。
节目和演讲者：Wrike的Alexander Kolesnikov-24/7产品的出色重构
伟大的重构是不可能在一夜之间甚至短距离完成的。 有时需要四分之一甚至几个工作。 大型重构的问题在于，尽管有些人尝试清理，而另一些人继续更改代码，并且乌龟可能根本没有时间赶上阿喀琉斯。 要实施大型重构，您必须能够自动确定工作计划。 这样一来，就有可能在测试级别禁止使用旧方法来组织代码。 因此，将确定必要的工作量，并且有可能在专门团队或整个开发部门的帮助下结清剩余的技术债务。
例如：Hibernate→MyBatis，Struts→Web.fw，Domain.fw，分片，帐户分离，API重构，加密。 计划：QueryEngine，混合基础结构，多个数据中心，收件箱。
NEXIGN的Philippe Delgyado，“不可思议的路径：即时更改方法，使用没有ORM的数据库等”。
我将谈论来自最近项目的几种非标准实践，这些实践被证明是成功和有用的。
首先，我将向您介绍为项目的不同阶段选择不同的开发方法的经验，为什么需要“方法重构”以及如何使方法的变化或多或少地轻松。
然后，我将描述在不使用ORM且不使用复杂查询的情况下使用数据库中的复杂结构的方案，该方案甚至可以极大地简化所使用数据结构的最复杂重构。
好吧，最后，我将讨论各种各样的小事情-没有ELK的日志分析，经验教训的重构以及其他任何事情。
在故事中，我将尝试着重于实践的边界条件，使用中的陷阱和其他危险。
Yandex.Money的Vasily Sozykin，“微服务：统一几乎所有内容，但仅此而已”
我的经验表明，试图统一一家大公司的员工不会带来任何好处。 但是流程和技术的统一有助于构建出色的微服务系统。
关于我们如何进入完全去中心化的开发系统的报告，但仍然是一个团队，并建立了一个明智的社区。 我将通过示例来说明我们如何改进流程-这有助于扩大规模，但从字面意义上讲，它并不是一家企业。
如果您开始实施微服务，但是不确定所有事情，那么该报告可能是您的行动计划。 如果您已经生活在微服务世界中，那么我们将一起回顾过去的旅程，并谈论当前的问题。
→
注册