День 2284. #УрокиРазработки
10 Уроков Качества Разработки ПО. Продолжение
Начало

4. Пишите код, который вы можете уверенно изменять
Самый важный аспект поддерживаемого кода — это возможность изменять его уверенно: уверенность в том, что вы его поняли, внесли правильные изменения и ничего больше не сломали.

Вот несколько рекомендаций:
- Код должен читаться как книга — методы упорядочены по порядку выполнения, а не по порядку видимости.
- Весь код в методе или функции должен находиться на одном уровне абстракции.
- Методы должны стараться не выходить за рамки 15 строк кода.
- Имена методов должны быть функциональными и объяснять их назначение, а не реализацию.
- Документация кода должна описывать, почему существует метод, а не как он работает.
- Встроенные комментарии допустимы, если они предоставляют дополнительный контекст.
- return либо в самом начале, либо в самом конце, но не в середине.
- Избегайте булевых параметров, используйте перечисления.
- Не вводите абстракции только ради внедрения зависимостей.
- Группируйте код по функциональности, а не по технической структуре для большей ясности.
- Обеспечьте достаточное покрытие тестами: 80% — хорошо, 90% — отлично, 95% — слишком много.
- Не тестируйте слишком подробно; тестируйте внешний интерфейс, но не детали реализации.

5. Это никогда не происходит только один раз
Вы когда-нибудь писали наспех код, а затем обнаруживали, что его используют снова и снова? Или вас просили создать прототип, который каким-то образом попадал в релиз? А как насчёт странной ошибки, которая волшебным образом разрешалась сама собой во время тестирования — только чтобы позже снова появиться в производстве?

Если вы не создаёте MVP (минимально жизнеспособный продукт), не используйте эти практики. Выделите время, чтобы заменить это одноразовое решение надлежащим долгосрочным кодом. Не соглашайтесь на ситуативные решения — будь то очистка куков, повторный запуск нестабильного теста, проблемы с разрешениями или тайм-аутами. Всегда решайте проблемы в корне. Будущий вы скажет вам спасибо.

6. Избегайте любых ручных шагов во время развёртывания
Способность команды развёртывать должным образом протестированную и версионированную программную систему на своей внутренней или облачной инфраструктуре является хорошим показателем зрелости команды. Любой ручной шаг в этом процессе (за исключением ручного запуска конвейера развёртывания) является потенциальной ответственностью и должен быть автоматизирован. Люди совершают ошибки, независимо от того, насколько они скрупулёзны.

С другой стороны, хорошо спроектированный конвейер развёртывания заботится о компиляции исходного кода, вызове любых инструментов анализа кода, запуске автоматизированных тестов, версионировании артефактов развёртывания, предоставлении инфраструктуры, обновлении схемы базы данных, развёртывании в промежуточном слоте, а затем, после подтверждения работоспособности, заменяет его на производственный слот. Всё это без необходимости сообщать разработчикам пароли производственной среды и без того, чтобы кто-либо подключался к производственной среде и вручную запускал скрипты. И если ваш руководитель не видит в этом ценности, аудит, связанный с многочисленными стандартами безопасности, которые у нас есть в настоящее время (ISO 27001, NIS и т.д.), поможет его убедить.

Окончание следует…

Источник: https://www.dennisdoomen.com/2025/03/10-quality-lessons.html

.NET Разработчик

День 2284. #УрокиРазработки
10 Уроков Качества Разработки ПО. Продолжение
Начало

4. Пишите код, который вы можете уверенно изменять
Самый важный аспект поддерживаемого кода — это возможность изменять его уверенно: уверенность в том, что вы его поняли, внесли правильные изменения и ничего больше не сломали.

Вот несколько рекомендаций:
- Код должен читаться как книга — методы упорядочены по порядку выполнения, а не по порядку видимости.
- Весь код в методе или функции должен находиться на одном уровне абстракции.
- Методы должны стараться не выходить за рамки 15 строк кода.
- Имена методов должны быть функциональными и объяснять их назначение, а не реализацию.
- Документация кода должна описывать, почему существует метод, а не как он работает.
- Встроенные комментарии допустимы, если они предоставляют дополнительный контекст.
- return либо в самом начале, либо в самом конце, но не в середине.
- Избегайте булевых параметров, используйте перечисления.
- Не вводите абстракции только ради внедрения зависимостей.
- Группируйте код по функциональности, а не по технической структуре для большей ясности.
- Обеспечьте достаточное покрытие тестами: 80% — хорошо, 90% — отлично, 95% — слишком много.
- Не тестируйте слишком подробно; тестируйте внешний интерфейс, но не детали реализации.

5. Это никогда не происходит только один раз
Вы когда-нибудь писали наспех код, а затем обнаруживали, что его используют снова и снова? Или вас просили создать прототип, который каким-то образом попадал в релиз? А как насчёт странной ошибки, которая волшебным образом разрешалась сама собой во время тестирования — только чтобы позже снова появиться в производстве?

Если вы не создаёте MVP (минимально жизнеспособный продукт), не используйте эти практики. Выделите время, чтобы заменить это одноразовое решение надлежащим долгосрочным кодом. Не соглашайтесь на ситуативные решения — будь то очистка куков, повторный запуск нестабильного теста, проблемы с разрешениями или тайм-аутами. Всегда решайте проблемы в корне. Будущий вы скажет вам спасибо.

6. Избегайте любых ручных шагов во время развёртывания
Способность команды развёртывать должным образом протестированную и версионированную программную систему на своей внутренней или облачной инфраструктуре является хорошим показателем зрелости команды. Любой ручной шаг в этом процессе (за исключением ручного запуска конвейера развёртывания) является потенциальной ответственностью и должен быть автоматизирован. Люди совершают ошибки, независимо от того, насколько они скрупулёзны.

С другой стороны, хорошо спроектированный конвейер развёртывания заботится о компиляции исходного кода, вызове любых инструментов анализа кода, запуске автоматизированных тестов, версионировании артефактов развёртывания, предоставлении инфраструктуры, обновлении схемы базы данных, развёртывании в промежуточном слоте, а затем, после подтверждения работоспособности, заменяет его на производственный слот. Всё это без необходимости сообщать разработчикам пароли производственной среды и без того, чтобы кто-либо подключался к производственной среде и вручную запускал скрипты. И если ваш руководитель не видит в этом ценности, аудит, связанный с многочисленными стандартами безопасности, которые у нас есть в настоящее время (ISO 27001, NIS и т.д.), поможет его убедить.

Окончание следует…

Источник: https://www.dennisdoomen.com/2025/03/10-quality-lessons.html

hottg.com/NetDeveloperDiary/2757

2.4K viewsMay 2 at 05:02