Верно ли утверждение, что "если делаем универсальный обработчик чего-либо, то теряем в масштабируемости ИС" или нет?

В данном контексте под "универсальностью" понимается создание единого алгоритма для обработки данных из различных модулей системы (ИС), а под "масштабируемостью" - возможность вносить изменения и коррективы в функциональности приложения.

Теперь, на примере...

Одним из первых рабочих опытов проектирования систем было участие в проектировании системы управления сайтом (CMS - C ontent M anagament S ystem) для одной компании. "Ядро" CMS было практически уже сделано одним человеком, когда я принял участие в этом. Потом только вместе придумывали как что подправить или улучшить и т.п..

В конечном итоге тот паренек, что написал "ядро" уволился, и сопровождать дальше пришлось мне. Что касается алгоритма и скорости работы (производительности) все было замечательно. И идея была хорошая... :)

Работа в "универсальности" приложения заключалась в том, что для выполнения команд SELECT, INSERT, DELETE, UPDATE к базе данных фактически запускался один и тот же обработчик для разных модулей, который и обеспечивал генерацию на сайт и выполнял эти команды (select, insert и т.д.). Все было до поры до времени удобно и всех устраивало. :)

Дык вот... Проблема была в том, что когда клиенты захотели внести некоторые изменения в "движок", то оказалось, что там "черт ногу сломит". Причем даже несущественные вроде бы изменения приводили к резкому увеличению человек-часов и переписыванию отдельных кусков кода.

Не отрицаю возможность таких программ, которые отвечали бы требованиям и "производительности", и "масштабируемости" (удобства и т.д.). Но, к сожалению, пока такого опыта у меня не было :) Думаю, что все еще впереди! :)

И в заключении вопрос: как в таких случаях поступать, между чем выбирать? Или все дело действительно в практическом опыте?

Alexey Rovdo
Для начала изучите терминологию. А то так вы только запутываете людей. Ваши вопросы касаются "гибкости" и "модульности" архитектуры, "читабельности" кода, но никак не "масштабируемости".
Хм... странно, а я действительно читал в некоторых книжках или в документациях (во всяком случае так пишут авторы), что "масштабируемость" и "гибкость" - это очень близкие по терминологии понятия. Хотя под "масштабируемостью" больше встречал именно возможность создания и добавления новых модулей программы, в то время как под "гибкостью" - удобство настройки и использования, возможность отключения/включения некоторого функционала на основе уже рабочей ИС.

Alexey RovdoПо существу же скажу, что переписывать заново нечитабельные (и как следствие малопонятные) куски кода, а то и целые системы в ситуациях наподобие вашей людям приходится регулярно. Вызвано это как некачественной/неграмотной работой предшественников, так и (что на мой взгляд встречается даже чаще) неправильной/близорукой политикой руководства компаний, которое обычно не желает тратиться на глубокую проработку вопросов архитектуры и документирование систем (как следствие - дважды/трижды/... оплачивает разработку/переработку одного и того же кода разными людьми). Впрочем, именно это дает хлеб программистам.
Что касается документирования проекта, не говоря собственно уже о комментариях в коде программы, то их фактически и не было. :)

Alexey RovdoСтолкнувшись с такой проблемой даже единожды вы уже можете задуматься и о том, что и ваш код, возможно, кто-то в будущем будет разбирать и модифицировать без вашего участия.
Не сомневаюсь в этом и полностью согласен, потому что у самого часто возникало желание переделать и "улучшить" проекты.

Alexey Rovdo
Представив себя на месте этого человека вы возможно захотите написать более понятный и архитектурно-грамотный код, про который уже нельзя будет сказать, что "там черт ногу сломит".

В принципе, такие мысли действительно были. Своей начальнице я так и отвечал "Что если хотите что-то серьезно изменить, то надо переписывать код, а на данный момент я могу сделать то-то и то-то".

Но на самом деле ответа пока на свой вопрос так и не получил. :)

guest_20040621> Но на самом деле ответа пока на свой вопрос так и не получил.
> Верно ли утверждение, что "если делаем универсальный обработчик чего-либо, то
> теряем в масштабируемости ИС" или нет?

Нет, это утверждение ложно. При любой трактовке масштабируемости.
Иными словами вы хотите сказать, что с хорошо спроектированной системой, таких проблем не возникает?

Но тогда, это опять вопрос как-никак практического опыта и уровня подготовки ИМХО :)

Интересен скорее всего, на самом деле, не ответ на вопрос "верно или нет", а примеры из жизни "кто и как" выходил из подобных ситуаций. Что вы предпринимали, если сталкивались с подобной ситуацией, и какие решения принимались в последующих проектах?

2 guest_20040621

Скорее соглашусь с вами :). Правда, также интересны и другие мнения.

softwarerЯ бы сместил фокус и сказал так: потерять в масштабируемости (в любой трактовке масштабируемости) несложно делая что угодно, в том числе и универсальный обработчик чего-либо. "Неуниверсальность" сама по себе ничем особенным не поможет.
Хорошо, а как тогда в таких случаях стоит поступать, когда вроде и "гибкость" хромает, и "обработка" данных изначально была спроектирована некачественно? Если конечно можно так сказать. :)

2 softwarer

Спасибо за ответ.

Действительно, в моем примере, как такового проекта (в смысле проектной документаций, соглашений и т.п.) и не было. Возможно поэтому трудности в "переделывании" имели место. :)

P.S. Все таки как никак первый опыт был, а неудачный опыт, ИМХО - тоже опыт :)