PETROV / INFOSYSTEMS. How to Measure Software Architecture [1.01]
.pdf
ТЕХНИЧЕСКИЙ ДОЛГ: ЛИЧНЫЙ ОПЫТ
Продуктовая разработка
1 |
Проекты с длительным циклом разработки рано |
|
или поздно всегда переписываются «с нуля» |
«Технический налог»
|
Расширенные технические советы |
|
2 |
Энтузиазм разработчиков |
10% |
Оптимально — 1 день в 2 недели (один и тот же, если позволяет план-график) или в спринте
21
ВОПРОС #2
ДОБИТЬСЯ УЛУЧШЕНИЯ АРХИТЕКТУРЫ НЕВОЗМОЖНО, ЕСЛИ НЕ НАЧАТЬ УЛУЧШЕНИЕ АРХИТЕКТУРЫ. С ЧЕГО НАЧАТЬ?
CODE_INSPECTION && DESIGN_REVIEW
КАК ЧАСТЬ ИНЖЕНЕРНОЙ КУЛЬТУРЫ
22
Статический анализ исходного кода
Пересмотр кода как метод персональной оценки
Рефакторинг и правила ООпроектирования. Примеры
Эффективность статического анализа кода и пересмотров архитектуры
Инструменты статического анализа
23
СТАТИЧЕСКИЙ АНАЛИЗ ИСХОДНОГО КОДА
Как и когда?
1 |
Предшествует рефакторингу и сопровождает его |
|
Проводится без реального выполнения кода, |
||
|
||
|
вручную или специальными инструментами |
2
3
Что выявляет?
Неверное или неопределенное поведение кода Вызов методов как процедур Нарушение зон ответственности классов и т.д.
Персональная оценка (инспекция)
Статический анализ без использования инструментальных средств в целях определения качества кода с позиции:
•эффективности (использования ресурсов, вычислительной сложности);
•удобства сопровождения (анализа, проверки, внесения изменений);
•надежности (зрелости, способности к восстановлению после сбоев) ;
•прочих структурных показателей качества (напр. по ГОСТ Р ИСО 9126).
24
ПЕРЕСМОТР (CODE REVIEW)
КАК МЕТОД ПЕРСОНАЛЬНОЙ ОЦЕНКИ КОДА
|
Регулярность |
1 |
Отчет о проведении — на каждом техническом |
|
совете (напр. еженедельно) |
Рецензенты
2 |
Назначение из числа членов команды, не |
|
|
|
являющихся первоначальными владельцами кода |
Вовлечение
3 |
Распространение знаний о каждом (не)удачном |
|
|
|
фрагменте кода среди всех членов команды |
Управление
4 |
Назначение сроков и ответственных за |
|
исправление выявленных недостатков |
|
25 |
РЕФАКТОРИНГ АРХИТЕКТУРЫ И КОДА
1
2
3
4
Технологичность
Систематическая деятельность с предсказуемым результатом каждого элементарного шага
Улучшение структуры ПО
Облегчение понимания работы кода облегчение обнаружения ошибок
Упрощение модификации без изменения наблюдаемого поведения системы
Улучшение композиции
Ускорение разработки
Повышение скорости внесения изменений и реализации новых функций
Возможности и угрозы
Продолжение проектирования во время разработки (сопровождения)
Необходимость модификации работающего кода |
26 |
|
и возможного пересмотра интерфейсов (API) |
||
|
ПРИМЕРЫ РЕФАКТОРИНГА (1 / 2, UML)
Переименование метода
1 |
Источник: Мартин Фаулер, Rename Method |
|
Причина: текущий вариант имени не раскрывает |
||
|
||
|
назначение метода. |
Customer
getinvcdtlmt()
Customer
getInvoiceableCreditLimit()
27
ПРИМЕРЫ РЕФАКТОРИНГА (2 / 2, JAVA)
|
Введение поясняющей переменной |
|
2 |
Источник: Мартин Фаулер, Introduce Explaining |
|
Variable |
||
|
||
|
Причина: выражение чересчур сложно для |
|
|
понимания и поддержки. |
if((platform.toUpperCase().indexOf("MAC") > -1) && (browser.toUpperCase().indexOf("IE") > -1) && wasInitialized() && resize > 0) {
// ...
}
final boolean isMacOs |
= platform.toUpperCase().indexOf("MAC") > -1; |
final boolean isIEBrowser = browser.toUpperCase().indexOf("IE") > -1; final boolean wasResized = resize > 0;
if(isMacOs && isIEBrowser && wasInitialized() && wasResized) { // ...
}
28
РЕФАКТОРИНГ ОО-КОДА И ПРАВИЛА ОО-ПРОЕКТИРОВАНИЯ
Брайан Фут и Уильям Опдайк в работе Life Cycle and Refactoring Patterns that Support Evolution and Reuse (1995) указали на ряд правил ОО-
проектирования, многие из которых перекликаются с каталогом методов рефакторинга из книги Мартина Фаулера.
DR1. Use Consistent Names
DR2. Eliminate Case Analysis
DR3. Reduce the Number of Arguments
DR4. Reduce the Number of Methods
DR7. Minimize Access to Variables
DR8. Subclasses Should Be Specializations
DR9. Split Large Classes
DR11. Separate Methods That Do not Communicate
29
МИФ О РЕФАКТОРИНГЕ
30