Представьте ситуацию, когда несколько заказчиков готовы купить у Вас программу.

Вы решили сделать одно тиражируемое решение и просто продать его всем своим заказчикам.

Отличная идея, верно? Вы быстро пишете программу потратив на неё 3-6 месяцев и потом вдруг обнаруживаете маааленькую проблемку…

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

Т.е. заказчики говорят: всё супер, мы покупаем, НО только, если в программе будут нужные нам доработки.

Это что же за тираж такой получается, если программу всё равно нужно допиливать под каждого?

Именно поэтому, делая любую программу неплохо сразу задуматься о том как сделать её по-настоящему тиражируемым решением, т.е. таким, которое либо совсем не нужно будет допиливать под заказчиков, либо допилы будут минимальными и не потребуют больших усилий.

Интересно, что для этого очень хорошо подходит известный принцип объектно-ориентированного программирования: оставляй только то, что не изменится никогда, а всё остальное выделяй в  отдельные классы.

Представьте, что Вы решили сделать программу и затем продать её сразу нескольким клиентам.

Очевидно, что каждый из них попросит её доработать под свои требования. Давайте рассмотрим пример с которым, вероятно, Вы сами могли сталкиваться на сайтах государственных органов.

Допустим Вы хотите оставить обращение в какой-то государственный орган через их сайт.

Обращения могут быть разные: в одном случае это может быть жалоба, а в другом — запрос на получение заграничного паспорта или что-то еще.

Очевидно, что обработка таких запросов тоже устроена по-разному: начиная с устройства сайта, на котором расположена форма принятия запроса, до формата передачи данных и процедуры обработки поступивших запросов.

В налоговой инспекции или на портале гос услуг процесс прохождения заявки устроен по-разному: в одном случае нужна отправка бумажных документов в ответ на запрос, а в другом не нужна, в одном случае заявка проходит 2 этапа обработки, а в другому 5. И т.д.

Различаться может буквально всё. Как же угодить всем и создать такую программу, которую не нужно будет очень сильно пилить, чтобы  подстроить под нужды заказчиков?

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

Анализу должно подвергнуться всё, от способа получения заявки, до её обработки в системе, структуры таблиц данных и архитектуры всех модулей.

Рассмотрим наш пример с заявками. Допустим Вы задумали создать программу для обработки поступивших заявок. Сейчас это любят называть виртуальной приёмной.

Для начала посмотрим на бизнес-процесс.

Очевидно, что каким бы ни был заказчик программы, неизменным остаётся одно: заявки всегда будут поступать с сайтов или из других систем. Их нужно рассортировать, проверить, убрать битые и фейковые, связать с внутренними даными и отправить на дальнейшую обработку. А в процессе обработки уведомлять человека, оставившего заявку, о том, что с его заявкой происходит.

Это и есть неизменные сущности. Их нужно оставить настолько абстрактными, насколько это вообще возможно.

Всё остальное, что может измениться нужно вывести как бы за пределы системы.

Что может измениться в этой системе?

  • Заявка может прийти не только с сайта, но и из любой другой системы;
  • Набор полей в заявке однозначно будет меняться. У каждого заказчика он свой;
  • Если заявка приходит с сайта, то надо учитывать, что сайты сделаны по-разному и поэтому заявки тоже будут присылать по-разному: одним проще прислать по почте, другим через файлы, третьим через веб-сервисы, четвертым по FTP или еще как-то;
  • Формат передачи заявки тоже может измениться. Это может быть как простое письмо с перечисленными в столбец полями так и сложный XML, причем XML-словари тоже могут быть разными;
  • Отображение заявки может изменяться. Ведь количество полей разное у всех, а отображать их нужно все;
  • Алгоритм привязки заявок к внутренним данным может меняться: кто-то буде обрабатывать заявки вручную, а кто-то захочет автоматическую привязку и проверку;
  • Процесс и этапы заявки могут меняться. В зависимости от заявки у неё может быть разная обработка, т.е. будут раздаваться разные поручения и высылаться разные уведомления;
  • Заявки могут попадать в систему сразу с нескольких сайтов-источников;
  • Формат и способ передачи информации в обратную сторону (из нашей системы на сайт-источник) тоже могут меняться.

Примерно так. Просто представьте, что у Вас есть объект, которому что-то идёт на вход, он это обрабатывает и выдаёт что-то на выход и тогда всё встанет на свои места.

После подробного анализа изменений начинайте думать над тем как Вам всё это реализовать более-менее универсальным способом.

Способ реализации с учтем возможных изменений — отдельная большая тема, поэтому здесь описана не будет.

Самое главное, что Вы должны понять — не прыгайте в воду не прощупав дно.

Не начинайте делать тиражируемое решение не продумав, что в нём может измениться, если вдруг заказчик потребует доработку.

Это позволит Вам сделать по-настоящему тиражируемое решение, которое смело можно будет предлагать заказчикам не боясь налететь на большие проблемы.

Связанные записи

Share →

Добавить комментарий