Материал: 406

В таблице представлены основные виды ошибок:

–Замыкания.

–Использование больших данных.

–Проблемы NP-полной задачи (полиномиальная для недетерминированной машины Тьюринга задача поиска и принятия решения).

–Безопасность.

–Управление идентификацией.

–Шифрование.

–Надежность измерения.

1.2.Написание корректного программного кода. Версионирование

Вопросы для рассмотрения: Функциональные, структурные, динамические модели. Создание двух взаимосвязанных моделей. Автоматизированное конструирование моделей бизнес-процессов.

Рекомендуемая литература: 2.

Перечень дополнительных ресурсов: 2, 3, перечень ресурсов в сети Интернет.

Наименование вида самостоятельной работы: изучение ли-

тературы, выполнение тестовых заданий, подготовка к лабораторным работам.

Корректный программный код – это код, который исключает различного рода ошибки, компилируется без дефектов и способен корректно исполнять написанную в нем логику.

Обычно качественный код характеризуется несколькими параметрами:

Читаемость кода. Одного взгляда на него должно хватать, чтобы обобщенно понять, что реализуется участком кода.

Присутствие понятных и ёмких комментариев. Данный параметр очень сильно влияет на читаемость, легкость в отладке, тестирование поддержки и устранение ошибок программного кода.

Низкая сложность.

Оптимизация кода. Организовать его стоит таким образом, чтобы программа использовала как можно меньше системных ресурсов, таких как память, время процессора и пространство жёсткого диска.

Отсутствие мусора. То есть не используемых переменных или

блоков кода, в которой никогда не заходит управление программой. Также, некоторые специалисты области программирования,

рекомендуют комментировать разрабатываемую кодировку, чтобы разработчику был он понятен даже через пару месяцев.

Обычно, качество кода поддерживается путем контроля версий. Этот процесс выполняет задачи хранения кода, доступа к коду всех разработчиков, организации параллельной работы разработчиков, дает возможность откатить неудачные изменения. Помимо этого, система контроля версий является частью внутренней документации на систему, причем совершенно уникального вида: по ней можно точно выяснить, когда именно было реализовано то или иное поведение ИС, и чем эта реализация была обоснована.

Существует два требования при работе с системой версионирования:

–Осмысленные коммиты. Коммит должен представлять собой какую-то завершенную мысль в коде. Он не должен быть слишком объемным и включать в себя несвязанные изменения различной функциональности, и не должен быть слишком маленьким, когда отправляются какие-то незавершенные фрагменты изменений.

–Каждый коммит должен быть снабжен комментарием, описывающим суть изменений и их причину. Это может быть явный текст или ссылка на трекер, в котором указано подробное описание задачи, или и то и другое. Комментарий не должен быть просто дублированием тех же изменений, что внесены в код (т.к. их и так будет видно в сравнении ревизий), а должен позволить быстро понять, что было изменено и почему.

Наряду с контролем версионности кода выделяют такой критерий, как его понятность. Если ИС активно эксплуатируется и развивается, то ее код приходится читать гораздо чаще, чем писать. Зачастую вносить изменения в код модуля приходится спустя длительное время после его написания и, возможно, другому разработчику, чем тот, кто писал исходный код. Как добиться читаемого кода:

–Все методы (а так же переменные, классы и все прочие сущности) должны иметь читаемые, значимые и понятные имена. Чтобы прочитав название метода можно было сразу понять его назначение. И, разумеется, название должно соответствовать реальному поведению метода. Если назначение метода меняется в ходе внесения доработок, то он должен быть переименован.

–Каждый класс должен иметь свою область ответственности и реализовать только операции из нее. Другие операции должны выноситься в отдельные классы.

–По возможности, каждый метод должен выполнять одно конкретное действие и не иметь побочных эффектов.

–Если метод слишком длинный, его стоит разделить на

несколько.

–Избегать большой связности между классами. Чем больше зависимостей между классами, тем сложнее осознать поведение системы в целом и тем сложнее вносить изменения.

–Избегать сложных языковых конструкций там, где можно обойтись более простыми.

–Добавлять комментарии, проясняющие реализацию алгоритма в сложных местах.

–Все члены команды должны использовать единые правила оформления кода (форматирование, отступы, правила именования).

Единое оформление кода зачастую кажется неважным требованием, но на практике оно дает очень серьезный эффект для работы команды в целом. Отсутствие необходимости «переключаться» при чтении различных фрагментов кода системы существенно упрощает процесс понимания кода. Также, единое оформление кода (Codestyle) помогает избавиться от наличия незначительных изменений в системе контроля версий.

1.3.Рефакторинг кода

Вопросы для рассмотрения: Цели рефакторинга. Причины применения рефакторинга. Признаки плохого кода. Рефакторинг кода. Методы рефакторинга. Изменение сигнатуры метода. Инкапсуляция поля. Выделение: класса, интерфейса, локальной переменной, метода. Встраивание. Подъём метода. Спуск метода. Переименование и перемещение метода. Замена условного оператора полиморфизмом. Замена наследования делегированием. Замена кода типа подклассами. Проблемы, возникающие при проведении рефакторинга. Средства автоматизации рефакторинга.

Рекомендуемая литература: 1.

Перечень дополнительных ресурсов: 2, 3, перечень ресурсов в сети Интернет.

Наименование вида самостоятельной работы: изучение литературы, выполнение тестовых заданий, подготовка к лабораторным работам; выполнение контрольной работы.

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

Цель рефакторинга – сделать код программы более легким для понимания; без этого рефакторинг нельзя считать успешным.

Рефакторинг следует отличать от оптимизации производительности. Как и рефакторинг, оптимизация обычно не изменяет поведение программы, а только ускоряет её работу. Но оптимизация часто затрудняет понимание кода, что противоположно рефакторингу

Рефакторинг нужно применять постоянно при разработке кода. Основными стимулами его проведения являются следующие задачи:

–необходимо добавить новую функцию, которая недостаточно укладывается в принятое архитектурное решение;

–необходимо исправить ошибку, причины возникновения которой сразу не ясны;

–преодоление трудностей в командной разработке, которые обусловлены сложной логикой программы.

Во многом при рефакторинге лучше полагаться на интуицию, основанную на опыте. Тем не менее имеются некоторые видимые проблемы в коде, требующие рефакторинга:

–дублирование кода;

–длинный метод;

–большой класс;

–длинный список параметров;

–«жадные» функции — это метод, который чрезмерно обращается к данным другого объекта;

–избыточные временные переменные;