Скачать 1.18 Mb.
|
Цели хорошего форматирования Многие решения о том, как должно выглядеть хорошее форматирование, представляют собой субъективные эстетические оценки; часто можно достичь одной и той же цели по-разному. Говоря объективно, хорошая схема форматирования должна делать следующее:
В дополнение к этим критериям иногда во внимание принимается и задача минимизации количества строк кода, необходимых для реализации простого выражения или блока. Способы форматирования Можно получить хороший формат кода, по-разному используя несколько инструментов для форматирования. Не отображаемые символы Используйте неотображаемые символы для улучшения читаемости. Неотображаемые символы, к которым относятся пробелы, знаки табуляции, переводы строк и пустые строки, – это основное средство для демонстрации структуры программы. Вам вряд ли придет в голову писать книгу без пробелов между словами, разбиения на абзацы и деления на главы. Может, такую книгу и можно прочитать от начала до конца, но практически невозможно просматривать ее в поисках какой-то мысли или важного момента. Еще хуже, что такой формат книги не позволит показать читателю, как автор намеревался организовать информацию. Структура, предлагаемая автором, дает подсказку о логической организации темы. Разбиение книги на главы, абзацы и предложения показывает читателю, как следует мысленно организовывать тему. Если эта организация неочевидна, читателю приходится самому ее домысливать, что налагает на него более тяжкое бремя и увеличивает вероятность никогда не узнать, как на самом деле организована данная тема. Информация, содержащаяся в программе, сосредоточена еще плотней, чем информация в большинстве книг. Если страницу книги можно прочесть и понять за 1 или 2 минуты, то большинство программистов не могут читать и понимать листинг программы со скоростью, даже приблизительно сравнимой с этой. Программа должна давать гораздо больше подсказок о своей организации, чем книга. Группировка взаимосвязанных выражений – еще один способ применения неотображаемых символов. В литературе мысли группируются в абзацы. Хорошо написанный абзац содержит предложения, относящиеся только к определенной идее. Он не должен содержать посторонних предложений. Точно так же абзац кода должен содержать только взаимосвязанные операторы, выполняющие одно задание. Пустые строки. Кроме необходимости группировать взаимосвязанные операторы, очень важно отделять несвязанные выражения друг от друга. Начало нового абзаца в книге обозначается отступом или пустой строкой. Начало нового абзаца в коде нужно указывать с помощью пустой строки. Пустые строки позволяют продемонстрировать организацию программы. Вы можете использовать их для деления групп взаимосвязанных операторов на абзацы, отделения методов друг от друга и выделения комментариев. Хотя эту статистику тяжело применить на практике, но одно исследование показало, что оптимальное число пустых строк в программе составляет от 8 до 16%. Если оно больше 16%, то время, затрачиваемое на отладку, заметно увеличивается. Отступы. Применяйте отступы для демонстрации логической структуры программы. Как правило, операторы выделяются отступами, когда они следуют после некоторого выражения, от которого они логически зависят. Оптимальными являются отступы из 2—4 пробелов. Скобки Используйте скобки чаще, чем вам это кажется необходимым. Применяйте скобки для разъяснения выражений, состоящих из двух и более членов. Возможно, в скобках нет нужды, но они добавляют ясности и ничего вам не стоят. Например, скажите, как вычисляется следующее выражение? Вариант на C++: 12 + 4% 3 * 7 / 8. Пришлось ли вам задуматься о том, как эти выражения вычисляются, вот в чем вопрос? Можете ли вы быть уверенными в своем ответе без обращения к справочной информации? Даже опытные программисты не отвечают с полной уверенностью, и именно поэтому следует использовать скобки, если есть хоть малейшее сомнение в том, как вычисляется выражение. Надежность программного обеспечения Это комплексное свойство включает две составляющие:
Улучшение первого качества достигается хорошей технологией, предупреждающей ошибки (faulе-avoidance). Однако 100%-ное отсутствие ошибок недостижимо. Устойчивость должна быть относительно любых виден отказов, для ее полдержания создаются специальные программно-аппаратные средства. Отказ (failure) по ГОСТу — нарушение работоспособности изделия и его соответствия требованиям технической документации (рисунок 4.3). Применительно к программам (стандарт IEEE/ ANSI) отказ есть неспособность функциональной единицы системы, зависящей от программы, выполнять требуемую функцию в заданных пределах. Рисунок 4.3 – Диаграмма состояний и переходов при отказе Классификация причин отказов:
Повреждение (Fault) – неисправность уже появилась, но еще не проявилась вовне. Например, отказала ячейка памяти, но из нес еще не читали или в нее еще не писали. Отказ компонента – это повреждение системы. Время нахождения в неисправном, но работоспособном состоянии называется латентным (скрытым) периодом отказа. Восстановление (Recovery) — возврат в исправное состояние путем:
В случае с) отказ называется сбоем, т. е. сбой – это кратковременный самовосстанавливающийся отказ. Остальные отказы называются устойчивыми (по умолчанию отказ устойчивый). В электронной аппаратуре сбои происходят на порядок чаще устойчивых. Их причины — флюктуации питания, ситуации «гонок» сигналов, альфа-частицы и др. В программах аналогично сбоям ведут себя времязависимые ошибки – их иногда называют «мерцающими» (blinking bugs). Типичный пример восстановления – с помощью резервной (backup) копии данных. Если выполнить восстановление в латентном периоде отказа, то он никогда не проявится вовне – в этом состоит идеальная отказоустойчивость. Количественные характеристики надежности программ Надежность нужно оценивать, измерять, предсказывать — обеспечивать заданные требования к надежности в проекте и проверять их выполнение в продукте. «Внутренняя» характеристика надежности — количество оставшихся ошибок в программе — интересна больше разработчикам, чем потребителям. Для последних важны характеристики, традиционные для теории надежности, основанные на предположении о стохастическом (случайном во времени) процессе возникновения отказов: среднее время безотказной работы (MTBF — Mean Time Between Failures) и коэффициент готовности. Третья характеристика, взаимосвязанная с первой, — интенсивность отказов — среднее их количество в единицу времени. Таблица 4.3. Средние значения MTBF для устойчивых отказов Таким образом, программы вносят наибольший вклад а (не)надежность современных вычислительных систем. Между тем существуют столь ответственные (mission-critical) приложения, где требуется очень малая вероятность отказов. Например, для бортовой системы управления космическим зондом требуется λ= 10-9, чтобы вероятность устойчивого отказа в первые 10 лет работы была не более 10-4 (или вероятность безотказной работы 0,9999), что означает MTBF = 100 тысяч лет! Преимущества парного программирования
4.3 Отладка программ Локализация и исправление ошибок называется отладкой. Отладка – это процесс обнаружения причин возникновения ошибки и ее последующего исправления (в отличие от тестирования, являющегося процессом обнаружения самого факта существования ошибки). Отладка включает в себя элементы тестирования и разработки. На некоторых проектах отладка может занимать до 50 % всего времени разработки. Для многих программистов отладка – это самая трудная часть программирования. При соответствующем подходе количество ошибок, требующих отладки, должно сократиться, и отладка должна стать самой легкой частью; при таком подходе все ошибки сводятся к небольшим недосмотрам или опечаткам. Как и тестирование, отладка не является способом улучшения качества ПО. Отладка – это всего лишь способ исправления дефектов в программе. Качество программ должно обеспечиваться аккуратным анализом требований или прототипированием, грамотным проектированием и использованием лучших практик кодирования. Ошибки синтаксиса языка Как правило, в абсолютном большинстве случаев ловятся на стадии компиляции программы, или же, если вы работаете с интерпретируемым языком типа Perl или РНР, то при первом интерпретировании программы. Но есть один существенный момент — когда выражение допустимо, но зависит от конкретного компилятора или интерпретатора. Например, в языке Си вполне допустимыми по синтаксису, но не по смыслу, являются выражения: s[i++]=i; printf("%d %d", i++, i++);. Результат этих строк не определен, так как неизвестно, в каком порядке будет инкрементироваться и вычисляться значение переменной i Переменная не может более 1 раза присутствовать в выражении, если ее значение изменяется в ходе вычисления этого выражения. Ошибки во время выполнения К ошибкам во время выполнения программы относятся ошибки в логике и алгоритмах программы. Ошибки в логике программы связаны с неправильной записью алгоритма, например, вместо && вы написали || или поставили точку с запятой там, где ее не должно быть. К этому же классу ошибок относится неправильное обращение с памятью. В языке Си неправильное обращение с памятью является наиболее распространенной ошибкой программистов, причем не только новички, но и профессионалы нередко допускают ошибки подобного типа. Для языка Си – это один из самых больных вопросов и больших недостатков. Ошибки в алгоритме связаны с неправильным проектированием программы или же с изначально неправильно заложенной бизнес-логикой и функциональными требованиями. Пользователь ждет от программы то, что изначально от нее не требовалось. Ошибки во время выполнения – наиболее часто встречаемый тип ошибок, и, как правило, устранение таких ошибок не представляется чересчур сложной задачей. Ошибки логики взаимосвязанных СGI -программ Ошибки данного типа лежат во взаимосвязанных CGI-прoграммах. Рассмотрим в качестве примера тестовую систему. При сдаче теста в цикле работают два скрипта. Первый показывает вопрос, а второй проверяет правильность ответа. Если в тесте 10 вопросов, то эти CGI-скрипты вызываются парно в цикле 10 раз. Но что будет, если пользователь нажмет кнопку «Обновить» в браузере? Скрипт, который показывает вопрос, вызовется повторно. Что будет при разрыве модемного соединения? Отладка в таких системах значительно сложнее, так как вам придется наблюдать за выполнением ряда Ошибки многопользовательского доступа Ошибки многопользовательских систем связаны с неправильным разграничением доступа к совместным ресурсам. Помимо фактов данных, записей в таблицах баз данных, общим ресурсов является генератор случайных чисел. На эти грабли нам пришлось наступить. Обязательно генерируйте случайные числа не только на основе времени, но и па основе уникального идентификатора процесса. В противном случае при выполнении в один и тот же момент времени двух копий одной CGI-программы вы получите одинаковые результаты для двух пользователей. Ошибки многопользовательского доступа сложны тем, что могут не проявлять себя очень долго, до тех пор, пока в один и тот же момент времени системой ни будет запушено несколько копий одной CGI-программы. Невоспроизводимые ошибки Невоспроизводимые ошибки представляют собой наиболее сложный тип ошибок. Например, в високосном году 29 февраля ваша система вдруг начала давать сбои, которые сами собой исчезают в не високосном году. Но бывают ошибки, которые мистическим образом появляются и исчезают. В той же тестовой системе была непонятная ошибка, которая проявлялась 1 раз на несколько сот случаев. Непонятным образом некоторые студенты после сдачи теста получали не результаты, а сбой системы. На исправление этой ошибки ушло два рабочих дня. Оказалось, что проблема в скрипте на JavaScript, который отправлял данные HTML-формы на сервер после истечения допустимого времени ответа на вопрос. Проблема в том, что если время подходило к концу и пользователь нажимал кнопку «Ответить», а в это же время уже начала работать функция JavaScript form.submit(), то отправка данных HTML-формы происходила дважды, т. е. скрипт проверки правильности ответа вызывался 2 раза. А это за собой тянуло ошибку во взаимосвязанных CGI-скриптах, и внешнее проявление сбоя системы мы наблюдали уже при подсчете результатов, а не непосредственно сразу после двойной отправки HTML-формы. Сам код JavaScript был написан верно, и с теоретической точки зрения даже если пользователь нажимает кнопку «Отправить» в последнюю секунду, HTML-форма должна была отправляться только 1 раз. Но на практике все оказалось совсем по-другому. На самом деле ничего мистического нет, или, как говорится, чудес на свете не бывает. Просто невозможно воспроизвести условия, в которых наблюдалась невоспроизводимая ошибка. Надо искать в программе случайности: одновременный доступ к одному ресурсу, генератор случайных чисел, неинициализированные переменные, некорректная работа с памятью или преобразование типов, которые могут проявлять себя не каждый раз. Ошибки инструментария и других компонентов системы Ошибки самою компилятора или интерпретатора очень редки, но и такие бывают. После классификации ошибок давайте рассмотрим методы их поиска. В первую очередь, один простой и, казалось бы, очевидный совет: «надо думать, анализировать, почему программа не работает так, как было задумано, что надо в ней исправить». Никакой самый навороченный отладчик за вас ошибку не найдет. Никакая самая лучшая методика не найдет и не ускорит поиск ошибки, если вы не «включите» мозги по полной программе и не сосредоточитесь целиком и полностью на поимке ошибки. Итак, допустим, вами, пользователем или тестирующим, было зафиксировано некорректное поведение программы. Что делать? Ниже перечислены методы в порядке их приоритетности, которые используют многие программисты. |
Конспект лекций междисциплинарного курса мдк. 03. 01 Технология разработки... Исследовать процессы создания новых технологий и определять их основные тенденции целесообразно, сопоставляя эти технологии с уровнем... |
Конспект лекций междисциплинарного курса мдк 01. 02 Прикладное программирование ПМ. 01 Разработка программных модулей программного обеспечения для компьютерных систем |
||
Учебно-методическое пособие "Управление качеством разработки программного... Отображены специфика в подходах к организации, базовым принципам и выполнению тестирования в зависимости от применяемой модели жизненного... |
Конспект лекций Ш 39 Метрология, стандартизация, сертификация: Конспект лекций / О. А. Шейфель; Кемеровский технологический институт пищевой промышленности.... |
||
Конспект лекций по курсу “Технология лекаственных форм и галеновых... Конспект лекций по курсу “Технология лекаственных форм и галеновых препаратов” для студентов специальности «Технология фармацевтических... |
Конспект лекций для студентов всех форм обучения специальности 080110... Налоги и налогообложение: Конспект лекций / Составитель Н. А. Леончик. – Кемерово, 2006. – 80 с |
||
Конспект лекций по дисциплине «Научные основы производства продуктов питания» Конспект лекций по дисциплине «Научные основы производства продуктов питания» для студентов кафедры «Технология и организация общественного... |
Календарно-тематический план учебной дисциплины преподаватель Алексеев Александр Игоревич Наименование междисциплинарного курса мдк. 01. 01 Электрические машины и аппараты |
||
Технические средства автоматизации конспект лекций Конспект лекций предназначен для студентов дневной, вечерней, заочной и дистанционной форм обучения по специальности 220301 «Автоматизация... |
Конспект лекций мдк 02. 02. Электронные средства и методы геодезических измерений ПМ. 02. Выполнение топографических съемок, графического и цифрового оформления их результатов |
||
Сборник лекций для студентов медицинского колледжа по пм 04/05/07... Сборник лекций для самоподготовки студентов медицинского колледжа по пм 04/05/07 «Выполнение работ по профессии младшая медицинская... |
Конспект лекций Владимир 2010 Министерство образования Российской... Автоматизированные системы бухгалтерского и управленческого учета. Часть 1: Конспект лекций / Владим гос ун-т; Сост.: Д. Н. Васильев... |
||
Конспект лекций лаконично раскрывает содержание и структуру учебной... Безопасность жизнедеятельности : конспект лекций для студентов очной и заочной форм обучения / сост. В. М. Домашко; Южный федеральный... |
Конспект лекций содержание тема Предмет и задачи курса Внутренняя и внешняя среда организации (фирмы) и их взаимосвязь. Мировой рынок и его развитие |
||
Конспект лекций профессионального модуля пм. 02 Разработка и администрирование баз данных Тема 3 Основы разработки клиент-серверных приложений для работы в компьютерной сети |
Конспект лекций для студентов специальности 271200 «Технология продуктов общественного питания» Печатается по решению редакционно-издательского совета Кемеровского технологического института пищевой промышленности |
Поиск |