Як просувати повторне використання коду та документацію? [зачинено]

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

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

Чи варто нагадати розробникам повторно використовувати компоненти / вдосконалити документацію / внести свій внесок у базовий компонент замість того, щоб дублювати існуючий код і налаштувати його або просто написати свій власний?

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

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

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

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

Поруч із згаданими чинниками "документація", "легко знайти та переміститися", "дисципліна" та "перегляд коду"

код для повторного використання повинен бути

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

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

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

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

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

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

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

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

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

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

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

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

Парне програмування також робить обіг знань набагато швидшим.

Я думаю, що це насправді два питання в одному - я спробую відповісти на обидва.

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

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

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

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

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

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

IMMO ключ його не документація чи інструменти, ключ - ЗВ'ЯЗКУ. 10+ розробників - це не так багато людей, які покращують цю комунікацію:

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

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

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

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

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

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

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

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

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

Існує кілька інструментів для управління фрагментом, я рекомендую цей: http://www.snip2code.com .

(Відмова: Я один із засновників Snip2Code, і я був разом із моїми співзасновниками - у вашому ж розумі: саме тому ми вирішили розпочати цей проект, який збирає всі функції, які я зазначено вище, тобто обмін фрагментами серед команди, інтеграція в IDE, такі як Visual Studio, Eclipse, IntelliJ, Notepad ++ тощо)