Чому команда розробників наполягає на тому, що використання єдиного рішення для декількох проектів у Visual Studio «збільшує складність взаємозалежності»?

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

Це робить згубний вплив на надійність і якість збірки, оскільки вони не завжди надсилають нам найновіший вихідний код. Ми намагаємось натиснути на них, щоб об'єднати весь посилається код на одне рішення, але ми отримуємо певний опір - зокрема, вони продовжують говорити про збільшення взаємозалежності між модулями (читайте "проекти" у Visual Studio), якщо все розміщується в єдиний файл рішення. Жоден код в окремих рішеннях не використовується в іншому місці.

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

Команда, про яку йдеться, також виконує виправлення помилок та розробку нових функцій для вже існуючого продукту, досвід роботи якого є найменшим загрозою і страждає від тієї самої проблеми розбиття на декілька рішень. Нам відмовили у доступі до їх джерела контролю ( TFS ), і підхід, який ми застосовуємо для уніфікації бази даних, - це спробувати принаймні зменшити кількість відсутніх оновлень і більше, ніж епізодичні регресії (так, виправлені помилки отримують знову -введено до продукту), кажучи: "надішліть нам ZIP всю папку рішення, щоб ми могли розпакувати, відкрити його у Visual Studio та натиснутиF5 для тестування ". З точки зору загальної структури та якості, код досить поганий і важко підтримувати. Цей досвід, тому я маю намір домогтися правильних робочих процесів як можна раніше на циклі розробки.

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

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

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

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

Проте я б запропонував додати сценарій збірки. Це має переваги навіть тоді, коли існує лише один файл рішення. Наприклад, він дозволяє запускати збірку VS з бажаною конфігурацією, дозволяє копіювати кінцеві файли для розгортання (і нічого більше) у папку "розгортання", а також може запускати деякі інші інструменти та кроки для завершення збірки. Дивіться також F5 - це не процес збирання! , і Тест Джоеля .

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

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

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

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

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

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

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

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

Єдине рішення полегшує посилання на проект з іншого проекту (тобто повторне використання коду проекту, який також називає "внесення складності взаємозалежності"):

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

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