Предлагаю обсудить эту тему. Выскажу свои соображения, с четким осознанием, что они могут оказаться неверными

Первое и главное. ( Сроки * качество * функционал ) = ( const * человекоресурсы ). То есть — надо сразу выбрать, чем жертвуем — сроками, качеством или функционалом.

Ситуацию, когда в жертву приносится качество, я обсуждать просто не готов. Нулевой практический опыт в этом. Разумные вещи ИМХО на эту тему сказал Гапертон в теме "совет от мудрого человека".

Еще могу заметить, что решение пожертвовать качеством во имя сроков зачастую несет за собой нехорошие последствия. А именно — пишут сначала начерно и быстро, думая, что потом будет время — и перепишем начисто. Так вот, эта переписка начисто может занять значительно больший срок, чем даже написание начисто с нуля. Такое возникает в условиях, когда система уже развернута, и в процессе переписывания никак нельзя лишать ее работоспособности. Потому принесение в жертву качества во имя сроков легко приводит к тому, что в конечном итоге сорванными окажутся именно сроки.

Отдельно скажу о том, как правильно приносить в жертву функционал. Технологией роадмапов. То есть — в обсуждениях затрагивается функционал по максимуму, даже тот, что будет реализован через пару лет в лучшем случае. Обсуждается огромное количество функционала действительно на годы вперед, и вся команда в курсе этого функционала. После чего раздаются приоритеты — это делаем прямо сейчас, это делаем потом, это делаем — когда руки дойдут.

Цель такой технологии — архитекторы знакомы с требованиями на два года вперед. В архитектуру продукта эти требования изначально попадают, что повышает шансы на то, что не потребуется никаких _архитектурных_ изменений в течение такого длинного срока.

Далее. Чего надо избегать. Избегать надо любого труда, требующего заметные человеко-часы. Надо быть ленивым, но не из соображений "меньше напрягаться", а из соображений "сократить сроки".

Это особый вид лени. В нем "за борт" отправляется не то, что требует напряжения или что неприятно, а осознанно то, что требует человеко-часов.

Ни в коем случае нельзя отправлять за борт _продумывание_ чего-то. Продумывание занимает, например, рабочий день, а сэкономить может — неделю кодирования и отладки. Продумывание должно быть направленно именно на — "как реализовать фичи, имея в виду роадмап, и при этом написав как можно меньше кода". Писать код — дороже по часам, чем думать.

Отлаживать и искать баги — дороже по часам, чем писать код. Потому писать надо сразу с минимумом багов. Любой код пишется сразу начисто с мотивацией "чтобы больше к нему уже никогда не возвращаться", а методологии, в которых сначала пишут начерно, а потом начисто — идут за борт.

Очень осторожно надо относиться к test-driven методологическим паттернам. Для оценки того, можно ли в данном месте применять test-driven, предлагается использовать воображаемую метрику "примерная цена поиска бага в человеко-часах". Если баг в каком-то месте кода _неизбежно сразу бросится в глаза при почти любом сценарии использования_ — то и не нужно там никаких юнит-тестов. Юнит-тесты крайне нужны для тех компонент, баг в которых очевидно будет тяжел в поиске, например, может "отзвонить" в совсем другое место в системе, или сильно зависит от входных данных, или что-то вроде.

В этой ситуации написание юнит-тестов, а также инструментирование кода чем то вроде ASSERTов (прекрасное дополнение к юнит-тестам) — просто обязательно. Причина — человеко-часы на инструментирование и написание тестов ниже, чем на поиск даже одной баги.

Естественно, тесты пишутся наскоро, экономя время. Этот код имеет большие шансы попасть в помойку. Нежелательно использование в юнит-тесте никаких тулов со сложными процедурами деплоймента. Можно написать на охапке BAT или VBS файлов — на них и пишется.

Обвешивать все вообще юнит-тестами — это такое же безумие, как ехать 60км/ч в левом ряду фривея. При том, что на очень многих улицах и дорогах 60км/ч таки превышать не стоит. Что же касается сочетания test-driven и "разработки начерно", известного под названием "XP" — то это сочетание езды 60км/ч (даже на фривее) с полным отсутствием контроля давления в колесах, из соображений — "если и спустило, то не убьюсь". Сочетание ИМХО близко к безумию.

За борт идут все соображения ортогональности вида "если написали operator+, напишите и operator-". Нет. Не так. Сначала плюс. Потом — когда минус будет нужен при реализации какой-то фичи — вот тогда напишем минус.

За борт идут все попытки создания мега-библиотек на все случаи жизни. Причины а) указано выше б) значительная часть реюза кода таки делается копи-пейстом исходника, а не реюзом бинарей или LIBов.

Очень осторожно надо относиться к наследованию в любом его виде — что на уровне языка, что на уровне практики кодирования. Нужно четко решить, что хуже — проблемы копи-пейста или проблемы хрупкого базового класса. Второе зачастую на самом деле хуже.

На полиморфизме же, напротив, экономить не стоит. Если есть малейшее ощущение, что вот тут в будущем понадобятся сменные модули — сразу все надо делать полиморфно. Написание и отладка полиморфного кода так же просты, как и не-полиморфного, и потому нет никакого смысла экономить на полиморфизме.

Главный критерий стиля кодирования — понятность. Никаких головоломок в коде. Лучше — локальная понятность, т.е. избегать оборачивания чего-то в классы, чтобы потом компилятор Си++ все сделал сам, развернув деструкторы и operator+. Лучше явно все написать.

Вычитка соседом — очень правильно. Зачастую она тратит меньше времени, чем отыскивание багов потом. Вычитка самим собой через неделю — тоже правильно, это равносильно вычитке соседом.

