К АЧЕСТВО КОД. А НАЛИЗ КОДА С ND EPEND. План Качество Какие способы достичь качества Качество кода в аспекте проектирования Принципы ООП/ООД Метрики кода.

Презентация:



Advertisements
Похожие презентации
Обязательные практики Agile и правило 3-х П. Павел Габриель agile-практик, программист, руководитель ООО Смарт системз.
Advertisements

Test Driven Development или как не выстрелить себе в ногу Дмитрий Хрюкин Fuse 8 Online Вторая конференция.NET разработчиков.
Технологии программирования. Что? Как? Когда? Зачем? Для кого? Постановка проблемы.
EXtreme Programming XP Тема 1. XP Экстремальное программирование небольших и средних неясных и быстро меняющихся требований Экстремальное программирование.
РАСПРОСТРАНЕННЫЕ ОШИБКИ В ИДЕОЛОГИИ, ПЛАНИРОВАНИИ И ПРОВЕДЕНИИ ТЕСТИРОВАНИЯ 2.
Программировани е Сергей Салищев Занятие 1. Введение.
Обзор гибких методологий разработки ПО (Agile) Антон Бевзюк (Intel)
Правильные процессы Process Design for Fun and Profit.
Статический анализ кода (на примере DDD-фреймворка) Алексеев Алексей Николай Гребнев
EXtreme Programming XP Тема 2. XP Заказчики определяют: объем работ; приоритеты; композиции версий; сроки выпуска версий. Разработчики определяют: оценку.
Алексей Кирсанов ведущий разработчик «1С-Битрикс» Магазин – глобальная реструктуризация. D7 Партнерская конференция «1С-Битрикс»
Выполнили студенты группы ЗСР-401 С Трапезникова О. А. Груздева Л. А. Найдина О. А.
Тестирование веб-проектов в Agile Асхат Уразбаев, ScrumTrek.
Прагматический подход к разработке гибких программных систем Степан Родионов twitter.com/rodionovstepan Вторая конференция.NET разработчиков.
Инструменты Visual Studio для контроля качества и безопасности кода MSSD-3 Александр Яковлев, Microsoft.
Мухин Максим Александрович 2015 г. Москва Как эффективно организовать разработку мобильных приложений для банка.
Рефакторинг кода: когда и зачем Наталья Белозёрова веб-разработчик
Директор по развитию КАК ВЫБРАТЬ РАЗРАБОТЧИКА? И КАК С НИМ РАБОТАТЬ? Алексей Довжиков.
Распределение функционала в e-Learning проекте компании «АльфаСтрахование» eLearnExpo – Москва – 2011.
Рефакторинг баз данных. Для начала… Избегайте сверхспециализации (overspecialization) Разработчик приложенияРазработчик базы данных Разработчик Коммуникация.
Транксрипт:

К АЧЕСТВО КОД. А НАЛИЗ КОДА С ND EPEND

План Качество Какие способы достичь качества Качество кода в аспекте проектирования Принципы ООП/ООД Метрики кода NDepend

Зачем качество?

Холиворная тема

Железный треугольник Объем работ (фичи, функционал, качество и т.д.) Время (график, сроки) Деньги (бюджет, ресурсы) Железный треугольник, или треугольник менеджмента. Его смысл в том, что ограничения на объём работ, сроки и бюджет должны быть разумными и нужно ими управлять (балансировать) Где же качество?

Железный треугольник Объем работ (фичи, функционал, качество и т.д.) Время (график, сроки) Деньги (бюджет, ресурсы) Качественное ПО получается в результате баланса между объемом работ, сроками и бюджетом Качество

К чему эти треугольники?

Ценности качественного кода Расширяемость, гибкость (extensibility, agility) Сопровождаемость (maintainability) Простота (simplicity) Читабельность, понятность (readability, clarity) Тестируемость (testability)

Какие есть способы? Организационные – XP (eXtreme Programming) – Code review – Project management, methodology, – Utilities: StyleCop, FxCop, Code Analysis – Requirements… Технические – Юнит-тесты – TDD, Defensive programming style – OOP/OOD, principles Обучение

Какие есть способы? Внешние – программистские практики – Парное программирование – Статический анализ кода – Code review, – Unit-tests, TDD/BDD Внутренние - правильное проектирование и рефакторинг кода как способ превращения плохого кода в более хороший – OOP/OOD, principles, – Programming style

Сode Review

Статический анализ кода StyleCop, FxCop, Code Analysis, Ndepend Цель автоматизировать review кода и обратить внимание на распространенные ошибки и скользкие участки. В идеале внедрить стат. анализ в CI (build process)

