Comments 17
— Если инспекторов несколько, то очень полезно, чтобы они не видели дефекты, найденные другими инспекторами. Это позволит потом посчитать количество дубликатов (одинаковых дефектов от разных инспекторов). Обычно чем их больше, тем выше качество инспекции.
— Все изменения, сделанные автором в ходе исправлений нужно снова послать на инспекцию. А то иногда бывает, что исправлений больше, чем исходного кода и это все коммитится в репозиторий без инспекции.
— Все изменения, сделанные автором в ходе исправлений нужно снова послать на инспекцию. А то иногда бывает, что исправлений больше, чем исходного кода и это все коммитится в репозиторий без инспекции.
> — Если инспекторов несколько, то очень полезно, чтобы они не видели дефекты, найденные другими инспекторами. Это позволит потом посчитать количество дубликатов (одинаковых дефектов от разных инспекторов). Обычно чем их больше, тем выше качество инспекции.
Интересная мысль, спасибо!
> — Все изменения, сделанные автором в ходе исправлений нужно снова послать на инспекцию. А то иногда бывает, что исправлений больше, чем исходного кода и это все коммитится в репозиторий без инспекции.
Согласен, скажу даже больше: исправления должны валидироваться авторами дефектов.
Интересная мысль, спасибо!
> — Все изменения, сделанные автором в ходе исправлений нужно снова послать на инспекцию. А то иногда бывает, что исправлений больше, чем исходного кода и это все коммитится в репозиторий без инспекции.
Согласен, скажу даже больше: исправления должны валидироваться авторами дефектов.
По пунктам:
>> А что это вы тут делаете?
Понимание инспектируемой задачи, бесспорно, важный момент. Но определение того, выполняет ли код поставленную задачу, это прерогатива отдела тестирования, а не инспектирования. Как Вы сами сказали, «Котлеты отдельно, мухи отдельно».
>> На вкус и цвет все фломастеры разные
Этого легко избежать, если инспектор будет руководствоваться чётко установленными стандартами. И при возврате кода программисту на доработку можно всегда указать на тот или иной пункт в Корпоративных Стандартах. У нас в компании таких документов несколько, в том числе и стандарты стилистического оформления кода.
>> А что это вы тут делаете?
Понимание инспектируемой задачи, бесспорно, важный момент. Но определение того, выполняет ли код поставленную задачу, это прерогатива отдела тестирования, а не инспектирования. Как Вы сами сказали, «Котлеты отдельно, мухи отдельно».
>> На вкус и цвет все фломастеры разные
Этого легко избежать, если инспектор будет руководствоваться чётко установленными стандартами. И при возврате кода программисту на доработку можно всегда указать на тот или иной пункт в Корпоративных Стандартах. У нас в компании таких документов несколько, в том числе и стандарты стилистического оформления кода.
Забыл добавить, что стандарты не берутся с потолка и/или не являются чьей-то прихотью в стиле «Мне так нравится, я начальник, значит так и будет». Все стандарты в нашей компании выработаны ключевыми программистами, обсуждались всем коллективом, а потом уже внедрялись.
В данном случае имелись ввиду не стандарты кодирования, для контроля которых, кстати говоря, и инспектирование не нужно, так как с этим отлично справляются автоматизированные средства в момент сборки.
Имелась ввиду вкусовщина в плане способа решения задачи (архитектура, разбиение ответственности, использованный алгоритмы, паттерны и пр.). Тут могут быть очень важные дефекты, которые обязательно нужно править, но должны быть аргументы «за» это кроме «мне декоратор нравится больше, чем стратегия»
Имелась ввиду вкусовщина в плане способа решения задачи (архитектура, разбиение ответственности, использованный алгоритмы, паттерны и пр.). Тут могут быть очень важные дефекты, которые обязательно нужно править, но должны быть аргументы «за» это кроме «мне декоратор нравится больше, чем стратегия»
> Но определение того, выполняет ли код поставленную задачу, это прерогатива отдела тестирования, а не инспектирования.
Во-первых тестирование и инспектирование решают одну и туже задачу: ищут дефекты. При этом инспектирование позволяет обнаружить такие дефекты, которые тестирование не факт, что и найдет.
Во-вторых, задачи бывают в том числе технические (например, рефакторинг). Тестировщикам тут вообще делать нечего.
Во-первых тестирование и инспектирование решают одну и туже задачу: ищут дефекты. При этом инспектирование позволяет обнаружить такие дефекты, которые тестирование не факт, что и найдет.
Во-вторых, задачи бывают в том числе технические (например, рефакторинг). Тестировщикам тут вообще делать нечего.
Собственно, Вы сами и подтвердили свои слова: «Котлеты отдельно, мухи отдельно». Хоть инспекторы с тестировщиками и решают одну и ту же проблему поиска дефектов, они всё-таки выискивают разные по типу дефекты. Следовательно, тут и подход разный, и инструменты, и люди с их квалификацией.
Множества дефектов, обнаруживаемых при инспектировании и при тестировании, конечно, не совпадают, но они во многом пересекаются. Чем раньше дефект будет пойман, тем дешевле его исправление, соответственно, дефект, пойманный на инспектировании в исправлении обходится дешевле, чем тот же дефект, пойманный во время тестирования. Так что нет никаких причин во время инспектирования не искать дефекты, которые теоретически могут быть пойманы тестировщиками (если они его не прошляпят).
Безусловно, соглашусь с Вами. Однако, есть один тонкий момент: цена рабочего времени специалиста. Как правило, рабочее время инспектора (он же квалифицированный программист) стоит гораздо дороже времени тестировщика. Поэтому компании не выгодно, чтобы инспектор делал то, что может сделать тестировщик.
Все зависит от стоимости пропущенного в production дефекта, то есть от конкретного программного продукта. Иногда такие дефекты стоят очень дорого, и тут даже время генерального директора можно потратить на поиск такого дефекта, если оно принесет пользу :)
Понимание инспектируемой задачи, бесспорно, важный момент. Но определение того, выполняет ли код поставленную задачу, это прерогатива отдела тестирования, а не инспектирования. Как Вы сами сказали, «Котлеты отдельно, мухи отдельно».
Практически, это обычно определяется тем, какой специалист в данный момент доступен. Если ему легко понять и проверить код на соответствие решаемой задачи, грех этим не воспользоваться.
Практически, это обычно определяется тем, какой специалист в данный момент доступен. Если ему легко понять и проверить код на соответствие решаемой задачи, грех этим не воспользоваться.
Инспектировать код лучше в привычной среде разработки. Тот же Code Collaborator (у нас активно используется) — ужасный по качеству инструмент. Например, нельзя оставлять код в комментариях. Так что мы тоже не пользуемся комментариями в нём, но по более простой причине — они же не работают!
Отправляя код на ревью, важно помнить что ревью призвано уменьшить количество ошибок, а не исключить их. Не надо оставлять какие-то изменения на потом при рефакторинге с мыслью «если забуду, во время ревью напишут» — не напишут. Соответственно, если после ревью в коде обнаруживается очевидный баг — не надо говорить ревьюверу «ну как же ты такой баг просмотрел?!» Такая атмосфера приведёт к трате непропорционального количество времен на инспекцию кода.
Отправляя код на ревью, важно помнить что ревью призвано уменьшить количество ошибок, а не исключить их. Не надо оставлять какие-то изменения на потом при рефакторинге с мыслью «если забуду, во время ревью напишут» — не напишут. Соответственно, если после ревью в коде обнаруживается очевидный баг — не надо говорить ревьюверу «ну как же ты такой баг просмотрел?!» Такая атмосфера приведёт к трате непропорционального количество времен на инспекцию кода.
По моему опыту, для инспектирования кода на языке Java гайдлайн номер ноль — это инспектировать в IDE. Иначе от инспектирования кода вреда будет больше, чем пользы, и лучше его вообще не делать или делать максимально быстро и формально, если уж распорядок требует. Выявить без IDE в новом коде какую-нибудь существенную ошибку, которую до этого не выловил компилятор, практически нереально.
Sign up to leave a comment.
Практические советы для эффективного инспектирования кода