Як переконати своїх товаришів по команді дотримуватися деяких основних правил

У мене проблеми з товаришами по команді. Коротка розповідь: ми троє студентів, які працюють над проектом для конкурсу. Проект складається з двох окремих додатків: одного для Windows (який я розробляю) та одного для Android (мої колеги відповідають за його розробку). Наші кодові бази ніколи не перетинатимуться, додатки будуть спілкуватися за допомогою сторонніх інструментів.

Проблема полягає в наступному: я маю певний досвід роботи в командах, коли я проходив стажування у великій компанії в минулому році, і намагаюся застосувати деякі стандарти кодування нашого коду. Я також створив програмне сховище git / wiki / співпраця, яке ми можемо використовувати для просування коду / написання ідей, документових протоколів тощо, але, здається, я єдиний, хто використовує ці інструменти.

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

Більшість кодів однолітків знаходиться на своїх комп’ютерах, вони не мають спільної кодової бази, і, як я з'ясував, вони інтегрували свої фрагменти, зустрівшись і ділившись кодом через usb stick.

Моє запитання: чи я занадто суворий з цього приводу? Чи слід застосовувати якісь абсурдні правила? Майте на увазі, що це невеликий проект, вимоги дуже чіткі (я створив документи, що вказують, що повинні робити додатки), три кваліфіковані розробники могли це зробити за 3-4 дні, щоб вони не побачили додаткової складності якості запису код, поки їх діючий метод просто працює.

Чи є спосіб, щоб я міг показати їм перевагу документування коду, використовуючи git тощо?

Моє запитання: чи я занадто суворий з цього приводу?

Ви можете вести коня до води, але ви не можете змусити його пити.

Важко сказати, чи є ви "занадто суворими", але, можливо, нереально сподіватися, що ваші товариші по команді приймуть всю інфраструктуру, на яку ви сподіваєтесь. І справді, якщо команда працює добре разом, використання вікі для спілкування між трьома людьми, ймовірно, буде надмірним.

Зменшіть свої очікування та шукайте шляхи досягнення деяких своїх цілей, не вимагаючи від них починати використовувати інструменти, які вони не знають. Якщо вони не знають, як користуватися git, вони, мабуть, не отримають від цього великої користі. Однак ви все ще хочете переконатися, що весь код резервного копіювання у разі поломки жорсткого диска чи іншої катастрофи, тому попросіть їх періодично копіювати свою папку проекту на Google Drive, Dropbox або подібну онлайн-службу обміну файлами. Переконайтесь, що ви робите те саме.

Моє ставлення до того, що якщо ти зможеш навчитися робити ці речі на невеликих проектах, ти будеш готовий, коли з’являться великі проекти.

Якщо вони дотримуватимуться належної практики розвитку у цьому проекті, вони матимуть код, який можна буде показати майбутнім роботодавцям, і вони матимуть досвід, який зробить їх цінними як співробітників.

Якщо ви хочете отримати більше матеріалів, щоб переконати їх, я б посилався на Прагматичного програміста або Кодексу .

З іншого боку, розгляньте, як нарізати їх деяким млявим. Якщо проект є доказовою концепцією, яка отримує пошкодження відразу після змагань, то вам слід подумати про те, щоб дозволити їм робити так, як їм подобається. Вони, можливо, намагаються просто написати код в першу чергу, не маючи душевних витрат належних практик.

Боюся, що описані вами правила зовсім не є основними.

Найпростіше завдання IMO - переконати своїх товаришів по команді використовувати деякі стандарти кодування. А простий спосіб досягти цього - показати їм той самий фрагмент коду, коли він буде добре відформатований, а потім погано стилізований, попросити їх прочитати код, зрозуміти, що він робить, і нехай вони самі судять.

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

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

Що ви можете зробити, це зробити короткі та прості демонстрації, щоб показати, як ці інструменти використовуються. Спочатку висвітліть основні функції, сядьте поруч і допоможіть їм використовувати інструменти. Будьте готові виконувати всі такі завдання, як налаштування git, створення структури wiki-сторінки тощо.

Редагувати : Відповідаючи на коментар, я вважаю, що встановлення чітких завдань, оцінок та термінів і відстеження витраченого часу важливіше, ніж використання git чи подібних інструментів. Якщо ви плануєте працювати над додатком пізніше, дуже важливо слідкувати за тим, що вже зроблено, і скільки часу займає кожна функція. Тому я пропоную почати з управління завданнями, а потім перейти до інструментів, які ви хочете використовувати.

