Как реализовать процесс разработки со студентами колледжа

На моей первой работе в качестве разработчика программного обеспечения моя команда использовала Agile / Scrum для управления рабочим процессом нашего проекта, и это работало довольно хорошо. У меня были опытные наставники, которые поставили меня на правильный путь - я в долгу перед ними. Я работал там несколько лет, а затем перешел к новой возможности пару месяцев назад.

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

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

Я не ищу, скажем, ответов типа «Используйте Scrum», «Настроить доску канбан» или «Взгляните на Agile!» (хотя идеи ценятся). В частности, я надеюсь получить представление о том, как реализовать процесс разработки для этой рабочей среды. Сотрудники обычно работают от 1 до 2 лет, прежде чем уйти, как правило, неопытны, и ежедневные встречи с участием каждого из них почти невозможно запланировать.

Как повысить качество, эффективность и коммуникацию на таком рабочем месте?

Обновление: после прочтения некоторых ответов и комментариев я подумал, что предоставлю дополнительную информацию.

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

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

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

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

Начните использовать функциональные ветви, чтобы каждый работал в отдельной ветви. Когда задача завершена, разработчик не может объединить свой код с главной веткой. Если вы используете Git, они все еще могут запустить запрос на получение. В противном случае используйте любой метод отслеживания завершенных задач (/ веток), который вам по вкусу.

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

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

Если нет опытных разработчиков, то у вас всегда будут проблемы. Если некому найти хороший код по плохому, невозможно поддерживать качество кода.
Лучшее, что вы можете сделать, это провести обзорные встречи, на которых разработчики представляют и объясняют свою реализацию перед другими разработчиками. Хотя это не может гарантировать предотвращение каждой проблемы (например, если все разработчики имеют одинаковое неправильное представление о надлежащей практике, это все равно предотвратит большинство проблем (например, если хотя бы один разработчик имеет правильную идею и может сформулировать ее; или когда проблема связана с от разработчиков понимание проблемы отличается друг от друга)

Как повысить качество, эффективность и коммуникацию на таком рабочем месте?

• Качество - обзор кода опытными разработчиками. В отсутствие опытных разработчиков, сделайте групповой обзор, чтобы как минимум охватить ваши основы как можно лучше.
• Эффективность - если вы правильно ставите независимые задачи, вы сводите к минимуму людей, которые вынуждены ждать друг друга. В среде, где не все доступны одновременно, я предполагаю, что вы сталкиваетесь с большим количеством задержек «ожидания человека А». Следите за разработчиками, которые не добиваются прогресса, только для того, чтобы проверить, нужна ли им помощь или даже просто позволить им выразить свои разочарования (эти разочарования могут выявить неправильные представления о проблемах, которых можно избежать).
• Коммуникация - Установите политику открытых дверей, чтобы разработчики могли обратиться к кому-нибудь за помощью, отзывами или вдохновением. В отсутствие квалифицированного наставника, попытайтесь облегчить взаимодействие команды (вы, конечно, можете сделать это, даже если у вас есть наставник, но важность этого возрастает в отсутствие наставника). Особенно в ситуации, когда люди работают удаленно и по разным графикам, разработчики часто не находятся рядом со своими коллегами и, как правило, не общаются между собой. Даже небольшое количество общественных собраний может творить чудеса для улучшения общения, связанного с работой, в другое время.

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

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

Потому что с таким большим оборотом и неопытностью, коммуникация важнее, чем обычно.

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

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

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

Непрерывная интеграция -

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

CI - это идея рабочего процесса от написания кода до развертывания. Эти задачи концептуально и фактически независимы.

КИ, в частности, автоматизация. Это имеет большое значение для качества и производительности, начиная с того момента, когда код вводится на экране.

• Реализация задачи CI может быть рассмотрена независимо, подробно и одновременно. Фокус может сместиться по мере необходимости.
• Не вводите CI-суп с орехами
  • Вы будете отвлекаться на процесс и склонны отбеливать заключенные в капсулу навыки.
• Представьте вещи на ура за доллар

• Ожидайте быть постоянным агентом изменений. Стать лидером; не просто менеджер, не просто старший кодер.

• Быть стратегическим

  • Святой Грааль CI - это автоматическая система компиляции для автоматизации развертывания. Они не могут FUBAR это, если они не могут коснуться этого.
  • Обучение и учебные материалы.
    • Процессы документов.
    • Создайте Руководство программиста , дайте ему развиваться органично.
    • Обязательное.
    • Исследование описывает конкретные навыки и саму базу кода.
  • Привить профессиональные ценности программиста, такие как:
    • TDD абсолютно создает качество
    • Обзоры кода включают все артефакты: комментарии, закомментированный код, модульные тесты и т. Д.
    • «Я смущен тем, сколько ошибок было найдено»
    • Объективность не подавлена ​​чувством владения личным кодом и страхом «обидеть» владельца.

• Будь тактическим

  • Отдельные задачи CI могут быть автоматизированы, например, фиксация контроля версий, запускающая компиляцию и модульные тесты.
  • Правила на основе автоматизации, такие как форматирование кода.
    • Остерегайтесь слишком большого количества педантичных мелочей. Инструмент начнет игнорироваться. Модулируйте соблюдение правил, чтобы оно не было подавляющим.
  • Внедрите тестовую разработку прямо сейчас
  • Расставьте приоритеты и выделите каждое изменение
    • Не думайте, что ключевые знания и навыки просто случаются.
  • Не позволяйте срочности подорвать правильную реализацию
  • Привести изменения и выполнить
    • Требуется ориентация на нового парня и минимальное обучение.
    • Явное обучение и однозначное руководство для новых вещей
    • Тренируйтесь хотя бы по каким-то минимальным, условным, стандартам. Не обязательно быть формальным, но случайная прогулка по YouTube - это не тренировка. Лично проверю - еще раз соблюдю формальность.
  • Будьте рецензентом кода, просмотрите весь код.
    • Подробно проведите сложные исправления ошибок и поделитесь заметным опытом обучения.
  • Жесткая гибкость. Извините, пришлось это сказать. Но это правда.
• Создать культуру
  • Есть профессиональные ожидания
  • Стандартизировать инструменты
  • Подчеркните обучение над производственными метриками
  • Быть наставником
  • Внося изменения, просто в зависимости от инициативы отдельных лиц «сделать это так» тонко подрывает развитие команды. Индивидуальность сплоченной команды включает в себя ее общее: инструменты, знания и уровень квалификации. Взаимное уважение растет по мере того, как каждый член принимает тезисы как достойные ценности. Руководитель группы - это модель, это неизбежно; не смоделируйте «все» отношение и ожидания.

Дорога к качеству

• Модульное тестирование

  • ключ к разработке через тестирование
    • Чтение целых книг об этом не нужно
    • Это должно стать кодирования парадигмы
    • Как лидер, вы должны придерживаться этого, пока все не совершат «прыжок веры в модульное тестирование». Это изменение парадигмы от "Я пишу дважды код!" чтобы охватить его удивительную производительность.
  • Модульное тестирование было обязательным в нашем магазине. Но многие не делали этого, потому что не хотели. Отсутствие убежденности руководства дало понять, что юнит-тесты на самом деле не работают.
    • Поэтому при проверке кода модульные тесты слишком часто игнорировались, что позволяло вводить ошибочные, неэффективные и ошибочные тесты в базу кода. Недостаточное тестирование юнитов уничтожит все усилия.

• Управление версиями

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

• Кодовые обзоры

  • Это имеет наибольший потенциал для улучшения качества кода в деталях.
  • Используйте 2 процесса обзора.
    • Я был очень удивлен тем, сколько ошибок ловит второй обзор.
    • Доверяй, но проверяй. Запустите код. Почему ты должен даже говорить это? Смотри сразу выше.
    • Изначально вы будете единственным рецензентом. Сделайте так, чтобы команда смотрела ваш отзыв "вживую" Они никогда не научатся думать иначе.
    • Скоро вы будете просто вторым рецензентом. Как индивидуальные навыки гарантируют, что они рассмотрят; в итоге оба рецензента. Вы, конечно, всегда будете смотреть на код без исключения.

• Рефакторинг

  • Это отдельная, формальная дисциплина.
  • Рефакторинг: Улучшение дизайна существующего кода Мартином Фаулером
    • Кодифицированные рецепты рефакторинга, которые гарантируют безошибочную смену кода.
    • Начните профессиональную библиотеку с этой книгой.
  • Не считая формальности, представьте это ad hoc через обзоры кода

• Захват вашей среды

  • Базовые конфигурации инструмента: контроль версий, IDE, инструмент CI, ОС и т. Д.
  • Исходный код, документация, конфигурации должны синхронизироваться в управлении версиями.

Слово о процессе

Agile (и его поджанры, такие как Scrum): забудьте об этом. «Ты проворен, ты не проворен». Посмотрите их Дэйвом Томасом, одним из первых подписантов Agile Manifesto .

• Коррупция Agile - интервью от Dr. Dobbs Journal
• Agile мертв (да здравствует ловкость)
• Agile мертв - основной доклад конференции.

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

Слово об инструментах

Просто я. Не из тех «Лучших программных инструментов сейчас ...».

Дженкинс

Инструмент интеграции CI. Сетевой, широко используемый. По сути, через веб-интерфейс пользователя вы настраиваете и автоматизируете различные задачи и порядок выполнения, такие как компиляция, запуск модульных тестов, обновление контроля версий. Это очень A-La Carte, так что он подходит для вашей зарождающейся среды CI.

Управление версиями

Я предпочитаю Mercurial, а не Git. Именно из этого поста в блоге я и выбрал Mercurial: Git - это MacGyver, Mercurial - это Джеймс Бонд

Subversion это хорошо. Mercurial & Git имеют другую архитектуру, которая превосходит Subversion.

Интегрированная среда развития

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

Слово о профессиональной библиотеке

Интернет широкий, неглубокий и неорганизованный.

• Код завершен Стивом Макконнеллом
  • Заставьте всех читать среднюю треть.
  • Имеет приложение из предлагаемых профессиональных книг.
• Рефакторинг: улучшение дизайна существующего кода
  • Кодифицированные рецепты рефакторинга, которые гарантируют безошибочную смену кода.
• Программные сбои. Никаких конкретных рекомендаций, но это должны быть рассказы о трактате.

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

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

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

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

Это также подготовит ваших учеников к тому, на что будет похожа работа в «реальном мире», и привит им достаточно хорошие привычки.