Продвижение практики проверки кода и модульного тестирования

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

Как вы собираетесь создать способ, чтобы проверка кода и модульное тестирование естественно вписывались в поток разработчиков?

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

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

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

Или они просто пытаются отвергнуть идею с этим оправданием?

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

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

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

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

Ключом к проверке кода является то, что вы хотите просмотреть как можно меньше кода, как можно быстрее. Таким образом, будет легче найти время для его просмотра, код будет свежим в памяти людей, а внедрение предложенных улучшений будет проще. В крайнем случае вы хотите пересмотреть каждую регистрацию. Хороший инструмент для автоматизации этого - http://code.google.com/appengine/articles/rietveld.html . Это вариант инструмента, который Google использует внутри, чтобы проверка кода происходила при каждой регистрации.

Задача проверки кода была описана десятилетия назад в классической «Психологии компьютерного программирования» . Проблема в том, что программисты склонны связывать свою самооценку со своими навыками программирования. Это означает, что всякий раз, когда программисты сталкиваются с доказательством того, что их навыки не соответствуют действительности, существует тенденция воспринимать это лично. Это может вызвать серьезные конфликты. Если вы выберете классическую Rapid Development Стива Макконнелла, он предложит несколько советов о том, как настроить процесс проверки кода, который уменьшит шансы на такой конфликт. (Ключевым элементом является обеспечение того, чтобы руководство никогда не участвовало в процессе.) Обратите внимание, что это уменьшает вероятность конфликта, но не предотвращает возникновение конфликта.

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

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

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

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

Представить ТДД против воли разработчиков не представляется возможным. Это сложный способ научиться любить тдд.

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

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