Как работать с легаси кодом
Перейти к содержимому

Как работать с легаси кодом

  • автор:

Эффективная работа с легаси-кодом. Майкл Физерс

Приёмы из этой книги мне помогают в работе, поэтому я решил составить по ней конспект. Примеры в ней написаны на Джаве и С++, поэтому не всё получилось перевести на JS. Я постарался вытянуть наиболее важное, но советую прочесть книгу и самим. Теперь к делу.

Физерс определяет легаси-код, как код без тестов. В таком коде невозможно предсказать, сделает ли какое-то изменение этот код лучше или хуже.

Глава 1. Изменение софта

Менять код нужно, чтобы:

  • добавить фичу;
  • пофиксить баг;
  • улучшить дизайн кода;
  • оптимизировать использование ресурсов.

В программе самое важное — её поведение. Пользователи любят, когда мы добавляем новое, и не любят, когда мы меняем старое. При добавлении нового поведения мы неизбежно меняем старое.

// до изменения class Player { addPlaylist(name, tracks) { // . } } // после class Player { addPlaylist(name, tracks) { // . } deletePlaylist(name) { // . } } 

Пока новый метод нигде не вызывается, поведение не меняется. Чтобы это поведение добавить, мы выводим кнопку на экране. Из-за этого интерфейс отрисовывается на долю секунды дольше. Это незаметно, но поведение поменялось.

Улучшение дизайна, рефакторинг, отличается тем, что не меняет поведение программы. Их цель — сделать код более читаемым, поддерживаемым и приятным.

Оптимизация похожа на рефакторинг, только рефакторим мы уже использование ресурсов, а не сам код.

Сохранить поведение неизменным трудно. Каждое изменение кода несёт риск изменения поведения. Чтобы смягчить риск, перед изменениями задавать себе три вопроса:

  • что надо поменять?
  • как узнать, что мы внесли изменения правильно?
  • как узнать, что мы не сломали остальное?

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

Глава 2. Работать на обратную связь

Вносить изменения в код можно двумя путями: «запушить и молиться» и «покрыть тестами и менять». Смысл второго подхода в том, чтобы получать обратную связь постоянно и как можно быстрее. Тесты дают обратную связь, говоря, как наши изменения ломают поведение программы.

  • быстрый;
  • помогает найти проблему быстро;
  • не имеет внешних зависимостей.

Рефакторинг легаси-кода следует начинать с покрытия его тестами. Проблема в том, что часто у легаси куча зависимостей, из-за которых его трудно тестировать. Возникает дилемма: чтобы изменить код, надо иметь тесты к нему, а чтобы написать к нему тесты, его надо поменять.

Алгоритм изменения легаси-кода:

  • найти точки изменения;
  • найти точки тестирования;
  • разорвать зависимости;
  • написать тесты;
  • сделать изменения и отрефакторить.

Глава 3. Распознавание и разделение

Для тестирования нужно разрывать зависимости в коде по двум причинам:

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

Класс NetworkBridge получает список узлов, каждый из которых открывает сетевое соединение и общается с другими узлами:

