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

Первое и главное. ( Сроки * качество * функционал ) = ( 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.

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

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

Здравствуйте, Maxim S. Shatskih

Многое из написанного уже было и не оправдало возложенных надежд. К сожалению осознать тему полностью крайне сложно. Нужен опыт выполненных проектов, больших и маленьких, простых и сложных, удачных и провальных. Нужна перспектива, прицел в будущее ...

Продумывание и копи-пейст ... Лучший комментарий это "правило трех ударов" Кеннета Бека. Человеко-часы не тратятся на ненужную работу, а появляются только когда появляется потребность. TDD позволяет получить более правильный дизайн автоматически, однако надо понять суть подхода и его философию. Без этого это слепая трата человеко-часов. Опять же рефакторинг без тестов, как уже говорили просто НОНСЕНС. "писать с минимумом багов" как раз отлично ложиться в тему.

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

"Лучше спагети, чем затягивание сроков" ... зависит от проекта. Если проект должен жить дальше контрольный срок сдачи проекта, то это провальный вариант. Лучше пересмотреть сроки, и это не из-за любви к искусству — просто перспектива потерь от куска г%? кода будут больше плюсов иллюзии. Ведь разработанная фича это не самоцель — цель проект.

"Осторожнее с джуниорами" — тоже бред. Вменяемого молодого можно быстрее научить работать правильно. В довольно скорой перспективе, джуониор станет на ноги и будет благодарен команде за науку. К тому же всегда есть масса других дел, которыми он может заняться прямо сразу. Звезда бросит проект, как только его начнут доставать подобные вам руководители, с видением подобными вашему. Один товарищь в начале года открывал подразделение оутсорсинговой компани и брал только молодых, после института или с годичным опытом. Понянчился с ними 3-4 месяца и окупил все вложения. Сидит закуривает и не лезет в проекты вообще — только когда его об этом просят. Это свершившийся факт. Просто нужен хороший наставник и правильный человек. Если нужно просто быстро и качественно сделать какую-то работу — отдайте ее на сторону профессионалам — это всегда дешевле.

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

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

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

Имеются в виду дефекты, которые проявляются в неверном поведении кода? А как быть с кодом, который работает правильно на настоящий момент, но написан так, что стоимость внесения в него изменений будет непомерно высокой? Нужно ли брать в расчет такое "качество"?

N>Продумывание и копи-пейст ... Лучший комментарий это "правило трех ударов" Кеннета Бека. Человеко-часы не тратятся на ненужную работу, а появляются только когда появляется потребность. TDD позволяет получить более правильный дизайн автоматически

Это как? обвешали что-то криво спроектированное юнит-тестами — и оно от этого стало прямо спроектированное?

N>"Наследование, полиморфизм" и связанные с ними осторожности тоже из области слепого. Есть разумный подход, пяток принципов OOП, метрики оценки дизайна.

Я знаю ООП _на практике серьезной работы_ с 93 года (на уровне хохотушек для личного самоудовлетворения где-то с начала 92 с ТурбоПаскалем и ТурбоВижном). Тогда и приучили.

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

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

N>"Лучше спагети, чем затягивание сроков" ... зависит от проекта. Если проект должен жить дальше контрольный срок сдачи проекта, то это провальный вариант.

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

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

Хыыы... джуниор может вдруг и невменяемым оказаться.

N>Понянчился с ними 3-4 месяца и окупил все вложения.

Повезло товарищу.

N>Если нужно просто быстро и качественно сделать какую-то работу — отдайте ее на сторону профессионалам — это всегда дешевле.

А недостатки такого подхода надо перечислять?

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

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

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

N>Имеются в виду дефекты, которые проявляются в неверном поведении кода? А как быть с кодом, который работает правильно на настоящий момент, но написан так, что стоимость внесения в него изменений будет непомерно высокой? Нужно ли брать в расчет такое "качество"?

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

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

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

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

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

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

А при грамотном применении это может экономить трудозатраты, и сокращать сроки. Но увеличивать бюджет проекта. Короче, будем считать не ограничивая общности, что интеллектуальную собственность мы уже выбрали до старта проекта. Так, на самом деле, правильно.

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

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

Это вообще кандидат на исключение из плана даже если сроки не поджимают. Потом жертвуем просто низким приоритетом, независимо от риска.

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

G>А при грамотном применении это может экономить трудозатраты,

Естественно, для того готовые компоненты и существуют.

G>Но увеличивать бюджет проекта.

Уменьшать.

Как правило цена этой IP ниже, чем цена разработки аналога "дома".

Причины воздержаться от сторонней IP могут быть а) выверты с ее лицензированием, налагающие обязательства б) то, что я перечислил в предыдущем сообщении.

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

