Заметки

emacsway-chat¶

https://t.me/emacsway_chat/4495

Говнокодинг лечится установкой петли обратной связи: то есть тот же самый менеджер будет сопровождать ту систему (и отвечать за инциденты), которую создал. Далее ставите метрики на категоризацию задач команды. Менеджер вынужден будет балансировать между сроком поставки фич и стоимостью сопровождения. Рост стоимости сопровождения замедляет выпуск фич, то есть напрямую портит KPI менеджеру.

Типовая ошибка управления это когда есть команда проекта (создающая MVP), а затем это все “скидывается” на поддержку в некое общее ИТ.

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

Архитектура большого проекта похожа на школьные опыты по биологии. Там, где рассматривают кожицу лука под микроскопом. Сначала вы смотрите на всё со стороны и добавляете контрастную жидкость. Потом вставляете в микроскоп и настраиваете свет, пытаясь остаться в границах на минимальном приближении. И лишь найдя цель, меняете увеличение на максимум фокусируетесь на деталях. То есть сначала вы делали блок схему, а потом перед непосредственной разработкой будете делать архитектуру каждого блока, заполняя его деталями. По необходимости будете добавлять всякие flow и sequence – они легче всего воспринимаются всеми участниками процесса разработки. Так что в отличии от строительства, вы начинаете разработку с наброска, а детальную архитектуру получите лишь в конце. Поэтому так полезны, хоть и не популярны, большие UML пакеты, позволяющие ссылки на диаграммы и вложенные чарты. Разработка – это drill down от blue-print до detailed architecture.

Проектные тесты¶

Это жесткие правила ломающие билд при нарушении, написанные в виде юнит теста или плагина к какому-нибудь сонару. Примеры подобных тестов:

Минимальное покрытие тестами в определённых модулях
Ограничение по количеству заигнориных тестов
Тест на то, что тест с ограничением тестов в игноре не заигнорин
Список запрещённых референсов (например уровень бизнес-логики не должен знать о типах в базе данных)
Список разрешённых референсов (допустим open source и legacy библиотеки)
Разрешённые типы файлов (к примеру файлов .sql не должно существовать)
Naming и структура проекта (если должно быть 3 слоя и каждый отдельной библиотекой, а тесты заканчиваться на _Test то будьте любезны)
Парсинг и проверка скриптов на соответствие (например скрипт конфигурации должен создавать одноименную запись и в параметрах окружения и в файлах)
Минимальное количество строк лога в каждом классе (если актуально)
Типы исключений и их иерархия (допустим модуль безопасности не должен отдавать детальные exception, так что там может быть только один тип и без текста)

Индикаторы здоровья проекта¶

Отсутствие взрывного роста строк кода после первых шагов. Как только мы закончили строить базу и перешли непосредственно к бизнесу, то коммиты должны быть частыми и небольшими. Меньше кода – практически всегда, лучше код. Поэтому если кто, то навалил кучу, то скорее всего там проблема с заданием и расхождением с линией архитектуры.
Длинные функции и классы – неплохой индикатор поспешной работы и костылей. На начальном этапе такого быть не должно.
Сложность кода можно отследить по количеству юнит тестов при высоком покрытии. Много тестов – значит много веток, а значит опять что-то попахивает.
Нарушение конвенций тоже стоит заавтоматить и следить. Закладывается фундамент дома, в котором нам всем жить долго.
Много статики (классов, методов, полей), обычно, проявления антипаттернов.
Проверки безопасности на вшитые пароли и вшивые референсы на какие-нибудь опенсорсы с уязвимостями или сложными лицензиями.

Источник

Полезные ссылки