Плохое качество кода
не является неизбежным аттрибутом любого программного продукта. Это результат
известных причин, которые могут быть предсказаны и проконтролированы. Но это
возможно только в том случае когда есть понимание о чем идет речь и разработчики
обладают знаниями как их недопустить.
Проблемы качества в
разработке програмных продуктов как правило относятся к основным рискам
бизнеса. Ниже описаны пять наиболее часто встречаемых причин плохого качества
кода и соответствующих путей, как их избежать.
1. Недостаток знаний предметной области.
Возможно, самый
большой вклад в плохое
качество программного обеспечения
является прискорбный факт,
что большинство разработчиков не являются экспертами
в области бизнеса,
для которого они создают код, будь то телекоммуникации,
банковское дело, энергетика,
цепочками поставок, розничная торговля, или
что-то другое.
Со временем знаний
будет становится больше, но большая
часть из этих знаний появится в результате исправления дефектов,
вызванных их ошибочном
понимании функциональных требований.
Лучший способ, чтобы смягчить эту проблему, это
обеспечить доступ к экспертам
в данной области от бизнеса
и активно обучать
разработчиков данной сфере, а также
проводить экспертные обзоры с
теми, которые обладают большим
опытом.
2. Недостаток знаний используемых технологий
Большинство разработчиков владеют
несколькими языками программирования
и разными технологиями. Тем
не менее, современные многоуровневые
бизнес-приложения состоят из нескольких уровней, в каждом
из которых используется разный набор технологий,
платформ и всевозможных языков
программирования.
Эти уровни
включают пользовательский
интерфейс, бизнес-логику и управление данными,
и они могут
взаимодействовать через промежуточные
системы управления
ресурсами предприятия и унаследованных
приложений, написанных на архаичных
языках. Немногие
разработчики знают все
эти языки и технологии, и
их неверное предположений
о том, как работает
та или другая технология
является основным источником
нефункциональных ошибок,
которые вызывают различные проблемы,
повреждения данных и
нарушения безопасности системы.
Лучшим способом смягчения этой
причины, это дополнительное обучение разработчиков
различным прикладным технологиям,
проведение экспертных
оценок с разработчиками, работающих
с другими уровнями приложений,
а также выполнение статического и динамического анализ
кода.
3. Нереальные сроки выполнения
Когда разработчики
вынуждены жертвовать сбалансированным процессом разработки в угоду сокращенного
графика работ, результат редко бывает хорошим.
Иногда случаются
героические подвиги, но очень редко они повторяются на последующих маршах
сметри. При работе на высокой скорости разработчики делают больше ошибок и меньше
времени тратят на их ликвидацию. Единственным способом избавится от подобных
проблем – это использование жестких практик управления проектом. Контроллирование
содание кода, отслеживание прогресса для идентификации всевозможных ошибок,
контроллирование изменений для конечных требований – все это критично для
обеспечения проффесионального окружения при создании программного продукта.
4. Плохо спроектированный код
Как минимум две трети
всего времени разработки, тратится на изменения и улучшения существующего кода.
Исследования показали, что половина времени тратится на модификации
существующего кода и попытки выяснить как же все там работает.
Чрезмерно сложный
код сложно модифицировать и это ведет к
различным ошибкам и негативным побочным эффектам. Ошибки в свою очередь
приводят к дополнительным затратам по их ликвидации и соответствено – к задержкам
релизов. Наилучший способ избавиться от подобных проблем – это проведение рефакторинга
наиболее проблемных участком кода, и дополнение его информацией вспомогательной
статической информацией.
5. Неправильная тактика разрботки
Большинство больших
многоуровневых приложений разрабатывается и поддерживается распределенными
командами, некоторые из которых могут работать на аутсорсе из других стран.
Соответственно нередко возникают ситуации, когда команда-разработчик имеет
минимальное представление о процессе разработки и не может повлиять на качество
получаемого продукта.
По некоторым причинам,
уровни CMMI не всегда гарантируют высокое качество
программного продукта. Для снижения рисков проблем качества сторонних команд,
менеджеры проекта должны предусмотреть подобные моменты в подписываемых
контрактах и обеспечить контроль качества при получении кода от сторонней
команды.
Послесловие
Первые две причины
отличаются от функциональных и нефункцинальных проблем качества, это отличие
критично, так как нефункциональные ошибки невозможно выявить в процессе
тестирования и их эффект часто является более разрушительным.
Третья и четвертая проблемы
существуют давно, хотя четвертая проблема продолжает усугубляться ввиду
увеличения числа возможных технологий, которые применяются в современных
приложениях.
Последняя проблема
также не нова, но эффект от нее увеличился с увеличением аутсорсинга и делегирования
разработки. Еще один момент отсутствующий в списке но также заслуживающий
внимания – это отсутствие координации между командами разработки, что в итоге приводит
к неменьшим негативным последствиям.
В хорошей организации
тестирование не является способом выявления ошибок. Скорее это верификация
выполнения требуемой логики программы в различных возможных условиях. Понимая описанные
проблемы и следуя приведенным выше рекомендациям, ваш продукт будет изначально
разработаываться с учетом требований качества, что позволит съэкономить до 40%
усилий, которые иначе пошли бы на переработку кода и ликвидации рисков, которые
существуют в сфере разработки программных продуктов.
