Souvent, les applications sont développées grâce à de nombreuses petites améliorations, mais il arrive un moment où de nombreux détails sont intégrés dans une image complète, dont la mise en œuvre nécessite des modifications de grande qualité et à grande échelle. Et ici, une seule bonne idée ne suffit pas. Les composantes organisationnelles et techniques de la question n'en sont pas moins importantes. Comment préparer et mettre en œuvre des changements architecturaux dans un système fonctionnel? Nous
voulons parler du refactoring global, de l'amélioration des performances du système, de l'optimisation du code, des approches de travail avec les bases de données et bien d'autres choses.
Programme et conférenciers:Alexander Kolesnikov, Wrike - Super refactoring dans un produit 24/7
Un refactoring efficace est quelque chose qui ne peut pas être fait du jour au lendemain et même au sprint. Parfois, cela prend un quart ou même quelques-uns pour fonctionner. Le problème avec une refactorisation importante est que tandis que certains essaient de nettoyer, d'autres continuent de changer le code, et la tortue peut tout simplement ne jamais avoir le temps de rattraper Achille. Pour implémenter un refactoring important, vous devez pouvoir déterminer automatiquement le plan de travail. Ensuite, à un moment donné, il sera possible d'interdire l'ancienne approche de l'organisation du code au niveau du test. Ainsi, le montant de l'effort nécessaire sera fixe, et il sera possible de clôturer la dette technique restante avec l'aide d'une équipe dédiée ou de l'ensemble du service développement.
Exemples: Hibernate → MyBatis, Struts → Web.fw, Domain.fw, Sharding, Séparation de compte, Refactorisation API, Cryptage. Plans: QueryEngine, Hybrid-Infrastructure, Multiple-DataCenters, Inbox.
Philippe Delgyado, NEXIGN, «Chemins impensables: changer de méthodologie à la volée, travailler avec des bases de données sans ORM, etc.»
Je parlerai de plusieurs pratiques non standard de projets récents (n) qui se sont avérées efficaces et utiles.
Au début, je vais vous parler de l'expérience de la sélection de différentes méthodologies de développement pour les différentes étapes du projet, pourquoi avez-vous besoin d'une «refactorisation de méthodologie» et comment rendre le changement de méthodologie plus ou moins indolore.
Ensuite, je décrirai le schéma de travail avec des structures complexes dans la base de données sans utiliser ORM et sans requêtes complexes, ce qui facilite considérablement le refactoring le plus complexe des structures de données utilisées.
Eh bien, à la fin, je parlerai de toutes sortes de petites choses - analyse des journaux sans ELK, leçons apprises, refactoring et tout autre.
Dans l'histoire, je vais essayer de me concentrer sur les conditions aux limites pour l'application des pratiques, les pièges en usage et d'autres dangers.
Vasily Sozykin, Yandex.Money «Microservices: unifier presque tout, mais pas plus»
Mon expérience a montré que les tentatives d'unification des personnes dans une grande entreprise ne mènent à rien de bon. Mais l'unification des processus et des technologies aide à construire des systèmes de microservices sympas.
Un rapport sur la façon dont nous sommes passés à un système de développement entièrement décentralisé, mais qui est resté une équipe et a élevé une communauté sensible. Je vais illustrer comment nous améliorons les processus à l'aide d'exemples - cela aide à se développer, mais pas à devenir une entreprise dans le mauvais sens du terme.
Si vous avez commencé à implémenter des microservices, mais n'êtes pas sûr de tout, alors le rapport peut être votre plan d'action. Et si vous vivez déjà dans un monde de microservices - ensemble, nous rappelons le chemin parcouru et parlons des problèmes actuels.
→
Inscription