Как программист, одной из основных проблем, с которыми вы столкнетесь на любом рабочем месте, является технический долг.
Технический долг — это медленное приобретение избыточного кода и бизнес-логики, которые не были выведены из эксплуатации или признаны устаревшими должным образом.
Одна из замечательных идей использования фреймворка MVC заключается в том, что компоненты легко заменяются без рефакторинга всей системы. Аккуратный код, который не является жестко связанным, означает, что мы должны иметь возможность быстро разрабатывать новые рабочие процессы и системы, не затрагивая другие.
Но что происходит, когда технология кардинально меняет версии, скажем, как хиазмальное изменение между Magento1 и Magento2, из-за которого Magento 1 больше не поддерживается, или уязвимости в системе безопасности вынуждают вас внедрять новые системы? Итак, вы принимаете эти новые системы и участвуете в процессе отказа от старых систем, или, скорее, это то, что должно произойти.
Большая проблема заключается в том, что клиенты не хотят внедрять новые системы, которые нарушают их текущий рабочий процесс. Что в итоге происходит, так это то, что строятся новые системы, в то время как старые системы переводятся в состояние скелетного экипажа. Новые системы никогда не смогут делать в точности то, что могут старые системы, поэтому в итоге мы поддерживаем 2 системы и переносим клиентов между ними в зависимости от их варианта использования. Мы не будем говорить об основных языковых обновлениях, на которых работают эти платформы.
Этот шаблон продолжает развиваться по мере старения бизнеса, а затем гибкость и время отклика вашего бизнеса сокращаются в геометрической прогрессии, и начинают проявляться новые, более гибкие версии вашего бизнеса.
Затем разработчикам приходится ломать голову над вещами, которые могут больше не применяться к новым платформам и рабочим процессам. Сроки поджимаются, и возникает какой-то девелоперский ад, где нет ни соответствующей документации, ни людей, которые могут помочь.
Я напишу еще одну статью о том, как решить этот беспорядок, если вы окажетесь в этом ужасном сценарии, короче говоря, инструменты отладки являются обязательными, вы не можете просто печатать в журналы ошибок.
Как нам избежать подобных ситуаций?
Что ж, мы используем микросервисы и более мелкие фреймворки.
Вместо создания монолитного приложения, которое может делать все, мы создаем небольшие приложения, основанные на облачных сервисах, предоставляемых такими компаниями, как Amazon.
Затем, когда происходят серьезные изменения языка или приложения, можно сформулировать последовательный ответ, не влияя на рабочий процесс ваших клиентов.
Затем мы интегрируем эти микросервисы в более крупное приложение, используя вызовы API на основе REST или Soap.
Когда потребуется изменение, оно будет происходить на основе компонентов, и клиенты не будут реагировать на эти изменения.
Наша цель как разработчиков должна состоять в том, чтобы создавать вневременные приложения, которые легко обновлять.
Я буду писать больше статей о проблемах разработчиков и о том, как их преодолеть, чтобы поддерживать хорошую ментальную гигиену и гигиену кода.
