Як впоратися з проблемою (складання) великої бази коду?


10

Хоча я можу кодувати, я ще не маю досвіду роботи над великими проектами. Мені до цього було або кодування невеликих програм, які збираються за лічені секунди (різні вправи c / c ++, такі як алгоритми, принципи програмування, ідеї, парадигми, або просто випробування api's ...) або робота над деякими меншими проектами, які були створені мовами скриптів (python, php, js), де компіляція не потрібна.

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

Як приклад я візьму Wordpress. Спробувати і зрозуміти, як створити плагін для нього, досить легко. Спочатку ви почнете зі створення простого плагіна "Hello World", потім ви складете простий інтерфейс для панелі адміністратора, щоб ознайомитись з API, потім ви складете його та зробите щось складніше, тим часом змінюючи, як виглядає пара разів .. Ідея про необхідність перекомпілювати щось таке велике, як WP знову і знову, після кожної незначної зміни, щоб спробувати "якщо він працює" і "як це працює / відчуває", просто здається неефективною, повільною і неправильною.

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

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

Дякую.


4
Об. XKCD та відповідна футболка thinkgeek * 8 ')
Марк Бут

1
Якщо ви працюєте над досить великим проектом з досить великим бюджетом, ви можете отримати сервери побудови, щоб зробити компіляцію для вас :)
SoylentGray

@Chad - Я це знаю, але на даний момент це просто моя домашня настільна машина gnu / linux і я на даний момент :)
pootzko

@Chad Добре, значить, ви говорите нам, що нам потрібні спеціалізовані сервери для вирішення масивів Java (або будь-якої іншої мови компіляції)? Це загальна лайна
Колобський каньйон

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

Відповіді:


8

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

У C / C ++ компіляція досить проста. Ви компілюєте переводити кожен вихідний файл у машинний код (ми називаємо їх об’єктними файлами * .o), а потім пов'язуєте всі об’єктивні файли в один великий виконуваний файл.

Так само, як згадував MainMaе, деякі бібліотеки вбудовані в окремі файли, які будуть динамічно пов'язані під час виконання з виконуваним файлом. Ці бібліотеки називаються спільними об'єктами (* .so) у Unix та динамічно пов'язаними бібліотеками (DLL) у Windows. Динамічні бібліотеки мають багато переваг, одна з яких полягає в тому, що вам не потрібно збирати / посилати їх, якщо їх вихідний код фактично не зміниться.

Існують засоби автоматизації побудови, які допоможуть вам:

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

Найвідоміші з них (make, ant, maven, ...) можуть автоматично визначати, які частини коду були змінені з моменту останньої компіляції та які саме об’єкти / бінарні дані потрібно оновити.

Однак, це пов'язано з (відносно невеликою) вартістю написання "сценарію побудови". Це файл, що містить всю інформацію про вашу збірку, як, наприклад, визначення цілей та їх залежностей, визначення того, який компілятор ви хочете використовувати та які варіанти використовувати, визначення середовища побудови, шляхів до вашої бібліотеки, ... Ви, можливо, чули про Makefiles (дуже поширений у світі Unix) або build.xml (дуже популярний у світі Java). Це те, що вони роблять.


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

@kevincline Я другий цей - ANT збирає все, якщо ви не вказали щось інше у build.xmlфайлі
Колоб Каньйон

7

Ви не перекомпілюєте весь проект кожен раз. Наприклад, якщо це програма C / C ++, є ймовірність, що вона буде розділена на бібліотеки (DLL-файли в Windows), кожна бібліотека збирається окремо.

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


3
Якщо я не перекомпілюю все це, то коли я
встигну

5

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

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

Розбиття проекту на частини, складені індивідуально, дозволяє зробити деякі акуратні речі.

Інкрементальне будівництво

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