Простите. То есть — высокие трудозатраты приводят к исключению _из роадмапа_? вот это вряд ли верно.

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

MSS>Это как? обвешали что-то криво спроектированное юнит-тестами — и оно от этого стало прямо спроектированное?

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

N>>"Наследование, полиморфизм" и связанные с ними осторожности тоже из области слепого. Есть разумный подход, пяток принципов OOП, метрики оценки дизайна.

MSS>Я знаю ООП _на практике серьезной работы_ с 93 года (на уровне хохотушек для личного самоудовлетворения где-то с начала 92 с ТурбоПаскалем и ТурбоВижном). Тогда и приучили.

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

MSS>С тех пор я могу говорить только о _коренных недостатках_ ООП, в т.ч. нерешаемой как правило проблеме хрупкого базового класса.

Давай пример поконкретнее — интересно. Да и что такое хрупкий класс? С большим количеством обязанностей?

N>>"Лучше спагети, чем затягивание сроков" ... зависит от проекта. Если проект должен жить дальше контрольный срок сдачи проекта, то это провальный вариант.

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

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

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

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

MSS>>Это как? обвешали что-то криво спроектированное юнит-тестами — и оно от этого стало прямо спроектированное?

N>Да нет еще круче — не тратится времени на проектирование — делается сразу как можно проще и дизайн эволюционирует только тогда, когда это действительно необходимо. Все точки расширения сразу все равно не угадать. Тесты обеспечивают работоспособность решения. Когда начинается второе повторение (копи-пейст) кода — берем на заметку, когда третье — делаем рефакторинг, улучшающий наш дизайн. Потом это же относится и к проектированию — не проектировать больше чем надо... Нужно сразу оговорится, что если все аспекты приложения известны заранее, то можно потратится на дизайн и сразу. Вот ты говорил о проектировании далеко вперед, но это тоже ругают как "коллапс проектирования". 1 принцип — вам это не понадобится.

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

Пара примеров из личной практики.

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

— Стал на неизвестную тропу Native XML DB с XML:DB-Api, немного повошкался сделал пару тестовых классов — доволен шо той слон — потратив около часа на тесты развеял все сомнения по всем интересовавшим вопросам.

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

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

G>Ну, идея выписать формулу — интересная. Тока, думается мне, формула чутка другая. Ну-ка, попробуем вывести.
G>Очевидно, в предположении идеальной балансировки задач по ресурсам, которое будет почти верным в случае, если у нас ограничены ресурсы, а проект длинный:
G>Трудозатраты = Сроки * человекоресурсы.
G>Также, очевидно, что
G>Трудозатраты ~ качество * функциональность.
G>Бюджет ~ Трудозатраты
G>Итого,

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

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

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


Широко известна аксиома проектного менеджмента о тройственном ограничении по параметрам Functional, Duration, Resources. Правило железного треугольника, говорит, что изменение одного из трех параметров обязательно приведет к изменению как минимум еще одного.

Всем известно, что на самом деле, треугольник не такой уж железный. И при хорошем желании его можно существенно деформировать в разные стороны, оптимизируя, например, один из параметров даже при фиксировании двух других. Т.е. жесткой зависимости между тремя этими параметрами нет. Можно говорить лишь об определенной пропорциональности. Можем, к примеру, сказать, что, объем функционала пропорционален объему ресурсов и длительности:

Functional = K * Duration * Resources

Кстати, совершенно понятно, что данная формула применима не только для проектов по созданию ПО. Она подходит для описания зависимостей основных параметров ЛЮБОГО проекта в классическом понимании слова "проект". Можно обобщить формулировку, и вместо термина "Functional" использовать более общий термин "Value", демонстрируя эту обобщенность:

Value = K * Duration * Resources (аксиома тройственного ограничения)

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

Так вот, задумываясь над этой формулой, понимаешь, что все самое интересное кроется в этом самом коэффициенте K. Как раз в нем и материализуются все тяготы и невзгоды проекторной действительности. Давайте попробуем разобраться в его экономическом, управленческом смысле.

Из школьного курса математики известно, что произведение длительности на объем ресурсов дает трудозатраты:

Work = Duration * Resources

Таким образом, подставляя в формулу тройственного ограничения трудозатраты, получаем:

Value = K * Work
K = Value / Work

Вот теперь смысл коэффициента K становится абсолютно осязаемым. Отношение созданной ценности к фактическим трудозатратам, проинвестированным в ее создание, есть ничто иное как производственная эффективность. Т.е. этот коэффициент демонстрирует насколько эффективно затраченные человеко-часы преобразуются в освоенный объем. Далее, для ясности, так и будем называть этот коэффициент: коэффициент производственной эффективности (Production Performance Index — PP):

