Непрерывность проверки кода
Непрерывность проверки кода
Уже двадцать лет тому назад было установлено, что визуальная проверка кода - это эффективный, с точки зрения стоимости, метод исправления дефектов в программных продуктах. Это подтверждают и эмпирическими исследованиями, однако несмотря на это, большинство программистов не любят проверок и не считают это занятие ни приятным, ни стоящим. В результате о проверках, как правило, забывают (за исключением тех случаев, когда их выполнение требуется официально). Зачастую проверку кода осуществляют неподготовленные к этой задаче программисты.
"Несмотря на положительные результаты исследований в течение более 20 лет, процедура проверки кода очень плохо приживается в индустрии производства программных продуктов. Точных данных у нас нет, однако согласно неформальному обзору USENET-групп, 72 из 90 опрошенных программистов практикуют проверку кода крайне редко, или вообще ей не занимаются."
Идея проверки кода базируется на известном постулате: чем раньше обнаружен дефект, тем проще и дешевле его исправить. Существует много исследований на эту тему, в некоторых даже утверждается, что исправление дефекта будет стоить в десять раз дороже на каждой последующей ступени развития проекта.
Экспоненциальный рост стоимости дефектов легко объяснить. Во время проверки, программист говорит: "У оператора "if", что на 450 строке кода, должен быть оператор "else"." После этого ему понадобится несколько минут, чтобы быстро исправить эту ошибку на своем компьютере. Если же программный продукт уже находится в эксплуатации, то в один прекрасный день раздается звонок разъяренного клиента: "Новый год на носу, а у меня ни одна касса не работает! Я ни-че-го не могу продать! Вы меня разоряете!"
Итак, в первом случае программист имеет дело с ошибкой, на которую ему только что указали. Во втором случае, группа технической поддержки должна потратить время на диагностику проблемы (все кассовые аппараты не работают), затем обратиться к самой системе и определить, где нужно вносить исправления (в какой строке кода не хватает оператора "else"). На этом примере всякий может убедиться - работа группы поддержки, которой надо проанализировать проблему и выявить дефект, стоит гораздо дороже, чем те несколько минут, которые должен затратить программист на исправлении ошибки в своем собственном коде. Если программисты работают парами, то такие проверки кода происходят непрерывно. А непрерыная проверка кода не только опережает спорадические "инспекции" как по качеству, так и по скорости нахождения ошибок, но и не вызывает у программистов отрицательных эмоций.
Посмотрите, как сардонически описывает свой опыт программирования в паре с новичком опытный программист, который в начале был настроен к идее совместной работы весьма скептически. К своему удивлению, этот специалист вдруг обнаруживает, что даже новичок может существенно улучшить качество кода, который он пишет.
Как-то я работал с одним из наименее опытных разработчиков над довольно простой задачей. Честно говоря, я всегда считал себя замечательным специалистом по языку Smalltalk, поэтому был уверен, что просто буду учить молодежь, как надо работать.
Не прошло и нескольких минут, как этот малец задает мне вопрос - почему, дескать, я делаю то, что я делаю. И точно, оказалось, что я уже совершил ошибку! Я исправился. Тогда этот бойкий мальчишка напомнил мне правильное название метода или чего-то там еще, что я писал в тот момент неправильно. Вскоре он уже вовсю указывал мне, что я должен делать дальше, а сам успевал подмечать еще и все ошибки в синтаксисе и форматировании.
[со слов Рона Джеффриза]
И наконец, еще одним преимуществом постоянных проверок кода является то, что с их помощью разработчики узнают новые способы и стили кодирования, особенности языка и лучше представляют себе всю систему.
Непрерывная проверка кода при совместном программировании создает уникальные условия для обучения, поскольку оба программиста постоянно учатся друг у друга. "Проверка кода - это уникальная возможность для обучения: процесс анализа и критики программных артефактов, которые создал кто-то другой, представляет собой замечательный по эффективности способ изучения языков, техники проектирования, предметной области и т.д."
В том же ключе выдержаны и другие высказывания программистов, занимающихся проверкой кода:
Ошибки обнаруживаются сразу, на момент появления, что позволяет экономить даже на компиляции, не говоря уже о прочих экономических выгодах раннего обнаружения и исправления дефектов.
Горазо легче соблюдать стандарты кодирования, если за этим следит сразу две пары глаз.
Команда разработчиков учится общению и совместной работе.
Более 800 000 книг и аудиокниг! 📚
Получи 2 месяца Литрес Подписки в подарок и наслаждайся неограниченным чтением
ПОЛУЧИТЬ ПОДАРОКЧитайте также
12.4. Макроопределения проверки адреса IPv6
12.4. Макроопределения проверки адреса IPv6 Существует небольшой класс приложений IPv6, которые должны знать, с каким собеседником они взаимодействуют (IPv4 или IPv6). Эти приложения должны знать, является ли адрес собеседника адресом IPv4, преобразованным к виду IPv6. Определены
17.5.4. Проверки
17.5.4. Проверки Документация, поставляемая вместе с ядром, советует после завершения конфигурации выполнить два действия: 1. Заглянуть в файл Makefile, чтобы вручную поправить некоторые значения. 2. Дать команду make dep для установки зависимостей.Конечно, для ручной правки файла
Настройки проверки орфографии
Настройки проверки орфографии Adobe InDesign не только содержит в себе текстовый редактор, но и постоянно использует его механизмы проверки орфографии. Особо следует отметить, что даже в нелокализованных версиях можно воспользоваться словарями и механизмами проверки
Утилиты для проверки почты
Утилиты для проверки почты Каждый раз запускать для проверки писем почтовый клиент, даже если он все делает сам, несколько неудобно. Тяжелые приложения забирают системные ресурсы, которые никогда не бывают лишними. На помощь приходят специальные утилиты для проверки
Универсальные утилиты проверки почты
Универсальные утилиты проверки почты Утилита проверки почты KDE Korn является частью модуля KDE pim (http://pim.kde.org/). Умеет проверять наличие информации по протоколам mbox, pop3, imap4, qmail, kmail, nntp и некоторым другим, поддерживает основные методы аутентификации. В репозитарии Ubuntu, как и во
Лаборатория проверки оборудования
Лаборатория проверки оборудования В лаборатории собрано много нетбуков и других устройств, на которых можно регулировать сетевые настройки (для проводного и беспроводного соединений), управлять питанием и т.д. Это инфраструктура для тестирования отдельных сервисов
3.1. Операторы и функции проверки условий
3.1. Операторы и функции проверки условий В этом разделе вы узнаете об операторах, которые предназначены для создания условий отбора, а именно: об операторах, выполняющих сравнение двух или нескольких величин, и о логических операторах, позволяющих создавать
Выполнение проверки
Выполнение проверки В первую очередь используются переключатели -v[alidate] и -f[ull] утилиты gfix для проверки структур записей и страниц. Процесс проверки сообщает о разрушенных структурах и освобождает неназначенные фрагменты записей или "осиротевших страниц" (т. е. страниц,
7.2. Операции проверки файлов
7.2. Операции проверки файлов Возвращает true если...-eфайл существует-fобычный файл (не каталог и не файл устройства)-sненулевой размер файла-dфайл является каталогом-bфайл является блочным устройством (floppy, cdrom и т.п.)-cфайл является символьным устройством (клавиатура, модем,
3.3.1 Проверки
3.3.1 Проверки Проверка значения может осуществляться или оператором if, или оператором switch:if ( выражение ) оператор if ( выражение ) оператор else оператор switch ( выражение ) операторВ С++ нет отдельного булевского типа. Операции сравнения== != « „= “ »=возвращают целое 1, если
Модульная Непрерывность
Модульная Непрерывность Метод удовлетворяет критерию Модульной Непрерывности, если незначительное изменение спецификаций разработанной системы приведет к изменению одного или небольшого числа модулей.Этот критерий непосредственно связан с критерием расширяемости.
Непрерывность
Непрерывность Ключевой проблемой при ответе на вопрос: "вокруг чего следует структурировать системы: вокруг функций или вокруг данных?" является проблема расширяемости, более точно - цель, названная непрерывностью в предшествующем обсуждении. Как вы помните, метод
Непрерывность доверия
Непрерывность доверия Политика доверия должна раскрывать внутренние механизмы доверия и демонстрировать, что доверие базируется не просто на обещаниях, а является важной составной частью деловых операций. Примерами внутренних механизмов доверия могут служить
Процедура проверки валидности пути
Процедура проверки валидности пути После построения пути сертификации необходимо проверить его валидность. Проверка валидности пути заключается в верификации всех цифровых подписей на сертификатах, составляющих путь сертификации, определении периода действия