Навіщо розробляти внутрішні бібліотеки для внутрішніх додатків?

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

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

Іншими словами: якщо записаний якийсь вихідний код, як ви вирішите, чи слід його збирати у бінарну бібліотеку та пов’язувати з вашою програмою чи просто включати у вихідні файли проекту та збирати регулярно?

Коли я кажу "включити" файли у кожен проект, я не маю на увазі копіювати та вставляти кожен файл у дерево джерела проекту, який зараз розробляється. Я маю на увазі розробку деякого каталогу / бібліотеки (окремо для будь-якого проекту), що містить загальний вихідний код, який можна включити у файли проекту звичайним способом, тобто #include.

ps Я тут говорю про розробку c / c ++ для декількох настільних додатків.

Існує чимало причин для створення бібліотек і спільних бібліотек (у .dll або .so файлах) навіть для внутрішнього використання:

1. Повторне використання в проектах набагато чистіше
2. Розмежування відповідальності - частина вашого коду може підходити різним розробникам чи командам
3. Ви можете скористатися вдосконаленнями бібліотек, які створюють інші команди, не знаходячи конкретний код
4. Швидші часи збирання, якщо бібліотека стабільна, її не потрібно повторно створювати.
5. Дисковий простір - у проекті ви можете мати лише бібліотеку та заголовки
6. Якщо ви використовуєте спільні бібліотеки, ви можете заощадити пам'ять лише однією копією, завантаженою в оперативну пам’ять, навіть якщо кілька програм використовують її
7. Як правило, ви покращуєте документацію та тестування бібліотек
8. Очищення дизайну та коду - роздуми про структурування речей в бібліотеки повинні спричинити за собою пов'язані групи функціональності в кожній бібліотеці, і ви, як правило, розділяєте загальний код, в бібліотеки , від специфіки програми, у додатку .
9. Якщо у бібліотеках є власні алгоритми, ви можете обмежувати доступ до джерела, наприклад, не дозволяючи підрядникам чи командам, що отримують джерела, потрапляти до джерела.
10. Код бібліотеки може бути розміщений під іншою ліцензією на додаток, який він спочатку був написаний у складі, деякі компанії навіть були відомі бібліотекам з відкритим кодом, якими вони пишаються - здобувши великі кудо в спільноті з відкритим кодом, і колись великі вдосконалення сприяли назад.

Деякі компанії навіть мають бухгалтерську практику, коли проекти, які створюють бібліотеки, отримують певну компенсацію за кожне повторне використання.

Деякі інші можливі причини, які можуть стосуватися більш великих, нетривіальних проектів:

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

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

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

• Код, який не повинен бути випущений у пряме середовище : Наприклад, тестові бібліотеки одиниць або "макетні" бібліотеки, які використовуються для тестування розробника, щоб замінити живий компонент системи (апаратне забезпечення, API, віддалені системи, бази даних тощо)

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

• Додаткові функції / Оптимізація : У великих системах програма може зачекати перед завантаженням певних динамічно пов'язаних модулів у пам'ять під час виконання, якщо вони не є критичними для основної функціональності програми.

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

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

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

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

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

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

Написання «бібліотеки» для одного випадку використання може перетворитися на дуже дороге вправу без жодної виплати --- мене це покусало кілька разів.

Приклад витрат:

1. Час / енергія, витрачена на розгляд "загальних" випадків використання
2. Час, витрачений на передання "бібліотеки" на "клієнта" (власний код)
3. Майбутній тиск, щоб використовувати "бібліотеку", навіть якщо вона повністю не відповідає наступному випадку використання

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

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

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

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

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

Нарешті, можуть бути технічні причини - чи може бути необхідним зберігати частину коду як бібліотеки, щоб він міг завантажуватися необов'язково або навіть завантажуватися та вивантажуватися на вимогу, і, таким чином, зменшувати використання пам’яті, коли економічність не потрібна?

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

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

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

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

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

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

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

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

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

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

Що робити, якщо в бібліотеці є помилка, і вам потрібно її виправити? Або відбудеться якась статутна чи нормативна зміна, що означає, що ви повинні змінити спосіб роботи бібліотеки?

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

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