Value = PP * Work
PP = Value / Work

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

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

Упрощая, положим, что на PP влияет только качество. Понятно, что производственная эффективность обратнопропорциональна требуемому уровню качества — чем строже ограничения по плотности деффектов, тем медленнее движется прогресс проекта:

PP = 1 / Quality

Тогда, подставляя значение коэффициента, в формулу тройственного ограничения, имеем:

Value = Resources * Duration / Quality

Resources = Value * Quality / Duration

Duration = Value * Quality / Resources

Полученные формулы, демонстрируя влияние требуемого уровня качества на параметры проекта, являются пищей для размышления ПМ-а стоящего перед задачей оптимизации качества на проекте.

Аналогичным образом, выражая PP через другие экономико-социо-инженерно-психологические факторы, можно отслеживать их влияние на проект.

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

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

N>Да нет еще круче — не тратится времени на проектирование

Уже смешно.

N>- делается сразу как можно проще и дизайн эволюционирует только тогда,

Еще смешнее. Изменения _дизайна_ — это не просто тупой рефакторинг из серии "выделить метод". Это крайне дорогостоящий реинжиниринг.

Предварительное продумывание, снижающее шансы на такую радость — это благо.

N>Все точки расширения сразу все равно не угадать.

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

N>пейст) кода — берем на заметку, когда третье — делаем рефакторинг, улучшающий наш дизайн.

Вот чем реже возникает нужда в таком — тем лучше.

N>Потом это же относится и к проектированию — не проектировать больше чем надо...

...авось кривая вывезет.

N>ругают как "коллапс проектирования". 1 принцип — вам это не понадобится.

Понадобится. Просто не сейчас.

N>Есть разумный подход, пяток принципов OOП

На них что, молиться теперь?

N>Давай пример поконкретнее — интересно. Да и что такое хрупкий класс? С большим количеством обязанностей?

Да нет, всего-то картина, когда разработчики наследников полагаются на внутренние детали о работе базы. Исходник базы-то вот он. Соблазн крайне велик.

N>>>"Лучше спагети, чем затягивание сроков" ... зависит от проекта. Если проект должен жить дальше контрольный срок сдачи проекта, то это провальный вариант.

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

Макароны — они локальны. Зачастую 1-2 экрана кода. А вот хрупкий базовый класс сразу делает хрупким все дерево наследования.

N>Я не против что оно работает. Я к тому что чем больше нужно будет в этот код лезть, тем более дорогим он становится.

Это не повод сразу делать хрупкий код.

N>если будет более двух обращений к такому коду — его просто эффективнее будет переписать.

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

N>Да это интересно — но и избавляться от таких джуниоров легче — не болит и не несет серьезных последствий.

Время только потеряно, деньги потеряны.

N>звезды не нужны — нужны просто вменяемые люди. Ну и выкинуть по контексту аналитика и архитектора, если они не нужны.

То есть — если есть кому делать аналитику и архитектуру.

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

Ага, а бензин на бензоколонках появляется благодаря соблюдению ПДД

N>Т.к. использование кода начинается до его написания. И соотвественно изменить дизайн чего-то чего еще нет — ничего не стоит.

Всего-навсего все тесты в помойку выкинуть и новые написать, а так действительно ничего.

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

MSS>Это опечатка.
MSS>Объем внимания у всех ограничен, и опечатки бывают.
AJD>>IMO, большинство багов у опытного девелопера — это ошибки в бизнес логике, но никак не ошибки в синтаксесе.
MSS>Это опечатки. Их количество почти одинаково у всех и всегда, а бизнес-логику можно и продумать.

Большинство опечаток находится компилятором. Опечатки типа испозование ++i вместо i++ в большинстве случаев абсолютно не принципиальные и не ломают логику софта. А вот "бизнес-логику можно и продумать" — не так-то просто.

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

MSS>GlebZ тут предлагал вообще такое — перед имплементацией фичи каким-то девелопером надо ее обсудить в коллективе.
+1
Только коллектив это не значит что вся компания обсуждает.

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

N>>Хочу добавить, что дизайн появляется именно благодаря тестам.
MSS>Ага, а бензин на бензоколонках появляется благодаря соблюдению ПДД
N>>Т.к. использование кода начинается до его написания. И соотвественно изменить дизайн чего-то чего еще нет — ничего не стоит.
MSS>Всего-навсего все тесты в помойку выкинуть и новые написать, а так действительно ничего.

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

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

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

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