Касательно спагетти. Это плохо, но не самое худшее — например, спагетти может годами надежно работать. При ответственном отношении к кодированию и к архитектуре спагетти появляется только при поступлении заранее неизвестных срочных требований. Чтобы такого не было — см. выше о роадмапах.

Если же такое все же произошло — то рефакторинг можно оставить "на потом". "Здесь и сейчас" надо реализовывать фичи. Рефакторинг — когда время будет. Лучше спагетти, чем затягивание сроков.

После рефакторинга (может быть совмещено с реализацией очередной фичи) — тут же оттестировать затронутый кусок, желательно все кейсы.

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

Осторожнее с джуниорами. Ввод джуниора в курс дела и его обучение — опять же сроки.

Меньше митингов. Это колоссальная затрата времени нескольких человек. Единственное разумное зерно в митинге — сделать так, чтобы все понимали задачу одинаково. Только это. Использование митингов для сбора статуса — зло. Статус-репортинг — штука индивидуальная.

Ну вот примерно так.

Здравствуйте, Maxim S. Shatskih, Вы писали:

Заметил классную штуку у тебя:

Высказывание:
MSS>Если баг в каком-то месте кода _неизбежно сразу бросится в глаза при почти любом сценарии использования_ — то и не нужно там никаких юнит-тестов.
||
закономерно и неизбежно влечет:
||
\/
MSS>рефакторинг можно оставить "на потом". "Здесь и сейчас" надо реализовывать фичи. Рефакторинг — когда время будет. Лучше спагетти, чем затягивание сроков.

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

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Предлагаю обсудить эту тему. Выскажу свои соображения, с четким осознанием, что они могут оказаться неверными

MSS>Первое и главное. ( Сроки * качество * функционал ) = ( const * человекоресурсы ). То есть — надо сразу выбрать, чем жертвуем — сроками, качеством или функционалом.

это уже постулат

MSS>Ситуацию, когда в жертву приносится качество, я обсуждать просто не готов. Нулевой практический опыт в этом. Разумные вещи ИМХО на эту тему сказал Гапертон в теме "совет от мудрого человека".

MSS>Еще могу заметить, что решение пожертвовать качеством во имя сроков зачастую несет за собой нехорошие последствия. А именно — пишут сначала начерно и быстро, думая, что потом будет время — и перепишем начисто. Так вот, эта переписка начисто может занять значительно больший срок, чем даже написание начисто с нуля. Такое возникает в условиях, когда система уже развернута, и в процессе переписывания никак нельзя лишать ее работоспособности. Потому принесение в жертву качества во имя сроков легко приводит к тому, что в конечном итоге сорванными окажутся именно сроки.

кхм.. как это соотносится с твоим следующем утверждении, что спагетти лучше чем не усепть? или там ты готов пожертвовать качеством. Спрашиваю, тк рано или поздно спагетти перейдет в "некачество". А так согласен.

MSS>Отдельно скажу о том, как правильно приносить в жертву функционал. Технологией роадмапов. То есть — в обсуждениях затрагивается функционал по максимуму, даже тот, что будет реализован через пару лет в лучшем случае. Обсуждается огромное количество функционала действительно на годы вперед, и вся команда в курсе этого функционала. После чего раздаются приоритеты — это делаем прямо сейчас, это делаем потом, это делаем — когда руки дойдут.

MSS>Цель такой технологии — архитекторы знакомы с требованиями на два года вперед. В архитектуру продукта эти требования изначально попадают, что повышает шансы на то, что не потребуется никаких _архитектурных_ изменений в течение такого длинного срока.

идея правильная, но ее реализация встречается редко. больно быстро меняются требования

MSS>Далее. Чего надо избегать. Избегать надо любого труда, требующего заметные человеко-часы. Надо быть ленивым, но не из соображений "меньше напрягаться", а из соображений "сократить сроки".

MSS>Это особый вид лени. В нем "за борт" отправляется не то, что требует напряжения или что неприятно, а осознанно то, что требует человеко-часов.

опять же редко когда удается, а так +

MSS>Ни в коем случае нельзя отправлять за борт _продумывание_ чего-то. Продумывание занимает, например, рабочий день, а сэкономить может — неделю кодирования и отладки. Продумывание должно быть направленно именно на — "как реализовать фичи, имея в виду роадмап, и при этом написав как можно меньше кода". Писать код — дороже по часам, чем думать.

+

MSS>Отлаживать и искать баги — дороже по часам, чем писать код. Потому писать надо сразу с минимумом багов. Любой код пишется сразу начисто с мотивацией "чтобы больше к нему уже никогда не возвращаться", а методологии, в которых сначала пишут начерно, а потом начисто — идут за борт.

+, вот они, человекочасы

MSS>Очень осторожно надо относиться к test-driven методологическим паттернам. Для оценки того, можно ли в данном месте применять test-driven, предлагается использовать воображаемую метрику "примерная цена поиска бага в человеко-часах". Если баг в каком-то месте кода _неизбежно сразу бросится в глаза при почти любом сценарии использования_ — то и не нужно там никаких юнит-тестов. Юнит-тесты крайне нужны для тех компонент, баг в которых очевидно будет тяжел в поиске, например, может "отзвонить" в совсем другое место в системе, или сильно зависит от входных данных, или что-то вроде.

MSS>В этой ситуации написание юнит-тестов, а также инструментирование кода чем то вроде ASSERTов (прекрасное дополнение к юнит-тестам) — просто обязательно. Причина — человеко-часы на инструментирование и написание тестов ниже, чем на поиск даже одной баги.

писать юнит тесты — занятие требующее нехилых человекочасов

MSS>Естественно, тесты пишутся наскоро, экономя время. Этот код имеет большие шансы попасть в помойку. Нежелательно использование в юнит-тесте никаких тулов со сложными процедурами деплоймента. Можно написать на охапке BAT или VBS файлов — на них и пишется.

