Добро пожаловать в Architecture Cleaning

Posted by Никита Ляпин on Thursday, April 15, 2021

Чем хорошая архитектура отличается от плохой?

Если мы зададимся этим вопросом, то в итоге придем к выводу о затратах на проект. В проектах с плохим качеством кода и плохим техническим дизайном развитие стоит дороже. По времени внесения изменений, необходимому оборудованию для нормальной производительности, числу сотрудников необходимых для реализации. С другой стороны иногда вам нет необходимости досконально продумывать структуру какой-то временной и маловажной утилиты. Реализации парсинга сайта, либо утилиты для очистки диска. В таком случае на архитектуру можно и не тратиться. Вложение в разработку архитектуры это поиск баланса между текущими затратами и потенциальными затратами проекта при его развитии.

Сделаем сейчас как проще и быстрее, а потом улучшим

Это хороший принцип, который позволяет начать что-то делать прямо сейчас, а не сидеть часами в размышлениях. Но это не повод руководствоваться только им. Всегда. Представим графически стоимость исправления ошибки в зависимости от того на какой стадии она была сделана:

Если вы ошиблись на этапе анализа - вам лишь нужно исправить текст постановки задачи, текстовое описание требований. На этапе проектирования - исправить нужно будет уже несколько схем, диаграмм компонент, разбиение на задачи. В случае разработки исправление ошибки еще сложнее - вы уже исправляете написанный ранее код, переписываете методы, данные внутри классов, переписываете тесты и т.п. Тестирование или даже эксплуатация - аналогичным образом. Для исправлений после релиза вам уже нужно думать как исправить накопившиеся данные в БД. Каким образом переучивать пользователей и как им объяснить что функционал в новой версии изменится, как обеспечить обратную совместимость. Именно поэтому проектирование ПО так важно и позволяет сэкономить усилия на более поздних стадиях.

Как понять, что в проекте большой технический долг

Давайте определимся с самим термином. Потому что технический долг понимают по разному и вкладывают в него разный смысл. Технический долг - это то, что никак не влияет на конечную бизнес-значимость продукта и то, что мешает разработчикам быстро и качественно реализовывать новый функционал. Например, если поместить все классы в один огромный класс приложения мы получим сложно сопровождаемый код на 50000 строк кода. С одной стороны все будет по прежнему работать как ожидает заказчик, но добавить что либо новое будет сложно. Это и есть техдолг. Его особенность в том, что он как айсберг - не видим напрямую заказчика, менеджерам, аналитикам. Всем тем, кто не сталкивается с кодом напрямую. Но с ним каждый день приходится иметь дело разработчикам. Для проектов в которых с техдолгом не работают можно наблюдать следующую картину:

Здесь мы видим, что с каждым следующим релизом время на каждую строчку кода только увеличивается. Многим, наверное, доводилось оказываться в похожей ситуации. Причем увеличение числа разработчиков со временем лишь ухудшает ситуацию, мотивация сотрудников также не приносит должного эффекта.

На страницах данного блога мы поговорим с вами о том как избежать подобной ситуации. Какие существуют паттерны и антипаттерны в организации технического дизайна системы, как работать с техническим долгом, почему покрытие тестами приводит к росту производительности разработки.