Як ви відстежуєте, які класи та функції написала ваша команда?

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

Чи існує певна практика документування таких речей? Як зробити їх легко знайти?

Якщо у вашої команди немає такої документації, як дізнатись, чи вже існує ваше колесо?

Редагувати:

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

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

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

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

Чи є ще ідеї в цьому напрямі ... для ізольованих і напружених часом розробників?

Бібліотеки. Каркаси. Контроль версій.

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

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

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

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

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

Перебуваючи в компанії з 700 працівниками, в колективах від 2 до 20 осіб, ось мій досвід.

На командному рівні

У нас "щоденні зустрічі" проходять щодня протягом 15-20 хвилин. Ми можемо швидко поділитися загальними знаннями на кшталт "Я цю функцію виконував вчора, вона так важко качається".

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

На рівні агентства

На рівні агентства у нас є 4 інструменти:

• Ще одна вікі. Це, головним чином, там, щоб дати нам інформацію про обладнання та інше, але ми іноді використовуємо його для обміну технічною інформацією, яку потрібно переглянути, перш ніж розміщувати її на рівні компанії.
• Щотижневі зустрічі. Вони здебільшого знають прогрес кожної команди / проекту, але оскільки ми в основному є ентузіастами технологій, ми можемо запропонувати класні речі.
• Список адресатів. Ми маємо розсилку з усіма в агентстві. Багато цікавих речей / забав / корисних речей потрапляє туди.
• Сховище VCS Кожне агентство має своє особисте сховище, де у нас є невеликі проекти, в основному модулі, які ми використовуємо в різних проектах.

На рівні компанії

На рівні компанії це більш організовано.

Вікі "агентського рівня" - це фактично частина вікі компанії.

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

Є також доступні списки розсилки, на які ми можемо підписатися. Будь-хто в агентстві може підписатися, і більшість людей дотримуються принаймні однієї або двох технологій, насправді більшість людей дотримується 5-10 з них.

І VCS - це, звичайно, найкраща система обміну кодом.

Висновок

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

Ну, все це зводиться до спілкування.

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

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

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

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

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

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

TL; DR: огляди коду для кожної реєстрації.