Насправді мені подобаються власні думки Джоела Спольського, як він викладав у "Виконувати речі, коли ти лише грунт" . Узагальнити:

1. Просто робіть це - пишіть файли, створюйте щоденний сервер побудови тощо.
2. Ніхто не використовує керування джерелами або бази даних про помилки? Почніть використовувати їх самостійно. Якщо хтось повідомляє про помилку проти вашої роботи, попросіть їх ввічливо використовувати базу даних про помилки, щоб повідомити про ваші помилки, щоб ви могли відстежувати їх; інакше ви не зможете тримати їх прямо в голові та виправляти. У будь-якому нетривіальному проекті може виникнути ситуація, яка вирішується лише з керуванням джерелом: використовуйте керування джерелом для коду самостійно і героїчно переходьте, щоб зберегти день виникнення такої ситуації. Як тільки це станеться кілька разів, вони переконаються
3. Створіть кишеньковий майстерність - робіть правильні речі для себе: промальовування, планування тощо. Оскільки це не здається робочим проектом, це не виглядає так, що ви можете користуватися цією порадою до кінця, оскільки не можете найняти нових членів команди, які вірять у ваше повідомлення
4. Станьте цінним - продемонструйте, що ви чудовий внесок у зміцнення свого впливу в команді. Інакше ви ризикуєте стати відомим як людина, яка цінує процес та інструменти над результатами

Документація, Wiki, версії програмного забезпечення для версій, методології тощо - це досвід та уроки, засвоєні з часом; робота над декількома проектами та, ймовірно, над кількома командами. І це зазвичай дотримується тих, хто вже працює або хто серйозно ставиться до своєї галузі. Вони студенти, тому їхні інтереси, ймовірно, обмежені, ніж те, що станеться в майбутньому. :)

Але спробувати відповісти на ваше запитання:

Якщо ви знаходитесь в команді з ними, вам потрібно застосувати те, що ви вважаєте важливим, таким чином, щоб вигідно їх інтересам. Як приклад: Чи повинні вони скаржитися на те, що їх код сильно порушився, коли usb-спільний доступ до нього? Тоді, можливо, дайте їм простий (не складний) спосіб використання SVN (а не git) як інструменту версії.

Я також згоден з коментарем arnaud.

Ви бачили перевагу всіх цих інструментів, коли працювали з ними, і саме тому ви бачили в них цінність і чому ви розумієте їх використання. Якщо товариші по команді не бачать доданої вартості в тому, як вони зараз роблять справи, вони не застосовуватимуть її. І сумно, що це навіть рахується для команд, що складаються з людей з будь-яким рівнем досвіду.

У підходу є проблеми:

1. Ваш підхід не симетричний. Інші члени вашої команди потребують змін, але ви не вивчаєте їх належних практик. Дотримуватись правил у подібній ситуації важко. Кращим підходом було б збирати хороші правила та практики від усіх членів команди, і тоді всі просто читають отриманий документ.

2. Навчитися важко. Правила інших людей просто не мають сенсу, оскільки ці правила не мають тієї логічної структури, яку очікують ваші програмісти. Застосування правил, які не мають сенсу, не є корисною діяльністю.

3. Всі дізналися різні речі. Цілком природно, що програмісти, що приїжджають з різного походження, навчилися різного. Їх сильні сторони різні, а стилі написання коду різні. Інструменти, якими вони користуються, різні. Застосування одного набору правил / інструментів / стилів стане кошмаром, оскільки обмеження втрачають сили, на які розробники витратили роки на навчання.
4. Зміна вимагає часу. Хоча людина, яка винайшла правила, які ви застосовуєте, має досить простий час за правилами, всі інші страждають і витрачають час на вивчення нових правил. Це одна з причин, чому всі в команді повинні мати можливість змінювати правила.
5. Вибір інструментів / умов кодування або стилів для цілої команди - це важка діяльність . З часом це можна робити лише повільно, перевіряючи, які речі працюють, а які - не працюють. Дати команді 2 тижні, щоб почати дотримуватися 50 правил, не вийде.

Я знайшов цю проблему в університеті. Багато людей просто не бажають освоювати інший (а може бути, і більш професійний підхід) спосіб роботи.

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