class NetworkBridge { constructor(endpoints) { // . } formRouting(sourceId, destId) { // . } } 

Как его тестировать? Если он связан с железом, можем ли мы себе позволить на каждый тест нагружать оборудование? Можем ли создать тестовый кластер? Есть ли на это ресурсы и время? Такие проблемы возникают, когда мы не понимаем, как выделить нужную часть и тестировать её изолированно. Здесь могут помочь фиктивные объекты.

Фиктивные объекты олицетворяют какой-либо класс во время тестирования. Например, у нас есть класс Sale , который сканирует штрих-коды, и выводит сообщения на экран устройства через класс Display :

class Sale { constructor(display) { this._display = display; } scan(barcode) { // сканирует // . // выводит сообщение this._display.showMessage('hello world'); } } class Display { showMessage(msg) { // . } } const display = new Display(); const sale = new Sale(display); 

Чтобы не зависеть от конкретного оборудования, мы можем написать поддельный класс FakeDisplay :

class FakeDisplay { // вместо вывода на экран, будем запоминать сообщение // это метод, который имитирует настоящий метод класса Display showMessage(msg) { this.lastLine = msg; } // и потом выводить его по требованию // это доп. метод, который нужен именно в тестах getLastLine() { return this.lastLine; } } 

В тесте мы можем подменить класс, работающий с конкретным оборудованием на поддельный:

it('Выводит название товара на экран', () => { const fakeDisplay = new FakeDisplay(); const saleTest = new Sale(fakeDisplay); saleTest.scan('1'); expect(fakeDisplay.getLastLine).toEqual('Молоко'); }); 

Этот тест не упадёт, если не работает какая-то часть в настоящем классе Display . Но мы тестируем класс Sale , а не Display , поэтому конкретно в этом тесте это не важно.

Глава 4. Швы

Шов — место в программе, где можно изменить её поведение, без редактирования кода в этом месте. Рабочий код должен быть одинаков и в продакшене и в тестах. Швы помогают разорвать зависимости и оттестировать код, без его изменения.

Чтобы использовать шов, нужно определиться с разрешающей точкой — местом, где вы решаете заменить одно поведение на другое.

Удобнее всего в объектно-ориентированных языках использовать объектные швы, когда действие какого-то метода подменяется на другое. Например, при создании экземпляра класса в конструкторе.

Глава 5. Инструменты автоматизированного рефакторинга

Рефакторинг — упрощение или улучшение дизайна кода без изменения поведения. Есть среды разработки, которые предлагают автоматические инструменты для рефакторинга. Они помогают переименовывать переменные, удалять лишнее, выносить код в отдельные функции или классы.

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

// класс до рефакторинга class Example { alpha = 0; getValue() { this.alpha++; return 42; } doSomething() { let total = 0; const val = this.getValue(); for (let i = 0; i  5; i++) { total += val; } } } // после class Example { alpha = 0; getValue() { this.alpha++; return 42; } doSomething() { let total = 0; for (let i = 0; i  5; i++) { total += this.getValue(); } } } 

Лишняя переменная исчезла, но вместе с этим alpha++ вызвалось 5 раз вместо 1. Юнит-тесты помогут выявить это изменение.

В следующий раз

Поговорим об изменении кода, когда не хватает времени, добавлении фич, TDD и зависимостях.

Ссылки по теме

  • Юнит-тестирование
  • Фиктивные объекты: стабы, моки
  • Модель швов

Легаси-код

Легаси-код (от англ. legacy — наследие) — в самом широком смысле это код, который используется, помимо его автора, другим лицом. Чаще всего это происходит, когда он передается «по наследству» от одного разработчика другому. Легаси-код считается неотъемлемой частью любого процесса разработки, причем он может быть как источником проблем для разработчиков, так и единственным, что нормально работает в программном обеспечении.

Освойте профессию
«Python-разработчик»

Python-разработчик

Освойте Python с нуля. Подготовим к трудоустройству: дадим много практики, реальные проекты для портфолио, поможем с резюме. Лучшие студенты пройдут стажировки в проектах компаний-партнеров.

картинка - 2023-03-14T190323.524

Python-разработчик

Освойте Python, самый популярный язык программирования

dffsdd (3)

Что такое legacy-код

Существует несколько определений легаси-кода, каждое из которых на самом деле описывает один из его аспектов:

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

Чтобы понять, что такое legacy в разработке, достаточно взглянуть на общую схему появления такого кода:

