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


The Presentation inside:

Slide 0

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


Slide 1

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


Slide 2

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


Slide 3

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


Slide 4

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


Slide 5

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


Slide 6

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


Slide 7

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


Slide 8

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


Slide 9

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


Slide 10

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


Slide 11

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


Slide 12

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


Slide 13

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


Slide 14

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


Slide 15

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


Slide 16

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


Slide 17

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


Slide 18

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


Slide 19

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


Slide 20

Принципы ООП/ООД Принципы SOLID Принципы GRASP KISS = Keep it simple DRY = Don’t repeat yourself YAGNI = You ain’t gonna need it Технические способы http://msug.vn.ua/Posts/Details/4221


Slide 21

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


Slide 22

NDepend. Dependency graph


Slide 23

NDepend. Dependency graph


Slide 24

Ndepend. Dependency matrix


Slide 25

Ndepend. Metrics view


Slide 26

CQL Query Explorer


Slide 27

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


Slide 28

Метрики


Slide 29

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


Slide 30

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


Slide 31

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


Slide 32

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


Slide 33

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


Slide 34

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


Slide 35

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 очень сложные и должны быть разбиты на более мелкие методы (кроме сгенерированного кода)


Slide 36

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


Slide 37

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/ http://blog.byndyu.ru


Slide 38

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


×

HTML:





Ссылка: