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

9

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

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

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

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

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

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

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

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

darksinge
источник
Отвечают ли разработчики за свой QA?
svidgen
Когда появляется проект, разработчикам предъявляется ряд требований, и с этого момента все было на их усмотрение. Поэтому спрашивать, отвечают ли разработчики за свои вопросы и ответы, все равно что давать ребенку пистолет и спрашивать, отвечает ли ребенок за безопасное обращение с оружием.
Дарксинге
Итак, я предполагаю, что мы говорим о команде студентов-заочных разработчиков? А ты? ... Кто-нибудь в команде или штатные разработчики (> = 10 лет опыта) вообще?
svidgen
Есть пара постоянных разработчиков, которые работают удаленно, но мы их не видим (или вообще не видим). В офисе, да, все сотрудники - студенты, работающие неполный рабочий день. В настоящее время я работаю полный рабочий день, но скоро начинаю магистерскую программу, так что это может измениться;) У меня 5-летний опыт работы, а не большой опыт управления проектами.
Дарксинге
Еще не было времени для полного ответа. Но стоит кое-что рассмотреть: я пишу код около 20 лет. По крайней мере, 10 лет в профессиональной среде, среди других довольно старших людей. Разнообразие в том, что опытные разработчики программного обеспечения называют «хорошим» и «плохим» кодом, огромно . Хорошим первым шагом может быть формулирование того, что делает код «хорошим» или «плохим» таким образом, чтобы обеспечить границы, в которых поощряются эксперименты, поощряются креативность и инновации, а ваш опыт и мнения признаются ценными, но в конечном итоге ограниченными .
svidgen

Ответы:

4

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

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

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

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

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

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

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

  • Качество - обзор кода опытными разработчиками. В отсутствие опытных разработчиков, сделайте групповой обзор, чтобы как минимум охватить ваши основы как можно лучше.
  • Эффективность - если вы правильно ставите независимые задачи, вы сводите к минимуму людей, которые вынуждены ждать друг друга. В среде, где не все доступны одновременно, я предполагаю, что вы сталкиваетесь с большим количеством задержек «ожидания человека А». Следите за разработчиками, которые не добиваются прогресса, только для того, чтобы проверить, нужна ли им помощь или даже просто позволить им выразить свои разочарования (эти разочарования могут выявить неправильные представления о проблемах, которых можно избежать).
  • Коммуникация - Установите политику открытых дверей, чтобы разработчики могли обратиться к кому-нибудь за помощью, отзывами или вдохновением. В отсутствие квалифицированного наставника, попытайтесь облегчить взаимодействие команды (вы, конечно, можете сделать это, даже если у вас есть наставник, но важность этого возрастает в отсутствие наставника). Особенно в ситуации, когда люди работают удаленно и по разным графикам, разработчики часто не находятся рядом со своими коллегами и, как правило, не общаются между собой. Даже небольшое количество общественных собраний может творить чудеса для улучшения общения, связанного с работой, в другое время.
Flater
источник
Было несколько хороших ответов, но это было самым тщательным и прямым, спасибо!
Дарксинге
1
Это близко, но не совсем там. Я согласен с обзорами кода, но я страстно не согласен с опытным разработчиком, который делает исправления, которые создают чрезвычайно плохую петлю обратной связи, где самые неаккуратные кодеры забивают опытный кодер работой быстрее, чем они могут его очистить. Гораздо лучше отправлять отзывы обратно в исходный кодер и заставлять их выполнять работу. Это достигает цели научить их, как лучше кодировать, но также имеет преимущество в том, что замедляет неаккуратные кодеры, заставляя их переделывать, пока они не произведут программное обеспечение в соответствии с приемлемым стандартом.
Маккотл
@mcottle Вы опровергаете точку зрения, которую я никогда не высказывал. Рефакторинг - это не то же самое, что исправление. Если код не работает, его нужно отправить обратно, как вы сказали. Если проблема является второстепенным стилистическим аргументом, все равно важно обратиться к разработчику, но иногда проще исправить это, чем объяснять подробно. Преимущество заключается в том, что вы можете показать deceloper улучшенный код, чтобы они поняли, что вы имеете в виду.
Флэттер
8

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

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

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

Telastyn
источник
2
Я на самом деле немного скептически отношусь к этому. Я не согласен с тем, что обзоры кода должны быть обязательными ... Но вы говорите о кучке бестолковых разработчиков, которые просят отзывы от других бестолковых разработчиков - если только вы не думаете, что у ОП есть время, чтобы просмотреть и оставить комментарии ко всему . .. Я имею в виду. Может быть, это не так уж надумано. Зависит от притока. Но «обзоры кода» кажутся (мне) не более чем четвертью решения. Я имею в виду, в лучшем случае.
svidgen
@svidgen: я не думаю, что он защищал обзоры другими невежественными разработчиками. Он никогда не указывал явно (так что это могло бы пойти в любом случае), но, по моему опыту, обзоры чаще бывают либо опытными коллегами, либо людьми в цепочке (ведущим разработчиком), особенно в тех случаях, когда некоторые из склонностей разработчиков являются ненадежными или недоказанной.
Флатер
1
@svidgen - сначала они могут быть сделаны ведущим, но проблема в том, чтобы иметь разработчиков или невежественных разработчиков. Вы не решите это, не сделав некоторые невежественные. В идеале, будет несколько разработчиков, которые получат его, а затем смогут помочь в рассмотрении кода на менее критичные вещи.
Теластин
2

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

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

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

Нафанаил
источник
2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

Дженкинс

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

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

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

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

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

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


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

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

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

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

gkhaos
источник
1
что такое прототип vert; Вы можете расширить свой ответ, это довольно кратко, как есть.
Эзотерик
Извините, у меня было мало времени этим утром. Во-первых, [вертикальный прототип] (tutorialspoint.com/sdlc/sdlc_software_prototyping.htm) представляет собой тип прототипирования, который означает, что вы полностью создаете свое программное обеспечение без реализации каких-либо функциональных возможностей. Преимущества состоят в том, что, во-первых, предполагаемый покупатель может видеть, как может выглядеть продукт, во-вторых, он дает разработчику хорошее представление о том, какой должна быть функциональность / какие данные он должен предоставлять.
gkhaos
что вы подразумеваете под "довольно кратко"? Тип управления проектом довольно сложно определить, потому что он зависит от разных вещей, например, о чем ваш проект? Насколько велика ваша команда? Также, например, в схватке вам нужен мастер схватки, который должен иметь глубокие знания о схватке. Я просто пытался считать, что разборки - не единственный ответ на управление проектами.
gkhaos
0

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

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

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

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

user1118321
источник