Здравствуйте, gandjustas, Вы писали:

G>Макконнелл понимает "качество кода" как совокупность факторов, в том числе количество ошибок на тысячу строк и то, что вы называете maintainability.

Предположим. На самом деле, я не вижу никаких существенных для проектного менеджмента характеристик "качества кода" помимо "плотности ошибок" (quality) и "цены внесения изменений" (maintainability). Вам кажется, есть еще какие-либо характеристики, производными которых прямо или косвенно не являлись бы эти две?

G>Но суть не в этом. Макконнелл рассматривает сам факт тестирования программы, говоря что он не увеличивает качество кода. (действительно сколько программу не тестируй работать она будет точно также) Но если рассматривать процесс разработки, в котором автоматизированное тестирование занимает свое место, то при таком процессе качество кода (в любом понимании) возрастает.

"Тестирование", очевидно, надо заменить на слово "отладка", это активность, которая включает в себя обнаружение и испроавление ошибок. Это единый процесс, обе составляющие необходимы, как день и ночь, и одна без другой не имеет смысла. До такой степени глупо их разделять, что я не понимаю, зачем МакКоннел на этом фиксируется. Процесс "отладки" безусловно способствует повышению качества, независимо от природы мероприятия отлова ошибки — будь то автоматический тест, ручной тест, unit-тест, системный тест, code review, design review, architecture review, или requirements review — разница не принципиальна и только в том, какой класс ошибок вносимых на каком этапе процедура ловит (и исправляет).

Вопрос. В чем глубокая мысть МакКоннела? Какие из нее следуют полезные выводы?

Здравствуйте, gandjustas, Вы писали:

LMA>>"Одно и тоже" подразумевают, что они оба будут писать C1.
G>Один сделает в одном методе одну ошибку, другой в этом же методе — другую.

Даже боюсь подумать какая у Вас в команде плотность дефектов (на тысячу строк кода), что Вас беспокоит такая ситуация!

Здравствуйте, Gaperton, Вы писали:

G>Мы, зная, что на тестирование-отладку у нас уходит 50% времени, поручаем ее обоим программистам. Получаем две системы с разным detailed design, в одной из которых примерно 20 ошибок, в другой — примерно 30. Что мы делаем дальше?

Ну, во-первых, мы должны получить не две системы, а две версии компонента (в концептуальном смысле, т.е. компоненты — это элементы, которые можно независимо друг от друга разрабатывать, покупать, обновлять и т.д.) или две версии набора компонентов (что зависит от масштаба). Дальше выбирается лучший из двух вариантов как можно меньшей по размеру части кода (такой размер будет продиктован детализацией спецификаций, которые, очевидно, одинаковые "на входе" у обоих программистов; в самом худшем случае — это будет компонент). Критерием лучшего варианта может быть "старая-добрая" метрика WTFs/min

Ключевой вопрос — какова должна быть степень детализации требований, а следовательно и размер "грануляции", которая оказывает в свою очередь влияние на количество багов (исходя из такого простого принципа, что множества багов каждого из них не будут равны). Естественно, тут важна граммотная проработка требований, совместные брифинги с привлечением обоих программистов (чтобы они шли "одним путем"), неслучайный подбор программистов в "пару" и здоровая конкуренция между ними... короче, все, что надо делать в любом случае — никуда не девается.

LMA>>Ну а еще "максимум 25%" хорошо согласуется с теми исследованиями на эту тему, что мне приходилось видеть. Ссылки на некоторые из них можно найти у того же Макконнелла в Code Complete.

G>Отлично. Допустим для целей нашей дискуссии, что это так и есть (цифра, кстати, на мой взгляд вполне правдоподобная). Теперь вопрос. У вас по замерам времени выяснилось, что это время — 40%. Вы — менеджер. У вас группа из 6 человек программистов. Ваши действия? Что лично вы делать будете? Каков будет план ваших мероприятий? В терминах конкретных действий, если можно.

Это всего-навсего означает, что на это тратится слишком много времени, по сравнению с оптимальной величиной. Это означает одно из двух: нетипичный проект (например, требующий повышенной надежности — "ядрёные штучки" и т.д.) или означает неэффективность процесса тестирования.

Шаги по повышению эффективности я уже приводил в первом посте.