За свою карьеру в IT я видел множество различных концепций, отличающихся различной степенью понятности, распространенности и важности. Больше всего я бы отметил концепцию технического долга, которая вроде бы, достаточно распространена, но в то же время достаточно пространна и непонятна: я часто вижу разработчиков и тимлидов, которые не понимают ее сути.
Сегодня же я решил осветить концепцию технического банкротства, которая еще менее распространена и менее понятна.
Выше я не зря упомянул технический долг, так как он достаточно сильно связан с банкротством, собственно, как и в реальном мире.
Возьмем аналогию.
Долг - необходимость в течение какого-то периода времени выплачивать деньги, взятые взаймы. Банкротство - отсутствие возможности эти деньги выплачивать.
Теперь переложим на разработку софта эти два понятия.
Технический долг - необходимость тратить время на улучшение кодовой базы (в общем случае) из-за того, что ранее в рамках внесения изменений (например, создание фичи или создание сервиса) не было уделено достаточно времени всем деталям. Выплата технического долга - это периодическое использование времени на улучшение кодовой базы.
Техническое банкротство - ситуация, когда переписать все с нуля экономически целесообразнее, чем пытаться исправить. Такая ситуация возникает в случае накопления долга технического.
Теперь я расскажу реальную историю, которая случилась во время консалтинга - ко мне обратились за помощью в восстановлении работоспособности небольшого платежного сервиса. Я решил, что будет нагляднее рассказать историю в хронологическом порядке, так будет видно, какие открытия нас настигали и "эффект" от этих открытий.
Часть 1. Самое начало.
Мы созвонились с заказчиком, обсудили ситуацию. Оказалось следующее:
Часть 2. Первые звоночки.
В первую очередь заказчик попросил внести несколько косметических изменений на сайт. Я предложил задачу знакомому фронтендеру - и он не взялся! Ему не очень хотелось раскатывать Ubuntu 16.XX, потому что только на ней работал NodeJS какой-то старой версии. Зафиксируем эту проблему как #1 - необновляемый софт. Позже я нашел аутсорс компанию, которая взялась за задачу и в итоге сделала это, но время на локальное разворачивание они потратили достаточно много.
В это же время обратили внимание на то, что у заказчика нет возможности добавлять пользователей в репозиторий с кодом, поэтому разработчикам пришлось все версии хранить на своем git-сервере. Спустя время заказчик восстановил доступ и мы смогли заливать код в основное хранилище. Это проблема #2 - некорректная работа с доступами.
Часть 3. Продолжение веселья.
После задач с сайтами необходимо было решить инфраструктурную проблему - на какой-то виртуальной машине заканчивалось место, из-за чего функции сервиса иногда не отрабатывали. (проблема #3 - архитектура системы не готова к работе "вдолгую"). Обращу внимание на пару моментов:
Часть 4. Начало конца.
Далее мы с заказчиком начали обсуждать следующую задачу - манипулирование контентом с помощью админки. Как постоянное решение мы решили использовать какую-нибудь CMS для этого, но т.к. необходимо было "подчистить" текущий контент (убрать неактуальные элементы, неактуальное описание и так далее), первым шагом мы решили поступить следующим образом:
Часть 5. Осознание.
Среди общего списка задач была интеграция с поставщиками контента, для этого нам было необходимо внести изменения в бекенд. Архитектура, которую я построил, была достаточно простой. Мы начали анализировать текущий код и увидели нечто: версия бекенда, которая крутилась на продакшне, не совпадали ни с одной веткой или коммитом в репозитории. (проблема #5 - неправильная работа с кодом). Сложилось впечатление, что код, который был на проде, не залили в репозиторий. Мы оказались в ситуации полной неопределенности - было очень рискованно выкладывать последний коммит на прод, т.к. там банально могло что-либо не работать. Мы обдумывали различные схемы, типа предпрода и тестированием заказчиком вручную, но из-за непоняток с сессиями и работой с базой данных решили от этого отказаться.
В итоге мы решили пойти длинным путем - аналитик будет просматривать фичи с текущего прода, описывать их поведение, потом разработчики проанализируют код на тестовом стенде, сравним и поймем, что необходимо доделать. Времени на это будет потрачено очень много.
Итоги
Буду честен, я первый раз столкнулся с такой ситуация, когда про проект известно очень мало и практически каждый раз мы получали выстрел в ногу.
Здесь я столкнулся со следующими основными проблемами:
Прокомментирую каждую.
#1. Необновляемый софт.
Весь софт, включая библиотеки, языки программирования, операционные системы обновляясь, поддерживают необходимый уровень безопасности, увеличивают производительность и пополняются новыми функциями. В это же время более старые версии выводятся из эксплуатации, и в какой-то момент ими просто не получится пользоваться без граблей и танцев с бубном. Своевременное обновление не занимает много времени, поэтому его нужно проводить.
#2. Некорректная работа с доступами.
В первую очередь хочется "скапитанить" - не теряйте доступе. Во вторую очередь - не стоит делать доступы к личным аккаунтам, стоит делать это на аккаунты корпоративные, которые не будут утеряны после ухода сотрудника.
#3. Недостаточное тестирование.
А вот эта ошибка крайне, крайне распространенная.
Даже в крупных компаниях я это наблюдал: тестирование может быть как ручное, так и автоматическое, даже нагрузочное, кое-где есть тестирование безопасности. Но мало кто на самом деле тестирует систему на предмет того, как она будет работать через какое-то время. Например, когда пользователей будет не 100, а 100000, будет ли система работать? Без тестирования сказать нельзя.
В случае развивающихся систем такое тестирование производится редко и редко виден негативный эффект. Это можно объяснить тем, что в принципе проверки производятся регулярно и проблемы детектируются и исправляются.
Но если предполагается, что развитие системы будет заморожено без остановки работы этой системы, то тестирование "на будущее" - обязательно.
#4.Отсутствие документации.
Ну тут все по классике - писать и поддерживать документацию не хочется, но после этого можно потратить дни и даже недели пытаясь понять, а что же происходит под капотом.
Особенность разработки ПО в том, что для того, чтобы понять, что происходит на самом деле необходимо потратить много времени из-за того, что все это работает неявно - нельзя увидеть связи, которые могут "выстрелить". Чтобы такие связи обнаружить, необходимо детальный анализ кода, чуть ли не построчно. Что занимает много времени, иногда дни, иногда даже недели.
#5. Неправильная работа с кодом.
Я помню темные времена, когда код правили "на бою". Но к счастью это уже прошло, и использование систем контроля версий стало де-факто стандартом индустрии. VCS (version control system) позволяет систематизировать работу с версиями софта, позволяя не потерять изменений и не "забыть", что же сейчас крутится на проде.
Как можно заметить, проблемы выше относятся к проекту, развитие которого было остановлено на некоторое время и восстановлено позднее.
Но не следует думать, что ситуация банкротства невозможна в случаях, когда развитие (внесение изменений) не останавливается.
Опасность такой ситуации в том, что ухудшение происходит медленно, из-за чего на это не обращается достаточное внимание. Лишь в какой-то момент происходит понимание, что банкротство неотвратимо. Обычно такое происходит из-за постоянного накопления технического долга, когда качеству технической базы не уделяется внимание, и в какой-то момент внесение изменений экономически нецелесообразно.
Итог
Я был бы очень рад, если бы после прочтения данной статьи вы стали больше обращать внимание на то, в каком состоянии находится ваша техническая база (код в том числе). Лишь постоянная критическая оценка позволит недопустить снижения эффективности разработки.
Сегодня же я решил осветить концепцию технического банкротства, которая еще менее распространена и менее понятна.
Выше я не зря упомянул технический долг, так как он достаточно сильно связан с банкротством, собственно, как и в реальном мире.
Возьмем аналогию.
Долг - необходимость в течение какого-то периода времени выплачивать деньги, взятые взаймы. Банкротство - отсутствие возможности эти деньги выплачивать.
Теперь переложим на разработку софта эти два понятия.
Технический долг - необходимость тратить время на улучшение кодовой базы (в общем случае) из-за того, что ранее в рамках внесения изменений (например, создание фичи или создание сервиса) не было уделено достаточно времени всем деталям. Выплата технического долга - это периодическое использование времени на улучшение кодовой базы.
Техническое банкротство - ситуация, когда переписать все с нуля экономически целесообразнее, чем пытаться исправить. Такая ситуация возникает в случае накопления долга технического.
Теперь я расскажу реальную историю, которая случилась во время консалтинга - ко мне обратились за помощью в восстановлении работоспособности небольшого платежного сервиса. Я решил, что будет нагляднее рассказать историю в хронологическом порядке, так будет видно, какие открытия нас настигали и "эффект" от этих открытий.
Часть 1. Самое начало.
Мы созвонились с заказчиком, обсудили ситуацию. Оказалось следующее:
- Команды разработки на проекте нет;
- Есть контакты с кем-то из предыдущей команды;
- Есть несколько Google Doc'ов с документацией;
- Система представляет из себя несколько сайтов, пара мобильных приложений, несколько бекенд-приложений, инфраструктура в одном из отечественных вендоров;
- Исходный код есть, лежит в Gitlab.
Часть 2. Первые звоночки.
В первую очередь заказчик попросил внести несколько косметических изменений на сайт. Я предложил задачу знакомому фронтендеру - и он не взялся! Ему не очень хотелось раскатывать Ubuntu 16.XX, потому что только на ней работал NodeJS какой-то старой версии. Зафиксируем эту проблему как #1 - необновляемый софт. Позже я нашел аутсорс компанию, которая взялась за задачу и в итоге сделала это, но время на локальное разворачивание они потратили достаточно много.
В это же время обратили внимание на то, что у заказчика нет возможности добавлять пользователей в репозиторий с кодом, поэтому разработчикам пришлось все версии хранить на своем git-сервере. Спустя время заказчик восстановил доступ и мы смогли заливать код в основное хранилище. Это проблема #2 - некорректная работа с доступами.
Часть 3. Продолжение веселья.
После задач с сайтами необходимо было решить инфраструктурную проблему - на какой-то виртуальной машине заканчивалось место, из-за чего функции сервиса иногда не отрабатывали. (проблема #3 - архитектура системы не готова к работе "вдолгую"). Обращу внимание на пару моментов:
- Документации к инфраструктуре не было (это проблема #4);
- Доступы к инфре были неполные, мы не могли админам дать доступ хотя бы на чтение. Поэтому пришлось ходить через аккаунт заказчика, чтобы задача хоть как-то двигалась. (это тоже проблема #2);
Часть 4. Начало конца.
Далее мы с заказчиком начали обсуждать следующую задачу - манипулирование контентом с помощью админки. Как постоянное решение мы решили использовать какую-нибудь CMS для этого, но т.к. необходимо было "подчистить" текущий контент (убрать неактуальные элементы, неактуальное описание и так далее), первым шагом мы решили поступить следующим образом:
- "Руками" выгрузить контент из базы в каком-нибудь CSV;
- Заказчик помечает записи для удаления;
- "Руками" обновляем информацию в БД.
Часть 5. Осознание.
Среди общего списка задач была интеграция с поставщиками контента, для этого нам было необходимо внести изменения в бекенд. Архитектура, которую я построил, была достаточно простой. Мы начали анализировать текущий код и увидели нечто: версия бекенда, которая крутилась на продакшне, не совпадали ни с одной веткой или коммитом в репозитории. (проблема #5 - неправильная работа с кодом). Сложилось впечатление, что код, который был на проде, не залили в репозиторий. Мы оказались в ситуации полной неопределенности - было очень рискованно выкладывать последний коммит на прод, т.к. там банально могло что-либо не работать. Мы обдумывали различные схемы, типа предпрода и тестированием заказчиком вручную, но из-за непоняток с сессиями и работой с базой данных решили от этого отказаться.
В итоге мы решили пойти длинным путем - аналитик будет просматривать фичи с текущего прода, описывать их поведение, потом разработчики проанализируют код на тестовом стенде, сравним и поймем, что необходимо доделать. Времени на это будет потрачено очень много.
Итоги
Буду честен, я первый раз столкнулся с такой ситуация, когда про проект известно очень мало и практически каждый раз мы получали выстрел в ногу.
Здесь я столкнулся со следующими основными проблемами:
- Необновляемый софт;
- Некорректная работа с доступами;
- Недостаточное тестирование;
- Отсутствие документации;
- Неправильная работа с кодом.
Прокомментирую каждую.
#1. Необновляемый софт.
Весь софт, включая библиотеки, языки программирования, операционные системы обновляясь, поддерживают необходимый уровень безопасности, увеличивают производительность и пополняются новыми функциями. В это же время более старые версии выводятся из эксплуатации, и в какой-то момент ими просто не получится пользоваться без граблей и танцев с бубном. Своевременное обновление не занимает много времени, поэтому его нужно проводить.
#2. Некорректная работа с доступами.
В первую очередь хочется "скапитанить" - не теряйте доступе. Во вторую очередь - не стоит делать доступы к личным аккаунтам, стоит делать это на аккаунты корпоративные, которые не будут утеряны после ухода сотрудника.
#3. Недостаточное тестирование.
А вот эта ошибка крайне, крайне распространенная.
Даже в крупных компаниях я это наблюдал: тестирование может быть как ручное, так и автоматическое, даже нагрузочное, кое-где есть тестирование безопасности. Но мало кто на самом деле тестирует систему на предмет того, как она будет работать через какое-то время. Например, когда пользователей будет не 100, а 100000, будет ли система работать? Без тестирования сказать нельзя.
В случае развивающихся систем такое тестирование производится редко и редко виден негативный эффект. Это можно объяснить тем, что в принципе проверки производятся регулярно и проблемы детектируются и исправляются.
Но если предполагается, что развитие системы будет заморожено без остановки работы этой системы, то тестирование "на будущее" - обязательно.
#4.Отсутствие документации.
Ну тут все по классике - писать и поддерживать документацию не хочется, но после этого можно потратить дни и даже недели пытаясь понять, а что же происходит под капотом.
Особенность разработки ПО в том, что для того, чтобы понять, что происходит на самом деле необходимо потратить много времени из-за того, что все это работает неявно - нельзя увидеть связи, которые могут "выстрелить". Чтобы такие связи обнаружить, необходимо детальный анализ кода, чуть ли не построчно. Что занимает много времени, иногда дни, иногда даже недели.
#5. Неправильная работа с кодом.
Я помню темные времена, когда код правили "на бою". Но к счастью это уже прошло, и использование систем контроля версий стало де-факто стандартом индустрии. VCS (version control system) позволяет систематизировать работу с версиями софта, позволяя не потерять изменений и не "забыть", что же сейчас крутится на проде.
Как можно заметить, проблемы выше относятся к проекту, развитие которого было остановлено на некоторое время и восстановлено позднее.
Но не следует думать, что ситуация банкротства невозможна в случаях, когда развитие (внесение изменений) не останавливается.
Опасность такой ситуации в том, что ухудшение происходит медленно, из-за чего на это не обращается достаточное внимание. Лишь в какой-то момент происходит понимание, что банкротство неотвратимо. Обычно такое происходит из-за постоянного накопления технического долга, когда качеству технической базы не уделяется внимание, и в какой-то момент внесение изменений экономически нецелесообразно.
Итог
Я был бы очень рад, если бы после прочтения данной статьи вы стали больше обращать внимание на то, в каком состоянии находится ваша техническая база (код в том числе). Лишь постоянная критическая оценка позволит недопустить снижения эффективности разработки.
