Нормально ли запускать весь свой код через «Архитектора программного обеспечения»?

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

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

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

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

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

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

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

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

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

Может случиться так, что проект, над которым вы работаете, должен соответствовать требованиям и управлению. В моей роли технического архитектора я должен проверять все, что делает команда разработчиков. Это связано с тем, что вся разработка осуществляется сторонними консультантами, мы не занимаемся собственной разработкой, поэтому у меня есть роль технического надзора (у нас есть 1 архитектор на каждое бизнес-приложение). В некоторых случаях я соберу архитектурные документы, в которых UML-диаграммы идентифицируют классы и сигнатуры методов, а также шаблоны проектирования и структуру программного обеспечения. В других случаях я просматриваю реализованный код, сравниваю его с нашими рекомендациями и стандартами, а также анализирую код и производительность. По сути, работа, которую я выполняю, во многих отношениях звучит как Архитектор программного обеспечения в вашем вопросе.

Почему я так работаю? Причина в том, что исторически поставщики подводили бизнес, и, поскольку мы обязаны соблюдать нормативные требования, я должен действовать как привратник и арбитр того, что бизнес должен использовать. Когда бизнес-приложение, подобное тому, над которым я работаю, утекло 25 миллионов фунтов стерлингов за год из-за неверных расчетов. В конечном итоге это приводит к увеличению численности персонала FTE (полный рабочий день) из-за низкой производительности, когда целью приложения является сокращение численности персонала FTE. Тогда бизнес, как правило, говорит: «Нам нужен кто-то, кто возьмет на себя ответственность и присмотрит за тем, что мы получаем», так что это моя шея на плахе, а не разработчики (если только ситуация, с которой вы на самом деле имеете дело, не является культурой обвинения, в отличие от моей что доллар останавливается со мной).

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

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

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

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

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

Нет, у вас ситуация немного экстремальная. У вас есть кто-то в качестве архитектора, который немного анально цепляет. Код-ревью — это одно, но если вы не можете сесть и написать код без того, чтобы кто-то не диктовал вам это перед работой, это совсем другое дело. Этот подход может работать только в небольшом магазине и не масштабируется. Можете ли вы представить себе команду из 25, 30, 35 разработчиков, которым приходится ждать своей очереди, чтобы встретиться с архитектором, прежде чем писать код? Пришло время принять серьезное решение с вашей стороны.

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

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

Это нельзя было считать нормальным. Если он точно знал, как должна выполняться работа, почему он не мог сделать ее сам? Трудная часть разработки — выяснить, как приложение должно работать внутри и как должен быть структурирован код.
Единственная ситуация, когда менеджер может вмешаться в процесс написания кода перед код-ревью, — это наставничество нового сотрудника, но если у вас ~6 лет опыта, то это не так.

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

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

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

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

Если бы это был я, меня бы попросили перейти на проект, где у вас больше автономии. Если это не работает, это рынок продавца. Не бойтесь прыгать.

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