- •2. Структурное программирование. Проектирование сверху вниз. Модульное программирование. Структурное кодирование
- •4. Функции. Компактность. Правило одной операции. Опасность смешения уровней абстракции
- •5. Функции. Правило понижения. Паттерн «Абстрактная фабрика» и использование оператора switch
- •6. Аргументы функций. Приемлемое количество и качество аргументов. Побочные эффекты в функциях. Примеры
- •7. Комментарии. Основные правила написания хороших комментариев. Комментарии todo.
- •8. Комментарии. Основные признаки плохих комментариев. Примеры.
- •9. Форматирование исходного кода. Цель форматирования. Вертикальное разделение концепций, вертикальное сжатие. Вертикальное расстояние
- •10. Форматирование исходного кода. Цель форматирования. Горизонтальное форматирование. Горизонтальное разделение и сжатие. Отступы
- •11. Объекты и структуры данных. Отличия процедурного и объектно-ориентированного кода. Случаи применения
- •12. Закон Деметры. Опасность построения гибридов объектов и структур данных. Объекты передачи данных и активные записи
- •13. Обработка ошибок. Исключения и коды ошибок. Использование паттерна «Особый случай».
- •14. Использование стороннего программного кода. Учебные тесты как инструмент исследования и анализа граничного кода.
- •16. Класс. Размеры класса. Принцип единой ответственности (srp).
- •17. Понятие связности класса. Влияние связности на размер классов.
- •18. Структурирование класса с учетом его изменений. Принципы проектирования классов в ооп.
- •19. Понятие эффективности программы. Выбор между эффективностью и удобочитаемостью. Оптимизирующие компиляторы.
- •20. Методология разработки через тестирование (tdd). Последовательность этапов разработки при использовании методологии tdd. Три закона tdd.
- •21. Тестирование как важный этап процесса разработки по. Чистота тестов. Тесты как средство обеспечения изменений. Правило «одна концепция на тест».
- •22. Экономические аспекты процесса тестирования. Тестирование методами «черного» и «белого» ящика. Невозможность исчерпывающего тестирования.
- •23. Основные принципы тестирования программного обеспечения.
- •24. Понятие отладки. Отличие между отладкой и тестированием. Средства отладки. Защитное программирование
- •25. Понятие отладки. Основные принципы отладки. Принципы локализации ошибок. Принципы устранения ошибок.
- •26. Понятие отладки. Основные подходы к отладке программ. Методы «грубой силы», индуктивная отладка, дедуктивная отладка, обратная трассировка, отладка тестированием.
- •28. Понятие правильности программ. Доказательство правильности программ. Правильность программ
- •29. Типы разложения вычислений (сочленение, выбор, повторение).
- •If условие then оператор 1 else оператор 2
- •30. Неоднозначность определения программы. Проблема сравнения программ.
- •32. Понятие рефакторинга. Рефакторинги «Согласование различий», «Миграция данных», «Выделение метода».
- •33. Понятие рефакторинга. Рефакторинги «Встраивание метода», «Выделение интерфейса», «Перемещение метода».
- •Inline method (встраивание метода)
- •34. Понятие рефакторинга. Рефакторинги «Метод в объект», «Добавление параметра», «Параметр метода в параметр конструктора».
2. Структурное программирование. Проектирование сверху вниз. Модульное программирование. Структурное кодирование
СТРУКТУРНОЕ ПРОГРАММИРОВАНИЕ
Одним из методов, улучшающих программы, является структурное программирование. Он служит для организации проектирования программ и процесса кодирования таким образом, чтобы предотвратить большинство логических ошибок и обнаружить те, которые допущены. Три главные составляющие:
1. Проектирование сверху вниз.
2. Модульное программирование.
3. Структурное кодирование.
ПРОЕКТИРОВАНИЕ СВЕРХУ ВНИЗ
Проектирование программ сверху вниз подобно написанию статьи сверху вниз. Начинают с исследования целей и определения основных задач. Если проект очень большой, то необходимо провести его разбиение.
Вначале необходимо написать на естественном языке.
На каждом шаге необходимо выявить основные функции, данная задача разбивается на ряд подзадач, каждой из них будет соответствовать один модуль.
Далее следует описать данные.
МОДУЛЬНОЕ ПРОГРАММИРОВАНИЕ
Модульное программирование — это процесс разделения программы на логические части, называемые модулями, и последовательное программирование каждой части.
Следует стремиться к независимости между модулями, или подпрограммами.
Каждый модуль должен иметь свое назначение, отличающееся от назначения других модулей. Это должен быть замкнутый блок, вход и выход которого точно определены.
СТРУКТУРНОЕ КОДИРОВАНИЕ
Структурное кодирование состоит в получения правильной программы из некоторых простых логических структур.
4. Функции. Компактность. Правило одной операции. Опасность смешения уровней абстракции
Функция – это поименованная часть программы, которая может вызываться из других частей программы столько раз, сколько необходимо.
КОМПАКТНОСТЬ
Функции должны быть компактными. Размер, порядка 20 строк.
ПРАВИЛО ОДНОЙ ОПЕРАЦИИ
ФУНКЦИЯ ДОЛЖНА ВЫПОЛНЯТЬ ТОЛЬКО ОДНУ ОПЕРАЦИЮ.
Если функция выполняет только те действия, которые находятся на одном уровне абстракции под объявленным именем функции, то эта функция выполняет одну операцию.
Уровень абстракции предоставляет способ сокрытия деталей реализации определенного множества функциональных возможностей.
ОДИН УРОВЕНЬ АБСТРАКЦИИ НА ФУНКЦИЮ
Смешение уровней абстракции внутри функции всегда создает путаницу. При их смешении функция постепенно начинает обрастать все большим количеством второстепенных подробностей.
5. Функции. Правило понижения. Паттерн «Абстрактная фабрика» и использование оператора switch
Функция — это поименованная часть программы, которая может вызываться из других частей программы столько раз, сколько необходимо.
ПРАВИЛО ПОНИЖЕНИЯ
Код должен читаться сверху вниз. За каждой функцией должны следовать функции следующего уровня абстракции. Это позволяет читать код, последовательно спускаясь по уровням абстракции в ходе чтения списка функций. Такой подход называется «правилом понижения».
ПАТТЕРН «АБСТРАКТНАЯ ФАБРИКА» И ИСПОЛЬЗОВАНИЕ ОПЕРАТОРА SWITCH
Команда switch должна использоваться для создания полиморфных объектов и скрываться за отношением наследования.
Решение проблемы заключается в том, чтобы похоронить команду switch в фундаменте АБСТРАКТНОЙ ФАБРИКИ и никому ее не показывать. Фабрика использует команду switch для создания соответствующих экземпляров потомков, а вызовы функций проходят полиморфную передачу через интерфейс.