Комментарии 2
Спасибо за полезную в целом статью и ссылки в ней.
А можно попридираться? Привычка тестировщика.
1. На мой взгляд, статья начинается с некоторой подмены понятий: утверждается, что в определении качества основной упор сделан на функциональности, хотя в цитируемых определениях речь идет о фокусе на потребностях заказчика. Потребности же — это не только функциональность, но и те самые безопасность, сопровождаемость, эффективность, портируемость, надежность. В любом нормальном ТЗ этим потребностям отведен раздел нефункциональных требований.
2. Возникает впечатление, что в статье противопоставлен статический анализ кода и code review и производится попытка показать, что статический анализ лучше. На самом деле они дополняют друг друга, поскольку никакой автоматический анализатор на самом деле, по крайней мере пока, не сможет помочь вам сделать код архитектурно красивым и повысить уровень владения кодом большим количеством программистов.
3. Из статьи не понятно каким образом анализатор становится не чисто техническим инструментом. Ведь свои сообщения он все равно пишет чисто техническим языком. Эта тема как-то не слишком раскрыта.
4. Сомнительно звучит, что программист не хочет знать о своем коде всю правду. Хочет. И хочет сделать код лучше, причем, чем раньше, тем лучше. И чтобы никто первоначальных недостатков не увидел. В этом-то анализатор и может ему наилучшим способом помочь: его можно использовать и поправить дефекты на самой ранней стадии.
5. Совсем ничего не сказано о возможных ложных срабатываниях анализаторов.
А можно попридираться? Привычка тестировщика.
1. На мой взгляд, статья начинается с некоторой подмены понятий: утверждается, что в определении качества основной упор сделан на функциональности, хотя в цитируемых определениях речь идет о фокусе на потребностях заказчика. Потребности же — это не только функциональность, но и те самые безопасность, сопровождаемость, эффективность, портируемость, надежность. В любом нормальном ТЗ этим потребностям отведен раздел нефункциональных требований.
2. Возникает впечатление, что в статье противопоставлен статический анализ кода и code review и производится попытка показать, что статический анализ лучше. На самом деле они дополняют друг друга, поскольку никакой автоматический анализатор на самом деле, по крайней мере пока, не сможет помочь вам сделать код архитектурно красивым и повысить уровень владения кодом большим количеством программистов.
3. Из статьи не понятно каким образом анализатор становится не чисто техническим инструментом. Ведь свои сообщения он все равно пишет чисто техническим языком. Эта тема как-то не слишком раскрыта.
4. Сомнительно звучит, что программист не хочет знать о своем коде всю правду. Хочет. И хочет сделать код лучше, причем, чем раньше, тем лучше. И чтобы никто первоначальных недостатков не увидел. В этом-то анализатор и может ему наилучшим способом помочь: его можно использовать и поправить дефекты на самой ранней стадии.
5. Совсем ничего не сказано о возможных ложных срабатываниях анализаторов.
Спасибо за хорошие вопросы.
1. Это, конечно, так. Термин «Потребности» нужно понимать действительно в широком смысле. Однако на практике, функциональные требования настолько доминируют над сознанием и отношениями, что прочие «смыслы» зачастую остаются на бумаге. Более того, не функциональные требования часто проверяются только в первой версии, а для последующих уже нет. Вот, например, классическая заглушка для ФТР одного из наших проектов
8. Обеспечение доступности
Функционально-технические решения по обеспечению доступности не изменяются и соответствуют описанию в соответствующем разделе ФТР предыдущей версии N.N
2. Нет, не противопоставление. Скорее я хотел донести идею, что использование автоматических средств анализа исходного кода — это своеобразный недорогой «code review». Разумеется, просмотр кода опытными разработчиками или архитекторами может помочь выявить серьезные ошибки проектирования, например. Однако, использовать такой ресурс для более простых задач анализа текста программы, которые гораздо эффективнее и быстрее решает соответствующий инструмент — это расточительство времени и сил. Опять же я привёл примеры, когда альтернативы анализаторам кода просто нет.
Что касается использование анализатора кода в качестве средства обучения хорошим правилам программирования, то здесь я бы поспорил. Когда анализатор выдаст исчерпывающую справку о найденной уязвимости с подробным описанием возможных последствий, предоставит примеры того, как код исправить, укажет на строки кода, где эта уязвимость обнаружена — то это уже вполне можно считать элементом обучения.
Например, для C# из Kiuwan
Overload Equals method on value types
Description
For the value type «structure', default implementation of the method that determines the equality of two objects (Equals) habitually it will have a performance lower than a personalized implementation and because of this it recommends to personalize this method and Violation will appear when it is not like that.
Code
OPT.CSHARP.Csharp.OverloadingEqualsValueTypes
Reference
msdn.microsoft.com/en-us/library/7h9bszxx(VS.80).aspx
Violation code
Fixed code
3. Базовым результатом работы любого анализатора кода будет список найденных уязвимостей, ошибок, замечаний. Всё самое интересно начинается потом. Как работать с этим списком? Классификация, сортировка, группировка, приоритизация. Над этим слоем можно построить более общие отчеты по обнаруженным проблемам.
Выше — общая статистика по приложению
Выше — статистика по портфелю приложений, командам разработки или внешним исполнителям и многое другое.
Пример общего отчета анализа С# приложения.
И это только срез отчетов после одной проверки. А если процедуру производить регулярно, то появится возможность посмотреть на информацию в динамике — кто улучшает качественные характеристики, кто ухудшает, по каким показателям и т.д.
Еще на один момент я обращал внимание в статье — насколько важно обнаруженные уязвимости преобразовать в задачи. Здесь два аспекта — оценка сложность исправления и доставка задачи исполнителю. И то и другое, например, есть в Kiuwan — система помогает примерно оценить в часах, днях сколько нужно времен на исправление. Есть выгрузка в Excel. Есть интеграция с Jira / SBM. Наверное можно и с другими трекерами установить „рабочие отношения“.
Вот теперь это уже не только инструмент самообразования программиста, а полноценный инструмент контроля качества серьезной организации, как мне представляется.
4. Как известно, есть две парадигмы в отношении управления людьми. Или нужно исходить из того, что все сотрудники лентяи, бездари, халтурщики и т.д. или наоборот, что они все молодцы, болеют за дело, как за свое, пожертвуют своим временем и здоровьем ради проекта и т.д. Я обычно исхожу из „второй“, а получается как в „первой“. :)
5. Я даже скажу больше. Важно не только отбрасывать ложные срабатывания, но и „отключать“ целые типы уязвимостей, которые для ваших обстоятельств использования приложения, например, значения не имеют.
В Kiuwan пользователь может отключить отдельные найденные ошибки — »Mute" — и они больше не попадут в отчет даже при повторном анализе. Либо настроить свою модель качества приложений, повысив приоритет одних характеристик и снизив для других, что отражается и для расчета метрик и для поиска уязвимостей. Либо загрузить свои правила обнаружения дефектов.
Как-то так. Надеюсь, что ответил на ваши вопросы.
1. Это, конечно, так. Термин «Потребности» нужно понимать действительно в широком смысле. Однако на практике, функциональные требования настолько доминируют над сознанием и отношениями, что прочие «смыслы» зачастую остаются на бумаге. Более того, не функциональные требования часто проверяются только в первой версии, а для последующих уже нет. Вот, например, классическая заглушка для ФТР одного из наших проектов
8. Обеспечение доступности
Функционально-технические решения по обеспечению доступности не изменяются и соответствуют описанию в соответствующем разделе ФТР предыдущей версии N.N
2. Нет, не противопоставление. Скорее я хотел донести идею, что использование автоматических средств анализа исходного кода — это своеобразный недорогой «code review». Разумеется, просмотр кода опытными разработчиками или архитекторами может помочь выявить серьезные ошибки проектирования, например. Однако, использовать такой ресурс для более простых задач анализа текста программы, которые гораздо эффективнее и быстрее решает соответствующий инструмент — это расточительство времени и сил. Опять же я привёл примеры, когда альтернативы анализаторам кода просто нет.
Что касается использование анализатора кода в качестве средства обучения хорошим правилам программирования, то здесь я бы поспорил. Когда анализатор выдаст исчерпывающую справку о найденной уязвимости с подробным описанием возможных последствий, предоставит примеры того, как код исправить, укажет на строки кода, где эта уязвимость обнаружена — то это уже вполне можно считать элементом обучения.
Например, для C# из Kiuwan
Overload Equals method on value types
Description
For the value type «structure', default implementation of the method that determines the equality of two objects (Equals) habitually it will have a performance lower than a personalized implementation and because of this it recommends to personalize this method and Violation will appear when it is not like that.
Code
OPT.CSHARP.Csharp.OverloadingEqualsValueTypes
Reference
msdn.microsoft.com/en-us/library/7h9bszxx(VS.80).aspx
Violation code
public struct A { //VIOLATION
int x;
}
Fixed code
public struct A {
int x;
public override bool Equals(object o) //OK
{
A obj = (A)o;
return (this.x == obj.x);
}
}
3. Базовым результатом работы любого анализатора кода будет список найденных уязвимостей, ошибок, замечаний. Всё самое интересно начинается потом. Как работать с этим списком? Классификация, сортировка, группировка, приоритизация. Над этим слоем можно построить более общие отчеты по обнаруженным проблемам.
Выше — общая статистика по приложению
Выше — статистика по портфелю приложений, командам разработки или внешним исполнителям и многое другое.
Пример общего отчета анализа С# приложения.
И это только срез отчетов после одной проверки. А если процедуру производить регулярно, то появится возможность посмотреть на информацию в динамике — кто улучшает качественные характеристики, кто ухудшает, по каким показателям и т.д.
Еще на один момент я обращал внимание в статье — насколько важно обнаруженные уязвимости преобразовать в задачи. Здесь два аспекта — оценка сложность исправления и доставка задачи исполнителю. И то и другое, например, есть в Kiuwan — система помогает примерно оценить в часах, днях сколько нужно времен на исправление. Есть выгрузка в Excel. Есть интеграция с Jira / SBM. Наверное можно и с другими трекерами установить „рабочие отношения“.
Вот теперь это уже не только инструмент самообразования программиста, а полноценный инструмент контроля качества серьезной организации, как мне представляется.
4. Как известно, есть две парадигмы в отношении управления людьми. Или нужно исходить из того, что все сотрудники лентяи, бездари, халтурщики и т.д. или наоборот, что они все молодцы, болеют за дело, как за свое, пожертвуют своим временем и здоровьем ради проекта и т.д. Я обычно исхожу из „второй“, а получается как в „первой“. :)
5. Я даже скажу больше. Важно не только отбрасывать ложные срабатывания, но и „отключать“ целые типы уязвимостей, которые для ваших обстоятельств использования приложения, например, значения не имеют.
В Kiuwan пользователь может отключить отдельные найденные ошибки — »Mute" — и они больше не попадут в отчет даже при повторном анализе. Либо настроить свою модель качества приложений, повысив приоритет одних характеристик и снизив для других, что отражается и для расчета метрик и для поиска уязвимостей. Либо загрузить свои правила обнаружения дефектов.
Как-то так. Надеюсь, что ответил на ваши вопросы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Анализируй это или о качестве программного обеспечения