Как (тактично) сказать моему менеджеру проекта или ведущему разработчику, что кодовая база проекта требует серьезной работы?

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

Проект (внутреннее бизнес-приложение ASP.NET WebForms среднего и крупного размера), из-за отсутствия более понятного термина, является катастрофой. Есть три сразу заметные проблемы со стандартами кодирования:

1. Стандарт очень свободный. Он описывает больше того, что не нужно делать (не используйте венгерскую запись и т. Д.), Чем то, что нужно делать.
2. Стандарт не всегда соблюдается. Повсюду несоответствия с форматированием кода .
3. Стандарт не соответствует рекомендациям Microsoft по стилю. На мой взгляд, нет смысла отклоняться от рекомендаций, которые были сформулированы разработчиком фреймворка и самым крупным вкладчиком в языковую спецификацию.

Что касается пункта 3, возможно, это беспокоит меня больше, потому что я нашел время, чтобы получить свой MCPD с акцентом на веб-приложениях (в частности, ASP.NET). Я также единственный Microsoft Certified Professional в команде. Из-за того, что я изучил во всех моих школах, самообучении и обучении на рабочем месте (включая мою подготовку к сертификационным экзаменам), я также обнаружил несколько примеров в коде проекта, где ничего не делается в лучший способ.

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

Должен ли я (и если да, то как мне) предложить своему руководителю проекта и руководителю группы, что проект нуждается в капитальном ремонте?

Я не хочу ходить в их офис, размахивая сертификатами MCTS и MCPD, говоря, что кодовая база их проекта - дерьмо. Но я также не хочу молчать и писать хитрый код поверх их хитрого кода, потому что я на самом деле хочу писать качественное программное обеспечение и хочу, чтобы конечный продукт был стабильным и легко обслуживаемым.

Вы могли бы потратить свое время на аргументацию своего дела; или вы можете потратить время на уборку по мере продвижения.

Возьмите Принципы, Шаблоны и Практики Чистого Кода и Agile Software Development и примените то, что вы изучите там, работая в системе. В конце концов, люди заметят (к лучшему или к худшему).

Редактировать Также проверить Эффективная работа с устаревшим кодом

Судя по тому, что вы описываете, проблемы, как правило, связаны с несоблюдением стандартов кодирования и проблемами именования. Это не катастрофа , безусловно. Для сравнения, это настоящая катастрофа.

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

Я предлагаю вам рассказать об этом как об улучшении и помочь команде обновить руководство и научить его использовать его по-настоящему. Мне действительно нравится использовать Definition of Done в качестве эталона качества, и его создание само по себе является отличным упражнением для команды. Но я не думаю, что вы должны делать гораздо больше, по крайней мере, не как новый член команды.

Определенно, не стоит размахивать вашим MCSD, люди будут просто откровенно смеяться над вами, сертификаты MS хороши, но они ни в коем случае не являются профессиональной квалификацией!

Слегка присоединяйтесь к новой команде, ищите возможности предлагать изменения по мере продвижения.

Подождите, пока вы не доберетесь до земли, прежде чем списывать код команды.

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

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

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

Ничто не говорит о том, что вы должны писать неаккуратный код только потому, что в кодовой базе могут быть некоторые. И ничто не говорит о том, что код ХОРОШИЙ только потому, что он не соответствует вашему стилю питомца. Просто делайте рефакторинг, когда вы работаете над частями, над которыми вы работаете, и пишите хороший код, когда вы работаете над новым материалом.

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

Кажется, вы выбрали три (относительно) незначительные вещи для беспокойства. Есть и другие вещи, о которых я бы больше беспокоился:

• Код хорошо документирован?
• Код придерживается спецификаций / документов дизайна?
• Работает ли код?
• Легко ли понять, что делает код?
• Вы рассматриваете возможность отправки больших кусков этой кодовой базы в TheDailyWTF?

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

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

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

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

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

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

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

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

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

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

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

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

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

Жалобы на венгерскую нотацию не вызывают у вас симпатии и, вероятно, являются одним из последних сражений в списке приоритетов.

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

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

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

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

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

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

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

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

Не обращайтесь непосредственно к руководству с этой «проблемой».

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

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

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

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

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