Здравствуйте, vb-develop, Вы писали:
VD>Если задача ставится не ведущему разработчику проекта, то по меньшей мере в одном месте эта инструкция должна быть зафиксирована.
Вот ведь парадокс получается.
В соседнем топике "Читай код" чуть ли не трубят в фанфары по поводу бубна и магии,
а в этом топике требуют детальных инструкций по тому, как дышать.
Утрирую конечно, но что-то в этом есть.
Здравствуйте, bkat, Вы писали:
B>а в этом топике требуют детальных инструкций по тому, как дышать.
Ты не путай. Тут хотят чтоб задача была сформулирована в понятном виде, без "угадушек".
Здравствуйте, vb-develop, Вы писали:
VD>Тот кто может самостоятельно, без какой-либо инструкции выполнить эти шаги, кому не нужно объяснять необходимость использования юнит тестов, какой используется процесс по выполнению задач на проекте, кто знает о требованиях к аналогичным задачам, и кому это ни разу не объясняли в рамках данного проекта, а знает это всё по опыту предыдущих — тот по сути уже стал ведущим разработчиком, независимо от того признало это начальство или нет.
Ну и я про это.
VD>А если квалификации на тот момент не хватает, но работу-то делать надо? Ну не писал человек никогда юнит тестов, и не догадывается об их существовании, ну не сделает констрейнт в базе, но ведь функциональные требования реализованы в полном объеме. А ты же уже заявляешь о безответственном отношении к работе, и о том что его надо срочно уволить. Нет, у вас определенно проблема в менеджменте.
А если человеку уже 10 раз объясняли необходимость юнит-тестов, и инструкция написана, только все равно человек регулярно "забывает" написать тесты, или проверить результат работы, или комментарий написать? тоже менеджмент виноват? надо над ним человека с палкой поставить и чтоб за каждое отклонение от инструкции бил по пальцам?
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, bkat, Вы писали:
B>>а в этом топике требуют детальных инструкций по тому, как дышать. CC>Ты не путай. Тут хотят чтоб задача была сформулирована в понятном виде, без "угадушек".
...что и сводится к инструкции на то, как дышать. Потому что на каждое забытое действие типа ненаписанного юнит-теста будет отмазка "а в инструкции этого нет" или "а нет инструкции тестировать вот этот метод вот этого класса".
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, bkat, Вы писали:
B>>а в этом топике требуют детальных инструкций по тому, как дышать. CC>Ты не путай. Тут хотят чтоб задача была сформулирована в понятном виде, без "угадушек".
Что значит понятно? Это все индивидуально.
Кому-то надо специфицировать вплоть до методов
и кратких описаний того, что должны делать методы.
Кому-то достаточно указать общее направление и он сам задаст нужные
вопросы по существу ( опять же что это такое? )
и сам спланирует работу.
Вот представь ситуцию, у тебя трудно воспроиводимый баг
и тебе поручили его пофиксить.
В этом топике народ будет требовать детальных инструкций, и описаний,
а иначе фиг знает где что искать и начальник идиот, а тестеры бездельники.
А в топике про "Читай Код", придет маг, откроет файл в нужном месте и тут же все исправит,
не задавая глупых вопросов и не смотря в ненужные картинки
Sshur пишет: > > B>>а в этом топике требуют детальных инструкций по тому, как дышать. > CC>Ты не путай. Тут хотят чтоб задача была сформулирована в понятном > виде, без "угадушек". > > ...что и сводится к инструкции на то, как дышать. Потому что на каждое > забытое действие типа ненаписанного юнит-теста будет отмазка "а в > инструкции этого нет" или "а нет инструкции тестировать вот этот метод > вот этого класса".
А если и впрямь этот метод этого класса недостоин тестирования ? На
геттеры/сеттеры (без логики внутри) юнит тесты пишете?
Здравствуйте, hrensgory, Вы писали:
H>А если и впрямь этот метод этого класса недостоин тестирования ? На H>геттеры/сеттеры (без логики внутри) юнит тесты пишете?
Флейм по поводу писать или не писать тесты на гет/сет не стоит разводить, это не тот форум.
А вот кто должен решать по вашему, какие методы достойны тестирования, а какие нет?
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, hrensgory, Вы писали:
H>Sshur пишет:
H>А если и впрямь этот метод этого класса недостоин тестирования ? На H>геттеры/сеттеры (без логики внутри) юнит тесты пишете?
Я пишу.
Ты из-за метода copy/paste при написании примитивных геттеров/сеттеров еще проблемы не получал?
У меня бывало...
Здравствуйте, Sshur, Вы писали:
S>А если человеку уже 10 раз объясняли необходимость юнит-тестов, и инструкция написана, только все равно человек регулярно "забывает" написать тесты, или проверить результат работы, или комментарий написать? тоже менеджмент виноват? надо над ним человека с палкой поставить и чтоб за каждое отклонение от инструкции бил по пальцам?
Ситуация когда человек регулярно забывает ходить на работу здесь не обсуждается. Но если его все еще не уволили за прогулы, то это действительно проблема в менеджменте...
Здравствуйте, Sshur, Вы писали:
S>А если человеку уже 10 раз объясняли необходимость юнит-тестов, и инструкция написана, только все равно человек регулярно "забывает" написать тесты, или проверить результат работы, или комментарий написать?
Раз объяснил — не понимает. Второй раз объяснил — не понимает. Третий раз объяснил — сам понял! А он не понимает!
Тут помойму все просто. Или требования от руководства не обоснованы, или проблема с человеком. Если остальные работают по этим правилам, почему он один не работает? Или увольняйте остальных и меняйте правила под него одного, или увольняйте его и не вносите смуту в умы остальных. Вытирать сопли постоянно — ну это уже не бизнес...
Sshur пишет: > > Флейм по поводу писать или не писать тесты на гет/сет не стоит > разводить, это не тот форум. > А вот кто должен решать по вашему, какие методы достойны тестирования, а > какие нет?
Ведущий разработчик (архитектор, тимлид, менеджер — название подставить
по вкусу) должен разработать, зафиксировать и довести до ПОНИМАНИЯ
каждого разработчика общую политику в отношении юнит-тестирования в
проекте. Вы наверняка знаете по опыту, что от проекта к проекту она
может отличаться даже внутри одной организации.
Разработчик при помощи верхней головы должен соотнести эту политику с
разработанным кодом и принять обоснованное решение о том стоит ли писать
тесты и какие именно, как выполнить норматив по покрытию если он есть и т.д.
Здравствуйте, vb-develop, Вы писали:
VD>Здравствуйте, Sshur, Вы писали:
S>>А если человеку уже 10 раз объясняли необходимость юнит-тестов, и инструкция написана, только все равно человек регулярно "забывает" написать тесты, или проверить результат работы, или комментарий написать? тоже менеджмент виноват? надо над ним человека с палкой поставить и чтоб за каждое отклонение от инструкции бил по пальцам?
VD>Ситуация когда человек регулярно забывает ходить на работу здесь не обсуждается. Но если его все еще не уволили за прогулы, то это действительно проблема в менеджменте...
Нет, на работу он как часы ходит. А вот тесты может "забыть" написать, или решит, что они не нужны так как тривиальны. Кто в этом случае виноват?
И как с этим должен справиться идеальный менеджмент?
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
bkat пишет: > > Ты из-за метода copy/paste при написании примитивных геттеров/сеттеров > еще проблемы не получал? > У меня бывало...
Не уверен что эта тема подходит к форуму, но "copy/paste при написании
примитивных геттеров/сеттеров" — это как?
Здравствуйте, SEDEGOFF, Вы писали:
SED>Здравствуйте, Sshur, Вы писали:
S>>А если человеку уже 10 раз объясняли необходимость юнит-тестов, и инструкция написана, только все равно человек регулярно "забывает" написать тесты, или проверить результат работы, или комментарий написать? SED>Раз объяснил — не понимает. Второй раз объяснил — не понимает. Третий раз объяснил — сам понял! А он не понимает! SED>Тут помойму все просто. Или требования от руководства не обоснованы, или проблема с человеком. Если остальные работают по этим правилам, почему он один не работает? Или увольняйте остальных и меняйте правила под него одного, или увольняйте его и не вносите смуту в умы остальных. Вытирать сопли постоянно — ну это уже не бизнес...
Ну да, рано или поздно человек перейдет черту и будет уволен. Но тут кстати разные варианты тоже могут быть. Некоторые конторы могут уволить без разговоров — все равно очередь за воротами стоит из желающих устроится. Конторы победнее, которые с трудом находят себе студентов за маленькую зарплату тянут до последнего, а вдруг человек образумится. Или такой подход — а давайте ему зарплату не будем повышать или премии платить перестанем, сам сбежит.. Всегда есть куча вариантов и истина где-то посередине и рядом )
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, hrensgory, Вы писали:
H>Не уверен что эта тема подходит к форуму, но "copy/paste при написании H>примитивных геттеров/сеттеров" — это как?
Ну на С++ примерно так:
void setBla( int bla )
{
m_bla = bla;
}
int getBla( )
{
return m_bla;
}
void setBlaBla( int bla )
{
m_bla = bla; // ooops
}
int getBlaBla( )
{
return m_blaBla;
}
Сам пару раз попадался и у других замечал.
На C# такие ляпы менее вероятны, но тоже бывают.
Здравствуйте, Sshur, Вы писали:
VD>>Ситуация когда человек регулярно забывает ходить на работу здесь не обсуждается. Но если его все еще не уволили за прогулы, то это действительно проблема в менеджменте...
S>Нет, на работу он как часы ходит. А вот тесты может "забыть" написать, или решит, что они не нужны так как тривиальны. Кто в этом случае виноват?
Не вижу принципиальной разницы между забытом тесте, или забытом каком-либо другом задании, включая присутствие на рабочем месте в оговоренное время. Кто в этом виноват, тебе уже выше ответили.
Здравствуйте, hrensgory, Вы писали:
H>Ведущий разработчик (архитектор, тимлид, менеджер — название подставить H>по вкусу) должен разработать, зафиксировать и довести до ПОНИМАНИЯ H>каждого разработчика общую политику в отношении юнит-тестирования в H>проекте. Вы наверняка знаете по опыту, что от проекта к проекту она H>может отличаться даже внутри одной организации.
Политика на самом верхнем уровне не может быть подробной, сами понимаете, поэтому:
H>Разработчик при помощи верхней головы должен соотнести эту политику с H>разработанным кодом и принять обоснованное решение о том стоит ли писать H>тесты и какие именно, как выполнить норматив по покрытию если он есть и т.д.
А вот этот процесс как раз точно задокументировать нельзя И у каждого разработчика свое понимание,
и кто-то будет писать подробно, а кто-то нет. То есть все равно детали выполнения задания отдаются на откуп разработчику. Вот мы пришли к тому, что абсолютно конкретно и детально поставить подчиненному задание нельзя, по крайней мере в сфере разработки ПО.
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, Sshur, Вы писали:
S>Ну да, рано или поздно человек перейдет черту и будет уволен. Но тут кстати разные варианты тоже могут быть. Некоторые конторы могут уволить без разговоров — все равно очередь за воротами стоит из желающих устроится. Конторы победнее, которые с трудом находят себе студентов за маленькую зарплату тянут до последнего, а вдруг человек образумится. Или такой подход — а давайте ему зарплату не будем повышать или премии платить перестанем, сам сбежит.. Всегда есть куча вариантов и истина где-то посередине и рядом ) Ну совсем утрировано давайте посчитаем. Разгильдяй стоит 100 рублей в месяц. Условно нормальный — 200 рублей в месяц. Так вот наличие разгильдяя реяльно конторе обходится от 300 рублей в месяц! Но этого никто не счиатает. Конечно каждый случай надо смотреть индивидуально, но в 80% случаях — это просто увольнение. Есть же дажа такое выражение — я не такой богатый, что бы покупать дешовые вещи. Так же и с такими людьми. И пока им платят и бухтят про что то — они такими и будут
Здравствуйте, Sshur, Вы писали:
S>Нет, на работу он как часы ходит. А вот тесты может "забыть" написать, или решит, что они не нужны так как тривиальны. Кто в этом случае виноват?
Что значит Решит? У него есть на это право? Если есть и вас эти решения не устраивают то или заберите это право или избавьтесь от человека. S>И как с этим должен справиться идеальный менеджмент?
Зачем же идеальный? Тут и обычного хватит. По моему посту ниже вы даже можете догадаться как
Здравствуйте, Sshur, Вы писали:
S>А вот этот процесс как раз точно задокументировать нельзя И у каждого разработчика свое понимание, S>и кто-то будет писать подробно, а кто-то нет. То есть все равно детали выполнения задания отдаются на откуп разработчику. Вот мы пришли к тому, что абсолютно конкретно и детально поставить подчиненному задание нельзя, по крайней мере в сфере разработки ПО.
ой! Привидите пожалуйста пример, когда у вас это не получилось. Я встречал задачи, которые на первый взгляд не имели конкретики. Но это на первый взгляд. Во всех задачах, которые я ставил за свою недолгую жизнь, я видел конкретные цели. Другое дело исполнители мне попадались такие, которым приходилось дольше эти цели объяснять. Ну да ладно — пример задачи в студию!
