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

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

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

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

Я не шукаю, скажімо, таких відповідей, як "Використовуйте Scrum", "Налаштуйте дошку kanban" або "Погляньте на спритність!" (хоча ідеї цінуються). Більш конкретно, я сподіваюся отримати уявлення про те, як реалізувати процес розробки для цього робочого середовища. Працівники, як правило, працюють від 1 до 2 років, перш ніж рухатися далі, як правило, недосвідчені, а щоденні зустрічі з автономним складом, які включають усіх, майже неможливо запланувати.

Як можна сприяти якості, ефективності та комунікації на такому робочому місці?

Оновлення: Прочитавши деякі відповіді та коментарі, я подумав, що надам додаткову інформацію.

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

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

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

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

Почніть використовувати гілки функцій, щоб усі працювали над окремою гілкою. Коли завдання закінчено, розробник не в змозі об'єднати свій код у головну гілку. Якщо ви використовуєте Git, вони все ще можуть запустити запит на виклик. В іншому випадку використовуйте будь-який метод відстеження готових завдань (/ гілок), який захоплює вас.

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

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

Якщо досвідчених розробників немає, то ви завжди будете стикатися з проблемами. Якщо немає хорошого коду від поганого коду, не можна продовжувати якість коду.
Найкраще, що ви можете зробити - це оглядові зустрічі, де розробники представляють та пояснюють їхню реалізацію перед іншими розробниками. Хоча це не може гарантувати запобігання кожної проблеми (наприклад, якщо всі розробники мають однакове помилкове уявлення про добру практику, воно все одно запобігає більшості питань (наприклад, якщо принаймні один розробник має правильну ідею і може сформулювати це; або коли проблема виникає) від розробників, які розуміють проблему по-різному один від одного)

Як можна сприяти якості, ефективності та комунікації на такому робочому місці?

• Якість - перегляньте код досвідченими розробниками. За відсутності досвідчених розробників, зробіть груповий огляд, щоб принаймні висвітлити ваші бази.
• Ефективність - Якщо ви правильно встановили незалежні завдання, ви мінімізуєте людей, які повинні чекати один одного. В умовах, коли не всі є одночасно доступними, я припускаю, що ви маєте справу з численними затримками "очікування на людину А". Слідкуйте за розробниками, які не досягають прогресу, лише щоб перевірити, чи потрібна їм допомога, або навіть просто дозволяють відмовитись від своїх розладів (ці фрустрації можуть виявити помилки щодо проблем, які можна уникнути).
• Комунікація - встановіть політику відкритих дверей, щоб розробники могли попросити когось про допомогу, відгуки чи натхнення. За відсутності кваліфікованого наставника, спробуйте полегшити командну взаємодію (ви, звичайно, можете це зробити, навіть якщо у вас є ментор, але важливість цього зростає за відсутності наставника). Особливо в ситуації, коли люди працюють віддалено і за різним графіком, розробники часто не наближаються до своїх колег і прагнуть не спілкуватися між собою. Навіть жменька соціальних зборів може творити чудеса для покращення спілкування на роботі в інший час.

Найбільше в такому середовищі, де люди є новими і, ймовірно, залишаються, це обов'язкові огляди коду.

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

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

Більше ідеї, ніж рішення, але знайдіть один критичний розділ кодової бази, який містить подібні функції та елементи для проектів, які могли б зробити ваші студентські розробники та очистити її ДУЖЕ добре. Одна з великих проблем нових розробників полягає в тому, що вони не знають норм і умов конвеєрної бази, і вони роздивляться інший код, щоб отримати уявлення про те, як налаштувати свій власний. Маючи багато нових розробників, які працюють у безладній кодовій базі, це означає, що вони побачать безлад і подумають, що це прийнятно чи найкращий спосіб робити речі. Тоді погані практики увічнюють себе навіть у високому перетворенні.

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

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

Постійна інтеграція -

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

CI - це ідея робочого потоку від написання коду до розгортання. Ці завдання концептуально і фактично є незалежними.

CI - це автоматизація, зокрема. Це має глибокі наслідки для якості та продуктивності, починаючи з того моменту, коли код набирається на екрані.

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

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

• Будьте стратегічними

  • Святий Грааль CI - це рукописний, складений для автоматизації розгортання. Вони не можуть FUBAR, якщо вони не можуть доторкнутися до нього.
  • Навчальні та навчальні матеріали.
    • Процеси документування.
    • Створіть Посібник для програміста , нехай воно розвивається органічно.
    • Обов’язково.
    • Дослідження окреслює орієнтацію на конкретні навички та саму базу коду.
  • Прищеплюйте професійні значення програміста, такі як:
    • TDD абсолютно створює якість
    • Огляд коду включає всі артефакти: коментарі, коментований код, одиничні тести тощо.
    • "Мені бентежить, скільки помилок знайдено"
    • Об'єктивність не задушується почуттям володіння особистим кодом та страхом "образити" власника.

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

  • Дискретні завдання CI самі по собі можуть бути автоматизовані, наприклад, контроль версій, який здійснює запуск компіляції та тестування одиниць.
  • Автоматизовані правила, такі як форматування коду.
    • Остерігайтеся занадто багато педантичних дрібниць. Інструмент почне ігноруватися. Модулюйте виконання правил, щоб це не було непосильним.
  • Впровадьте тест-керовану розробку відразу
  • Визначте пріоритети та підкресліть кожну зміну
    • Не припускайте, що ключові знання та навички можуть відбутися просто.
  • Не дозволяйте терміново підривати належну реалізацію
  • Ведіть зміни та дотримуйтесь їх
    • Необхідна нова орієнтація на хлопця і мінімальна підготовка.
    • Явна підготовка та однозначні вказівки щодо нових речей
    • Навчіть хоч якісь мінімальні, вигадані стандарти. Це не повинно бути справжнім формальним, але випадкова прогулянка по YouTube не є навчальною. Переконайтесь особисто - знову відмовтеся від формальності.
  • Будьте переглядачем коду, перегляньте весь код.
    • Явно керуйте складними виправленнями помилок та діліться помітним досвідом навчання.
  • Жорстка гнучкість. Вибачте, довелося це сказати. Але це правда.
