C++ осень 2012 лекция 12
- 1. Углубленное программирование на языке C++ Алексей Петров
- 2. Лекция №12. Стандарты кодирования и основы командной разработки ПО • Соглашение о кодировании как нормативный акт, иные руководящие документы. • Комментирование и документирование кода. • Примеры нотаций. • Средства поддержки коллективной работы. • Современные методологии разработки. • Понятие «гибких» (agile) методологий. • Методологии TDD, SCRUM. • Обзор SWEBoK.
- 3. Соглашение о кодировании и его роль в командной разработке ПО Соглашение о кодировании (англ. coding standard) — непроектный документ, который: • регламентирует подходы к оформлению исходного кода на языке высокого уровня или ручной верстки на языке разметки; • (опционально) имеет статус локального правового акта организации; • действует в рамках организации или проектного офиса (реже — отдельного проекта или проектов). Преимущества заключения соглашения о кодировании: • легкость включения в проект разработки новых специалистов; • удобство чтения и простота понимания и инспекции исходного кода; • формирование важных в командной разработке навыков и привычек оформления результатов труда; • легкость трассировки изменений и ручного контроля версий.
- 4. Иные руководящие документы. Артефакты анализа Помимо соглашения о кодировании, участвующий в командной разработке ПО разработчик опирается на следующие документы: • устав (хартия) проекта; • календарный план-график (КПГ); • соглашения о моделировании (предметной области, БД и пр.). Значимыми для успешной разработки проектными артефактами являются все (почти все) выходные артефакты этапа системного анализа и проектирования системы, в том числе: • модели предметной области; • макеты и прототипы фрагментов исходного кода и интерфейса; • диаграммы классов, прецедентов, взаимодействия и т.д.; • техническое задание на информационную (автоматизированную) систему.
- 5. Правила организации и способы записи исходного кода на языке C++ (1 / 2) Эмпирические правила организации исходного кода на языке C++ — результат многолетнего опыта практического программирования специалистов по всему миру (начало): • объявления классов, как правило, хранятся в заголовочных файлах с именами <имя класса>.{h | hpp}, исходный код реализации в основном хранится в исходных файлах с именами <имя класса>.{c | C | cpp}; • члены класса перечисляются в порядке назначенных им уровней доступа: public, protected, private.
- 6. Правила организации и способы записи исходного кода на языке C++ (2 / 2) Эмпирические правила организации исходного кода на языке C++ — результат многолетнего опыта практического программирования специалистов по всему миру (окончание): • подставляемые функции обычно выделяются из интерфейса и со спецификатором inline размещаются в заголовочном файле после объявления класса (оптимальное разделение достигается размещением определений подставляемых функций в отдельном заголовочном файле); • полностью заголовочный файл помещается в директивы условной компиляции во избежание повторного включения в сборку при вложенных директивах #include.
- 7. Ортодоксальная каноническая форма класса (1 / 2) Ортодоксальная каноническая форма (ОКФ) класса — одна из важнейших идиом C++, согласно которой класс должен содержать: • конструктор по умолчанию: T::T(); • конструктор копирования: T::T(const T&); • операцию-функцию присваивания: T& T::operator=(const T&); • деструктор: T::~T(). ОКФ обеспечивает: • единый стиль оформления классов; • помогает справиться со сложностью классов в процессе развития программы.
- 8. Ортодоксальная каноническая форма класса (2 / 2) ОКФ класса следует использовать, когда: • необходимо обеспечить поддержку присваивания для объектов класса или передачу их по значению в параметрах функций; • объект создает указатели на объекты, для которых применяется подсчет ссылок; • деструктор класса вызывает operator delete для атрибута класса. ОКФ класса желательно использовать для всех классов, не ограничивающихся агрегированием данных аналогично структурам C. Отклонения от ОКФ позволяют реализовать нестандартные аспекты поведения класса.
- 9. Примеры нотаций Венгерская нотация (Ч. Симони (Charles Simonyi), Microsoft, 1999) — широко известное соглашение о префиксации идентификаторов констант, переменных, типов, методов и т.д. в соответствии с их функциональной нагрузкой: m_pHead; // указатель-атрибут класса g_nObjCount; // глобальная целочисленная переменная CWarrior; // класс szConnPar; // строковый (char*) локальный объект Сложившийся на сегодняшний день стиль написания объектно- ориентированного кода и современные IDE позволяют не указывать тип переменной в имени, а сосредоточиться на «правильном» форматировании блоков, расстановке разделителей, знаков операций, левых отступов и т.д.
- 10. Комментирование и документирование кода Одним из показателей качества исходного кода является его самодокументируемость (англ. self-descriptiveness). Соблюдение принципа самодокументирования обеспечивает: • понятность кода без обращения к проектной документации; • соответствие исходного кода «внутренней программной документации». Самодокументируемости исходного кода способствуют: • единообразие нотации; • значимость (осмысленность) идентификаторов (противоположное — анти-шаблон «загадочный код» (англ. cryptic code)); • наличие аннотаций для артефактов (переменных, классов, методов и т.д.) и комментариев в местах, трудных для понимания; • модульность решения, отсутствие монолитных артефактов большого размера.
- 11. Средства коллективной разработки К числу систем и средств поддержки коллективной разработки ПО относятся: • системы управления версиями; • системы отслеживания ошибок; • системы управления проектами, планирования и контроля работ; • средства поддержки тестовых окружений и т.д.
- 12. Этапы канонического жизненного цикла разработки ПО (1 / 2) Анализ и проектирование Формирование требований Программи- рование Внедрение Интеграция и тестирование Спецификация Дизайн Исходный код Продукт
- 13. Этапы канонического жизненного цикла разработки ПО (2 / 2) Наибольшая вовлеченность программистов в разработку ПО приходится на этапы программирования (кодирование) и тестирования (исправление ошибок) (см. график). Сопровождение — это не этап ЖЦ разработки ПО, а последующий, не ограниченный во времени процесс, участие в котором программисты принимают наряду с консультантами, аналитиками и пр. 0% 5% 60% 30% 5% 0% 20% 40% 60% % занятости
- 14. Экономика и ответственность (1 / 2) Программисты должны получать качественные проектные артефакты с качественно описанными требованиями к ПО. Сравнительная цена ошибки (стоимость ее исправления) на этапе программирования выше, чем на этапе проектирования и тем более — на этапе сбора требований к ПО (см. график) Cбор треб. Проект. Прогр. Тест. Внедр. Сравнительная цена исправления ошибки в ПО
- 15. Экономика и ответственность (2 / 2) Со ссылкой на кн.: Martin, J., McClure, C. Software Maintenance — The Problem and Its Solutions, Prentice Hall, Englewood Cliffs, New Jersey, 1983 — С. Канер и др. (2001) приводят следующую оценку распределения статей затрат на выпуск и сопровождение ПО в разрезе жизненных циклов производимой системы (см. график). 6% 5% 7% 15% 67% Структура совокупных затрат на выпуск и сопровождение ПО Cбор треб. Проект. Прогр. Тест. Сопровожд.
- 16. Каскадная и итеративная модели жизненного цикла ПО Классическая каскадная, или «водопадная», модель (англ. waterfall model) предполагает последовательное (во времени) однократное прохождение этапов жизненного цикла разработки ПО (фаз проекта) с жестким предварительным планированием в контексте однажды и целиком определенных требований к ПО. Итеративная модель предполагает разбиение жизненного цикла на последовательность итераций («мини-проекты»), включающие все фазы проекта в применении к меньшим фрагментам функциональности. С завершением каждой итерации продукт развивается инкрементально.
- 17. «Гибкие» методологии разработки «Гибкие» (англ. agile) методологии разработки основаны на использовании итеративной модели жизненного цикла разработки ПО, динамическом формировании требований и постоянном взаимодействии внутри самоорганизующихся рабочих групп. Отличительные черты: • короткий цикл разработки; • непосредственное общение (в том числе с заказчиком). Основные идеи: • личности и их взаимодействия важнее процессов и инструментов; • работающий продукт важнее полной документации; • сотрудничество с заказчиком важнее договорных обязательств; • реакция на изменения важнее следования плану.
- 18. Методологии TDD, Scrum Разработка через тестирование (англ. Test-Driven Development, TDD) — методология разработки, реализующая концепцию «сначала тест» и состоящая в последовательном расширении набора тестов, покрывающих требуемую функциональность, и написании кода, позволяющего пройти существовавшие и вновь введенные тесты. Scrum — методология итеративной разработки с акцентом на контроль процесса разработки ПО, в которой: • каждая итерация («спринт») имеет фиксированную продолжительность; • требования к продукту упорядочиваются по их важности, отражаются в документах Product Backlog и Sprint Backlog и фиксируются на время спринта.
- 19. Руководство SWEBoK Software Engineering Body of Knowledge (SWEBoK) – «Свод знаний в области программной инженерии», подготовленный при участии IEEE и призванный определить набор профессиональных знаний и рекомендуемые практики в следующих областях (англ. knowledge area): Требования к ПО Управление конфигурациями ПО Проектирование ПО Управление программной инженерией Конструирование ПО Процесс программной инженерии Тестирование ПО Методы и инструменты программной инженерии Сопровождение ПО Качество ПО
- 20. Спасибо за внимание Алексей Петров