Як найкраще залучати молодшого розробника до проектування програми з нуля? [зачинено]

Ми команда з 3 розробників (2 досвідчені розробники та молодший).

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

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

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

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

Ми думали про кілька підходів:

• нехай він спробує самостійно спробувати пару днів, потім втрутиться та переробляє код разом із ним, спрямовуй його в правильному напрямку, а потім повтори => Можливо, це не буде цікавим досвідом для нього, оскільки ми вкажемо на його помилки на кожному рефакторі ;
• дозвольте йому парувати програмування з одним із нас => він може стати просто «спостерігачем» і погодитися з усім, що ми робимо, не насправді багато навчившись і не перетравивши значну частину інформації;
• змусимо нас скласти каркас кожного модуля, з надійною конструкцією, а потім надавши йому модуль, щоб додати відсутні деталі => може бути не цікаво забрати за нами, і є ризик, що він зверне лише увагу на заповнення прогалин а не на всю конструкцію.

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

Я рекомендую наступні вказівки:

• Залучайте молодшого розробника до своїх дизайнерських зустрічей і вимагайте його вкладу. Це змусить його замислитися над великою картиною, навіть якщо він не готовий сам зробити дизайн високого рівня.
• Спробуйте ізолювати та чітко визначити модуль програми, який потрібно призначити молодшому розробнику. Опишіть письмово, що таке входи / виходи та інші вимоги модуля. Уникайте присвоєння йому модуля, який неможливо легко перевірити, або який можна перевірити лише тоді, коли він інтегрований з іншими, які ще потрібно записати.
• Можливо, молодший розробник міг би допомогти іншими способами, крім кодування основного додатку. Наприклад, він міг написати тестовий код. Написання хороших тестових сценаріїв, що не є обов'язковою роботою, є цінним внеском у проект, а також дає молодому розробникові чітке розуміння проекту.

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

• ця функція дає N кількість персон з таблиці персоналу
• ця функція забезпечує статистику персоналу з урахуванням ідентифікатора персоналу

->

Завдання: створити сторінку зі списком персоналу, який показує його / її статистику, коли натискається на кадровий запис. Ось простий зразок сторінки, побудований раніше в проекті.

Найважливішим аспектом даної задачі є вирішення саме цих ресурсів і не потребує в них змін.

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

Проблема з програмуванням пари не виникне, якщо ви будете дотримуватися процесу перемикання капелюхів / мислення кожні 10 хвилин (або близько того), не виняток, слідуючи процесу, спочатку описаному Кентом Беком (я не пам'ятаю, де)

Що стосується залучення інших людей до проектування - то, що ми виявили, що допомагає, якщо на етапі проектування створюються якісь конструкторські документи (з деякими моделями UML). Інші люди (ваш молодший) можуть потім перечитати їх, переглянути їх, зіграти захисника диявола. Ця роль незалежної третьої сторони може бути дуже корисною, наприклад, для розвідувальних випробувань - http://www.softwaretestinghelp.com/exploratory-testing-beyond-traditional-testing-границі