Спасибо за полезную в целом статью и ссылки в ней.
А можно попридираться? Привычка тестировщика.
1. На мой взгляд, статья начинается с некоторой подмены понятий: утверждается, что в определении качества основной упор сделан на функциональности, хотя в цитируемых определениях речь идет о фокусе на потребностях заказчика. Потребности же — это не только функциональность, но и те самые безопасность, сопровождаемость, эффективность, портируемость, надежность. В любом нормальном ТЗ этим потребностям отведен раздел нефункциональных требований.
2. Возникает впечатление, что в статье противопоставлен статический анализ кода и code review и производится попытка показать, что статический анализ лучше. На самом деле они дополняют друг друга, поскольку никакой автоматический анализатор на самом деле, по крайней мере пока, не сможет помочь вам сделать код архитектурно красивым и повысить уровень владения кодом большим количеством программистов.
3. Из статьи не понятно каким образом анализатор становится не чисто техническим инструментом. Ведь свои сообщения он все равно пишет чисто техническим языком. Эта тема как-то не слишком раскрыта.
4. Сомнительно звучит, что программист не хочет знать о своем коде всю правду. Хочет. И хочет сделать код лучше, причем, чем раньше, тем лучше. И чтобы никто первоначальных недостатков не увидел. В этом-то анализатор и может ему наилучшим способом помочь: его можно использовать и поправить дефекты на самой ранней стадии.
5. Совсем ничего не сказано о возможных ложных срабатываниях анализаторов.
А можно попридираться? Привычка тестировщика.
1. На мой взгляд, статья начинается с некоторой подмены понятий: утверждается, что в определении качества основной упор сделан на функциональности, хотя в цитируемых определениях речь идет о фокусе на потребностях заказчика. Потребности же — это не только функциональность, но и те самые безопасность, сопровождаемость, эффективность, портируемость, надежность. В любом нормальном ТЗ этим потребностям отведен раздел нефункциональных требований.
2. Возникает впечатление, что в статье противопоставлен статический анализ кода и code review и производится попытка показать, что статический анализ лучше. На самом деле они дополняют друг друга, поскольку никакой автоматический анализатор на самом деле, по крайней мере пока, не сможет помочь вам сделать код архитектурно красивым и повысить уровень владения кодом большим количеством программистов.
3. Из статьи не понятно каким образом анализатор становится не чисто техническим инструментом. Ведь свои сообщения он все равно пишет чисто техническим языком. Эта тема как-то не слишком раскрыта.
4. Сомнительно звучит, что программист не хочет знать о своем коде всю правду. Хочет. И хочет сделать код лучше, причем, чем раньше, тем лучше. И чтобы никто первоначальных недостатков не увидел. В этом-то анализатор и может ему наилучшим способом помочь: его можно использовать и поправить дефекты на самой ранней стадии.
5. Совсем ничего не сказано о возможных ложных срабатываниях анализаторов.