Як ввести код колезі

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

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

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

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

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

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

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

Дякую!

(Як завжди, будь ласка, редагуйте питання так, як вважаєте за потрібне.)

Перший крок - це, звичайно, видалити "козирки" з коду. Чіткий, стислий, послідовний код легше вводити, працювати з налагодженням.

З чого ви починаєте?

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

Як ви висвітлюєте незнайомі технології чи зразки слухача, не займаючи цілий день?

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

Де ви пов'язуєте бізнес-логіку з кодовою структурою?

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

Варто пам’ятати про те, щоб інструкція була короткою. Люди, як правило, перевіряють досить швидко, тому будь-яка інша інструкція в цей момент просто не «притримується». Покажіть їм речі на 15-60 хвилин (різні люди мають різні проміжки уваги), потім зробіть 5-30-хвилинну перерву, щоб обробити це.

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

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

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

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

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

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

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

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

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

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

Звичайно, ваші існуючі ідеї широкого огляду та блок-діаграм є важливими першими кроками.