Качество код. Анализ кода с NDepend

Содержание

Слайд 2

План

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

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

Слайд 3

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

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

Слайд 4

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

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

Слайд 5

“Железный треугольник”

Железный треугольник, или треугольник менеджмента. Его смысл в том, что ограничения

“Железный треугольник” Железный треугольник, или треугольник менеджмента. Его смысл в том, что
на объём работ, сроки и бюджет должны быть разумными и нужно ими управлять (балансировать)

Где же качество?

Слайд 6

“Железный треугольник”

Качественное ПО получается в результате баланса между объемом работ, сроками и

“Железный треугольник” Качественное ПО получается в результате баланса между объемом работ, сроками и бюджетом Качество http://www.intuit.ru/department/se/msd/4/3.html
бюджетом

Качество

http://www.intuit.ru/department/se/msd/4/3.html

Слайд 7

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

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

Слайд 8

Ценности качественного кода

Ценности качественного кода

Слайд 9

Какие есть способы?

Организационные
XP (eXtreme Programming)
Code review
Project management, methodology,
Utilities: StyleCop, FxCop,

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

Слайд 10

Какие есть способы?

Внешние – программистские практики
Парное программирование
Статический анализ кода
Code review ,
Unit-tests, TDD/BDD
Внутренние

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

Слайд 11

Сode Review

Организационные способы

Сode Review Организационные способы

Слайд 12

Статический анализ кода

StyleCop, FxCop, Code Analysis, Ndepend
Цель автоматизировать review кода и обратить

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

Организационные способы

Слайд 13

Методологии и управление

Управление проектом напрямую влияет на результаты и удовлетворенность от работы
Хаотическое

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

Организационные способы

Слайд 14

Extreme programming

Парное программирование
Всесторонний code review
Юнит-тесты на весь код (TDD)
YAGNI, не пишем того,

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

Организационные способы

Слайд 15

Обучение

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

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

Обучение

Слайд 16

Юнит-тесты, TDD

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

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

Технические способы

Слайд 17

Рефакторинг

Технические способы

Рефакторинг Технические способы

Слайд 18

Защитное программирование

Defensive programming
Использование ассертов (asserts)
Использование контрактов кода (code contracts) Ассерты или контракты как

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

Технические способы

Слайд 19

Технический долг

К его появлению приводит быстрая и бездумная разработка
Когда мы понимаем, что

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

Технические способы

Слайд 20

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

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

Слайд 21

Принципы ООП/ООД

Принципы SOLID
Принципы GRASP
KISS = Keep it simple
DRY = Don’t repeat yourself
YAGNI

Принципы ООП/ООД Принципы SOLID Принципы GRASP KISS = Keep it simple DRY
= You ain’t gonna need it

Технические способы

http://msug.vn.ua/Posts/Details/4221

Слайд 22

Метрики кода

Это количественные показатели, которые можно измерить и которые могут дать представление

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

Слайд 23

NDepend. Dependency graph

NDepend. Dependency graph

Слайд 24

NDepend. Dependency graph

NDepend. Dependency graph

Слайд 25

Ndepend. Dependency matrix

Ndepend. Dependency matrix

Слайд 26

Ndepend. Metrics view

Ndepend. Metrics view

Слайд 27

CQL Query Explorer

CQL Query Explorer

Слайд 28

NDepend. CQL

SQL подобный синтакс
Запросы к базе кода (code base), чтобы полу- чить метрики
SELECT TOP

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

Слайд 29

Метрики

Метрики

Слайд 30

Coupling

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

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

Слайд 31

Instability (I)

Instability (I): отношение внутренней связанности(Ce) к общей связанности, индикатор устойчивости к

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

Слайд 32

Abstractness (A)

Abstractness (A): абстрактность, отношение числа внутренних абстрактных типов к числу внутренних

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

Слайд 33

Relational Cohesion (H)

Relational Cohesion (H): относительная сцепленность, среднее число внутренних отношений на

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

Слайд 34

Coupling, Cohesion, Abstractness and Instability metrics on example

Се = внутренняя связанность,

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

Слайд 35

Lack of cohesion (LCOM)

Принцип SRP утверждает, что класс должен иметь не более

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

Слайд 36

Cyclomatic Complexity (CC)

Число следующих выражений в методе:
if, while, for, foreach, case, default,

Cyclomatic Complexity (CC) Число следующих выражений в методе: if, while, for, foreach,
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 очень сложные и должны быть разбиты на более мелкие методы (кроме сгенерированного кода)

Слайд 37

Distance from main sequence: zone of pain and zone of uselessness

Main sequence в

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

Слайд 38

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

Msug
http://msug.vn.ua/Posts/Details/4199 - NDepend
http://msug.vn.ua/Posts/Details/4221 - GRASP
NDepend
http://www.ndepend.com/
http://www.ndepend.com/GettingStarted.aspx
Метрики NDepend
http://www.hanselman.com/blog/content/binary/NDepend%20metrics%20placemats%201.1.pdf
http://ndepend.com/Metrics.aspx
О качестве
http://merle-amber.blogspot.com/

Cсылки и источники Msug http://msug.vn.ua/Posts/Details/4199 - NDepend http://msug.vn.ua/Posts/Details/4221 - GRASP NDepend http://www.ndepend.com/

http://blog.byndyu.ru
Имя файла: Качество-код.-Анализ-кода-с-NDepend.pptx
Количество просмотров: 198
Количество скачиваний: 0