Чи слід розраховувати на розробників внутрішню бібліотеку перед реальною програмою?

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

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

Цей аргумент старшого розробника для мене не має сенсу.

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

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

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

Пропозиція є

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

Ви можете зробити альтернативну пропозицію

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

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

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

Раніше я працював у великій фірмі з програмним забезпеченням, яка постійно "випробовувала" власні програми з внутрішніми бізнес-системами.

Вони розглядали це як інший рівень тестування.

Що я згоден, для компанії - це гарна річ.

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

Хоча наявність вихідного коду може бути користю, якщо у вас є агент збірки CI, який контролює сховище, то ДОБРЕ більш розумним є те, щоб цей агент збирав цю бібліотеку і копіював її у залежні проекти як зовнішню, ніж вимагати від розробників виконайте два різних етапи компіляції при складанні їх копії.

Зараз я працюю над проектом, який не підключений до збудового агента, який вимагає побудови підпрограми перед створенням основного додатка. Це серйозний біль у моїй задній частині; щоб внести зміни в додаток, спочатку я повинен створити весь проект, потім перейти в папку підбудови, дістати з цього скомпільований продукт і скопіювати його в іншу підпапку, перш ніж будувати весь проект ПРОТИ щоб переконатися, що остання версія додатка включена в збірку основного додатка. Це НЕ, як це слід робити; принаймні, повинен бути сценарій MSBuild, який автоматизує цей процес, і я вважаю за краще, щоб агент збирання оновлював зовнішні програми, коли новий код вводиться в магістраль.

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

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

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

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

   • Це може статися тому, що багато бібліотек далеко не ідеальні, і хоча ми всі хочемо працювати зі "стабільним" випуском, проблеми все ще можуть бути.
   • Можливо, ви отримуєте погані результати через нерозуміння способу використання API. Навіть з документацією люди часто роблять неправильні припущення
   • Ваш старший хлопець, напевно, втомився від нових людей (а іноді є набагато більше нових людей, ніж тих, хто знає проект усередині та зовні), кидаючи зброю в повітря, коли трапляється збій / якась інша помилка, що виникає з коду бібліотеки. Тож замість того, щоб підходити до вашої машини, а потім до хлопця, який сидить поруч, вони хочуть відповісти на ці запитання: 1) де саме відбувається збій? який модуль / файл / рядок? 2) ви це налагодили? що ви знайшли?
   • Ваші старші хлопці працювали з цією базою коду (додаток і ваша основна бібліотека) досить довго, і, можливо, він, можливо, помітив, що коли код вже є на машині і готовий до налагодження та переходу, це полегшує його життя і стає людьми швидше засвоїти базу коду. Тож з цієї причини він змушує вас взяти за собою первісну вартість будівництва бібліотеки на вашій машині.

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

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

_{З того, що ви описуєте, це здається, що в проекті немає тестерів - якщо це так, це проблема управління і досить серйозна.}

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

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

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

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

Коли в колективі є тестери, такі речі дійсно прості і з ними можна впоратися набагато простіше. Те, що ваш «старший» розробник кидає на вас, в основному є проектом вимоги тестування.

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

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

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

Те, що пропонує Сер Дев, має для мене в кращому випадку мало сенсу. Приємно вміти переглядати джерела, але є кращі способи зробити це.

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

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

Це просто має статися у вашому сценарії збірки:

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

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