Что делать, если новая команда руководит проектом с проблемами сопровождения?

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

Я нахожусь в месте, где мы работаем с очень большой многоуровневой системой .NET, в которой отсутствуют многие важные вещи, такие как модульные тесты, IOC, MEF, слишком много статических классов, чистые наборы данных и т. Д. только 24 года, но я здесь уже почти три года (это приложение разрабатывалось уже 5 лет), и в основном из-за нехватки времени, мы просто добавили больше дерьма, чтобы соответствовать другому дерьму. После выполнения ряда проектов в свободное время я начал понимать, насколько важны все эти концепции. Кроме того, из-за смены сотрудников я теперь являюсь руководителем группы по этому проекту, и я действительно хочу придумать несколько умных способов улучшить это приложение. Пути, где ценность может быть объяснена руководству. У меня есть идеи о том, что я хотел бы сделать, но все они кажутся ошеломляющими без особой выгоды. Любые истории о том, как люди сталкивались или могли бы справиться с этим, были бы очень интересными для чтения. Благодарю.

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

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

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

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

Включите технический долг в исправление ошибок и дополнительную функцию.

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

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

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

Я мог бы просто заявить об очевидном, но эй.

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

Это также поможет вам немного ближе познакомиться с базой кода.

Некоторое время спустя вы поймете, что пришло время провести более расширенный рефакторинг. Выяснение дублированного кода, нарушения принципа СУХОЙ ... вы знаете, обычные вещи. К тому времени у вас будет достаточно приличное покрытие кода, которое позволит вам перетасовывать методы, извлекать интерфейсы и все эти удобства.

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

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

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

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

Удачи.

Один из вариантов - стереть свое резюме и начать поиск работы.

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

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

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

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

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

«Невозможно сделать из уха свиньи шелковую сумочку».