Прежде всего, хочу пояснить, что я относительный новичок в мире разработки, проработав 8 лет в службе ИТ-поддержки, и только в прошлом году начал серьезно заниматься кодингом. Я не работал над репозиториями с 45 миллиардами строк кода, или даже чем-то реалистичным. Я еще не работал в настоящей agile-командной среде и имел дело и работал только с несколькими парадигмами программирования и языками. Воспринимайте мои слова с учетом этого.
Проблема
Проведя некоторое время на DEV, я наткнулся на ряд статей людей, которые выдают себя за опытных разработчиков, которые работали над «крупными проектами, используемыми многими тысячами людей в течение длительного времени». В этих статьях (на которые я не буду давать ссылки, так как уверен, что вы уже слышали подобные мнения в этом или других местах) обсуждаются такие темы, как парадигмы программирования (например, объектно-ориентированное программирование против функционального программирования), а также методологии разработки (например, Agile) с акцентом на то, насколько они плохи по х причинам. У меня были подобные разговоры с людьми в моей собственной жизни, когда мне говорили, например: «ООП — это дьявол, потому что оно делает программы слишком сложными по сравнению с их назначением».
Дискуссия
Основная проблема, которую я испытываю в связи с подобными разговорами, заключается в их токсичности для новичков, таких как я, которые лишь по касательной знакомы с концепциями. Подобные мнения складываются за годы работы с этими концепциями и негативного опыта их применения, такого как безудержное усложнение кода при ООП или чрезмерная процедурная нагрузка при Agile.
Примером этого из моей собственной карьеры в сфере ИТ-поддержки является то, что я лично не думаю, что ITIL является особенно хорошей системой для небольших и средних сервисных команд. По моему опыту, я считаю, что она может помешать передаче задач нужным людям в команде обслуживания в то время, когда они необходимы, и вызвать значительные задержки в правильном проектировании и масштабировании небольших команд поддержки. Я пришел к такому выводу за годы работы в малых и средних командах, где такая структура часто скорее мешала, чем помогала.
Хотя это мое мнение, основанное на моем опыте, было бы неправильно с моей стороны утверждать, что это истина. Важно отметить, что я мог прийти к такому мнению еще и потому, что организация, в которой я работал, неправильно внедряла руководство ITIL или инструменты, с которыми я работал, не были правильно настроены для надлежащего соблюдения структуры ITIL. Мое мнение может быть сформировано на основе неудачного опыта, который я имел в своей профессиональной жизни.
Подобные мнения сильно зависят от профессионального опыта человека, который их высказывает, а также от того, как он мыслит. Парадигмы программирования, философии разработки и другие мета-темы, подобные этим, служат, прежде всего, в качестве ментальных моделей для разделения и абстрагирования очень сложных и глубоких тем как в коде, так и в реальном мире. То, что работает для одного человека, может не работать (а в некоторых случаях и не будет работать) для всех.
В примере, который я привел выше, не мне решать, понравится кому-то другому ITIL или нет. Новичку при любых обстоятельствах должно быть позволено сформировать свое собственное мнение без мнения учителя. Очень нечестно и в некоторых случаях вредно учить кого-то, что «х — это плохо», когда у него нет инструментов или опыта, чтобы правильно оценить это мнение, не говоря уже о том, чтобы сформировать собственное обоснованное мнение. Я также достаточно хорошо знаю себя, чтобы понимать, что мое мнение об ITIL, как правило, не разделяется большинством организаций в отрасли, а некоторые люди могут считать его просто ошибочным.
Заключение
Для ясности, я не предлагаю, чтобы опыт учителя не передавался, просто он должен быть контекстуализирован. Выделение подводных камней конкретной методики и объяснение того, почему вы считаете ее неправильным выбором для конкретной ситуации, может быть гораздо более ценным, чем утверждение, что что-то плохо, потому что это «всегда приводит к нежелательному результату».
Как относительный новичок во всем этом, прочитав или услышав: «ООП — это плохо, и вы никогда не должны его использовать, потому что он всегда превращается в неуправляемый спагетти-код в масштабе», это убивает мою мотивацию к обучению, поскольку я чувствую, что мои усилия, какими бы короткими они ни были, пропадают зря. Это просто не помогает, даже если это правда.
Друзья-новички: не слушайте этих людей! Не позволяйте им навязывать вам свой негативный профессиональный опыт. Формируйте свое собственное мнение на основе собственного опыта.
Я бы также предположил, что если бы я посвятил десятилетие изучению и внедрению ООП, например, то если бы какой-нибудь 25+ летний ветеран пришел и сказал мне, что мой десятилетний опыт практически ничего не стоит, потому что ООП — это плохо, я бы точно не поверил.
Ветераны: это нормально, что у вас есть такие пустые мнения, но, пожалуйста, подождите, пока мы не попросим вас высказать их нам. Часто ваше мнение приносит больше вреда, чем пользы, особенно если мы не до конца понимаем контекст или не обладаем опытом, необходимым для правильного понимания того, почему вы говорите эти вещи.
Спасибо всем вам за то, что читаете! Мне бы хотелось услышать ваше мнение о подобных укоренившихся токсичных мнениях. Вы согласны или не согласны?