  • Команда разрабатывает многофункциональный и сложный продукт с большим количеством возможностей.
  • Некоторые (чаще всего используемые) функции этого продукта со временем оптимизируются разработчиками, а другие остаются в старом виде, поскольку они либо редко используются, либо хорошо работают в изначальном виде.
  • Со временем команда разработчиков, работающая над продуктом, меняется и в ней не остается людей, которые писали старый код.
  • Текущая команда не знает, почему именно так был написан старый код.
  • Эти участки кода сложны для изменения или разборки, так как остальной код уже написан иначе. И вот этот сложный для поддержки и анализа старый код и называется legacy.

К причинам появления легаси-кода можно отнести следующие:

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

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

Станьте разработчиком на Python и решайте самые разные задачи: от написания кода до автоматизации процессов

Достоинства легаси-кода

Работоспособность. Легаси-код уже проверен временем и доказал свою работоспособность. Он может быть надежным и стабильным, особенно если прошел множество тестирований и исправлений ошибок.

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

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

Недостатки легаси-кода

Сложность поддержки. Легаси-код часто не имеет хорошей документации или комментариев, что делает его сложным для понимания и поддержки. Разработчики, незнакомые с ним, могут тратить много времени на разбор и изучение его структуры и особенностей.

Ограниченные возможности. Легаси-код может быть написан на устаревших языках программирования или использовать устаревшие библиотеки. Это может ограничивать возможности расширения функциональности системы и препятствовать интеграции с новыми технологиями.

Риск ошибок и безопасности. Легаси-код, особенно если он не поддерживался и обновлялся в течение длительного времени, может содержать уязвимости и ошибки, которые могут представлять угрозу для безопасности системы.

Как работать с легаси-кодом

Работа с легаси-кодом может представлять определенную сложность для разработчика, но следующие рекомендации помогут справиться с этой задачей:

  • Осознать контекст. Перед тем как начать изменения, изучите код и разберитесь в его архитектуре и структуре. Понимание текущего функционала и основных проблем поможет вам определить, какие изменения необходимо внести и какие риски могут возникнуть.
  • Создать тесты. Прежде чем вносить изменения в легаси-код, создайте набор тестов, которые позволят вам проверить его работоспособность после внесенных корректировок. Тесты помогут избежать непредвиденных ошибок и подтвердить, что изменения не повлияли на работу системы.
  • Разделить код на модули. Если легаси-код слишком сложен для изменений в целом, попробуйте разбить его на отдельные блоки или компоненты. Это позволит вам работать с более маленькими и понятными частями, упрощая процесс изменений и обеспечивая более чистую архитектуру.
  • Постепенно вносить изменения. Вместо того чтобы пытаться переписать весь легаси-код сразу, начните с маленьких изменений. Поэтапное внедрение нового кода поможет контролировать риски и проверять работоспособность системы на каждом шаге.
  • Документировать изменения. Важно документировать все внесенные в легаси-код изменения, чтобы другие разработчики могли понять, что было изменено и почему. Это также поможет вам возвращаться к изменениям в будущем и понимать их влияние на систему.
  • Обратиться за помощью. Если вы столкнулись с особыми сложностями или не можете справиться со старым кодом самостоятельно, не стесняйтесь обратиться к коллегам или сообществу разработчиков за помощью и советами. Часто опыт других людей может быть очень полезным в работе с легаси-кодом.

Обязательно ли устранять или переписывать легаси-код

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

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

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

Что такое легаси в коде

Иногда программисты на вопрос, почему программа работает именно так, отвечают, что это «легаси» и исправить ничего нельзя. Разберёмся, что это значит, насколько это мешает разработке и что делают с легаси-кодом.

Что такое легаси

С английского legacy переводится как «наследие». Легаси-код — это код, который перешёл «по наследству» от предыдущих разработчиков. Чаще всего это происходит так:

