Как я могу помочь младшим участникам обрести уверенность в своих способностях рефакторинга кода?

Единственным надежным ответом будут юнит-тесты ИМХО. Не обязательно TDD - просто попросите их написать тесты для существующих методов / классов, которые они хотят реорганизовать, убедитесь, что они делают то, что они делают, а затем позвольте им провести рефакторинг как сумасшедший, полагаясь на тесты, чтобы убедиться, что методы все еще действительны.

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

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

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

Согласен - и юнит-тесты, и парное программирование.

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

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

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

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

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

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

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

Несмотря ни на что, вы должны настаивать на «большем количестве парного программирования, TDD, обзоров кода и т. д.». Вы также должны убедиться, что ваши программисты (как младшие по возрасту, так и по привычкам) хорошо разбираются в основах.

Я рекомендую предложить им прочитать Код завершен Макконнелла и Рефакторинг Фаулера.

• Попросите их написать или изучить существующие тестовые примеры
• Запустите эти тестовые примеры, запишите результат
• Попросите их реорганизовать код
• просмотрите код рефакторинга
• Запустите тестовые случаи, соответствующие предыдущим наблюдениям

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

См .: http://www.codingdojo.org/

Я считаю, что этот вопрос не относится к C#, поэтому я предлагаю попробовать с Java, используя Затмение. В Eclipse есть лучшие инструменты рефакторинга, которые я когда-либо видел (хотя я никогда не пробовал IntelliJ IDEA или Resharper). Я получил много пользы, изучая рефакторинг через Eclipse, особенно используя окно предварительного просмотра перед выполнением каких-либо изменений.

Я бы порекомендовал комбинацию книг, инструментов, кодирования и наставничества.

Прежде всего - попросите кандидата купить или позаимствовать Refactoring Мартина Фаулера и прочитать его.

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

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

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

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

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