• Створюйте культуру
  • Майте професійні очікування
  • Стандартизуйте інструменти
  • Підкресліть навчання над виробничими показниками
  • Будьте наставником
  • Вводячи зміни, просто залежно від ініціативи людей "зробити так" субтильно підриває розвиток команди. Ідентичність згуртованої команди включає її загальне: інструменти, знання та рівень майстерності. Взаємна повага зростає, наскільки кожен член приймає тези як гідні цінності. Лідер команди - модель, вона неминуча; не моделюйте "будь-яке" ставлення та сподівання.

Шлях до якості

• Блок тестування

  • ключ до тестової розробки
    • Читати про це цілі книги не обов’язково
    • Це повинно стати кодування парадигми
    • Як лідер, ви повинні дотримуватися цього, поки кожен не зробить "одиничний тест стрибок віри". Ця парадигма зміна від "Я пишу два рази код!" щоб охопити її приголомшливу продуктивність.
  • Тестування приладів було обов'язковим у нашому магазині. Але багато хто цього не зробив, бо цього не хотів. Відсутність переконання керівництва надіслала повідомлення про те, що одиничні тести дійсно не працюють.
    • Тож одиничні тести занадто часто ігнорувались під час огляду коду, дозволяючи невірно, неефективно і багі тести в базі коду. Недостатні випробування одиниць зруйнують усі зусилля.

• Контроль версій

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

• Огляди коду

  • Це найбільший потенціал для детального поліпшення якості коду.
  • Скористайтеся процесом 2 перегляду.
    • Я був дуже здивований, скільки помилок назбирає другий огляд.
    • Довіряйте, але перевіряйте. Запустіть код. Чому ви навіть повинні це сказати? Дивіться безпосередньо вище.
    • Спочатку ви будете єдиним рецензентом. Запропонуйте команді спостерігати, як ви переглядаєте "наживо". Вони ніколи не навчаться думати інакше.
    • Незабаром ви будете лише другим рецензентом. Оскільки індивідуальні навички вимагають перегляду їх; врешті обидва рецензенти. Ви, звичайно, завжди будете дивитися на код без винятку.

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

  • Це виразна формальна дисципліна.
  • Рефакторинг: вдосконалення дизайну існуючого коду Мартіна Фаулера
    • Кодифіковані рецепти рефакторингу, які забезпечують вільну зміну коду від індукованої помилки.
    • Почніть професійну бібліотеку з цієї книги.
  • Формальність в сторону, введіть її спеціально за допомогою оглядів коду

• Захоплюйте своє оточення

  • Конфігурації базових інструментів: контроль версій, IDE, інструмент CI, ОС тощо.
  • Вихідний код, документація, конфігурації повинні синхронізуватися в контролі версій.

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

Agile (та його піджанри, як Scrum): Забудьте про це. "Ти спритний, ти не робиш спритного". Ознайомтеся з ними Дейвом Томасом, одним із оригінальних підписантів маніфесту "Agile" .

• Корупція спритного - інтерв'ю журналу "Доктор Доббс"
• Agile мертвий (довго живуть спритність)
• Agile мертвий - основна конференція.

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

Слово про інструменти

Тільки я. Не з тих "Найкращих програмних засобів зараз ..." медоносні горщики.

Дженкінс

Інструмент інтеграції CI Веб-основа, широко використовується. По суті, через веб-інтерфейс користувача ви налаштовуєте та автоматизуєте різні завдання та порядок виконання, такі як компіляція, виконання тестів одиниць, оновлення контролю версій. Це дуже A-La Carte, тому він підходить до вашого зароджуваного середовища CI.

Контроль версій

Я віддаю перевагу Меркуріалу над Гітом. Цей пост у блозі, чому я спочатку вибрав Mercurial: Git - це MacGyver, Mercurial - Джеймс Бонд

Підрив - це добре. Mercurial & Git мають іншу архітектуру, яка краща за підривну.

Інтегроване середовище розробки

Ось великий розгляд жиру, якщо всі використовують різні засоби кодування: Немає такої речі, як звичайний текст

Слово про професійну бібліотеку

Інтернет широкий, неглибокий і неорганізований.

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

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

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

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

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

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