Які міркування слід враховувати щодо та проти "супер" сайтів?

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

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

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

Редагувати :

Нинішнє середовище складається з трьох сайтів ASP.Net 1.1, які майже не побачили справжньої любові з моменту написання (в основному через відсутність досвідчених розробників у компанії) та однієї програми MVC2, яка також була сайтом ASP.Net 1.1 до того, як була створена оновлено минулого року. Ми пишемо виключно на C #.

Компанія досить невелика, з близько 50 співробітників; троє з яких є фактичними розробниками. Менеджмент (навіть ІТ-менеджмент) не має жодного ІТ-досвіду та досвіду, окрім управління проектами ІТ-проектів (і, отже, певні знання термінології та впливу на бізнес).

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

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

Погана ідея

Ця реакція ґрунтується на таких припущеннях:

1. Існує багато досить різних застосувань, гомогенізованих
2. Є багато команд, які працюють над різними додатками
3. Немає шанованого та авторитетного архітектора програмного забезпечення, який активно керує програмами

Що буде, якщо ви продовжите

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

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

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

а через мить хтось інший надумає

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

поки нарешті

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

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

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

Google це робить, тому це, безумовно, можливо .

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

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

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

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

Ми проходили подібний процес. У нас був продукт, який був деякий час. Минулого року ми представили ще один продукт, який на 95% такий же, як перший, з 5% інколи тонких, але істотних відмінностей, причому ці відмінності повинні розроблятися та підтримуватися окремою командою.

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

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

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

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

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

Ті, хто вирішив це, повинні рішуче задуматися, ЧОМУ вони хочуть це зробити, і подумати, скільки роботи вони хочуть витратити, потрапляючи туди.

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

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

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

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

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

Виведення загальних речей на компоненти / сервіси та стандартизація таким чином було б набагато простіше IMHO.

Ви можете підійти до цього по-різному, використовуючи технологію інтеграції, таку як « Постачання», щоб поділити тематику всіх своїх веб-додатків аналогічно. В основному кожен додаток все ще є окремим; Служба доставки використовує правила XSLT, щоб підключити їх вихід у статичний шаблон HTML, який ви розробляєте. Це дозволяє застосувати відносно просту статичну тему HTML / CSS до всього набору програм із мінімальним горем.