День 2251. #УрокиРазработки
Уроки 50 Лет Разработки ПО

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

Чтобы избежать малозаметных разрывов между плохим и хорошим, часто нужно лишь немного подумать, прежде чем продолжать. Все мы встречали множество программных продуктов с ошибками, которые должны были быть обнаружены во время тестирования, или с плохим дизайном, по которому было видно, что пользовательскому опыту не уделили должного внимания. Например, сайт сообщает, что у вас есть непрочитанное уведомление. Но при нажатии на значок уведомления появляется сообщение: «У вас нет сообщений». Или форма на сайте, которая из-за ошибки в Javascript не проходит валидацию, и клиент не может её отправить. Подобные дефекты мелкие, но очень раздражают и заставляют задуматься: «А что, если во всём остальном эта компания тоже работает спустя рукава»?

Вот некоторые категории проблем, ухудшающих качество ПО, которых разработчики могут избежать:
1. Предположения
Бизнес-аналитик может ошибиться в своих предположениях или записать предположение, сделанное клиентами, но затем забыть проверить, насколько оно верно.

2. Идеи решения
Клиенты часто предлагают бизнес-аналитикам свои идеи решения вместо требований. Если бизнес-аналитик не заглянет за пределы предложенного решения, чтобы понять реальную потребность, то может взяться за решение неправильной задачи или выбрать неадекватное решение, которое придётся исправлять позже.

3. Регрессионное тестирование
Если не выполнить регрессионное тестирование после быстрого изменения кода, то можно пропустить ошибку в изменённом коде. Даже небольшое изменение может неожиданно сломать что-то ещё.

4. Обработка исключений
Разработчики могут настолько сосредоточиться на «счастливом пути» в ожидаемом поведении системы, что могут забыть о распространённых ошибках. Отсутствующие, ошибочные или неправильно отформатированные данные могут привести к неожиданным результатам или даже сбою системы.

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

Качество не бесплатно в смысле стоимости. Предотвращение, обнаружение и исправление дефектов требуют дополнительных ресурсов. Тем не менее устранение малозаметных разрывов между плохим и хорошим обязательно окупится, так как вам не придётся тратить ещё больше ресурсов на устранение проблем.

Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 6.

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

День 2251. #УрокиРазработки
Уроки 50 Лет Разработки ПО

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

Чтобы избежать малозаметных разрывов между плохим и хорошим, часто нужно лишь немного подумать, прежде чем продолжать. Все мы встречали множество программных продуктов с ошибками, которые должны были быть обнаружены во время тестирования, или с плохим дизайном, по которому было видно, что пользовательскому опыту не уделили должного внимания. Например, сайт сообщает, что у вас есть непрочитанное уведомление. Но при нажатии на значок уведомления появляется сообщение: «У вас нет сообщений». Или форма на сайте, которая из-за ошибки в Javascript не проходит валидацию, и клиент не может её отправить. Подобные дефекты мелкие, но очень раздражают и заставляют задуматься: «А что, если во всём остальном эта компания тоже работает спустя рукава»?

Вот некоторые категории проблем, ухудшающих качество ПО, которых разработчики могут избежать:
1. Предположения
Бизнес-аналитик может ошибиться в своих предположениях или записать предположение, сделанное клиентами, но затем забыть проверить, насколько оно верно.

2. Идеи решения
Клиенты часто предлагают бизнес-аналитикам свои идеи решения вместо требований. Если бизнес-аналитик не заглянет за пределы предложенного решения, чтобы понять реальную потребность, то может взяться за решение неправильной задачи или выбрать неадекватное решение, которое придётся исправлять позже.

3. Регрессионное тестирование
Если не выполнить регрессионное тестирование после быстрого изменения кода, то можно пропустить ошибку в изменённом коде. Даже небольшое изменение может неожиданно сломать что-то ещё.

4. Обработка исключений
Разработчики могут настолько сосредоточиться на «счастливом пути» в ожидаемом поведении системы, что могут забыть о распространённых ошибках. Отсутствующие, ошибочные или неправильно отформатированные данные могут привести к неожиданным результатам или даже сбою системы.

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

Качество не бесплатно в смысле стоимости. Предотвращение, обнаружение и исправление дефектов требуют дополнительных ресурсов. Тем не менее устранение малозаметных разрывов между плохим и хорошим обязательно окупится, так как вам не придётся тратить ещё больше ресурсов на устранение проблем.

Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 6.

👍5👎1

hottg.com/NetDeveloperDiary/2717

2.57K viewsMar 30 at 05:01