MSS>Обвешивать все вообще юнит-тестами — это такое же безумие, как ехать 60км/ч в левом ряду фривея. При том, что на очень многих улицах и дорогах 60км/ч таки превышать не стоит. Что же касается сочетания test-driven и "разработки начерно", известного под названием "XP" — то это сочетание езды 60км/ч (даже на фривее) с полным отсутствием контроля давления в колесах, из соображений — "если и спустило, то не убьюсь". Сочетание ИМХО близко к безумию.

MSS>За борт идут все соображения ортогональности вида "если написали operator+, напишите и operator-". Нет. Не так. Сначала плюс. Потом — когда минус будет нужен при реализации какой-то фичи — вот тогда напишем минус.

+

MSS>За борт идут все попытки создания мега-библиотек на все случаи жизни. Причины а) указано выше б) значительная часть реюза кода таки делается копи-пейстом исходника, а не реюзом бинарей или LIBов.

все-таки нет.

MSS>Очень осторожно надо относиться к наследованию в любом его виде — что на уровне языка, что на уровне практики кодирования. Нужно четко решить, что хуже — проблемы копи-пейста или проблемы хрупкого базового класса. Второе зачастую на самом деле хуже.

спорно

MSS>На полиморфизме же, напротив, экономить не стоит. Если есть малейшее ощущение, что вот тут в будущем понадобятся сменные модули — сразу все надо делать полиморфно. Написание и отладка полиморфного кода так же просты, как и не-полиморфного, и потому нет никакого смысла экономить на полиморфизме.

в целом, да

MSS>Главный критерий стиля кодирования — понятность. Никаких головоломок в коде. Лучше — локальная понятность, т.е. избегать оборачивания чего-то в классы, чтобы потом компилятор Си++ все сделал сам, развернув деструкторы и operator+. Лучше явно все написать.

нет, если это требует пяти минут, то нет категорически

MSS>Вычитка соседом — очень правильно. Зачастую она тратит меньше времени, чем отыскивание багов потом. Вычитка самим собой через неделю — тоже правильно, это равносильно вычитке соседом.

спорно, все зависит от сложности задачи

MSS>Касательно спагетти. Это плохо, но не самое худшее — например, спагетти может годами надежно работать. При ответственном отношении к кодированию и к архитектуре спагетти появляется только при поступлении заранее неизвестных срочных требований. Чтобы такого не было — см. выше о роадмапах.

MSS>Если же такое все же произошло — то рефакторинг можно оставить "на потом". "Здесь и сейчас" надо реализовывать фичи. Рефакторинг — когда время будет. Лучше спагетти, чем затягивание сроков.

сам же пишешь, что "потом" оборачивается затратой еще большего времени

MSS>После рефакторинга (может быть совмещено с реализацией очередной фичи) — тут же оттестировать затронутый кусок, желательно все кейсы.

MSS>Теперь об административных мерах. Крайне нежелательна текучка кадров. Ввод нового человека в курс дела — время, а его как раз не хватает, ибо мы зафиксировали качество, а возможности жертвовать функционалом ограничены, и в идеале уже и так все "выбраны" до предела.

MSS>Осторожнее с джуниорами. Ввод джуниора в курс дела и его обучение — опять же сроки.

обучение — да, но есть еще предметная область, где и профи потратит кучу времени

MSS>Меньше митингов. Это колоссальная затрата времени нескольких человек. Единственное разумное зерно в митинге — сделать так, чтобы все понимали задачу одинаково. Только это. Использование митингов для сбора статуса — зло. Статус-репортинг — штука индивидуальная.

статус-митинги не зло. зло частые статус-митинги

MSS>Ну вот примерно так.

Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Предлагаю обсудить эту тему. Выскажу свои соображения, с четким осознанием, что они могут оказаться неверными
Блин, ты на земле живешь или на планете роботов? Такое ощущение, что ты впервые начал программировать в команде, и даже стал управлять командой. Но проблема в том. Люди (=проект) это больше, мясо, кости и сроки.

Теперь портрет:
— ты разработчик дров, а не бизнес приложений
— ты чаще работаешь один по чёткой документации
— ты любишь доки, чем общение
— тебе не слишком важно довольство заказчика, ты следуешь соответствию твоей программы чёткой докуме

Твой подход для драйверов пойдёт, пойдёт для компании CBOSS. Но это не подход качественного

Всё, что ты написал это ужас доперестоичного периода. Уже старьём считаются практики test-driven, паттерны и т.п. Не применение их это словно в туалете не пользоваться туалетной бумагой. Попробуй хоть одну книгу найти, где твой подход оправдан. Возьми любое развитие "водопада" современное или адаптивные методологии -- в общем открой для себя мир. Выйди на улицу и будет счастье