G>>Ну, идея выписать формулу — интересная. Тока, думается мне, формула чутка другая. Ну-ка, попробуем вывести.
G>>Очевидно, в предположении идеальной балансировки задач по ресурсам, которое будет почти верным в случае, если у нас ограничены ресурсы, а проект длинный:
G>>Трудозатраты = Сроки * человекоресурсы.
G>>Также, очевидно, что
G>>Трудозатраты ~ качество * функциональность.
G>>Бюджет ~ Трудозатраты
G>>Итого,

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

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

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

По сути то же самое (что хорошо — значит все правильно, раз одинаковый результат получен независимо), но рассуждение — совершенно великолепно. И более общо. Буду ссылаться.

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


MSS>Макароны — они локальны. Зачастую 1-2 экрана кода.
Это не макароны и тем более не спагетти — ет вермишель

А вот строчек от 500 — ет уже спагетти в которые смотреть страшно

MSS>>GlebZ тут предлагал вообще такое — перед имплементацией фичи каким-то девелопером надо ее обсудить в коллективе.
AJD>+1
AJD>Только коллектив это не значит что вся компания обсуждает.

Дурацкие растраты времени.

MSS>>Потрясающе. У других девелоперов есть другие задания, а они от них отвлекутся. Глянем на Микрософт — у них есть такое? нет, у них есть понятие code ownership.
AJD>Густо-часто кодом владеет команда, а не определенный человек. В MS это по другому?

По-другому. Каждым куском кода владеет персонально один девелопер. Это владение переменно со временем с периодом порядка 1-2 лет, как я слышал.

AJD>Большинство опечаток находится компилятором. Опечатки типа испозование ++i вместо i++ в большинстве случаев абсолютно не принципиальные и не ломают логику софта.

Совершенно неверно. Запросто может возникнуть ошибка, да еще трудновоспроизводимая и тяжелая в поиске.

N>Ну где-то так. Причем особенно интересно именно в погоне за фичерами. Глубокое опережающее проектирование в заранее неизвестной задаче это плохо.

Этап первый. Делаем задачу известной. Это аналитика требований. Если ее толком нет — то будет плохо, и никакое TDD не поможет.

А в известной (хотя бы примерно) задаче уже и глубоко проектировать можно. Кстати, подход "ядро — плагины" имени Гапертона, к которому независимо приходили многие разные команды — это благо. Очень хорошие архитектуры. Если правильно сделать интерфейс втыкания плагинов, конечно. В Windows Shell правильно, во FreeBSD VFS (а неправильно — в Linux VFS, но Линус вообще убогий архитектор).

N>Особенно когда сидит и думает один или два человека.

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

N> И как раз тут в помощь TDD — ты не знаешь проектирования, а пытаешься сразу создать код, который использует еще не созданную архитектуру.

...как первокурсник на коленке. Посмешище.

N>Т.е. TDD это прежде всего не тесты — просто такой подход к проектированию через практику использования.

Мне это напоминает ремонт телевизора путем ковыряния отверткой в ухе — "сижу, ковыряюсь, звук пропал".

N>Именно в архитектуре и должен TDD себя хорошо проявлять, т.к. тестов не много и вместе с тем они охватывают систему целиком.

...о аллах...

Как это "немного" тестов могут "охватывать систему целиком"?

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

Юнит-тесты — штука кое-где полезная и незаменимая. Но TDD...

SP_>А вот строчек от 500 — ет уже спагетти в которые смотреть страшно

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

Вот спагетти второго типа покрывает только небольшие куски кода, хотя и противно.

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

AJD>>Только коллектив это не значит что вся компания обсуждает.
MSS>Дурацкие растраты времени.

Зачем же переносить свой негативный опыт на других?

MSS>По-другому. Каждым куском кода владеет персонально один девелопер. Это владение переменно со временем с периодом порядка 1-2 лет, как я слышал.
И что происходит если человек заболел/в отпуске/уволился?

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

AJD>>Большинство опечаток находится компилятором. Опечатки типа испозование ++i вместо i++ в большинстве случаев абсолютно не принципиальные и не ломают логику софта.

MSS>Совершенно неверно. Запросто может возникнуть ошибка, да еще трудновоспроизводимая и тяжелая в поиске.
Такая ошибка достаточно просто и стабильно воспроизводится и с большой степенью вероятности будет обнаружена еще на этапе юнит тестирования. А вот прокол в бизнес логике, когда не был учтен какой-то специфический usecase и который воспроизводится только на продакшен системе во время полнолуния — вот это, ИМО, тяжелая ошибка.

