Я смотрел/слушал отличный доклад Саймона Брауна на тему Модульные монолиты с GOTO 2018.
В нем он упоминает термин под названием Программирование культа карго, и это действительно затронуло меня.
Недавно я присоединился к новой компании с новым языком программирования, новыми инструментами, новыми процессами и новой командой. На самом деле, это в значительной степени «новое» все.
Это заставило меня многому научиться за последние месяцы. Имея относительно большой опыт, я предпочитаю изучать почему, а не как при изучении нового. Я понял, что это не самый распространенный подход.
Когда перед пользователем ставится задача добавить к существующей кодовой базе расширение текущего решения, он, скорее всего, проверит, как это делалось ранее, скопировав подход для своего решения. Они могут/будут слепо следовать этому шаблону, как это делалось раньше. Дополнительные блоки добавляются на вершину башни, не задумываясь, правильно ли это делать. Если все будут так делать, то рано или поздно это произойдет.
Отсюда и термин «Программирование культа карго».
Википедия объясняет это так:
Культовое программирование – это стиль компьютерного программирования, характеризующийся ритуальным включением кода или программных структур, которые не служат никакой реальной цели. Программирование культа карго обычно является признаком того, что программист не понимает ни ошибки, которую он пытался решить, ни очевидного решения (сравните отладку дробовика, глубокую магию). [1] Терминпрограммист культа карго может применяться, когда неквалифицированный или начинающий программист (или тот, кто не имеет опыта решения данной проблемы) копирует некоторый программный код из одного места в другое, мало или совсем не понимая, как он работает и нужен ли он в новой версии. положение.
Культовое программирование также может относиться к практике слепого применения шаблона проектирования или стиля кодирования без понимания причин, лежащих в основе этого принципа проектирования. Примерами могут служить добавление ненужных комментариев к не требующему пояснений коду, чрезмерное соблюдение соглашений определенной парадигмы программирования или добавление кода удаления для объектов, которые сборка мусора собирала автоматически.
Общая проблема?
Представьте себе сценарий, в котором вы работаете над ошибкой, находя код, вызывающий ошибку. Вы не совсем уверены в том, что происходит, поэтому вы;
- Гуглите ошибку.
- Вы найдете вопрос StackOverflow.
- Найдите самый популярный ответ.
- Скопируйте и вставьте решение в свой код.
- Попробуйте выполнить отладку, чтобы увидеть, устранена ли ваша проблема.
Это так, поэтому вы проверяете его и идете дальше.
Звучит знакомо?
Зачем мы это делаем? Почему мы слепо берем этот фрагмент и используем его как есть в нашей реализации?
Вариант использования, вероятно, не тот, поэтому я был бы удивлен, если бы решения были такими. Помимо простых примеров, понимание причин, лежащих в основе решения, более важно, чем само решение. Есть много вещей, которые вы не можете сделать с тем, чего не понимаете. Вы не можете изменить, улучшить или протестировать его. Вы не можете задокументировать это, и вы не можете владеть этим.
Технические тренды, модные словечки и микросервисы
Мы все любим все новое, а руководству особенно нравится следовать популярным тенденциям, идти в ногу с технологическим прогрессом.
Большинство команд теперь будут следовать Agile-подходу. TDD и автоматизированное тестирование могут быть очень полезны в определенных сценариях, непрерывная интеграция снимает большую часть накладных расходов с команды инфраструктуры, большие данные и искусственный интеллект могут значительно повысить удовлетворенность пользователей и контейнеризацию, а в последнее время микросервисы сдвигают наш старый монолит архитектуру в более мелкие автономные сервисы.
Каждое из этих достижений само по себе блестяще, и я не оправдываю ни одно из них. Мое затруднительное положение заключается в том, нужно ли нам внедрять их все во все наши процессы и код? Мы видим сообщения в блогах из Netflix, Facebook, Twitter, показывающие, как их использование изменило их работу. Если крупные компании сочтут их необходимыми, не должны ли и мы? Вот где карго-культовое программирование снова поднимает свою уродливую голову.
Нам нужно понять проблемы с нашими нынешними разработками, почему они возникли и как их можно устранить в будущем. Да, эти новые процессы могут помочь нам в решении наших проблем, но слепое следование им в слабой надежде на то, что они помогут, — это не путь вперед и не имеет никакого логического смысла.
Я особо упоминаю микросервисы, поскольку многие компании, похоже, осуществляют переход, ссылаясь на такие преимущества, как:
- Более быстрое время разработки
- Высокая масштабируемость
- Легко улучшить
- Простота развертывания
- Автономные команды со свободой выбора технологий
С таким списком, о чем тут думать? Давайте все прыгнем на подножку!
Подождите секунду… есть ли какие-либо недостатки в этом подходе?
- Архитектурная сложность
В монолитных архитектурах сложность и количество зависимостей находятся внутри кодовой базы, тогда как в микросервисных архитектурах сложность переносится на взаимодействие отдельных сервисов, которые реализуют конкретную область.
- Операционная сложность
- Как выделять ресурсы масштабируемым и экономичным способом
- Как эффективно управлять десятками или сотнями микросервисных компонентов, не умножая усилий
- Как справиться с отсутствием стандартов и неоднородной средой, включающей разные технологии и людей с разными наборами навыков
- Как работать с версиями
- Как отслеживать и отлаживать взаимодействия во всей системе
- Как отслеживать сотни конвейеров развертывания кода и их взаимозависимости
Они взяты из собственного технического описания Amazon Challenge of Microservices. Не знаю, как вам, а мне недостатки кажутся намного страшнее, чем преимущества. Еще раз, я не говорю, что это неправильный подход к снижению, но если эти преимущества не перевешивают недостатки, что вы получаете, следуя этому подходу?
«Общественная» проблема.
На самом деле все просто: перестаньте использовать ключевое слово Public, перестаньте автоматически создавать классы Public . Почему мы делаем это?
Проблема с использованием ключевого слова public заключается в том, что вы упускаете преимущества, связанные с инкапсуляцией. Почему мы так часто его используем? Это в значительной степени слово по умолчанию, которое мы используем при создании классов, во всех примерах будут использоваться общедоступные классы, мастера и фрагменты будут реализовывать общедоступные классы. Пора остановиться. У скольких людей есть общедоступная учетная запись Facebook? Большинство вещей в этом мире являются частными, как и наши занятия. Сделайте их частными по умолчанию, а затем, если вам нужно, чтобы они были общедоступными, измените их.
С большим опытом приходят большие опасения.
Чем дольше вы работаете в какой-то области, тем менее наивно вы воспринимаете улучшения, которые принесет новый инструмент или процесс. Большинство сегодняшних идей исходят из многолетних исследований в этой области, которые, наконец, получили признание. Как только что-то получило массовое признание, легче чувствовать себя комфортно, полностью охватывая это. То есть, если это правильно.
"Хорошее суждение происходит из опыта, а опыт рождается из ошибочного суждения"
- Рита Мэй Браун
Так что не стесняйтесь продолжать рыскать в Интернете в поисках решений и руководств по своим проблемам; продолжайте изучать новые языки, фреймворки и реализации. Просто знайте, почему они работают, а не просто как. Все мы учимся на собственном опыте и ошибках, поэтому понимание основ поможет вам не идти по тому же пути в будущем.