V>То есть, другими словами, при желании сэкономить время на юнит-тестах мы практически [b гарантированно[/b] получаем спагетти-код.

Не понял логики. Каким боком юнит-тесты к рефакторингу? совершенно разные вещи. Есть рефакторинг, после которого не нужны юнит-тесты. И есть увешанные юнит-тестами компоненты, которые раз написаны, отлажены и никогда не рефакторятся.

Причины возникновения спагетти:

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

Все это совершенно реальная практика.

V>Ибо в режиме экономии времени и отсутствия юнит-тестов рефакторинг невозможен в принципе (точнее он возможен, то тогда об экономии времени придется забыть).

Ну да. Он становится возможен, когда возникает некое временное послабление в жесткости сроков.

V>А спагетти — это такая штука, которая имеет свойство накапливаться, проявляя при этом кумулятивный эффект.

Да, но при этом "замакарониваются" какие-то конкретные "горячие" места кода, а не вообще равномерно весь код проекта. Скажем, в драйвере замакаронивается обработчик IOCTL по мере их добавления, и особенно добавления семантики к существующим.

То есть сложность задачи по рефакторингу и устранению макарон растет медленно.

V>экономия на юнит тестах (и, как следствие, на рефакторинге)

Не вижу абсолютно никакой логической связи между первым и вторым.

V>добавление очередной фичи требует разгребание огромной кучи воняющего дерьмокода, что при отсутствии юнит-тестов и невозможности рефакторинга вызовет желание переписать все заново.

Если возможно переписать заново — то возможен и рефакторинг, причем он всегда будет проще.

КЛ>кхм.. как это соотносится с твоим следующем утверждении, что спагетти лучше чем не усепть? или там ты готов пожертвовать качеством. Спрашиваю, тк рано или поздно спагетти перейдет в "некачество".

Нет. Спагетти просто неприятно читать, а необходимость его править вызывает идиосинкразию. Но оно может работать, и работать надежно.

Спагетти не влияет на качество _продукта_. Оно влияет только на эмоции девелопера, что в нем ковыряется.

КЛ>идея правильная, но ее реализация встречается редко. больно быстро меняются требования

Вот я бы советовал ознакомиться с любой литературой по управлению оными требованиями. Это действительно очень важный вопрос, в отличие от изучения всяких XP и Agile.

КЛ>писать юнит тесты — занятие требующее нехилых человекочасов

Да ну? Пример юнит теста для компрессора/декомпрессора данных — пара из пол-экрана кода на Си для тестдрайва и полэкрана кода на VBS, который прогонит эту радость по всей директории, указанной в командной строке, каждый файл сожмет, разожмет, сравнит результаты. Дальше уже речь о наборах данных — windows\system32, парочка сильно сжатых огромных ZIPов, парочка файлов с кучей нулей, файл с длинной последовательностью ABABABABA, ну и еще что-нить до кучи.

Полдня максимум стоит разработка такого теста.

КЛ>спорно, все зависит от сложности задачи

За неделю при плотной работе ты точно забудешь код недельной давности, и вычитка тобой будет равна вычитке соседом.

Конечно, при таких вычитках надо обращать внимание ТОЛЬКО на баги, если одновременно еще обращать внимание на спагетти и стиль кодирования — то уйму времени потратишь.

КЛ>сам же пишешь, что "потом" оборачивается затратой еще большего времени

Баги править "потом" — да. Рефакторинг потом — нет. Нет особой разницы, когда его делать.

КЛ>статус-митинги не зло. зло частые статус-митинги

На такой митинг реально уходит полдня. Даже раз в неделю это черезчур, а уж раз в неделю собрать статус точно нужно.

DM>Теперь портрет:
DM>- ты разработчик дров, а не бизнес приложений

Да не только дров, уже давно и юзер-мод, но очень "системный" юзер-мод.

Бизнес-приложения меня никогда не интересовали. Мне больше интересно, как устроен компьютер, чем как устроен бизнес (перефразируя рекламу ThinkPadов).

DM>- ты чаще работаешь один по чёткой документации

Задача почти всегда на одного, требования всегда четкие, документацию писать как правило в лом.

DM>- ты любишь доки, чем общение

Общение с руководством _для уточнения требований_ просто обязательно, до полного и абсолютного их понимания. Что касается общения по техническим вопросам — да, доки мне как-то сподручнее.

DM>- тебе не слишком важно довольство заказчика, ты следуешь соответствию твоей программы чёткой докуме

Довольство заказчика — это соответствие требованиям. К чему и стремлюсь. Нет четкой документации, есть требования.

DM>Твой подход для драйверов пойдёт, пойдёт для компании CBOSS. Но это не подход качественного

Качественного "чего"? 1С-программирования?

DM>Всё, что ты написал это ужас доперестоичного периода. Уже старьём считаются практики test-driven, паттерны и т.п. Не применение их это словно в туалете не пользоваться туалетной бумагой. Попробуй хоть одну книгу найти, где твой подход оправдан.

А по пунктам можно? что именно не оправдано?

DM>Всё, что ты написал это ужас доперестоичного периода. Уже старьём считаются практики test-driven, паттерны и т.п. Не применение их это словно в туалете не пользоваться туалетной бумагой. Попробуй хоть одну книгу найти, где твой подход оправдан. Возьми любое развитие "водопада" современное или адаптивные методологии -- в общем открой для себя мир. Выйди на улицу и будет счастье
Денис, а откуда такая ненависть к классическим методам? Может стоит поговорить об этом? Тебе-же уже говорили, что есть разные ситуации и разные возможности. Есть разные клиенты и разные программисты. Почему всегда надо применять Agile? И почему применяя его будет мне счастие?

PS
Как говорил инструктор по ПМству из ИБМ — никогда не прибегайте и не предлагайте делать то-то и то-то, потому, что кто-то сказал, что это лучше. Даже если у этого кого-то действительно вышло это лучше. Есть устоявшиеся методики разработки в организации и попытки изменить их одним ПМом не приведут ни к чему хорошему... Более того, с возрастом меня начали настораживать высказывания в этом стиле: "Все, что мы делали до сих пор — устарело! Давайте применим эту более новую и прогрессивную технологию!".

Здравствуйте, Maxim S. Shatskih, Вы писали:

КЛ>>кхм.. как это соотносится с твоим следующем утверждении, что спагетти лучше чем не усепть? или там ты готов пожертвовать качеством. Спрашиваю, тк рано или поздно спагетти перейдет в "некачество".

MSS>Нет. Спагетти просто неприятно читать, а необходимость его править вызывает идиосинкразию. Но оно может работать, и работать надежно.

MSS>Спагетти не влияет на качество _продукта_. Оно влияет только на эмоции девелопера, что в нем ковыряется.

Влияет, еще как влияет. Это бомба замедленного действия.

КЛ>>идея правильная, но ее реализация встречается редко. больно быстро меняются требования

MSS>Вот я бы советовал ознакомиться с любой литературой по управлению оными требованиями. Это действительно очень важный вопрос, в отличие от изучения всяких XP и Agile.

Никакая литература не спасет тебя от парамены настроения кастомера

КЛ>>писать юнит тесты — занятие требующее нехилых человекочасов

MSS>Да ну? Пример юнит теста для компрессора/декомпрессора данных — пара из пол-экрана кода на Си для тестдрайва и полэкрана кода на VBS, который прогонит эту радость по всей директории, указанной в командной строке, каждый файл сожмет, разожмет, сравнит результаты. Дальше уже речь о наборах данных — windows\system32, парочка сильно сжатых огромных ZIPов, парочка файлов с кучей нулей, файл с длинной последовательностью ABABABABA, ну и еще что-нить до кучи.

MSS>Полдня максимум стоит разработка такого теста.

May be yes, or may be no

КЛ>>спорно, все зависит от сложности задачи

MSS>За неделю при плотной работе ты точно забудешь код недельной давности, и вычитка тобой будет равна вычитке соседом.

MSS>Конечно, при таких вычитках надо обращать внимание ТОЛЬКО на баги, если одновременно еще обращать внимание на спагетти и стиль кодирования — то уйму времени потратишь.

Баги бывают разные. Логические баги часто придется вычитывать днями. Нелогические конечно проще.

КЛ>>сам же пишешь, что "потом" оборачивается затратой еще большего времени

MSS>Баги править "потом" — да. Рефакторинг потом — нет. Нет особой разницы, когда его делать.

так "нет", или нет особой разницы.

КЛ>>статус-митинги не зло. зло частые статус-митинги

MSS>На такой митинг реально уходит полдня. Даже раз в неделю это черезчур, а уж раз в неделю собрать статус точно нужно.

Максим, ты больно много сам себе противоречишь

Здравствуйте, Maxim S. Shatskih, Вы писали:

V>>То есть, другими словами, при желании сэкономить время на юнит-тестах мы практически [b гарантированно[/b] получаем спагетти-код.

MSS>Не понял логики. Каким боком юнит-тесты к рефакторингу? совершенно разные вещи. Есть рефакторинг, после которого не нужны юнит-тесты.

Как разработчик может быть уверен, что рефакторинг произведен правильно (т.е. не вносит непредусмотренных изменений в поведение кода), если код не покрыт юнит-тестами?

N>Как разработчик может быть уверен, что рефакторинг произведен правильно (т.е. не вносит непредусмотренных изменений в поведение кода), если код не покрыт юнит-тестами?

А как разработчик может быть уверен, что _написанный с нуля новый_ код работает правильно? а ведь далеко не весь написанный с нуля код тут же покрывается юнит-тестами.

Кроме юнит-тестов, есть еще тестирование продукта в сборе. Тестирование продукта в сборе на разных наборах данных. Я еще вот что применяю постоянно (не знаю, как оно в книжках называется) — в какую-то другую часть кода вносится временное изменение, которое на самом деле есть просто _баг_, и смотрится, как моя "активная" часть кода отрабатывает с таким изменением. Например, обработку ошибок так можно тестировать.

В общем, юнит-тесты — далеко не единственный инструмент тестирования.

КЛ>Никакая литература не спасет тебя от парамены настроения кастомера

Ну в таких случаях делается иначе. Кастомер захотел чего-то новое — ему говорится, что продукт уже разработан без поддержки такого (ибо никто об этом раньше ничего не говорил), а сделать эту поддержку будет стоить ну, скажем, полгода, потому как переписывать придется почти все.

Проглотит, т.е. или откажется от идеи, или оплатит полгода. Почти точно. У него альтернатива — это вас слать подалее, брать ваш исходник, искать новую команду, которая в нем разберется и его подхватит. Все это — большой геморрой, значительные потери времени и заметные потери денег. Такое делают, но НЕ в случае неспособности быстро реализовать вдруг выдуманное на позднем этапе требование.

Опасность в этом случае почти только тогда, если это требование — важнейшее, и без него продукт не пригоден к практическому использованию ну совсем никак. В этом случае вас пошлют. Кастомер при этом сам себя наказал своей неспособностью формулировать _важнейшие_ требования — попал на время и на предоплату по проекту вам.

КЛ>Баги бывают разные. Логические баги часто придется вычитывать днями. Нелогические конечно проще.

Большинство багов у опытного девелопера, добросовестно подходящего к работе — это невнимание. ++i вместо i++, или перепутаны 2 переменных с похожими именами.

Вычиткой ловится на ура.

КЛ>Максим, ты больно много сам себе противоречишь

Нет, это ты невнимательно читаешь. Я говорил и говорю, что митинги для сбора статуса — это зло, что процедура сбора статуса должна быть индивидуальна, что каждый отчитывается по статусу персонально и в этом не должны быть задействованы соседи, и что причина этого — избежать траты времени соседа.

Митинг для сбора статуса — зло даже раз в неделю, а отчетность по статусу раз в неделю нужна точно, из чего очевидный вывод — митинги для сбора статуса неприменимы.

N_C>Денис, а откуда такая ненависть к классическим методам? Может стоит поговорить об этом? Тебе-же уже говорили, что есть разные ситуации и разные возможности. Есть разные клиенты и разные программисты. Почему всегда надо применять Agile? И почему применяя его будет мне счастие?

У меня сложилось ощущение, что Денис тут впаривает свои услуги тренера по Agile. В этом случае обсуждение маловозможно.

N_C>"Все, что мы делали до сих пор — устарело! Давайте применим эту более новую и прогрессивную технологию!".

Ага, ага, и начнем с того, что всех уволим, наберем новую команду и перепишем весь код с нуля

На самом деле не устарело _ничего_. Не устарел, например, переменный ток в розетке, двигатель внутреннего сгорания, язык Си, и многое другое.

Здравствуйте, Maxim S. Shatskih, Вы писали:

КЛ>>Баги бывают разные. Логические баги часто придется вычитывать днями. Нелогические конечно проще.
+1

MSS>Большинство багов у опытного девелопера, добросовестно подходящего к работе — это невнимание. ++i вместо i++, или перепутаны 2 переменных с похожими именами.
MSS>Вычиткой ловится на ура.

Опытный девелопер написал ++i вместо i++ ?

IMO, большинство багов у опытного девелопера — это ошибки в бизнес логике, но никак не ошибки в синтаксесе.

Здравствуйте, Maxim S. Shatskih, Вы писали:

N_C>>Денис, а откуда такая ненависть к классическим методам? Может стоит поговорить об этом? Тебе-же уже говорили, что есть разные ситуации и разные возможности. Есть разные клиенты и разные программисты. Почему всегда надо применять Agile? И почему применяя его будет мне счастие?
Да никто не говорит применять Agile. Я говорю о применение практик, которые помогут проекту и команде. Если нужно классические решения -- я и их предлагаю. ВСЕ РАДИ РЕШЕНИЕ БИЗНЕС ЗНАЧИМЫХ ЗАДАЧ (и получения удовольствия от работы ) А не зацикливание как наказать, как всех вымуштровать, как бабла выбить... не этим нужно заниматься. дружить нужно и работать

MSS>У меня сложилось ощущение, что Денис тут впаривает свои услуги тренера по Agile. В этом случае обсуждение маловозможно.
И не только услуги — бесплатные семинары, бесплатные ссылки, бесплатные тулзы.
Евангелист — не просто зарабатывание денег, а рассказ о хорошем и добром.

N_C>>"Все, что мы делали до сих пор — устарело! Давайте применим эту более новую и прогрессивную технологию!".
MSS>Ага, ага, и начнем с того, что всех уволим, наберем новую команду и перепишем весь код с нуля
MSS>На самом деле не устарело _ничего_. Не устарел, например, переменный ток в розетке, двигатель внутреннего сгорания, язык Си, и многое другое.
Хёрь какая-то. Важно использовать все к месту. Нужна докума — пишем докуму, нужен xUnit используем.
Руководствоваться нужно не дебильными лозунами — "Уволить всех", "Перепишем всё с нуля". А целесообразностью и осознанностью и без фанатизма.

В баню фанатизм и лозунги. Нужно работать и нести в мир хорошее и доброе

N_C>Как говорил инструктор по ПМству из ИБМ — никогда не прибегайте и не предлагайте делать то-то и то-то, потому, что кто-то сказал, что это лучше. Даже если у этого кого-то действительно вышло это лучше. Есть устоявшиеся методики разработки в организации и попытки изменить их одним ПМом не приведут ни к чему хорошему... Более того, с возрастом меня начали настораживать высказывания в этом стиле: "Все, что мы делали до сих пор — устарело! Давайте применим эту более новую и прогрессивную технологию!".

Я говорю о другом. Единоличная разработка VS командная разработка.
Командная — счастье, единоличная — поделка.
Счастья нужно добиваться с использованием современных "водопадных" моделей и/или адаптивные методологии (причем не важно какой). Главное КОМАНДА, а не методология и процессы.

Я за Команду

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Предлагаю обсудить эту тему. Выскажу свои соображения, с четким осознанием, что они могут оказаться неверными

MSS>Первое и главное. ( Сроки * качество * функционал ) = ( const * человекоресурсы ). То есть — надо сразу выбрать, чем жертвуем — сроками, качеством или функционалом.

Ну, идея выписать формулу — интересная. Тока, думается мне, формула чутка другая. Ну-ка, попробуем вывести.

Очевидно, в предположении идеальной балансировки задач по ресурсам, которое будет почти верным в случае, если у нас ограничены ресурсы, а проект длинный:

Трудозатраты = Сроки * человекоресурсы.

Также, очевидно, что

Трудозатраты ~ качество * функциональность.

Бюджет ~ Трудозатраты

Итого,

Бюджет ~ Сроки * Человекоресурсы ~ Качество * Функциональность.

Вот, собственно. Каждый показатель из пяти может быть ограничен. Собственно, у тебя ошибка — Сроки должны в знаменателе стоять.

Кроме того, формула не учитывает влияние такого важного фактора, как применение интеллектуальной собственности сторонних производителей, что очень сильно и нелинейно влияет и на бюджет, и на трудозатраты, и на качество. Скажем, делаем мы среду разработки для собственного DSL. Бюджет и сроки будут радикально, на порядки разные при выборе в качестве основы VBA или Qt+Scintilla+Python, например. Или, скажем, Java + Eclipse. Или рукопашной разработке без применения интеллектуальной собственности. Но допустим, что это не важно. Есть много проектов, где подобный выбор не стоит — а если и стоит, то лучше для определения оптимума проводить отдельный "НИР" за рамками основного проекта (ОКР).

MSS>Еще могу заметить, что решение пожертвовать качеством во имя сроков зачастую несет за собой нехорошие последствия. А именно — пишут сначала начерно и быстро, думая, что потом будет время — и перепишем начисто. Так вот, эта переписка начисто может занять значительно больший срок, чем даже написание начисто с нуля. Такое возникает в условиях, когда система уже развернута, и в процессе переписывания никак нельзя лишать ее работоспособности. Потому принесение в жертву качества во имя сроков легко приводит к тому, что в конечном итоге сорванными окажутся именно сроки.

Хочу на всякий случай пояснить значение термина "качество" в управлении проектами, чтобы под ним не понимали черт знает что. Термином "качество" в разработке ПО обозначают количество дефектов, которые репортят кастомеры, и которые находит тестирование. Качество характеризуется метрикой Defects/KLOC. "Жертвовать качеством" — это означает экономить на тестировании, откладывая его на поздние этапы, не более того.

Вы можете называть качеством что угодно — красоту кода, стройность дизайна — ради бога, но имейте в виду, что в контексте управления проектами "качество" это довольно узкий и конкретный термин — связанный с метрикой "плотность дефектов".

MSS>Отдельно скажу о том, как правильно приносить в жертву функционал. Технологией роадмапов. То есть — в обсуждениях затрагивается функционал по максимуму, даже тот, что будет реализован через пару лет в лучшем случае. Обсуждается огромное количество функционала действительно на годы вперед, и вся команда в курсе этого функционала. После чего раздаются приоритеты — это делаем прямо сейчас, это делаем потом, это делаем — когда руки дойдут.

MSS>Цель такой технологии — архитекторы знакомы с требованиями на два года вперед. В архитектуру продукта эти требования изначально попадают, что повышает шансы на то, что не потребуется никаких _архитектурных_ изменений в течение такого длинного срока.

+1. А я дам одну из конкртеных техник, как это делать — из старой внутренней инструкции, в основе квадрат риск-приоритет. Читайте в тексте задача = задача по реализации одной прикладной функции.

Приоритет
Приоритетом функции является ее важность для конечного результата. Функция имеет высокий приоритет в том случае, если без нее обойтись не возможно, и низкий, если без этой функции можно обойтись. Не все функции одинаково важны для результата.
Для оценки приоритетов принимается 3-х бальная шкала:

1 Продукт без той функции выпускать нельзя.
2 Отсутствие данной функции существенно уменьшит целевую аудиторию продукта, и/или заметно ухудшит его потребительские свойства.
3 Отсутствие данной функции в целом окажет небольшое влияние на размер аудитории и основные потребительские качества, важные для данной аудитории.

Риск
Под риском понимается:

Степень определенности в прогнозе трудозатрат.
Степень уверенности в технической реализуемости.
Высокий риск имеют задачи, которые непонятно как делать, настолько, что неясно, сколько времени они займут, и/или можно ли их сделать вообще.
Количественным выражением риска в первом случае является величина PERT Deviation для прогноза сроков задачи, которую можно понимать как среднеквадратичное отклонение случайной величины — собственно прогноза срока.

Риск всего проекта — это риск срыва плана, риск вылезания проекта за бюджет и потери экономической целесообразности разработки. Риск — это характеристика нашей неуверенности и нашего незнания. По мере приближения к окончанию проекта, мы способны все точнее и точнее предсказать дату его завершения — риск уменьшается по мере продвижения по графику. Очевидно, чем быстрее снижается риск проекта по мере продвижения по плану, тем лучше.

Что говорит о том, что задачи с высоким риском (неточным погнозом), в целом, надо ставить вперед.

Для качественной оценки технического риска узла и изделия Балиным В.Н. введена следующая 3-х бальная шкала:

1, Понятны границы работ, понятно как делать — возможно возникновение непринципиальных проблем по ходу реализации, которые будут решены за счет удлиннения срока.
2, Понятно, что делать, понятно, что это сделать можно, однако не до конца понятно как. Затруднительна достоверная оценка сроков, свойств реализации, и составление плана. (Надо проработать архитектуру и/или провести прототипирование)
3, Нет ясности с требованиями, непонятно, можно ли это сделать в рамках заданных ограничений, совершенно непонятно, как это делать (Надо проводить исследование, чтобы разобраться с темой)

Определение порядка выполнения задач
Рекомендуется ставить задачи в следующем порядке, принимая во внимание риски и приоритеты, используя "квадрат риск-приоритет":

Задачи с высоким приоритетом, и высоким риском.
Высокий приоритет, низкий риск.
Низкий приоритет, низкий риск.
Задачи низкого приоритета и высокого риска являются кандидатами для исключения из плана.
При определении порядка задач необходимо проследить, чтобы были учтены зависимости задач.

MSS>Далее. Чего надо избегать. Избегать надо любого труда, требующего заметные человеко-часы. Надо быть ленивым, но не из соображений "меньше напрягаться", а из соображений "сократить сроки".

+1

MSS>Это особый вид лени. В нем "за борт" отправляется не то, что требует напряжения или что неприятно, а осознанно то, что требует человеко-часов.

См. правило .

MSS>Ни в коем случае нельзя отправлять за борт _продумывание_ чего-то. Продумывание занимает, например, рабочий день, а сэкономить может — неделю кодирования и отладки. Продумывание должно быть направленно именно на — "как реализовать фичи, имея в виду роадмап, и при этом написав как можно меньше кода". Писать код — дороже по часам, чем думать.

Можно. См правило "квадрат риск-приоритет", которое вполне указывает конкретно, продумывание чего можно посылать.

MSS>Отлаживать и искать баги — дороже по часам, чем писать код. Потому писать надо сразу с минимумом багов. Любой код пишется сразу начисто с мотивацией "чтобы больше к нему уже никогда не возвращаться", а методологии, в которых сначала пишут начерно, а потом начисто — идут за борт.

+1. Ты о предварительном проектировании, конечно.

MSS>Очень осторожно надо относиться к test-driven методологическим паттернам. Для оценки того, можно ли в данном месте применять test-driven, предлагается использовать воображаемую метрику "примерная цена поиска бага в человеко-часах". Если баг в каком-то месте кода _неизбежно сразу бросится в глаза при почти любом сценарии использования_ — то и не нужно там никаких юнит-тестов. Юнит-тесты крайне нужны для тех компонент, баг в которых очевидно будет тяжел в поиске, например, может "отзвонить" в совсем другое место в системе, или сильно зависит от входных данных, или что-то вроде.

+1.
Они ваще идут нахрен, если надо сроки вытянуть. Тестировать надо только те сценарии, которые реально требуется — их надо ограничить, но протестить как следует.

MSS>В этой ситуации написание юнит-тестов, а также инструментирование кода чем то вроде ASSERTов (прекрасное дополнение к юнит-тестам) — просто обязательно. Причина — человеко-часы на инструментирование и написание тестов ниже, чем на поиск даже одной баги.

Можно съекономить на тестировании режимов работы юнитов, которые не задействованы в системных сценариях, разрешенных к тестированию. А вот Ассерты — это хорошо, это дешево.

MSS>Естественно, тесты пишутся наскоро, экономя время. Этот код имеет большие шансы попасть в помойку. Нежелательно использование в юнит-тесте никаких тулов со сложными процедурами деплоймента. Можно написать на охапке BAT или VBS файлов — на них и пишется.

MSS>Обвешивать все вообще юнит-тестами — это такое же безумие, как ехать 60км/ч в левом ряду фривея. При том, что на очень многих улицах и дорогах 60км/ч таки превышать не стоит. Что же касается сочетания test-driven и "разработки начерно", известного под названием "XP" — то это сочетание езды 60км/ч (даже на фривее) с полным отсутствием контроля давления в колесах, из соображений — "если и спустило, то не убьюсь". Сочетание ИМХО близко к безумию.

+1

MSS>За борт идут все соображения ортогональности вида "если написали operator+, напишите и operator-". Нет. Не так. Сначала плюс. Потом — когда минус будет нужен при реализации какой-то фичи — вот тогда напишем минус.

+1 Они у нормальных людей всегда идут за борт ИМХО. Лучше написать когда потребуется, и тогда отладить, чем сделать сразу, и наклепать там ошибок, но их не выловить, потому "что не потребовалось". А то, помню, дернешь за функцию — а она глючит не по децки, потому что ты за 7 лет первый, кто ее вызвал . Бесит.

Ну и далее везде.

G>Вот, собственно. Каждый показатель из пяти может быть ограничен. Собственно, у тебя ошибка — Сроки должны в знаменателе стоять.

Ага, я просто неверно употребил слово "Сроки". В моей формуле имелось в виду — ЖесткостьТребованийПоСрокам, которая, понятно, имеет размерность ( время^-1 ).

G>Кроме того, формула не учитывает влияние такого важного фактора, как применение интеллектуальной собственности сторонних производителей

Мне это пришло в голову при написании исходного поста, но я понял, что у меня крайне малый опыт такого использования, и потому мне почти нечего сказать на эту тему.

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

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

Ага, тут уже посчитали спагетти-код низким "качеством".

G>Defects/KLOC. "Жертвовать качеством" — это означает экономить на тестировании, откладывая его на поздние этапы, не более того.

Я это и имел в виду. На тестировании, на аккуратном кодировании (скажем, нет нормальной обработки ошибок).

G>Можно. См правило "квадрат риск-приоритет", которое вполне указывает конкретно, продумывание чего можно посылать.

Низкий приоритет и высокий риск?

G>+1. Ты о предварительном проектировании, конечно.

И о кодировании тоже. Если при кодировании не думают о corner cases, об обработке ошибок и нештата — то все это потом неизбежно всплывет в тестировании или у кастомера. Причем некоторые баги имеют очень высокую цену поиска.

G>Можно съекономить на тестировании режимов работы юнитов, которые не задействованы в системных сценариях, разрешенных к тестированию. А вот Ассерты — это хорошо, это дешево.

Даже в релизе ассерты можно оставить. Естественно, они иначе реализуются — например, в виде сообщения в UI или в event log такого же вида, как и невозможность открыть указанный файл. Internal Error %d. У микрософта в компиляторе такое

Если потом тестеры или кастомер на нее жалуются — то я уже знаю, что у меня где-то _баг_, который поймался на ассерте.

G>+1 Они у нормальных людей всегда идут за борт ИМХО.

Ну как же... бывают люди, которые от этого просто в восторге, или, например, в восторге от предельно строгого следования ООП или еще какой парадигме. Время разработки от такого подхода раздувается в разы.

AJD>Опытный девелопер написал ++i вместо i++ ?

Это опечатка.
Объем внимания у всех ограничен, и опечатки бывают.

AJD>IMO, большинство багов у опытного девелопера — это ошибки в бизнес логике, но никак не ошибки в синтаксесе.

Это опечатки. Их количество почти одинаково у всех и всегда, а бизнес-логику можно и продумать.

DM>Я говорю о другом. Единоличная разработка VS командная разработка.
DM>Командная — счастье, единоличная — поделка.

И почему это мне при этих словах вспомнилась Мария Дэви Христос?

Наблюдаемый мною реал говорит вот о чем: сам факт перехода разработки с единоличного уровня на командный сразу создает огромный оверхед. Оверхед на общение внутри команды. Девелоперы начинают вместо продумывания, кодирования и отладки делать упор на общение между собой.

Это чудовищные потери времени. Например, если началась flame war о том, как что-то писать — это амбец. Тут же начинаются еще и интриги и перетягивание одеяла на себя.

GlebZ тут предлагал вообще такое — перед имплементацией фичи каким-то девелопером надо ее обсудить в коллективе. Потрясающе. У других девелоперов есть другие задания, а они от них отвлекутся. Глянем на Микрософт — у них есть такое? нет, у них есть понятие code ownership.

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

Конечно, команда может быть и самоцелью, она создает у некоторых людей ощущение, что "Юоанн С Вами" , но к успеху проекта это все весьма косвенно относится.