Legacy: что нужно знать о работе с чужим кодом

У вас бывало так, что вы смотрите на чужой код и не знаете, с чего начать? В этом лабиринте чужих решений не придет на помощь и нить Ариадны: полагайтесь только на свои силы. А мы подскажем 🙂

Пожалуй, первое правило звучит так:

«Если в коде что-то реализовано не так, как вы привыкли – это не значит, что оно реализовано неправильно.»

Каждый опытный программист найдет недостатки в чужом коде. Из этого может последовать решение переписать код «под себя», ведь можно сделать лучше. «Правильность» кода в этом случае понимается исключительно субъективно, исходя из собственного опыта.

Прежде чем приступить, подумайте, что вы пытаетесь сделать, и есть ли причины не делать этого. Используйте Итеративный подход, а главное помните: возможно, код, над которым вы работаете, написан командой в течение многих лет. Наверняка там исправлено много багов, и, скорее всего, это целостное решение, которое не пишется за неделю.

О рефакторинге есть не одна книга. Поэтому вторым советом будет обратиться к литературе, например, Working Effectively With Legacy Code.

Главная идея книги построена на тестах, которые помогают понять и улучшить систему. Книга организована по принципу «вопрос-ответ», помогает разобраться в сложном коде и решить проблемы.

Есть очень важный момент – уважение к чужому коду и коллегам, работавшим до вас. Сложно быть эффективным без соблюдения этого правила.

Legacy: что нужно знать о работе с чужим кодом

Легко критиковать чужую систему, но от этого она не станет понятней. Поэтому при вхождении в новый проект приложите максимум усилий к пониманию внутреннего устройства и заложенных знаний. Вам помогут официальные или собственные юнит-тесты. Задокументируйте все, что слышите от людей, связанных с проектом, анализируйте ссылки и документацию проекта, сверяйте с собственными результатами. Фундаментальные знания помогут понять сложную систему.

Привыкните к тому, что люди редко жертвуют временем ради того, что уже работает, и предпочитают сосредоточиться на новых тасках. Но в legacy часто нужен человек, который способен внести ясность. Решение этой проблемы может не входить в прямые обязанности действующих или бывших сотрудников. Так что «новичку» приходится разбираться самому: разворачивать среду разработки, искать повторяющиеся конфигурации, процессы, улучшать виртуальную среду или контейнеры, подключать внешние службы к локальной среде или использовать заглушки, проводить тесты.

Изучение системы может забрать недели или месяцы. Но безрезультатным это не будет. В итоге вы узнаете систему, поймете процессы и всё задокументируете.

Работа с legacy-кодом открывает большие перспективы. И не спешите углубляться в критические проблемы, которыми озадачены другие люди. Очищайте и документируйте код. Помните, люди рассказывают гораздо больше о том, как работает код, когда критикуют, чем когда вы спрашиваете напрямую.

Кончено, не обойдется без собственных ошибок в процессе, поэтому придется часто начинать заново.

Есть поставленные цели и задачи: их нельзя игнорировать. Учитывайте интересы бизнеса и вносите изменения, когда:

  • приняты правила того, как никто не должен делать;
  • есть негативное влияние на показатели бизнеса, такие как производительность, безопасность, etc.;
  • текущая система мешает бизнесу выйти на новый левел.

Умение правильно определять решения – тоже навык. Поэтому вместе с утверждением, приведенным в начале, спросите себя:

«Открою ли я новую возможность, которая была нереализуема до этого, и принесет ли это пользу кому-то, кроме меня?»

Если нет уверенного «Да», отложите изменения. Улучшение одного или нескольких показателей стоит немалых усилий.

Абстрагирование – это важный инструмент ООП наряду с полиморфизмом, наследованием и инкапсуляцией. Абстракция позволяет работать с объектами, не вдаваясь в подробности их реализации.

Но разработчики часто неверно полагают, что можно «спрятать» сложности кода за абстрактный слой. Это не так. Лучше мириться с явными сложностями существующей системы, чем выдумывать абстрактный уровень над этими сложностями.