Це породжує ідею додаткової забудови . Виконуючи покрокову збірку, перекомпілюються лише фрагменти, які вплинули на зміну. Це значно прискорює час розробки. Щоправда, вам може знадобитися чекати, коли все буде повторно пов’язано, але це все-таки економія від необхідності як перекомпілювати, так і відновити все. (BTW: Деякі системи / мови підтримують інкрементне посилання, так що лише ті речі, що змінилися, повинні бути повторно пов’язані. Вартість на це зазвичай у низькій продуктивності та розмірі коду.)

Тестування одиниць

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

Обмежувальний випадок застосування тестування розглядається в Test Driven Development (TDD). У цій моделі розробки жоден код не записується / не змінюється, якщо не виправити невдалий тест.

Зробити це простіше

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

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

Але це все ще залишає з'ясовувати, як все стосується один одного. Це дуже багато роботи, і, як я вже говорив, програмісти лінуються. Так вони придумали ще один клас інструментів. Ці інструменти написані для визначення залежностей від вас! Часто інструменти є частиною інтегрованих середовищ розробки (IDE), таких як Eclipse та Visual Studio, але є також окремі окремі, які використовуються як для загальних, так і для конкретних програм (makedep, QMake для програм Qt).

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


5

Ось мій список речей, які ви можете спробувати прискорити складання C / C ++:

  • Чи налаштовуєтесь ви відновлювати лише те, що змінилося? Більшість середовищ роблять це за замовчуванням. Не потрібно перекомпілювати файл, якщо він або жоден із заголовків не змінився. Аналогічно, немає причин для відновлення dll / exe, якщо всі пов'язані в objs / lib не змінилися.
  • Помістіть сторонні речі, які ніколи не змінюються, і пов’язані заголовки в одній області бібліотеки коду, що читається лише. Вам потрібні лише заголовки та пов’язані бінарні файли. Вам ніколи не потрібно буде перебудовувати це з іншого джерела, ніж, можливо, один раз.
  • Перебудовуючи все, двома обмежувальними факторами в моєму досвіді були кількість ядер і швидкість диска . Отримайте непоганий чотирьохядерний, гіпертокований апарат із справді хорошим HD-диском, і ваша продуктивність покращиться. Подумайте про твердотільний накопичувач - майте на увазі, що дешеві можуть бути гіршими, ніж хороший hdd. Спробуйте скористатися рейдом для збільшення вашого HD-диска
  • Використовуйте розподілену систему збирання, таку як Incredibuild, яка розділить компіляцію на інші робочі станції у вашій мережі. (Переконайтеся, що у вас міцна мережа).
  • Встановіть збірку єдності, щоб врятувати вас від постійного перезавантаження файлів заголовків.

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

Ще одне дешеве рішення - компілювати в tmpfs. Може значно підвищити продуктивність, якщо процес компіляції пов'язаний з IO.
Artefact2

4

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

Виконання чогось інтерпретованого також дуже неефективно і повільно, і (можливо, неправильно). Ви скаржачись вимогами часу на ПК Dev, але НЕ компіляції вимог часу виробляє на користувача ПК, який , можливо , набагато гірше.

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


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

@pootzko: Ну, досить несправедливо обговорювати мінуси складання, коли ви також не говорите про мінуси інтерпретації.
DeadMG

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

@pootzko: Тоді ви не повинні присвячувати більшість запитань тому, щоб перерахувати те, що вам не подобається у складанні. Ви повинні були написати щось набагато коротше і більш стисле, наприклад, "Як можна скоротити час складання великих проектів?".
DeadMG

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

4
  • Часткова перебудова

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

  • Процес декількох компіляцій

Також припускаючи правильну DAG залежність від компіляції, ви можете компілювати за допомогою декількох процесів. Одна робота на ядро ​​/ процесор - це норма.

  • Виконавчі тести

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


2

На додаток до відповіді MainMa, ми також лише оновили машини, над якими працюємо. Однією з кращих покупок, яку ми зробили, був SSD, коли ви не можете не перекомпілювати весь проект.

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

Наш 37 000 файловий проект склав близько 15 хвилин, щоб скласти з нуля, перш ніж ми вносили ці зміни. Після змін її скоротили до 2-3 хвилин.

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.