AJD>>>Только коллектив это не значит что вся компания обсуждает.
MSS>>Дурацкие растраты времени.
AJD>Зачем же переносить свой негативный опыт на других?

Это не свой негативный опыт, а объективная реальность и законы физики. Посчитайте в человеко-часах, сколько времени займут эти дурацкие митинги. Длительность митинга минимум полчаса. Умножьте на числе участников. За это время можно было исправить несколько багов и написать ощутимый объем кода.

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

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

Ну вот, например, такой факт бытия: текучесть кадров есть объективная реальность. Ну и смысл "тимбилдовать" человека, если он уже изначально точно знает, что данное место работы ему как одна из ступенек?

MSS>>По-другому. Каждым куском кода владеет персонально один девелопер. Это владение переменно со временем с периодом порядка 1-2 лет, как я слышал.
AJD>И что происходит если человек заболел/в отпуске/уволился?

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

Потеря времени? на тимбилдинг и полусектантские митинги теряется больше.

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

ИМХО нельзя так однозначно говорить о том, что митинги нужны или не нужны.

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

AJD>>Зачем же переносить свой негативный опыт на других?
MSS>Это не свой негативный опыт,

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

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

MSS>Ну вот, например, такой факт бытия: текучесть кадров есть объективная реальность. Ну и смысл "тимбилдовать" человека, если он уже изначально точно знает, что данное место работы ему как одна из ступенек?
Значит именно в этой компании тимбилдинг не имеет смысла

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

MSS>Потеря времени? на тимбилдинг и полусектантские митинги теряется больше.
Нет, опрделенно у тебя был только негативный опыт.

AJD>Если митинг делать ради митинга на котором все спят — то это да, безусловно, трата времени. А если это брэйншторм то и результат другой.

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

Простая задача — это задача, решение которой очевидно одному отдельно взятому специалисту, пусть и толковому.

Да, кстати, напомню такую вещь: интеллект коллектива не есть сумма интеллектов отдельных его участников, и не есть даже их среднее. Он всегда НИЖЕ среднего интеллекта участников. См. Густава ле Бона и его классический труд о психологии толпы.

Еще напомню такую вещь: творчество всегда индивидуально. Удачное соавторство, вроде Олдей или Стругацких — редкость. См. классические работы Айн Ранд.

AJD>Значит именно в этой компании тимбилдинг не имеет смысла

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

AJD>Чем дать "соседу" разбираться отличается от совместного владения кодом несколькими людьми?

Тем, что вне форсмажорных ситуаций "соседа" не отвлекают на чужой код, у него свой есть.

AJD>Нет, опрделенно у тебя был только негативный опыт.

А в чем здесь может быть позитивный опыт? действительно не понимаю.

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

AJD>>Если митинг делать ради митинга на котором все спят — то это да, безусловно, трата времени. А если это брэйншторм то и результат другой.

MSS>Мало задач, заслуживающих брейншторма. Очень мало.

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

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

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

N_C>Если ПМ не технический, а больше административный, то тиммитинг как раз и позволяет
N_C>быстро собрать список открытых вопросов по проекту, чтобы составить общее жизненное состояние проекта.

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

DAS> Административный ПМ может обойти всех сотрудников и выяснить статус интересующих его работ. Если ему не позволяет гордость — можно поодному вызвать их для этого к себе в кабинет. Для него это займет ровно столько же времени, а для остальных сотрудников в N раз меньше (где N — кол-во сотрудников).
Ну, иногда, чтобы команда не чувствовала, что она работает просто над списком несвязанных задачек это просто необходимо...
Оговорюсь сразу, я имею ввиду малые команды (3-5 человек). При большем количестве такие собрания конечно неэффективны.

DAS> Административный ПМ может обойти всех сотрудников и выяснить статус интересующих его работ.

Обходить зачем? есть мейл и мессенжеры.

DAS>Если ему не позволяет гордость — можно поодному вызвать их для этого к себе в кабинет.

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

N_C>Ну, иногда, чтобы команда не чувствовала, что она работает просто над списком несвязанных задачек это просто необходимо...

Какая разница, кто что чувствует. Главное, чтоб не ненависть к работе и начальству, остальное — пофиг.

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

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

MSS>>Мало задач, заслуживающих брейншторма. Очень мало.

DAS> Очень согласен, более того большая их часть лежит не в области разработки ПО.
DAS> Брейншторминг имеет смысл в творческих, креативных областях

...где одному человеку не очевидно решение сразу.

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

DAS>> Административный ПМ может обойти всех сотрудников и выяснить статус интересующих его работ.
MSS>Обходить зачем? есть мейл и мессенжеры.

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

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

MSS>...где одному человеку не очевидно решение сразу.

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