2021-07-16 19:00:10
Когда я изучал программирование и в дальнейшем, когда начал зарабатывать программированием первые деньги, я не задумывался о том, что есть какие-то принципы разработки, да меня они и не интересовали. Полагаю, из-за того, что я самоучка, я любил писать код «в лоб» и сразу получать результат, не заботясь об архитектуре, поддерживаемости, тестируемости и т.п.
В 2000-х популярность программирования набирала обороты, а самым популярным направлением изначально была десктоп-разработка. Самыми ходовыми решениями для десктоп-разработки были Java, Delphi, C++ Builder, .NET Framework. Все они подразумевали разработку в парадигме объектно-ориентированного программирования, поэтому в моде тогда было знать паттерны (шаблоны) ООП, чтобы писать красивые решения, не изобретать велосипеды и не городить костыли. Я старался применять популярные паттерны в уместных местах, не потому, что это правильно (что, в зависимости от задачи, бывает спорным), а потому, что это экономило время.
А ещё в то время было модным обсуждать и пробовать «экстремальное программирование». Кроме автотестов, парного программирования и прочего, оно подразумевает непрерывный процесс улучшения качества кода (рефакторинг). То есть, если сейчас код написан плохо, например, имеется дублирование, но задача решена, в этом нет ничего плохого, но этот код обязательно должен быть улучшен в ближайшее время. Таким образом, не так важно какая архитектура у только что написанного кода, важно чтобы этот код стал лучше через месяц и ещё лучше через два. Я с удовольствием взял тогда на вооружение этот принцип и применяю его в своей работе. Это позволяет, не выделяя отдельных дней на рефакторинг, поддерживать код в хорошем состоянии: видишь код, который можно улучшить, улучшаешь его прямо сейчас, не откладывая «на потом». У такого подхода есть и ещё один плюс: ты не забываешь кодовую базу и хорошо в ней ориентируешься, как паук в своей паутине.
Несмотря на то, что принципы SOLID были описаны в начале 2000-х, широкую практику применения они стали получать в конце нулевых - начале десятых во многом благодаря спросу на разработку и поддержку огромного количества веб-сервисов. Из-за отсутствия релизов, которые были заменены непрерывной доставкой, необходимо было покрытие кода автотестами, чтобы очередной деплой ничего не сломал. Микросервисная архитектура требовала от кода модульности, возможности беспроблемного заимствования отдельных частей. Эти и другие факторы, а также высокие требования к масштабируемости процесса создания продукта, когда команда программистов могла увеличиться за год в разы, сделали SOLID мастхевом в промышленной веб-разработке.
Мне принципы SOLID нравятся, но я понимаю, что их применение приводит к увеличению кодовой базы и, главное, увеличению времени на разработку. Поэтому я применяю их в зависимости от условий задачи: если от меня требуется сделать что-то быстро или это вообще MVP, я предпочту антипаттерны, суперклассы и тому подобное. В дальнейшем, если продукт не умрёт и будет развиваться, за счёт непрерывного рефакторинга архитектура кода будет приведена в порядок.
Мне просто использовать на практике эту свободу следования, частичного следования или неследования каким-либо принципам, потому что опыт помогает сделать правильный выбор. К сожалению, часто такой свободы выбора нет у джунов: они либо не умеют применять паттерны и принципы, либо, наоборот, умеют и стараются писать идеальный код даже тогда, когда этого не требуется. У меня есть яркий пример, когда джун с хорошей алгоритмической и архитектурной подготовкой писал MVP месяц вместо недели: уговоры на него не действовали, потому что он не мог принять тот факт, что иногда SOLID несёт только вред.
Поэтому одним из факторов профессионального роста является не столько знание архитектурных подходов, сколько умение их правильно применять. То есть быть эффективным, а не просто много знать.
Задать вопрос, предложить тему для заметки, а так же проголосовать за понравившиеся темы вы можете на странице qst.it-monk.ru.
496 views16:00
I
