Разработка сервиса. Как избежать провала
Cегодня я хочу рассказать про часто допускаемую ошибку при разработке стартапов, у которых есть интеграция со сторонними ресурсами. Например, товарных агрегаторов, в которых нужно выгружать данные раскрученные площадки, типа Ozon. В общем, всех тех стартапов, которые существуют не сами по себе, а вместе с некой IT-инфраструктурой, которой вы не мож…
Комментарий недоступен
Тут автор прав, я делал различные агрегаторы в свое время.
Лучше сначала изучить API каждого сервиса, за много лет они все примерно приходят к одному и тому же. Нужно выделить это общее, тогда интеграция с последующими сервисами и сами интерфейсы не будут противоречить этой логике.
Если отталкиваться от красивых интерфейсов, то скорей всего их все равно придется переделывать, даже костыли могут не помочь, потому что в них может быть неправильный общепринятый порядок действий и данных.
Не стану претендовать на истину в последней инстанции, но скажу как человек, который руководил разработкой и внедрением двух сложных ERP-систем. Подход "завтра вы захотите использовать другую БД и поэтому давайте использовать БД как гроб данных, а всю транзакционную логику выносить в приложение" — очень дорогой способ абстрагирования. Реальные системы изначально проектируются с прицелом на конкретную СУБД, чтобы взять максимум от ее возможностей. В реальных и действительно сложных системах (банки, логистика, телеком и т.д.) почти вся бизнес-логика хранится в процедурах на стороне БД. Хорошо это или плохо — вопрос философский. Но это как минимум оптимальнее по затратам на сопровождение таких систем.
Спроектировали Вы приложение, реализовали, начали данные загонять из API и выясняется что неудастся получить необходимые данные в нужном формате, а бюджет уже израсходован.
Правильно автор пишет, что если есть в ТЗ черный ящик, нужно либо с него начинать, либо более детально прописывать ТЗ чтобы этот черный ящик превратился в белый