Методологии и управление Управление проектом напрямую влияет на результаты и удовлетворенность от работы – Хаотическое управление = низкое качество (e.g. Cowboy coding)

Extreme programming Парное программирование Всесторонний code review Юнит-тесты на весь код (TDD) YAGNI, не пишем того, что не нужно Изменчивые требования Частая коммуникация с заказчиком и в команде

Обучение Никакие утилиты стат. анализа не заменят людей Позволяет писать качественные код Повышает коммуникации Улучшает команду Парное программирование способствует Обучение Профессиональная команда Качественный код

Юнит-тесты, TDD Юнит-тесты – позволяют контролировать соответствие кода задуманному поведению. ТDD – подход к написанию кода начиная с тестов. «Тесты вперед»

Рефакторинг

Защитное программирование Defensive programming Использование осетров (asserts) Использование контрактов кода (code contracts) Ассерты или контракты как мини юнит-тесты если что то идет не так

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

Ценности, принципы и паттерны Код Паттерны Принципы Ценности

Принципы ООП/ООД Принципы SOLID Принципы GRASP KISS = Keep it simple DRY = Dont repeat yourself YAGNI = You aint gonna need it

Метрики кода Это количественные показатели, которые можно измерить и которые могут дать представление о качестве кода Что можно поменять: » Lines of code » Number of classes » Inheritance depth » Maintainability index » Cyclomatic index

NDepend. Dependency graph

Ndepend. Dependency matrix

Ndepend. Metrics view

CQL Query Explorer

NDepend. CQL SQL подобный синтакс Запросы к базе кода (code base), чтобы получить метрики SELECT TOP 10 METHODS ORDER BY NbLinesOfCode DESC SELECT METHODS WHERE NbLinesOfCode > 10 SELECT FIELDS WHERE HasAttribute "System.ThreadStaticAttribute"

Метрики

Coupling Efferent coupling (Ce): внутренняя связанность, число типов внутри сборки, которые зависят от типов из вне сборки Afferent coupling (Ca): внешняя связанность, число типов вне сборки которые зависят от типов в внутри сборки

Instability (I) Instability (I): отношение внутренней связанности(Ce) к общей связанности, индикатор устойчивости к изменениям. I = Ce / (Ce + Ca) I=0 – полностью стабильная сборка, сложная для модификации. I=1 – нестабильная сборка, внутри слабая связанность

Abstractness (A) Abstractness (A): абстрактность, отношение числа внутренних абстрактных типов к числу внутренних типов. A=0 – полностью «конкретная» сборка A=1 – полностью абстрактная сборка

Relational Cohesion (H) Relational Cohesion (H): относительная сцепленность, среднее число внутренних отношений на тип: H = (R + 1) / N, где R = число отношений внутри сборки, N = число типов сборки Классы внутри сборки должны сильно соотносится друг с другом, и сцепленность должна быть высокой. С другой стороны, слишком большие значение могут означать излишнюю связанность. Хорошие значения сцепленности 1.5 H 4.0

Coupling, Cohesion, Abstractness and Instability metrics on example Се = внутренняя связанность, Са – внешняя, I – стабильность, N – число типов сборки, А – абстрактность, Н – относительная сцепленность

Lack of cohesion (LCOM) Принцип SRP утверждает, что класс должен иметь не более чем одну причину для изменения. Такой класс сцепленный (cohesive). Высокое значение означает плохо сцеплений класс. Типы, у которых LCOM > 0.8 могут быть проблемными. Тем не менее, очень сложно избежать таких не- сцепленных типов

Cyclomatic Complexity (CC) Число следующих выражений в методе: if, while, for, foreach, case, default, continue, goto, &&, ||, catch, ? : (ternary operator), ?? (nonnull operator) Эти выражения не учитываются: else, do, switch, try, using, throw, finally, return, object creation, method call, field access CC > 15 сложно понимать, CC > 30 очень сложные и должны быть разбиты на более мелкие методы (кроме сгенерированного кода)

Distance from main sequence: zone of pain and zone of uselessness Main sequence в терминах NDepend, A + I = 1, Представляет оптимальный баланс между абстрактностью и стабильностью D – это нормализированное расстояние от main sequence, 0 D 1 Сборки с D > проблематичны Но, в реальной жизни, сложно избежать таких сборок. Просто необходимо удерживать число таких сборок минимальным.

Cсылки и источники

Спасибо за внимание:)