Как стать автором
Обновить

Комментарии 23

Спасибо, на злобу дня тема. А определение «сложно понять, легко сломать» — лучшее по ëмкости)))

Сотовый телефон в кармане — это легаси? Сломать легко, понять сложно.

НЛО прилетело и опубликовало эту надпись здесь

Замените телефон на любой shiny new гаджет, который легко сломать, а понять сложно.


Короче, утверждение "сложно понять" не катит, так же как и "легко сломать".

"Легаси" и "легаси код" — это разные вещи.


Например, "легаси" можно считать комплект проблем, которые решают люди. Допустим, у них была проблема с передачей файлов больше 1.44 мегабайта, и они изобрели свою оверлейную файловую систему с поддержкой оффлайн-томов и автоматическим переупорядочиванием.


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


… Шли годы, и пришло время потрогать это. Человек, который откроет код не стой стороны увидит АД с переупорядочиванием блочных устройств (!) при чтении файла.


Это — легаси. Вне зависимости от того, сколько там тестов и документации.


Легаси — это решение задач, которых нет, либо решение задач методами, которые больше не признаются за решение. А код, который реализует это решение — легаси код. И проблема не в "легаси коде", а в "легаси задачах", о которых никто даже слышать больше не хочет.


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

Вы хорошо это разделили

НЛО прилетело и опубликовало эту надпись здесь

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


В моем мире даже удаление базы данных — это рефакторинг

НЛО прилетело и опубликовало эту надпись здесь
ИМХО, рефакторинг это когда горел дедлайн и в код натыкали костылей, что бы все работало, а потом появилось время эти костыли выпилить и сделать все нормально. А удаление базы данных — это уже улучшение программы, пусть конечный пользователь этого и не видит, но внутренняя логика работы программы изменяется.
ИМХО, легаси — это например модули на COBOL в банке, со всеми вытекающими и COBOLa последствиями. А то что можно решить рефакторингом или добавлением тестов, это не совсем легаси, это просто не очень качественный код.
По коду всётаки всегда можно понять что он делает, главная проблема в объёме этого кода, и тут уже не важно покрыт он тестами или нет.

Если вы всегда можете понять, что он делает по коду, то вы, сюрприз, круче, чем компьютер. Потому что в рамках computer science, по данным и коду невозможно сказать, что он делает (в общем случае), потому что задача остановки (и эквивалентные ей) решены быть не могут.


С практической точки зрения, вот вам чуть-чуть питона, enjoy.


def business_dispatcher(*args, **kwargs):
   for a in args:
      for k,v in kwargs:
          yield from a(k)(v)

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

Поскольку ничего не поняли, начинайте отсюда. https://en.wikipedia.org/wiki/Halting_problem


Желательно, не пропуская доказательство.

Был у меня давным давно, в далёкой галактике, проект.

Десктопное приложение, точнее, чудовищный рой из запускающих друг друга процессов, рисующих в окно главной программы. Написано на смеси .net, C/C++ и древнего языка TFM с использованием между делом COM. Всё это работало с локальной базой данных древнего производителя, обращалось по сети в кучу мест, ходило в безумное количество файловых шар в сети и запускало-нуждалось в куче внешних компонентов.

Задача: заменить локальную базу данных на центральный сервис.
Решение (принимал менеджмент, не я). Я пришёл выполнять.

Поскольку мы в принципе не можем проанализировать, понять и переработать весь этот код и не должны его сломать, а запросы в бд в коде везде, лезут из всех компонентов, то был написан REST-сервис, принимающий на вход sql-запросы древней базы данных и транслирующий этот диалект в T-SQL. На стороне же клиентов была написана на c++ shim-dll, имитирующая интерфейс бинарной 3rd party библиотеки для доступа к старинной базе. Осложнялось всё это тем, что древний производитель базы в своё время принципиально не документировал эту библиотеку. Вместо этого предложил некий скриптованный вариант C, в котором условные вызовы запросов проходили через специальный компилятор, который наружу выдавал C, где эти запросы были заменены на серии вызовов методов этой бинарной dll, не всегда тривиальных. Например, работа с курсорами, это куча вызовов разных методов и понятно, что библиотека хранит в памяти состояние. Догадаться, что там делается, можно, мы догадались, но официального подтверждения и гарантий работы нет и в принципе не будет, не ваше собачье дело это понимать, пишите скрипты.

Потом как-то девочка в проект пришла, IT-оптимизатор. Со взором горящим. Говорит, давайте покроем это всё тестами. Давай, милая — говорим. Только вот цена такого покрытия это цена полной переработки архитектуры. Чем мы бы и рады заняться, но начальство, понимая, что это человеко-годы работы сениоров, запрещает. Расстроилась и через месяц ушла.

Я что-то вывода не понял. Т.е. вы меняете систему опираясь на чутье? Что мешает фиксировать внешнее видимое поведение системы? Как вы копите знание про систему и ее поведение?


Тесты не пишутся за неделю, это часть процесса.

Ну тестеры-то есть, с некоторым ограниченным бизнес-знанием. Сидят, кнопки давят.

Про тесты я как бы немного в курсе :-)
Все эти тутуриалы как рефакторить лагаси код прекрасно выглядят на простых примерах, а когда откроешь старый Java класс, где в static блоках неявно грузится конфигурация из Oracle базы данных, тогда становится очень грустно.
Вся эта булева логика прекрасно выглядит на простых примерах, конъюнкция, дизъюнкция, инверсия, а как только откроешь схему какого-нибудь микропроцессора, тогда становится очень грустно.
Вся эта математика прекрасно выглядит на простых примерах, сложение, умножение, деление, а как только откроешь учебник по матанализу, тогда становится очень грустно.
Все эти языки программирования прекрасно выглядят на простых примерах, «hello world», консольный калькулятор, вычисление факториала через рекурсию, а как только встает реальная задача, тогда становится очень грустно.

Всё очень грустно.
Хуже всего когда тесты пишутся для галочки, только для того, что-бы увеличить покрытие. Открываешь такой проект, смотришь тесты — радуешься, их просто огромное количество, все классно, разобраться будет просто!
Начинаешь разбираться, а оказывается что тесты там по факту проверяют сколько и в каком порядке модули дергают вызовы из других модулей. Понимания эти тесты не добавляют, надежности так-же, зато работы добавляют — любое изменение внутренней логики работы приходится отражать в этих тестах, при том что именно «что делает код» никак не проверяется, проверяется «как код это делает», что в общем-то и не особо ценно.

Согласен, «как» код это делает я и в коде вижу, важнее понять зачем и для какой случая. Я встречал термин «тавтология» теста, по нему можно нагуглить

Как аппаратчик, я тоже встречаю очень часто слово legacy в англоязычной документации. Для себя я перевожу его как что-то «устаревшее, архаичное». Ну, типа, на всякий случай, шнурок для слива в вашем умном туалете. Недавно я написал полезную для компании программу и, почитав сейчас комментарии к статье, понял, что написал сразу легаси код. Никто из профи-программеров в компании так и не может понять написанного, про рефакторинг и разговора нет. Хотя тесты были еще до рождения кода. Наверное, это потому, что написан код на самом простом Си. Архаизм, другими словами :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий