Рефакторинг — це завжди дорого і довго. Принаймні так вважає бізнес. Але з появою ШІ-агентів та правильних інструментів статаналізу правила гри змінилися.
У своїй статті Андрій ділиться планом виживання для PHP-розробників: як продати рефакторинг бізнесу через «здешевлення підтримки», чому магія в коді — це зло, і як її випалити.
Андрій, Data Engineering Lead у HOLYWATER, ділиться чотирирічним досвідом побудови data-платформи. У статті — про те, як архітектура та неймінг замінюють документацію, та що робити з питанням стійкості пайплайнів й подоланням legacy-складнощів.
Автор із понад 30-річним досвідом в ІТ ділиться реальними кейсами з посилення безпеки великого легасі-застосунку під час переходу на мікросервісну архітектуру. У статті — приклади вразливостей, фікси та інтеграція Snyk і SonarQube у CI/CD.
Програмування — це коли ти розв’язуєш одну проблему і створюєш дві нові. Так починається блог Architect Руслана, в якому він ділиться ефективним способом позбавлення від легасі-коду.
Front-end розробник Дмитро Ханджанов продовжує ділиться досвідом рефакторингу проєктів. У цій статті він розглядає основні етапи процесу: від формулювання ідеї до продажу її менеджменту, створення технічного дизайну та перенесення функціоналу на нову архітектуру.
Назар Струк, Back-end розробник, описує чотири стратегії модернізації легасі-коду. Він пропонує практичні рекомендації до кожного зі сценаріїв, а також пояснює, який з них вважає найкращим та застосовує у власній роботі.
Сергій, iOS Developer, ділиться досвідом оптимізації роботи з відео у застосунку для соціальних мереж. Він розповідає про використання AVFoundation, асинхронне завантаження ресурсів, а також впровадження AsyncDisplayKit для покращення продуктивності при роботі з UICollectionView.
Дмитро Ханджанов, фронтенд-розробник з майже 10-річним досвідом, розглядає рефакторинг проєктів та проблеми легасі-коду. Він пропонує структурування архітектури, розподіл на шари та архітектурні патерни для покращення тестованості, підтримуваності й гнучкості.
Вадим Зубков розповідає, як ефективна комунікація між бізнесом і розробниками програмного забезпечення підвищує якість розробки. Він наводить приклади з власного досвіду та показує, як правильні рішення на початку проєкту, такі як правильна архітектура та використання універсальних компонентів, можуть суттєво зменшити проблеми в майбутньому.
Олексій Мельниченко ділиться своїм «болем» стосовно того, з чим йому доводиться працювати, а саме: легасі-кодом. Такий код часто вимагає більше часу на розуміння та виправлення, а також на внесення будь-яких нововведень. Тож ця стаття буде корисною для тих, хто стикається з подібними викликами.
За последние годы работать со светлой и темной темой приходится во всем: IDE, в браузере, на десктопе, часто даже на мобильных устройствах. В этой статье Павел Румянцев, Front-end Architect в Itransition с более 8 годами опыта во фронтенде, разбирает различные варианты того, как предоставить пользователю возможность выбирать различные темы и настраивать их под себя.
Дарья Козленко, Project Manager в NIX, рассказывает об опыте миграции старой legacy-системы на новую платформу. С какими проблемами столкнулась её команда, как их решали и как отработали навык работы с ожиданиями клиента в условиях неопределенности — в статье.
Материал будет полезен PM, BA, Tech Leads и другим специалистов, которые в той или иной мере примеряют на себя роль РМ’а.
Александр Рябцев, Back-end Lead в Django Stars, пишет о необходимых обновлениях кода и как их сделать так, чтобы не влиять на функциональность приложения. Это особенно важно в финтехе, поскольку технологии и навыки пользователей продолжают развиваться. И по мере того, как это происходит, пользователи становятся более требовательными и хотят больше функций, таких как лучшая безопасность или возможность проводить платежи онлайн.
В аутсорсе вы непременно столкнетесь с legacy-проектами. Эта статья поможет начинающему РМ’у понять, на что обратить внимание, как успешно стартовать, поддерживать и сдать legacy-проект.
Про микросервисную архитектуру и переход на нее говорят много, но редко упоминают о том, что проекты приходят к этому после многих лет развития как монолиты. Чтобы поменять архитектуру живого решения, надо пройти через несколько этапов.
Автор работал с разными проектами — и с полноценным multitenancy service-oriented REST architecture в Oracle, и с огромным монолитом, в репозитории которого были коммиты за десять лет.
Ця стаття — про те, як зробити процес передачі/отримання проєкту легким і навіть приємним. Стаття буде корисна молодим командам, які ще не пройшли всі перешкоди на своєму шляху, або лідерам команд, які тільки опановують цю роль.
Эта статья — попытка обобщения многолетнего опыта знакомства с legacy-системами в виде набора подходов и практических советов. Примеры буду приводить из собственного опыта — в частности, работы с унаследованной Java-системой.
Коментарі