  1. Команда делает продукт, внутри много разных возможностей.
  2. Часть функций со временем оптимизируется, а часть остаётся неизменной в виде старого кода, потому что и так работает.
  3. Некоторое время спустя в команде не остаётся тех, кто писал старый код.
  4. Текущая команда не знает, почему старый код написан именно так.
  5. В этих кусках сложно что-то поменять или разобраться, потому что всё остальное написано уже по-другому.
  6. Этот старый код, который сложно поддерживать и сложно разбираться — это и есть легаси.

�� Проще говоря, легаси — это код, про который говорят: «Это ещё Михалыч писал 8 лет назад для синхронизации с сервером, он работает, мы его не трогаем, потому что иначе всё сломается». При этом Михалыча в компании давно нет, документации тоже нет, и проще этот код не трогать совсем.

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

Откуда берётся легаси

Причин появления легаси может быть несколько:

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

Легаси — это не какое-то преступление, а часть жизни любой живой ИТ-компании. Рано или поздно у любого продукта появится легаси. И чем крупнее проект, тем больше его будет. Например, в исходном коде Windows 10 до сих пор остаются фрагменты кода, написанные ещё 20 лет назад для Windows 3.1.

Легаси — это плохо?

Легаси — это просто старый код, который нужно поддерживать наравне с новым. Если он работает — отлично, пусть живёт. Другое дело, что команде, например, было бы удобнее, чтобы код был написан не на старом фреймворке, а на новом, который знают все.

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

Что значит «поддерживать старый код»?

Например, в старом коде для запроса к серверу идёт сначала адрес, а потом номер запроса. Спустя 10 лет требования сервера изменились, поэтому сначала должен идти запрос, а потом уже адрес. Значит, нужно изменить порядок полей в коде.

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

Что делать с легаси-кодом

Если легаси-код работает и не требует вмешательства и поддержки — то можно пока ничего не делать, пусть работает. Будет время — перепишем на новый фреймворк, а если нет, то и так пока поработает.

А если нужно срочное вмешательство — пахнет бедой. Зовите менеджеров.

Курсы по программированию с нуля

Приходите к нам в ИТ. У нас есть удаленная работа, высокие зарплаты и удобное обучение в «Яндекс Практикуме». Старт бесплатно.

Курсы по программированию с нуля Курсы по программированию с нуля Курсы по программированию с нуля Курсы по программированию с нуля

Получите ИТ-профессию

В «Яндекс Практикуме» можно стать разработчиком, тестировщиком, аналитиком и менеджером цифровых продуктов. Первая часть обучения всегда бесплатная, чтобы попробовать и найти то, что вам по душе. Дальше — программы трудоустройства.

Советы по работе с легаси кодом в PHP

Сколько раз, приходя в новую компанию, вы получали в руки “большой комок грязи“, к которому каким-то образом нужно прикручивать новый функционал?

Без контроля версий.

Без какой-либо надежды на душевное равновесие в будущем.

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

Это вполне реальная и чересчур распространенная ситуация, но говорим мы о ней не так уж и часто (если только не нужно покритиковать ныне ушедшего автора, который об этом точно не узнает, чтобы защитить себя).

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

Советы по отладке

Помимо наличия подушки, в которую можно покричать, и обильного количества кофеина, что вообще можно посоветовать перед проведением хирургических операций одному из кошмаров Кроненберга?

Разбиение пополам (Half Splitting)

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

Пример А: База данных или код?

Допустим, у вас возникли проблемы с получением данных о клиентах. Это проблема проистекает из базы данных или из кода? Вы можете вставить SQL-запрос непосредственно в клиент MySQL, чтобы сразу понять, с чем конкретно связан проблема.

Пример Б: Здоровенный контроллер.

Допустим, у вас есть злополучный скрипт, который дает сбой. Когда-то давно мне приходилось работать с контроллер длиной в 45 000 строк. Нет, это не опечатка.

К тому же он был процедурным, прямо посреди MVC framework, если до этого вы еще не прониклись моей болью.

Я бы даже не пытался постигать такой монолит плохих практик. Я бы просто всандалил оператор die() или error_log() где-то около строки 22500 и посмотрел, присутствует ли еще ошибка.

Затем убедившись, что переменная сеанса все еще неверна или я получаю сообщение об ошибке, я бы продолжил в том же духе: поставил бы те же проверки в районе строки 11250. И так далее и тому подобное.

Это глупо, это примитивно. Но очень часто это самый быстрый способ отладить что-то, особенно если это процедурно написанный код.

Пользовательское приемочное тестирование (User Acceptance Testing)

Я понимаю, что это то, что обычно приходит на ум, когда вы создаете новое программное обеспечение, однако все-таки выслушайте меня.

Как я уже говорил о превратностях работы с “большим комом грязи”, тут невозможно быть слишком осторожным.

Хорошей практикой, которая стоит на страже моего душевного равновесия, является то, что я сразу буду уделять особое внимание одной или двум основным частям функционала. Тому, из-за чего мне могут позвонить в 2 часа ночи, если оно не работает. Хорошим примером в приложениях электронной коммерции является возможность купить продукт.

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

Это до боли легко и просто. Мне бы очень хотелось, чтобы вместо слепой веры в свою непогрешимость и тот факт, что у них не бывает синтаксических ошибок, это практиковали многие сторонние компании, с которыми я сотрудничал.

Последнее изменение файла

Вы когда-нибудь встречали самодельные системы контроля версий, которые выглядели бы следующим образом?

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

Берем все под личный контроль

В самом начале, пока вы только готовитесь к работе, можно предпринять несколько шагов, чтобы защитить себя.

Бэкапим все

“Все, что не сохранено, будет потеряно”

— экран завершения работы Nintendo Wii

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

Вам нужны бэкапы:

Иногда в кодовую базу может быть вмешано много мусора, например, adobe-файлы от дизайнера, фотографии в полном разрешении от фотографа и так далее.

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

Ограничиваем доступ

“Легче попросить прощения, чем получить разрешение” —

адмирал Грейс Хоппер

У кого еще есть доступ? Иногда на этот вопрос трудно найти ответ. Если вы сомневаетесь, то знайте, что проще попросить прощения, чем разрешения. Просто смените пароль и посмотрите, кто придет к вам. Вы также можете любезно поинтересоваться, к чему им особенно нужен доступ.

Я не могу сосчитать количество раз, когда на моей памяти производственный FTP-сервер использовался для хранения общих документов или архивов Outlook.

Если вы по какой-то причине не можете использовать службы обмена файлами, такие ​​​​как Dropbox или Google Drive, по крайней мере, создайте учетные записи FTP, которые ограничены выбранным каталогом. Хотя бы вы перестанете хранить PDF-файлы и шаблоны электронной почты в своей кодовой базе.

Контроль версий и локальная среда разработки

“Да, с помощью git легко отстрелить себе ногу, но также легко вернуться к предыдущей ноге и объединить ее с текущей ногой.”

— Джек Уильям Белл

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

Что хорошего в этих безнадежно устаревших кодовых базах, так это то, что они зачастую работают на очень простом стеке (Apache, PHP, MySQL).

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

Если в моем рабочем пространстве отсутствует какой-либо рабочий процесс, быстрой промежуточной мерой, которая может ускорить процесс, является использование одного из различных плагинов GIT-FTP (либо для GIT, он может даже подключаться к вашей IDE). Это делает исправление катастрофических ошибок еще быстрее.

И вместе с этим вы сможете даже уйти так, чтобы никто этого не заметил.

Заключительные размышления и рефакторинг

Я понимаю, что некоторых читателей, вероятно, настолько пробрало от удовольствия, что у них на клавиатуре появились пару свежих пятен от кофе.

Очевидно, что если у вас есть средства для замены старой системы или рефакторинга ее частей, то вы должны это сделать.

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

И, как всегда, не воспринимайте все близко к сердцу.

Перевод материала подготовлен в преддверии старта курса «PHP Developer. Professional».

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *