Делать это по-вашему когда-нибудь помогало? Был ли хоть раз, когда вы использовали непрямую связь, инъекцию и дополнительные интерфейсы, а в последний момент произошел сбой, и все это было обработано гладко и красиво, без мата? Даже на предыдущей работе, если вам никогда не удавалось зафиксировать этот код здесь?

Я собираюсь предположить, что был. Потренируйтесь рассказывать эту историю. Это конкретно и реально. Это не «х может случиться» или «у может измениться», а «Однажды я сделал это таким образом, и вот как это сработало». Менеджеры (я говорю как один из них) с подозрением относятся к трате денег (и поверьте мне, вы пишете более сложный код, который другие не могут понять с первого раза, это трата денег) на то, что может произойти. Они не хотят финансировать спекуляции, которые могут быть основаны только на «книжном обучении» и последних причудах в Интернете. Но когда вы опираетесь на свой опыт? Это совсем другая ситуация.

Я не большой поклонник заводов, провайдеров, инжекторов и прочего. Как правило, они настроены для вещей, которые на самом деле никогда не произойдут (переход с MS SQL на Oracle) или имеют небольшое влияние, когда они это сделают (изменение папки, в которой сохраняются файлы). У них действительно есть место в аранжировках, которые очень изменчивы, в которых вы, кажется, участвуете. Поэтому вам нужно показать, что у них есть это место. Кажется, вы исходите из позиции: «Это нормальный способ делать что-то, и мне нужна причина, чтобы этого не делать». Ваш менеджер говорит: «Это не нормально, нормально — это просто и понятно. Дайте мне вескую причину, чтобы добавить еще один слой на пути». Работайте над этой причиной. Работайте над историей успеха в прошедшем времени, где этот дополнительный слой экономит дни или недели работы. Обоснуйте свою инженерию, иначе это действительно чрезмерная инженерия.

Меня смущает эта цитата из одного из ваших комментариев:

Как инженеру-программисту, для меня стало второй натурой «делать вещи, которые могут не иметь веских оснований на поверхности», например взаимодействие с неизвестными, о которых я упоминал. Необходимость постоянно быть на грани объяснений по глубоко техническим (а иногда и очень самоуверенным) предметам истощает меня.

Я видел несколько повторений следующего жизненного цикла:

• Квалифицированная команда программистов предлагает другой подход к программированию.
• Он рассматривается в течение нескольких лет, вплоть до десятилетия, как нечто, что должно использоваться повсеместно, несмотря на любые недостатки и ограничения. На этом этапе достаточно сказать: «Я применяю методологию X», не анализируя, является ли X чистой выгодой.
• Он выходит из моды, но его самые полезные идеи остаются частью набора инструментов для разработки программного обеспечения, и их можно извлечь и использовать всякий раз, когда они приносят чистую пользу.

На мой взгляд, и TDD, и шаблоны проектирования колеблются между второй и третьей стадиями жизненного цикла методологии программирования. Я уверен, что TDD и многие шаблоны проектирования будут иметь долгую и ценную жизнь в наборе инструментов, и их можно будет использовать всякий раз, когда они больше помогают, чем вредят. Я также думаю, что они все еще могут использоваться чрезмерно, по привычке, а не преднамеренно.

Вы никогда не должны применять шаблон проектирования, потому что это вторая натура, или вам трудно объяснить, как вы его используете. Вместо этого, прежде чем применять шаблон проектирования, подумайте о его затратах и ​​преимуществах в данной конкретной ситуации. Если его преимущества действительно перевешивают его затраты, вы должны точно знать, почему, поэтому объяснение компромисса не должно вас утомлять. Если его преимущества не перевешивают его затраты, не используйте его. Опять же, ваши собственные размышления о вашем дизайне должны подготовить вас к ответу, если вас спросят, почему вы не использовали возможно применимый шаблон проектирования.

Помните, что вам нужно думать об этих компромиссах с точки зрения общей ремонтопригодности программы, а не только о том, чтобы ваша часть работала быстро. Излишняя косвенность может затруднить для будущих программистов поиск того, что происходит на самом деле.

Я единственный человек, озадаченный тем, как в Workplace мы видим, что так много внимания уделяется методам кодирования, а не фактическим конфликтам на рабочем месте? Поэтому я буду использовать другой подход.

Вот общие аспекты вашей проблемы, как я ее вижу:

1. Вы находитесь в квалифицированной области, которая требует сотрудничества
2. Нет никаких документированных процедур, определяющих, как должна выполняться эта совместная работа.
3. Существуют разногласия по поводу того, как следует проводить эту совместную работу.
4. Один из тех, кто не согласен, ваш менеджер

Мне кажется, что ваша группа должна собраться вместе и договориться о том, какие стандарты и методы вы примете, и внедрить их во всем мире, к лучшему или к худшему. Потому что для продукта нет ничего хуже, чем команда, которая постоянно враждует, а для ваших отношений с работодателем нет ничего хуже, чем постоянно перессориться с ними .

Поэтому постарайтесь собрать свою команду вместе, чтобы договориться о некоторых стандартах, и используйте это собрание, чтобы отстаивать свои позиции в отношении методов, которые вы используете. Если вы их получите, отлично! Если нет, то так тому и быть. Ваша работа не в том, чтобы писать красивый код. Ваша задача — доставить готовый продукт. Если ваш работодатель (в лице вашего менеджера) и большинство членов вашей группы настаивают на том, чтобы вы делали это определенным образом, то кто вы такой, чтобы противоречить им?

Тем не менее, похоже, что большая часть вашей команды согласна с вами, поэтому во время этих обсуждений должно стать очевидным, что ваш менеджер — лишний. Если этот человек по-прежнему отказывается изменить консенсус команды, то это дисфункция, которую мы не можем вам помочь решить (кроме рекомендации перейти в другую команду).

К сожалению, он ваш менеджер, и вы не пишете код так, как он хочет, чтобы вы его писали. Если он менеджер, он, возможно, не планирует уходить из компании через 2-3 года, как это планирует большинство разработчиков. Вы пишете код, который вашим заменителям будет труднее исправить, поэтому он суров с вами за то, что вы построили его таким образом.

Если мне позволено сделать здесь предположение, прекрасно зная, что я могу ошибаться, то для чего вы пишите этот материал? Я был бы весьма удивлен, если бы это было что-то большее, чем LOB-приложения. Шаблоны проектирования, вероятно, чрезмерно усложняют некоторый код для бизнес-приложения, которое не должно быть особенно сложным.

За 10 лет моей разработки настоящий шаблон стратегии/фабрики потребовался только три раза, два из которых были связаны с работой:

• В приложении, которое отображало информацию о продукте, где некоторые из этих продуктов были, по сути, набором более мелких продуктов в коробке, мы использовали стратегию, чтобы определить, какая фабрика необходима для преобразования информации о продукте (запрошенной с помощью ключа) в представление. Не очень славно, но это сделало работу. Если мне будет позволено присоединиться к вашему скромному хвастовству об ошибках, за все время моего пребывания там у нас не было ни одной ошибки! (об одном сообщили после того, как я ушел, но оказалось, что это ошибка пользователя :)).
• В приложении, которое показывало пользователям, куда идти на занятия, которые они посещали, мы использовали фабрику и абстракцию, чтобы обеспечить быстрый переход между Bing Maps API и Google Maps API. Это было связано с тем, что оба варианта имели соотношение цены и качества, а компания не решала, какой из них использовать. В конце концов мы узнали из нашего домашнего офиса, что у нас уже есть ключ API для одного из них, и мы смогли в последнюю секунду переключиться на этот API, прямо перед запуском.

И третий — это проект, над которым я возился, который занимается мониторингом серверов для серверов Windows:

• Я использую интерфейс для вывода данных мониторинга и для самих мониторов. Мониторы легко настраиваются (в зависимости от настроек приложения). Реализация вывода зависит от того, тестирую ли я новый монитор или приступаю к развертыванию, например, IOutputInterface имеет ConsoleOutput и SqlOutput в качестве реализаций, которые могут различаться.

Обратите внимание, что мой личный проект сразу же чаще использует шаблоны и инверсию управления (IoC), чем мои рабочие проекты.

Если после всего этого я могу дать вам какой-нибудь совет, пусть он будет таким: работа есть работа, и если вы хотите делать что-то по-своему, постарайтесь найти золотую середину. Технические специалисты обычно не задерживаются надолго, и не стоит ввязываться в драку с руководством из-за того, как это делается. Сделайте так, чтобы ваши личные домашние проекты были стопкой шаблонов столько, сколько вы хотите.

Простое решение: выйти .

Трудное решение: в любом разногласии половина вины лежит на вас .

Сделайте перерыв, изучите, как работают другие команды, выясните, где несоответствие импеданса между вами и другой стороной. Говорите с ними лично, рано и часто. Если вы сделаете это хорошо, вы оба научитесь понимать опасения и полномочия другой стороны, а они научаться ценить вас за ваш вклад, опыт и твердое мнение. Вот несколько областей, которые следует учитывать:

• качество продукта и время выхода на рынок
• хороший продукт против хорошего кода
• умный код против понятного кода
• корпоративная культура «сверху вниз» и инженерная культура «снизу вверх»

Если это не работает, рассмотрите другую роль в команде, другую команду в компании или, наконец, другую компанию .

Если ты столкнешься с этими людьми лицом к лицу, ты столкнешься с величайшим сопротивлением, кузнечик. Я был наиболее эффективен в осуществлении перемен, когда стратегически попадал в нужные болевые точки. Это требует большого терпения и больших усилий. Я должен сначала адаптироваться к ним, прежде чем оказывать давление на слабые места.

Очисти свой разум, будь бесформенным. Бесформенный, как вода. Если вы нальете воду в чашку, она станет чашкой. ... Теперь вода может течь или она может разбиться. - Брюс Ли

Слушайте их и задавайте много вопросов. Искреннее слушание кого-то отнимает у него желание сопротивляться. Поймите, что мотивирует их мышление, а затем говорите на их языке. Поскольку ваши убеждения являются осевыми, в данный момент он, вероятно, отражает ваше упрямство, презрение и разочарование. Поскольку вы подчинены, это его выбор не присоединяться к вашей длине волны, и на вас лежит ответственность построить мост.

Когда вы увидите его, вы увидите себя. Как вы относитесь к нему, вы будете относиться к себе. Думая о нем, вы будете думать о себе. Никогда не забывай об этом, ибо в нем ты найдешь себя или потеряешь себя. - Хелен Шукман

Мастер Вин Чун Кунг Фу притянет своего противника и сократит дистанцию, прежде чем искать и атаковать центральную линию, где он наиболее уязвим. Не спорьте о мелочах только для того, чтобы победить, найдите центральную линию более крупной проблемы и сосредоточьте на ней давление.

Я ежедневно сталкиваюсь с инженерами, которые отказываются переоснащать или изучать новые парадигмы программирования, и я получал некую форму аргумента «я был здесь с перфокарт» больше раз, чем я могу сосчитать. По моим подсчетам, я проиграл 80% сражений, но эти 20%... ох... произошли большие изменения. Я могу показаться расплывчатым, но поищите в Google некоторые из этих ключевых слов, и вы поймете, что я имею в виду.

Кроме того, попробуйте получить новый проект белки , который вы можете сделать по-своему. Если это действительно работает и экономит время или деньги, люди согласятся с вашим образом мышления. Если нового проекта нет, создайте его в свободное время, чтобы решить болевые точки компании, и никто не заинтересован в том, чтобы тратить время на их решение.

Что я должен делать?

В программной инженерии то, насколько хорошо код написан (или переписан), всегда зависит от определенного уровня интерпретации (мнения). На мой взгляд, вы предпринимаете шаги, которые сделал бы я на вашем месте, но, в конечном счете, именно ваш менеджер должен увидеть свет … продолжайте показывать ему это.

Я бы продолжал, как бы болезненно это ни было , делать именно то, что делаете вы, и указать на окупаемость инвестиций в использование шаблона проектирования, где вы можете, не выставляя вашего менеджера в плохом свете .

Не меняйте того, что вы делаете, если вы не чувствуете, что рискуете получить что-то большее, чем выговор. Продолжайте показывать им преимущества использования шаблона, и в конечном итоге они должны прийти в себя.

Продолжая борьбу, постарайтесь заполучить других союзников в команду. Таким образом, вы не единственный голос, говорящий в пользу шаблона.

Однако в какой-то момент, если они откажутся, у вас будет выбор, подходит ли вам эта среда. Я не думаю, что вы еще там, но вам, возможно, придется перейти к среде, более приемлемой для хороших методов кодирования.

Помните, эта борьба, в которой вы находитесь, — это марафон . Если вы хотите изменить культуру кодирования, вам придется продемонстрировать ценность шаблона.

Во-первых, по предоставленной информации мы не можем сказать, кто прав. На самом деле, если бы меня вызвали для аудита проекта, мне все еще было бы трудно решить, кто прав, потому что вы можете проектировать с другими целями. Но я предполагаю, что босс знает цели лучше, чем вы.

Во-вторых, ваш вопрос: "как мне уговорить своего начальника?" Ответ в том, что вы, вероятно, не можете. В конце концов, он босс. Единственный раз, когда я убедил своего босса изменить его взгляды на разработку программного обеспечения, был после того, как мы потратили год на исправление ненадежной части программы, которая была написана так, как он хотел, и мы сказали ему, что не можем сделать ее надежной, кроме как спроектировав ее. иначе.

Мы не знаем, кто здесь прав с технической точки зрения, немногие — это может быть менеджер, застрявший глубоко в прошлом, или новый разработчик, слепо верящий во всю эту шумиху.

Но он ваш менеджер, и вы не имеете дело с менеджером, вы имеете дело с его отказом делать то, что вы считаете лучшим, и настаивает на том, чтобы делать то, что он считает лучшим. И это нормально, что решение принимает ваш менеджер. Это также нормальное положение вещей, что он в конечном счете несет ответственность за успех или неудачу, а не вы. У него есть полномочия. И он прав, вы не должны подвергать сомнению его авторитет. Вы можете сомневаться в его правоте, но не в его авторитете. Так что вы либо смиритесь с этим, либо перейдете в компанию, которая делает все по-вашему.

Между тем, вместо того, чтобы думать, что все идет не так, как вы хотите, подумайте о том, как вы можете создавать код самого высокого качества, насколько это возможно в рамках ваших ограничений. Многие вещи можно делать по-разному. Есть «прямо, плохо спроектировано» и «прямо, хорошо спроектировано». Выбирайте последнее.

Опыт позволяет судить о том, возможны ли выгоды от шаблона проектирования в будущем. Если руководитель знает шаблон и все же отказывается от него, он, вероятно, признает случай, когда применение этого или подобного шаблона не окупается. Иногда опыт противоречит правилам или, что более вероятно, их интерпретациям.

Существует известное мнение, что более короткий и простой код проще для понимания и более открыт для значительных изменений.

В основном то, что вы пытаетесь сделать, это иметь еще один уровень косвенности, еще один и так далее. Это все усложняет.

Действительно ли эти слои решают проблему? Упрощение добавления функций в будущем не решает проблему. Клиент не готов за это платить. Поэтому для бизнеса это не проблема. Для бизнеса проблемы не существует.

К тому же этого делать нельзя. Неизвестно, какую конкретную функцию может захотеть клиент в будущем. Когда вы разрабатываете продукт особым образом, вам становится сложнее добавлять определенные функции. Дизайн лучше оставить открытым.

Таким образом, вы не только делаете несанкционированные инвестиции от имени своей компании, но и понятия не имеете о связанном с этим факторе риска.

Сложные вещи требуют больше времени для выполнения и обслуживания. Время - деньги.

Сложные вещи ограничивают количество и тип других вещей, которые можно добавить в систему. Если однажды вы встанете на путь усложнения вещей, то вам придется усложнять и другие существующие и новые вещи, даже если они сами по себе не должны быть сложными.

В этом есть последнее сообщение. Говорят, что числа два в информатике не существует. Если вещь имеет два варианта, вы не добавляете еще один уровень косвенности. Вы просто позволяете двум вариантам существовать. Так проще. Если у вас нет трех или более вариантов, общность не ясна, поэтому вы не абстрагируете ее. Вы не знаете, что извлечь, вы рискуете и выдаете желаемое за действительное.

Я бы предложил парное программирование и экспертную оценку. Это поможет вашим коллегам лучше понять ваш код, поскольку вам нужно объяснить, почему и как вы это делаете, а не постфактум.

Либо они будут учиться у вас и поймут, почему это умно, либо вы узнаете, что лучшие программисты пишут код, который другие могут поддерживать.