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