Эффект "разбитых окон" в разработке софта
Подробнее про теорию разбитых окон можно прочитать тут.
Если коротко, то эффект “разбитых окон” - это психологическая концепция, которая утверждает, что мелкие правонарушения и признаки безразличия к порядку провоцируют рост более серьёзных преступлений.
Касаясь темы разработки можно переформулировать определение и сказать, что “разбитые окна” в программировании - это мелкие недоработки / плохие практики в кодовой базе. Они приводят к ухудшению общей архитектуры проекта и способствуют использованию антипаттернов и спорных решений в проекте.
В видео про то, как не надо выстраивать коммуникации между блоками во flutter_bloc, мы затрагивали тему использования блоков внутри блоков. Это - яркий пример “разбитого окна”. Вместо того, чтобы провайдить параметры из одного блока в другой, использования BlocListener’ов или других виджетов для создания коммуникации между ними, мы просто делаем все как можно быстрее. Это дает в свою очередь карт-бланш всем остальным коллегам на подобные технические решения. Особенно если это прошло ревью от лида или других разработчиков, вопросы отпадут само-собой - так точно можно и вам никто ничего не скажет. Даже если и будут вопросы, можно ссылаться на предыдущие реквесты и уже имеющийся код, мол так тут принято.
Порой наши собственные решения порой могут разбиваться нами самими. Например, если в проекте есть UI-Kit, то все компоненты должны быть только в нем. Но бывают ситуации, когда новые элементы интерфейса начинают класть в приложение. После пары-тройки таких ситуаций, у вас исчезнет целостность UI-системы. Получается, зря тратили время на ее построение, а дальнейшая модификация или ее распространение на другие проекты стоит под вопросом.
Описанное выше можно поправить разработкой через официальные рекомендации из документации, либо же хорошим ревью изменений. Вопрос больше в том, если ли время и ресурсы на проработки таких вещей? Вот у нас их не всегда хватает, приходится в рамках других задач делать правки по техническому долгу.
Так же нужно учитывать, что мы не всегда можем определить “разбитое окно”. Дело касается больше не технических, а концептуальных решений. Глобальные состояния - это не всегда плохо. Плохо то, что они могут использоваться где попало и без следования регламентам и требованиям проекта. Если сущность должна сохраняться через репозиторий или сервис, делать это в обход (например, из самого класса бизнес-модели) - “разбитие окна”.
При росте проекта все болячки рано или поздно вылезут, и будет лучше, если вы заранее позаботетесь о состоянии кодовой базы. Добавить виджет блока или создать визуальный компонент в другом модуле - не самые трудоемкие задачи, а рефакторинг проекта будет дороже и сложнее. Старайтесь думать наперед о таких вещах.
P.S: на создание поста повлияли события в моем подъезде (смотри изображение в посте). Сначала там подрались какие-то нетрезвые ребята. Потом краской на полу указали на нехорошего человека и квартиру, в которой он живет (стрелками). Сейчас вообще кто-то дверь открыл будто бы с ноги, и на стене есть отпечаток от сильного удара ручки. Это все происходило постепенно, аналогии напрашиваются сами-собой.