Проблемы начинаются когда команда первых разработчиков становится недоступной. В этом случае невозможно овладеть теоретической базой в полной мере и, как следствие, выбрать правильные абстракции.

Правильный способ – упрощение существующего кода или рефакторинг.

Да, бывает откровенно плохой код.

Legacy: что нужно знать о работе с чужим кодом

Но нужно сперва разобраться.

Общение – важный навык. Без него тяжко разобраться в сложной системе. Поэтому, прежде чем проводить рефакторинг и тесты, спросите других разработчиков:

  • «Какой используется шаблон проектирования?»
  • «Как производятся тесты?»
  • «Каким образом разворачивается среда разработки?»
  • «Как получить доступ к данным?»
  • «Каким способом происходит миграция данных?»
  • «Как обеспечивается масштабирование, параллелизм, безопасность, аутентификация?»

Если разработчики недоступны, ищите ответы в коде.

Столкнулись с незнакомым паттерном? Ищите информацию о странных на первый взгляд наименованиях, встречающихся в коде.

А еще помните, что разработчики часто копируют код из интернета, и реализовывают идеи, которые изучили недавно (все этим грешат, верно? 🙂 ). Для подозрительных отрывков кода используйте поисковики.

Следуйте сценарию использования для анализа уровней приложения с помощью debugger’а. Возьмите на заметку непонятные фрагменты и набросайте диаграмму архитектуры.

Вы пропустили

AEGIS Algorithms Android Angular Apache Airflow Apache Druid Apache Flink Apache Spark API API Canvas AppSec Architecture Artificial Intelligence Astro Authentication Authorization AutoGPT AWS AWS Aurora AWS Boto3 AWS EC2 AWS Lambda Azure Babylon.js Backend bash Beautiful Soup Bento UI Big Data Binary Tree Browser API Bun Career Cassandra Charts ChatGPT Chrome Extension Clean Code CLI ClickHouse Coding Codux Combine Compose Computer Context Fusion Copilot Cosmo Route CProgramming cron Cryptography CSS CTF Cypress DALL-E Data Analysis Data science Database dbt dbt Cloud deno Design Design Patterns Detekt Development Distributed Systems Django Docker Docker Hub Drizzle DRY DuckDB Express FastAPI Flask Flutter For Beginners Front End Development Game Development GCN GCP Geospatial Git GitHub Actions GitHub Pages Gitlab GMS GoFr Golang Google Google Sheets Google Wire GPT-3 GPT3 Gradio Gradle Grafana Graphic Design GraphQL gRPC Guidance HMS Hotwire HTML Huawei HuggingFace IndexedDB InfoSec Interview iOS Jackknife Java JavaScript Jetpack Compose JSON Kafka Kotlin Kubernetes LangChain Laravel Linux LlaMA LLM localStorage Logging Machine Learning Magento Math Mermaid Micro Frontends Mobile Mobile App Development mondayDB MongoDB Mongoose MySQL Naming NestJS NET NetMock Networks NextJS NLP Node.js Nodejs NoSQL NPM OOP OpenAI OTP Pandas PDF PHP Playwright Plotly Polars PostgreSQL Prefect Productivity Programming Prometheus Puppeteer Pushover Python Pytorch Quarkus Rabbitmq RAG Ramda Raspberry Pi React React Native Reactor Redis REST API Revolut Riverpod RProgramming Ruby Ruby on Rails Rust Scalene SCDB ScyllaDB Selenium Servers Sklearn SLO SnowFlake Snowkase Software Architecture Software Development Solara Solid Spring Boot SQL SQLite Streamlit SudoLang Supabase Swift SwiftUI Tailwind CSS Taipy Terraform Testing Transformers TURN TypeScript Ubuntu UI Design Unix UX UX Design Vim Vite VSCode Vue Web Architecture Web Components Web Development Web Frameworks Web Scraping Web-разработка Webassembly Websocket Whisper Widgets WordPress YAML YouTube Zed Наука о данных Разное Тренды

Как исследовать и визуализировать данные МО для обнаружения объектов на изображениях