… при работе с заказчиком в виде ДИТа мы понимали, что все проекты делаются чиновниками от IT. Чиновник от IT очень смутно представляет весь процесс фабрики разработки; что есть очень много звеньев, маленьких, но очень важных; что нужно понимать, что такое фабрика разработки, что такое среда тестирования, что такое environment нагруженного тестирования. Мы этого не видели, мы сделали этот environment, эту среду разработки, написали кейсы, сценарии. На нас посмотрели, сказали: «Вы чио, с ума сошли? У нас работает все по-другому». И отдали другому подрядчику, который понимал это по-своему.
А когда началась вся эта история с пропусками Москвы, мы с удивлением обнаружили в исходных кодах куски кодов нашей платформы, которая никаким боком не должна была появляться в приложениях подобного рода. Во-первых, то, что делали мы, было сделано для другой области профессионального использования платформы, а во-вторых, это было, по сути, копипастом из фронтендового приложения… я сейчас открою такую тайну… оно было взято из мониторинга отслеживания вывоза отходов.
То есть на нашей платформе был пилотный проект по мониторингу вывоза бытовых отходов на полигоны. И там было сделано приложение как раз с QR-кодами, с геопозицией и прочими вещами. И мы это тогда сделали за десять дней.
И когда начался эпатаж, связанный с проблемами приложения «Социального мониторинга», ребята наши посмеялись, сказали: «Слушай, а ты ничего не узнаешь?». Я говорю: «Ну, да». То есть у меня, конечно, не было больше вопросов. Я понимал, что приложение, написанное за десять дней и бюджету Москвы оно обошлось в больше сотни миллионов – это классный бизнес [прим. ред.: компания «Гаскар Интеграция» получила от мэрии Москвы контракт на 180 млн. рублей ещё до старта разработки «Социального мониторинга»; на каких условиях в него был добавлен мониторинг, доподлинно неизвестно].
По поводу «можно ли было сделать лучше?». Я считаю – да. Я считаю, что если бы, в принципе, уважаемый ДИТ Москвы использовал бы хотя бы элементарные понятия о девопс-фабрике, о фабрике разработки, как это принято в компаниях, которые занимаются профессиональной разработкой, многих проблем можно было бы избежать. То есть, по сути, приложение собиралось из ранее собранных проектов, близко подходящим к тематике, и компилировалось в какие-то пакеты и сервисы. Конечно, никоим образом эти сервисы не были оркестрированы между собой, то есть они вообще имели разное api и собиралось это все на коленках и быстро.
Отсюда начались проблемы, собственно говоря, с негибкостью приложения. Вот коллеги сказали, что надо было сделать так, чтобы функции не влияли друг на друга, чтобы подпорка, выбитая в одном месте, не обрушила все здание. Собственно говоря, ни о какой сервисной архитектуре речь не шла. Это был тупой монолит, собранный из всего, что там было и, естественно, первый дятел, залетевший в скворечню, обрушил все дерево. Так что я думаю, что сделать можно было лучше.
Как мне кажется, разработку делала компания придворная, которая ранее работала с нашей платформой — и она очень быстренько, на коленках, по первому свистку за месяц собрала все, что могла собрать из того, что было.
https://digitaldem.ru/2020/05/26/prilozhenie-soczialnyj-monitoring-bylo-sdelano-iz-trekera-musorovozov/
