Я очень двояко отношусь к legacy-коду. Я встречал людей, которые согласны в нем копаться и разбираться. Встречал тех, кто готов изрыгать из себя нечистоты от одной мысли что надо будет разбираться. Лично мне важнее качество самого кода, а не авторство. Но сейчас я работаю на legacy-проекте и в наследство мне досталось столько восхитительных находок, что разбирая баги я одной рукой печатаю исправление, а другой – натачиваю штык на случай если встречу автора. Что же мне подготовил мой предшественник? Сейчас приведу несколько примеров.
Исходные данные – нам нужно передать юридические данные компании-заказчика и что хочет приобрести с фронтэнд части в API. Всё. Проще некуда. Инн/Кпп, Контактные данные, данные о покупке. Что может быть проще? Ну вот сейчас покажу. Нет предела полету творческой мысли.
Как ввести имя человека? Т.е. получить от клиента ФИО и передать в API. На стороне фронта клиент вводит раздельно фамилию, имя и отчество. А затем…SPA склеивает через пробел и передает в API. Но гений не одинок в своем роде – второй гений писал API. Так как имя расшифровывается как разбивка строки по пробелам. Первый гений не в курсе что существуют люди без отчества, например корейцы, китайцы. И как ни странно – они тоже работают в нашей стране как индивидуальные предприниматели или руководители юридических лиц. А второй гений не в курсе что существуют люди с парной фамилией. Итог? Имя человека от таких склеек и разбивок без проблем будет испорчено, а вы будете думать – отчество «Иванович» с явно азиатским именем это баг или правда такое отчество.
Как валидировать данные? Снова вопрос капитана очевидность? Как оказалось, нет. Можно валидировать атрибутами модели. Можно писать классы валидаторы. Можно писать методы валидации. Можно просто в методе-обработчике запроса проверить нужные поля... А можно… применить все методы сразу в одном запросе. Причем некоторые данные проверить более 1 раза. Т.е. вы чуть-чуть изменили логику валидации, а задача из тестирования возвращается с пометкой «переоткрыта». Оказывается надо искать другие места, где делается тоже самое.
Как описать модель запроса? Представьте, что вы пишете мобильное приложение и вам дали API сервиса. Для выполнения запроса вам нужно передать около 20 полей. Что сделаете? Будете передавать? Правильно, главное не забыть авторизацию передать. Это позиция вполне здорового человека. Только автор API не очень здоровый человек. Он берет эту модель и переписывает переданные данные полями из контекста текущего пользователя. Пусть будет сюрприз для клиента API.
Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте. Думаете это шутка? Нет. Это не шутка. Это предупреждение. Для автора приведенных примеров это просто шутка, а я теперь увеличиваю продолжительность любой дурацкой работы в 2-3 раза. Просвещенный читатель скажет что «нужно всё переписать», «зарефакторить» и прочее. Да, нужно. И на это нужно время. В 2-3 раза больше чем продолжительность задачи. Потому что вместо реализации задачи – я буду заниматься рефакторингом. А изначальный автор продолжит творить.