Перехід від проекту одного чоловіка до командного проекту в майбутньому. Що мені робити зараз під час підготовки і що можна чекати?

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

Кожен, хто має будь-який досвід просування цього сценарію, їхню оцінку оцінять.

Що я навчився. (Я спробував інший порядок. Я помилявся. Це порядок, у якому речі стають актуальними.)

1. Покладіть все на контроль вихідного коду. Використовуйте те, до чого кожен має доступ, і почніть прямо зараз . Немає винятків. Ніяких затримок. Ніяких виправдань.

2. Створіть QA / тестову зону, яка повністю відокремлена від вашого особистого "робочого" чи "розвивального" середовища. Принаймні окремий ідентифікатор користувача. В ідеалі на окремому VM.
   Цілком окремо. Неможливо перетинатися з вашим поточним робочим середовищем.

3. Не припиняйте тестування за межі тестування у власних робочих умовах Код і одиничний тест ви робите "як самі". Всі інші тестування (інтеграція, продуктивність, що завгодно) ви робите на окремому VM. Ніколи не тестуйте себе. Завжди тестуйте як окремого користувача QA. В ідеалі на окремому VM.

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

4. Плануйте все записати. Використовуйте інструмент розмітки простого тексту (RST або Markdown або щось подібне), щоб вся документація була звичайним текстом у сховищі контролю версій. Інструмент може створювати HTML-сторінки (тобто Docutils для RST) або PDF-файли або все, що здається найкращим. Не використовуйте власні формати документів (наприклад, MS-Word). Вони можуть не грати добре з деякими системами управління вихідним кодом.

5. Перші речі, які вам потрібно записати, - це наступне.

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

   • Як запустити набір тестових модулів. Знову. Будьте впевнені, що інструкції працюють і не потребують роздумів. "Введіть це:" "Підтвердіть, що:" вид матеріалів. Справа не в тому, що члени вашої команди дурні. Це те, що ти не пам’ятаєш, що ти припускаєш, якщо все це не запишеш.

   • Як запустити набір тестів на інтеграцію.

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

6. Наступні документи, які потрібно документувати, - це історії користувачів. І тестові справи, які підтримують ці історії. І прилади даних, необхідні для тестових випадків, які підтримують ці історії користувачів.

   Ви поділитесь цим. Він перебуває під контролем вихідного коду.

7. Зрештою ви можете задокументувати інші 4 перегляди.

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

   • Перегляд процесу часто корисний. Залежно від загальної програми, наскільки це важливо.

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

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

   • Інформація про розгортання. Сервери. IP-адреси. Вхідні дані бази даних. Усі ці речі повинні бути записані. Врешті-решт

Інструменти та методологія

Що потрібно для успішної співпраці та для продуктивності?

• Визначте частини / компоненти вашого проекту: чітко розмежуйте різні частини (база даних, рівень доступу до даних, веб-сайт, сервіс, API, тестові проекти, сценарії побудови, ...) та середовища (розробник, постановка, виробництво) та називаючи їх послідовно впливає на ваше усне та письмове спілкування (документація, назви проектів, ...)
• Використовуйте систему управління вихідним кодом (про всяк випадок, якщо ви цього ще не зробили). Подумайте, як використовувати розгалуження для свого проекту та налаштування.
• Автоматизуйте свої збірки - зробіть це максимально простим у створенні середовища з вашого вихідного сховища.
• Тестові проекти є обов'язковими для великих проектів, принаймні для більш складних проектів.
• Використовуйте сценічні середовища, де ваш проект готовий до використання. Крім того, створіть та підтримуйте вибіркові дані для автоматизованого налаштування постановки.
• Використовуйте систему відстеження помилок, яка може допомогти розставити пріоритети та планувати розробку, а також служить пам'яттю для попередніх помилок та способів їх вирішення.
• Документуйте кожну частину свого проекту, трохи більше, ніж інші. Мені особисто подобається: Огляд - Архітектура - Залежності - Конфігурація - Загальні проблеми ( звідси ). Іноді менше - більше, щоб не дати застаріти вашій документації, краще бути стислим і нехай документація стане частиною вашої повсякденної діяльності.

Управління / робота в команді

... або що-небудь ще на міжособистісному рівні

• Визначте ваші очікування від іншого розробника. Будьте розумні, ніхто, ймовірно, не викликає такої ж привабливості та пристрасті, як і ви - принаймні, не з самого початку. Повідомте, що ви очікуєте, а що ні, визначте свої та інші обов'язки. Не всі - інженер, архітектор, розробник, dba та sysadmin, але якщо це те, що ви шукаєте, виберіть потрібну людину, або ви розчаруєтесь.
• На першому , визначити завдання точно , а також огляд і обговорення результатів. Поступово починайте все менше і менше мікроуправління. Ідея полягає у формуванні довіри та посиленні відповідальності.
• Сплануйте свій проект , встановіть цілі для свого проекту та для своєї команди на наступний рік. Запишіть це та перевірте пізніше, це дасть перспективу . Ці цілі можуть бути передані або не можуть бути передані іншим (якщо це цілі, яких вам потрібно досягти, а не іншим), вони можуть бути просто вашим власним контрольним списком.
• Візьміть день, щоб підготуватися і спланувати перший місяць (або два / три місяці) вашого нового розробника. Я вважаю це надзвичайно мотивуючим при роботі з добре підготовленими людьми. Ніхто не повинен створювати враження, що його / її час витрачається даремно.
• Відпустіть . Це ваша дитина, вона також повинна стати чужою. Дозвольте іншому стати експертом кращим за вас, принаймні в деяких частинах проекту. Це означає, що ви насправді досягли успіху.
• Слухай - якщо ти її найняв, вона має щось сказати. Будьте готові вчитися.
• Будьте готові поділитися своїми знаннями та досвідом (а отже, час - будьте терплячі).
• Помилки будуть зроблені, це як їх обробляти і що всі дізнаються про них, що є важливим.
• Дайте час вивчити та експериментувати

