Розділення проектів java

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

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

Моє мислення таке:

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

Я трохи стурбований тим, який вплив це може мати на час створення.

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

Також у мене є невелике занепокоєння щодо того, який вплив може мати час редагування IDE (ми в основному використовуємо Intellij). Схоже, Intellij будує кожен проект по черзі через дерево залежностей - тобто, якщо C залежить від B, залежить від A, а я змінити A, він не намагатиметься побудувати B, якщо A не збирається тощо. Можливо, це вигідно, але я виявив, що якщо - наприклад, змінити інтерфейс в A, який широко використовується в B і C, потрібен певний час, щоб виправити всі помилки, пов'язані з цією зміною ...

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

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

• підпроект A - містить інтерфейси
• підпроект B - залежить від A для інтерфейсів та старої зовнішньої банки
• підпроект C - залежить від B (і, отже, A і старої зовнішньої банки), і містить клас Factory, який використовує реалізацію інтерфейсів B

Якщо мені потрібно змінити зовнішню банку B, я можу:

• створити підпроект B_ii - знову залежить від А, а тепер і нової зовнішньої банки
• Після повноцінного функціонування я можу додати залежність C до B_ii та змінити клас Factory на використання нових реалізацій інтерфейсів.

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

• Це розумний спосіб робити це?

Отже, в основному мої запитання:

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

Я збираюся зробити короткий перший поріз на цьому (чудовий Q BTW!):

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

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

Також у мене є невелике занепокоєння щодо того, який вплив може мати час редагування IDE (ми в основному використовуємо Intellij). Схоже, Intellij будує кожен проект по черзі через дерево залежностей - тобто, якщо C залежить від B, залежить від A, а я зміню A, він не намагатиметься побудувати B, якщо A не збирається тощо. Можливо, це вигідно, але я виявив, що якщо - наприклад, я зміню інтерфейс в A, який широко використовується в B і C, потрібен певний час, щоб виправити всі помилки від цієї зміни ...

Різні ІДЕ мають різні сильні сторони щодо зв'язків Мейвена та управління залежностями. Поточний стан гри виглядає так, що він здебільшого просто працює на останніх Eclipse, Netbeans та IntelliJ - але вам доведеться навчити своїх розробників надзвичайній подвійній хитці "Оновити вихідні файли з диска та відновити всі пов'язані проекти Maven".

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

Пункти пунктів заводських класів

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

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

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

Отже, в основному мої запитання:

Хтось має досвід розбиття великих проектів? Чи є якісь поради та поради, якими ви хотіли б поділитися?

• Інтерфейси та введення залежності - ваш друг.
• Книга Майкла Пера про ефективне поводження зі спадковим кодом обов'язково читається.
• Інтеграційні тести - твій друг
• Розщеплення підпроектів на foo-api (лише інтерфейси!) Та foo-core та наявність модулів залежать лише від foo-api дуже допомагає та примушує розділити
• Модулі Jboss та / або OSGi можуть допомогти забезпечити чисте розділення

Який вплив це мало на ваш розвиток та час побудови?

Дуже незначний вплив на розробку та час побудови - величезний приріст часу для нашого загального трубопроводу безперервної доставки.

Яку пораду ви можете запропонувати щодо структури такого розбиття такого проекту?

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

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

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

Не здавайся - деякі якусь гоління тепер будують основу для того, щоб можна було «швидко збирати та рефакторировать без побоювання» Безсоромний штекер -> від Бена і я «Добре заземлений розробник Java» .

Удачі!

Моє взяти на це лише окремо, коли це необхідно. Однак тут виникає наступне питання: як визначити, чи потрібно?

• Якщо артефакт інший (тобто не будуйте EAR, WAR, JAR, інтеграцію-тестування-jar в одному проекті).
• Коли під час поділу ви помічаєте, що деякий код повинен існувати в декількох рефакторах артефактів, вони переходять у новий.
• Коли якийсь інший проект поза вашою командою хоче використовувати щось, що є у вашому проекті.

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

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

Реконструкція також простіша в рамках проекту, а не в межах проектів.

Якщо час збирання - це проблема, тоді просто забезпечте краще обладнання.