8-800-707-02-78      +7 (495) 927-02-78       info@centrobit.ru

Как я написал «драфт» системы В2В

20
Apr

Наконец-то я смог начать писать эту маленькую статью, хотя хотел её написать уже давно. Надеюсь, она поможет коллегам, кто решил разрабатывать подобную систему. Итак, расскажу вам, как все началось. Летом 2010г, приехав из Италии после докторантуры, решил, что надо продолжать свою деятельность по IT, создав некую «офигенную систему», не зная, правда, какую именно ))).

Я случайно встретился с товарищами из института, которые занимались определённым видом бизнеса. Мы подняли вопрос о создании фронтенд системы, которая автоматизирует приём заказов,  передачу заказов в бекенд ERP, синхронизирует цены, остатки, умеет автоматически оформлять счета клиентам и искать товар по характеристикам. Грубо говоря, «продвинутый» сайт со шлюзом с 1С для оптовика. На первый взгляд все оказалось просто. Мы назначили срок проекта 3 мес. и вперёд.

После академической сферы в Европе, где популярны Open Source, Ubuntu и подобные вещи,  не хотелось браться за Битрикс или др. коммерческие платформы, как на том настаивал заказчик (теперь партнер). Кстати, потом, когда я уже достаточно глубоко окунулся в данный проект, я не пожалел о своем выборе. Причины своего выбора с технической точки зрения я объясню в другой статье.

Есть 2 подхода для разработки приложений MVC: толстый С — тонкий М и наоборот. Грубо говоря, в первом подходе все бизнес-логики лежат на плече контроллеров, модель лишь обеспечивает фундаментальные вещи. Во 2-ом подходе все наоборот – модель максимально обеспечивает бизнес-логики, а контроллеры пишут как можно проще. Выбрал 1-ый подход, т.к. он простой и дает быстрый результат. Он подходит для тех, кто хочет побыстрее закончить проект и взять деньги, в итоге все довольны.

Теперь расскажу об ошибках. Совершили ряд ошибок в проектировании, начиная с ТЗ и заканчивая моделью данных в БД. С самого начала недооценили сложность данной системы. Она – не сайт (как мы считали), а целый движок с множеством сущностей со своими логиками. Мы с заказчиками тоже не смогли обобщить объекты в системе. Например, бронь, заказ и заявка под заказ рассмотрели как 3 разных сущности, хотя можно было их и объединить.

Из-за недальновидности в проектировании модели данных (без обобщения) с обеих сторон, сделали такую «жесткую модель данных». Пожалуйста, не повторяйте эту ошибку. Бизнес – это живое существо. Оно постоянно меняется. Не будьте заложником своего сегодняшнего видения и своих нынешних бизнес-процессов.

- Назвали амбициозный срок — 3 месяца. Теперь я не понимаю, откуда мы взяли такие цифры. Может быть, думали, что обычный интернет магазин на движке Joomla, Bitrix… сделаем за 2 недели — 1 мес., значит 3 мес. этого достаточно для продвинутого интернет магазина для оптовиков?

Перечислю наши основные ошибки:

- Назвали амбициозный срок — 3 месяца. Теперь я не понимаю, откуда мы взяли такие цифры. Может быть, думали, что обычный интернет магазин на движке Joomla, Bitrix… сделаем за 2 недели — 1 мес., значит 3 мес. достаточно для продвинутого интернет-магазина для оптовиков?

- Амбиция проектной команды. Мы пытались по максимуму все автоматизировать, придумали проблемы и заранее пытались их решить. Из-за этого вместо 3 месяцев мы этот «драфт» закрыли только через 1 год!  Никогда не пытайтесь оптимизировать то, чего нет, или как мудро сказал известный ученый Дональд Кнут: «Premature optimization is the root of all evil» (Преждевременная оптимизация является корнем всех зол).

- Недооцененность сложности реализации шлюза в 1С. С первого взгляда все казалось очень просто. Есть стандартный механизм обмена данными (в 1С через номера сообщений). Оформи XML файл, закинь его в общую папку, потом заберёшь, парсишь, импортируешь в базу и все.  Поверьте мне, стандартный механизм обмена  обеспечивает обмен только простых объектов. Грубо говоря, бросишь объекты в шлюз на отправку и забудешь.

- Выбор неправильного фреймворка для разработки. Сам язык РНР прекрасен в своей простоте – пиши как хочешь, незачем заморачиваться выбором тяжеловесного фреймворка, такими как Zend, или Symphony, тем более ORM и тд. На самом деле это иллюзия. Когда вы работаете в небольшой команде и в небольшом проекте, все нормально. Когда же начинаешь писать программу на промышленном уровне, то свобода в стиле кодинга это лишняя головная боль. Только вы понимаете ваши коды и иногда через некоторое время даже вы сами забудете что написали ранее.

- Выбор очень плохого подхода работы с БД. Сроки были сжатыми и бизнес-процессы оказались жесткими, поэтому решили написать все основные логики через процедуры в БД. Это кошмар в проверке корректности данных. Поверьте мне, лучше делать БД просто как хранилище данных и не больше.

Вывод:

Я перечислил только основные ошибки, которые смог вспомнить. На самом деле их больше. После 1 года мучения с этим драфтом мы поняли, что та система В2В служит лишь в качестве индивидуального решения для 1 компании. Её сложно обслуживать без участия разработчиков и практически нельзя применять в другом бизнесе, где бизнес-логики другие.
После этого эксперимента мы сделали вывод: нужно разработать специальную платформу В2В, которая сможет отвечать другим требованиям…. Подробнее в следующей статье.

встроенный шкаф купе полки для обуви в гардеробную встроенный шкаф гардеробная Срочная виза в чехию за 1 день источник.