Как вытащить проект из жопы
«Кто везет — на том и возят», слышали? Вывозить я умею, поэтому вытягиваю чужие проекты из различных жоп на регулярной основе, уже много лет. Рассказываю на личном опыте как это происходит.
А зачем?
Внезапно да? Но вопрос вообщем-то важный:
до начала любых работ, нужно однозначное понимание глубины жопы, на которую закопали ваш проект. Причем не только у вас лично но и у руководства, которое выделяет ресурсы на вытаскивание.
Чтобы не было эксцессов, вам не мешали и не отвлекали.
Еще нужны четкие цели и показатели, которых вы должны достичь по итогам работ:
процесс вытаскивания — тяжелый, болезненный и достаточно рисковый, и далеко не всегда успех сразу очевиден и осязаем.
У руководства будет очень велик соблазн прервать вашу работу, не дав закончить — например попросив срочно починить какую-то горящую проблему «прямо сейчас». А затем еще одну и еще одну.
У меня несколько раз именно так и происходило. Дальше процесс вытаскивания «ставился на паузу», а основная версия очень быстро уезжала дальше — и все, конец.
Или заканчивались ресурсы выделенные на проект или заказчик вообще исчезал с концами.
Грани п#здеца
Ниже на примерах опишу что вас может ждать, если вы вдруг решили вытащить из жопы чужой проект.
Все кейсы только из личного опыта, это не про «услышал от друзей» или «нашел в интернете» — только сам, лично и своими руками.
Кейс первый: голая степь
Про#б исходников, документации и команды — ничего нет вообще.
Сама система — в виде бинарной сборки на CD-диске, подписанном маркером.
Вам это подается как «нелепое стечение обстоятельств», под хороший алкоголь в дорогом ресторане. Заказчик естественно в Brioni, с часами дороже годового бюджета проекта.
не рекомендую принимать какие-либо серьезные решения в дорогом ресторане, тем более с алкоголем.
Почему-то такое всегда заканчивается полным п#здецом.
Кейс второй: пакет с говном
Проект был передан в виде прототипа (MVP) от аутсорсера, бинарная сборка была развернута «где-то там»: на тестовом сервере, в докере за печкой под полом.
Переданные исходники устарели, по сравнению с тем что поставили на стенд. Контрольной сборки конечно не было — часть исходников успешно про#бали потеряли.
Компания-аутсорсер ушла в закат и больше не отвечает а сдача проекта была полгода назад. Еще и расстались с аутсорсером не очень красиво — кинули с оплатой были финансовые разногласия.
Вам этот проект само собой преподносится как «надо просто развернуть, запустить и сделать пару правок», а все милые детали выше узнаются в процессе. Месяца так через два.
Кейс третий: лупанарий вместо разработки
Проект существует и даже как-то работает, но занимаются им вместо нормальных разработчиков какие-то инопланетные бл#ди.
Как будто гендир сходил в ближайший шалман и на радостях за хороший сервис сдал им в аутсорс ваш проект за мелкий прайс.
И теперь эти жрицы любви во главе с сутенером, в перерывах между своей основной деятельностью осваивают языки разработки, фиксят баги и выкатывают обновления.
Переводя с обычного на айтишный:
Ни контроля версий, ни репозитория, ни трекера, ни стендов, ни даже бекапов — ни-х#-я нет.
Примерно такой софт дает вам оформить заказ на такси, пиццу или суши-роллы. И как-то даже это работает.
Кейс четвертый: перспективный стартап
Красивый современный сайт с промо-роликами про некий «облачный SaaS».
Пара молодых фаундеров в стильных прикидах, свой штатный или пока приглашенный CTO. Все улыбаются и машут рассказывают о сказочных перспективах.
Потом вы подписываете «NDA» и оказывается что никакого сервиса еще нет, даже в виде прототипа.
Все считают в эксельке и работают в гуглопочте.
Зато есть сотня-другая подписанных договоров с обязательствами по реализации функционала и фиксированными сроками.
И суммарный объем работы где-то на год вперед, начиная со вчера. Командой, по 10 часов в день. А вы один, да.
К слову, описанное выше — далеко не все что было, просто наиболее характерные либо запомнившиеся варианты.
Как вытаскивать из жопы
Коль уж вы в это вписались по какой-то причине (денег вам не хватает или проблем в жизни приключений) — рассказываю что нужно делать и чем это примерно может закончиться.
Но лучше бы меня наняли, ей богу.
Во всех случаях вам так или иначе нужно привести состояние проекта к некоему общепринятому понятию нормы:
- Проект полностью собирается из исходного кода, весь исходный код находится в общем репозитории, есть релизная и девелоперская ветки;
- Продуктовая версия собирается из релизной ветки и выкатывается на стенды, без магии и колдовства;
- Есть трекер с текущими задачами, есть план работ, спринты и беклог;
- Есть бекапы и исходного кода и баз данных и самих стендов.
Да, это в основном технические детали и никого выше CTO они волновать не будут.
К сожалению бремя (и риски) донесения технических истин до ЛПР далеких от мира технологий — оно настолько велико, что оставляю это на вас:
Ищите подходы сами, как именно презентовать вашу жопу очередному Вайнштейну от бизнеса.
Ибо процесс сей непредсказуем, во всех смыслах. Могут выеб#ть, могут дать денег, а могут и то и другое.
Восстановление исходников
Как именно вы собере проект никого особо не волнует, но конечно реверс-инжиниринг это всегда крайний вариант.
На ваше счастье, это теперь возможно практически всегда, для всех языков, фреймворков и технологий, поэтому ночи сидения за листингами ассемблера в каком-нибудь IDAPro больше не нужны.
Само собой что есть всякие защиты от восстановления, упаковщики, шифровальщики — но это все про умных, а не про идиотов с проектами из жопы. Качество — другое дело:
восстановленный код будет представлять из себя адское месиво, поддерживать которое будет очень тяжело.
Поэтому рассчитывайте сразу как минимум на частичное последующее переписывание такого кода.
Сборка и фиксация состояния
Как только получилось все хоть как-то собрать и запустить — нужно обязательно зафиксировать состояние.
Это и будет новая точка отсчета жизни проекта — точка ноль.
Заливаете в репозиторий, раскатываете на стенд и обязательно создаете ваш первый бекап.
Отдельно про рефакторинг
Вас могут попросить «кое-чего поправить в новой версии», рассказывая про то что система тормозит и глючит.
А увидев первый раз код — ваши руки сами потянутся к огнемету топору клавиатуре, с целью переписать все нах#й. Начиная с ДНК тех кто породил это на свет.
К сожалению, вам придется притормозить:
Не стоит затевать рефакторинг до стабилизации проекта.
Дело в том что ключевая проблема плохих проектов это плохие люди, которые их сделали. И редко когда они не присутствуют рядом.
Вы можете дорефакторить хоть до нового движка Lamborghini — никто просто не оценит. Первый же айтишный слесарь работяга зальет в ваш чудо-движок паленого бензина или старое масло и вся ваша работа сгорит в огне.
А затраченное время никто не вернет.
Не надо метать бисер перед пролетариями. Исходите из того кто, где и зачем создал ваш жопный проект, кто загнал его в жопу и кто будет дальше его развивать, после вытягивания.
Ваша задача — вернуть проект к жизни и дать ему какую-то перспективу на будущее. Все.
А не пытаться выйграть заезд Формулы-1 на ржавых жигулях, особенно при бюджете в виде зарплаты советского инженера.
Так что дальше начинается самое важное, самая важная часть работы.
Постановка процесса
В современной разработке редко бывает что проект создается в одиночку, практически всегда это будет команда.
А там где команда — там все проблемы совместной работы над проектом.
нужен инструментарий и определенные правила, которые все участники процесса разработки будут соблюдать.
Команду вам либо придется собрать — если предыдущая разбежалась, либо доукомплектовать и обучить то что есть.
Ни в одном из вариантов ничего простого нет, все это будет сложно долго и со скрипом, поэтому именно формирование команды опишу в отдельной статье.
Вам нужно развернуть софт для совместной разработки, я использую вот такое:
https://www.atlassian.com/software/jira
Этих двух вполне хватит на начальном этапе, плюс какой-нибудь мессенджер и почта.
В JIRA настраивается и заполняется беклог, заводятся первые спринты.
В Gitlab выкладывается исходный код проекта и заводятся 'develop' и релизные ветки.
Дальше начинаются сложности, так как вам надо как-то заставить ваш лупанарий соблюдать определенные правила:
- Коммиты создаются с описаниями и ссылкой на тикет в JIRA;
- Код перед коммитом вычищается от отладочных блоков и форматируется;
- Новые задачи заводятся в беклог, по определенным правилам оформления;
- Тикеты закрываются только после выкладывания на стенд и тестирования;
- Спринт имеет конечные сроки, которые нужно соблюдать.
Это далеко не все правила, их еще много разных — опишу в отдельной статье. От того насколько успешно у вас получится заставить эти правила соблюдать напрямую будет зависеть: вылезет ваш проект из жопы или нет. А вы думали тут будет про «щас приду и все поправлю?»
Чем это все может закончиться
К сожалению процесс вытаскивания из жопы заключается далеко не только в одних технических работах — параллельно должны работать продажники, маркетинг, менеджмент, техподдержка и так далее.
Судьба проекта зависит от их работы в той же степени что и от вашей, но контролировать сейлов вам конечно же никто не даст.
Поэтому часто даже при технической победе и работающем проекте легко может случиться финансовое фиаско.
Еще бывает такое, что высшее руководство не хочет тратить деньги не умеет ждать и не готово работать в долгую, поэтому очень велик шанс «аборта на последнем месяце» — когда уже практически все готово.