Довідники на книги

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

Ці книги справді варто прочитати стосовно команд, організацій та проектів програмування:

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

Жоден із них не є практичним посібником щодо того, як реалізувати методологію X (окрім оцінки програмного забезпечення, ці книги допомагають вибрати відповідний процес оцінки). Звичайно, книги, більш орієнтовані на саме програмування, як Code Complete, також дуже збагачують.

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

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

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

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

На тему "чистий, швидкий, багаторазовий код" - пропоную на співбесіді попросити написати невелике мікроядро / менеджер служби та / або виконавець роботи. Подивіться, як вказані та налаштовані підключаються компоненти. Це не повинно бути закінченим, це важлива думка. А також ви швидко навчитесь людям, які добре знають, як це зробити, захочете гідних грошей ;-) Удачі!

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

Автоматизація побудови: Чудова ідея, чи можу я додати автоматизацію конфігурації для машини розробників. Найпростіше побудувати, тим більше буде (тим більше / швидше тестування розгортання).

Ще одна ідея (вона мені колись дуже допомогла): Попросіть нового розробника виконати кілька прибирань невеликих масштабних завдань у різних областях вашої кодової бази, щоб він звик до інструментів компонування тощо. Одна гарна ідея - видалити незрозумілі області, які згодом можуть додавати плутанину (наприклад: якщо ви використовували емм-питон для двох рядків сценарію оболонки десь і ваш проект базується на Java, попросіть ці два рядки переписати в java, щоб розробнику №3 було потрібно знайте менше, щоб працювати)

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

• встановити керування версіями та замінити резервні копії вручну на автоматизовані,
• максимально налаштувати автоматичне розгортання (як мінімум, написати сценарій для розгортання через FTP, а не робити це вручну.

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

Іншим важливим завданням є, як зазначає @dimitris, документація. @S. Лотт додав про це набагато більше деталей, тому просто +1 йому, а не повторюючи :-)

Ось кілька думок, частково заснованих на особистому досвіді:

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

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

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

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

• Використовуйте систему контролю ревізії . Підтримуйте логічний макет вихідного файлу та будуйте дисципліну .

Щодо інтерв'ю - я не є великим прихильником тестів на штучне кодування або хитрощів, якщо ви не хочете спробувати здатність кандидата витримати стрес. Навіть найрозумніші вирішувачі проблем можуть зациклюватися в такій ситуації. Якісні якості, яких ви шукаєте, серед інших: чесність , професійні можливості , технологічні знання / проникливість , ентузіазм та взаємна сумісність . Робоча атмосфера може означати дуже багато; не доцільно вибирати товариша по команді, який вам не подобається. Поставте свої питання правильно та проведіть кілька неофіційних дискусій, щоб отримати гарну картину свого кандидата. Удачі!

Технологія

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

1. Контроль джерела
2. Відстеження випусків
3. Постійна інтеграція

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

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

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

http://www.pragprog.com/Sense/tpp/the-pragmatic-programmer http://www.pragprog.com/titles/tsgit/pragmatic-version-control-using-git http: //www.pragprog. com / заголовки / авто / прагматичний-автоматизація проектів

Особисті

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

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

На мою думку, найважливіші моменти:

1. Прочитайте важливі частини коду та переконайтеся, що їх легко зрозуміти. Використовуйте коментарі або інтуїтивні назви функцій та змінних.
2. Спростіть нову особу для надсилання коду.
3. Якщо це не банально, зробіть файл README, який пояснить усі необхідні кроки для нового розробника щодо налаштування середовища розробки. Крім того, тісно допомагають у створенні цього середовища.
4. Дайте новому розробнику дуже чітко визначені завдання під час роботи над цим новим проектом. На мою думку, ці завдання повинні включати нові, але прості функціональні можливості. Завдання з очищення не мають особливого сенсу на мою думку, оскільки новий розробник спочатку повинен звикнути до вашого стилю кодування та тих звичок у ньому, навіть якщо вони погані. Прибирання або навіть рефакторинг - це завдання, які повинні виконувати люди, які знають код.
5. Уявіть, що таке процес надсилання коду. (Наприклад, надсилайте лише ті матеріали, які складаються.) Але не будьте занадто суворими, це може засмутити на початку.
6. Підготуйте документ із умовами кодування. Дуже неприємно здогадуватися, що таке інші умови кодування.
7. Якщо додаток складний, готуйте деяку документацію, яка пояснює архітектуру. Або поясніть архітектуру новій людині за допомогою діаграм потоку або чогось подібного. Ви не хочете, щоб новий розробник витрачав занадто багато часу на реверсивну інженерію свого проекту.
8. Якщо новий розробник повинен виконувати розгортання самостійно, майте готовий упорядкований контрольний список, в якому пояснюються всі необхідні кроки для розгортання.

І останнє, але не менш важливе: отримати систему контролю версій. Підрив - це просто чудово. Але обов'язково не додайте ті файли Eclipse (або будь-які інші), які є специфічними для користувача і тому постійно змінюються. Вони змушують вас витрачати години. Не соромтеся запитати у Stackoverflow, якщо у вас є проблеми.