Как убедить моих товарищей по команде следовать некоторым основным правилам

У меня проблема с моими товарищами по команде. Короче говоря: мы трое студентов, работающие над проектом для конкурса. Проект состоит из 2 отдельных приложений: одно для Windows (которое я разрабатываю) и одно для Android (мои коллеги отвечают за его разработку). Наши базы кода никогда не будут пересекаться, приложения будут взаимодействовать через сторонние инструменты.

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

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

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

Мой вопрос: я слишком резок в этом вопросе? Должен ли я применять некоторые абсурдные правила? Имейте в виду, что это небольшой проект, требования очень ясны (я создал документы, в которых указано, что должны делать приложения), три опытных разработчика могут сделать это за 3-4 дня, поэтому они могут не увидеть дополнительную сложность качества письма код до тех пор, пока их текущий метод просто работает.

Можно ли как-нибудь показать им преимущества документирования кода, использования git и так далее?

Мой вопрос: я слишком резок в этом вопросе?

Вы можете привести лошадь к воде, но вы не можете заставить ее пить.

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

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

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

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

Если вам нужны дополнительные материалы для их убеждения, я бы обратился к прагматическому программисту или к Code Complete .

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

Боюсь, что описанные вами правила не являются базовыми.

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

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

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

Что вы можете сделать, это сделать короткие и простые демонстрации, чтобы показать, как используются эти инструменты. Сначала рассмотрите самые основные функции, сядьте рядом с ними и помогите им использовать инструменты. Будьте готовы выполнить все задачи, такие как настройка git, создание структуры вики-страницы и т. Д.

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

Мне на самом деле нравятся собственные мысли Джоэла Спольски, которые он изложил в книге «Как все сделать, когда ты только хрюканье» . Обобщить:

1. Просто сделайте это - напишите make-файлы, создайте ежедневный сервер сборки и т. Д.
2. Никто не использует систему контроля версий или базы данных ошибок? Начните использовать их самостоятельно. Если кто-то сообщает об ошибке в вашей работе, попросите его вежливо использовать базу данных ошибок, чтобы сообщать вам об ошибках, чтобы вы могли отслеживать их; иначе вы не сможете держать их прямо в голове и исправлять их. В любом нетривиальном проекте будет ситуация, которую можно решить только с помощью контроля версий: используйте контроль исходного кода для кода самостоятельно и героически налетайте, чтобы спасти день, когда такая ситуация возникнет. Как только это произойдет несколько раз, они убедятся
3. Создайте карман совершенства - Делайте правильные вещи для себя: спецификация, планирование и т. Д. Поскольку это не похоже на рабочий проект, не похоже, что вы можете воспользоваться этим советом полностью, так как вы не можете нанять новые члены команды, которые верят в ваше сообщение
4. Станьте бесценным - продемонстрируйте, что вы большой вкладчик, чтобы закрепить свое влияние в команде. В противном случае вы рискуете стать известным как человек, который ценит процесс и инструменты за результаты

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

Но чтобы попытаться ответить на ваш вопрос:

Если вы работаете в команде с ними, вам нужно применять то, что вы считаете важным, таким образом, чтобы это отвечало их интересам. В качестве примера: должны ли они жаловаться на то, что их код сильно ломается, когда его разделяет usb? Тогда, возможно, дайте им простой (не сложный) способ использования SVN (а не git) в качестве инструмента управления версиями.

Я также согласен с комментарием от Арно.

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

Подход имеет проблемы:

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

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

3. Все узнали разные вещи. Естественно, что программисты из разных областей научились разным вещам. Их сильные стороны разные, а стили написания кода разные. Инструменты, которые они используют, разные. Соблюдение одного набора правил / инструментов / стилей станет кошмаром, потому что ограничения теряют силу, которую разработчики потратили на обучение годами.
4. Изменение требует времени. Хотя человеку, который придумал правила, которые вы применяете, довольно легко следовать правилам, все остальные страдают и тратят время на изучение новых правил. Это одна из причин, по которой каждый в команде должен иметь возможность менять правила.
5. Выбор инструментов / правил или стилей кодирования для всей команды - сложная задача . Это можно сделать медленно, проверяя, что работает, а что нет. Давать команде 2 недели, чтобы начать следовать 50 правилам, не сработает.

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

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