Technical mitap in Petersburg on September 13 - How to make big changes on the backend

Often, applications develop through many small improvements, but there comes a time when many particulars are built into a coherent picture, the implementation of which requires qualitative and large-scale changes. And here only one good idea is not enough. Equally important are the organizational and technical components of the issue. How to prepare and implement architectural changes in a working system? We want to talk about global refactoring, improving system performance, optimizing code, approaches to working with databases and many other things.



Program and speakers:



Alexander Kolesnikov, Wrike - Great refactoring in a 24/7 product

')





A great refactoring is what can not be done overnight or even for a sprint. Sometimes a job takes a quarter, or even a few. The problem of big refactoring is that while some try to restore order, others continue to change the code, and the tortoise may simply never have time to catch up with Achilles. To implement a large refactoring, you need to be able to automatically determine the work plan. Then, at a certain point, it will be possible to prohibit the old approach to code organization at the test level. Thus, the amount of effort required will be fixed, and it will be possible to close the remaining technical debt by using a dedicated team or the entire development department.



Examples: Hibernate → MyBatis, Struts → Web.fw, Domain.fw, Sharding, Account Separation, API Refactoring, Encryption. Plans: QueryEngine, Hybrid-Infrastructure, Multiple-DataCenters, Inbox.



Philippe Delgado, NEXIGN, “Non-trails: changing methodologies on the fly, working with a database without ORM, etc.”







I will talk about a few non-standard practices from recent projects that (p) have been successful and useful.



At the beginning I will talk about the experience of selecting different development methodologies for different stages of a project, why do we need a “method refactoring” and how to make the change of methodology more or less painless.



Then I will describe the scheme of working with complex structures in the database without using ORM and without complex queries, which makes even the most complex refactoring of the data structures used much easier.



Well, at the end I will talk about all sorts of little things - the analysis of logs without ELK, lessons learned refactoring and everything else.



In the story I will try to focus on the boundary conditions of the application of practices, pitfalls in use and other dangers.



Vasily Sozykin, Yandex.Money “Microservices: unify almost everything, but not more”







My experience has shown that attempts to unify people in a large company do not lead to anything good. But the unification of processes and technologies helps to build cool microservice systems.



A report on how we moved to a fully decentralized development system, but remained a team and raised an intelligent community. Using examples, I will show how we improve processes - it helps to expand, but not to become an enterprise in a bad sense of the word.

If you have started to implement microservices, but are not sure about everything, then the report can be your action plan. And if you already live in the microservice world - together we will recall the path traveled and talk about current issues.



→ Registration