Комментарии 37
С приходом html5 я посчетал что для интернет приложения будет наиболее предпочтительна «xml верстка» (свои теги + html5 теги) проекта соответственно верстка не пройдет валидацию а в том же css используются плюшки css3, включая border-radius. Для решаемых задач — это оптимально, для понимания кода — это оптимально. Исходя из того что приложения узкопрофильное, для девелоперов — ie6 и тд не являются ЦА — это снова оптимально.
Это пример из последних практик. Конечно за долгоое время накопилось случаев когда лучше сделать «не валидно», но зато доступоно всем пользователям — это из веб-девелоп. А например в гейм деве подобное встречается всюду, взгляните на игровые ресурсы и если есть возможность и желание на код…
Это пример из последних практик. Конечно за долгоое время накопилось случаев когда лучше сделать «не валидно», но зато доступоно всем пользователям — это из веб-девелоп. А например в гейм деве подобное встречается всюду, взгляните на игровые ресурсы и если есть возможность и желание на код…
>> Best working practices versus жизнь
Позвольте не согласиться с предложенной постановкой проблемы. На то они и best practices, что:
а) пришли из жизни, а не из абстрактных учебников, и не одним человеком было проверено, что с ними получается лучше;
б) это практика, т.е. опробованно опытом. Если ваша практика указывает другое — выдавайте другие, свои best practices с описанием границ применимости. А вы зачем-то на эти бочку катите :)
У меня из практики пришло такое понимание, что эту диллему (practice/life) обычно поднимают разработчики, которые сначала обзывают МакКоннела теоретиком, а потом плачут, две недели перед релизом силясь разобраться, что ж тут такого они поменяли в середине спринта в пятницу вечером, после чего SSL отвалился :)
А еще вопрос — как вы определяете, где проходит граница между «TDD реально поможет» и «TDD обуза» на практике?
Позвольте не согласиться с предложенной постановкой проблемы. На то они и best practices, что:
а) пришли из жизни, а не из абстрактных учебников, и не одним человеком было проверено, что с ними получается лучше;
б) это практика, т.е. опробованно опытом. Если ваша практика указывает другое — выдавайте другие, свои best practices с описанием границ применимости. А вы зачем-то на эти бочку катите :)
У меня из практики пришло такое понимание, что эту диллему (practice/life) обычно поднимают разработчики, которые сначала обзывают МакКоннела теоретиком, а потом плачут, две недели перед релизом силясь разобраться, что ж тут такого они поменяли в середине спринта в пятницу вечером, после чего SSL отвалился :)
А еще вопрос — как вы определяете, где проходит граница между «TDD реально поможет» и «TDD обуза» на практике?
Черд: правильно — «дилемму»
лично я проверяю так, если функция (алгоритм) достаточно простая и логически легко воспринимается, то обойтись можно и без теста. если же разнобой форматов данных и какие-то сложные вычисления, то лучше написать пару тестов использующих каки-то «крайние» случаи, чтобы потом не беспокоиться
Вы думаете масштабами компании. Иногда нужно за месяц набрость небольшой сайт или программу в одного программиста. И тут проще делать без всех этих TDD и прочих валидаторов. И зачастую этот проект затем живёт очень долго и очень редко в нём, что-то правится.
Вот кстати tag.habrahabr.ru/blog/67377/#comment_1904167
> а) пришли из жизни, а не из абстрактных учебников, и не одним человеком было проверено, что с ними получается лучше;
«Абстрактные учебники»? Что это? Если это внеочередной наезд на математику — так там тоже все из жизни, и не одним человеком было проверено.
Ну так, strawman argument + butthurt. Не сдержался.
«Абстрактные учебники»? Что это? Если это внеочередной наезд на математику — так там тоже все из жизни, и не одним человеком было проверено.
Ну так, strawman argument + butthurt. Не сдержался.
«Абстрактные учебники» в данном случае означает (насколько я понимаю) «абстрактные, оторванные от реальности, рассуждения». Про «наезд на математику» — у вас случайно нет мании преследования? :-)
Я имел в виду, что меня беспокоит следующая мысль: если best practices не есть life, то что тогда?
P.S. Я стесняюсь спросить — что, в самом деле батхёрт? )
P.S. Я стесняюсь спросить — что, в самом деле батхёрт? )
a) .., и не одним человеком было проверено, что с ними получается лучше;
К сожалению нет доказательств, не моей, не Вашей теории:
Proffitt, Jacob. «TDD Proven Effective! Or is it?».
[http://theruntime.com/blogs/jacob/archive/2008/01/22/tdd-proven-effective-or-is-it.aspx] Retrieved 2008-02-21 (Wikipedia).
«So TDD's relationship to quality is problematic at best. Its relationship to productivity is more interesting. I hope there's a follow-up study because the productivity numbers simply don't add up very well to me. There is an undeniable correlation between productivity and the number of tests, but that correlation is actually stronger in the non-TDD group (which had a single outlier compared to roughly half of the TDD group being outside the 95% band).»
б) Я хочу предложить более оптимальный, как мне кажется, подход.
>>А еще вопрос — как вы определяете, где проходит граница между «TDD реально поможет» и «TDD обуза» на практике?
Если логика простая то можно обойтись без теста.
К сожалению нет доказательств, не моей, не Вашей теории:
Proffitt, Jacob. «TDD Proven Effective! Or is it?».
[http://theruntime.com/blogs/jacob/archive/2008/01/22/tdd-proven-effective-or-is-it.aspx] Retrieved 2008-02-21 (Wikipedia).
«So TDD's relationship to quality is problematic at best. Its relationship to productivity is more interesting. I hope there's a follow-up study because the productivity numbers simply don't add up very well to me. There is an undeniable correlation between productivity and the number of tests, but that correlation is actually stronger in the non-TDD group (which had a single outlier compared to roughly half of the TDD group being outside the 95% band).»
б) Я хочу предложить более оптимальный, как мне кажется, подход.
>>А еще вопрос — как вы определяете, где проходит граница между «TDD реально поможет» и «TDD обуза» на практике?
Если логика простая то можно обойтись без теста.
Боюсь, что невозможно определить, что такое «простая логика». И что такое «логически легко воспринимается», как предложили выше :) Вам это кажется простым, мне (второму члену команды) — сложной.
Так что тут придется на глаз, либо определять политику на уровне крманды, разработка каких модулей будет покрываться тестами, а каких — нет.
>>К сожалению нет доказательств, ни моей, ни Вашей теории
Зато есть опытные данные. МакКоннел утверждает, что TDD и тесты _уступают_ по отлову багов формальному ревью кода ) У тестов несколько другое назначение — выработка опытным путем будущего API проектируемого компонента.
Так что тут придется на глаз, либо определять политику на уровне крманды, разработка каких модулей будет покрываться тестами, а каких — нет.
>>К сожалению нет доказательств, ни моей, ни Вашей теории
Зато есть опытные данные. МакКоннел утверждает, что TDD и тесты _уступают_ по отлову багов формальному ревью кода ) У тестов несколько другое назначение — выработка опытным путем будущего API проектируемого компонента.
Тьфу, блин, ниже то же самое написали :(
>>Боюсь, что невозможно определить, что такое «простая логика».
Согласен, это не строго формально.
Но у нас это работает лучше чем набор формальных правил которые определяют когда нужно писать тест. Трудно охватить все возможные случаи. Да, можно и на уровне команды принимать такие решения.
>>МакКоннел утверждает, что TDD и тесты _уступают_ по отлову багов формальному ревью кода
Не вижу препятствий, ничто не мешает нам проводить формальные инспекции кода используя/не используя TDD.
Согласен, это не строго формально.
Но у нас это работает лучше чем набор формальных правил которые определяют когда нужно писать тест. Трудно охватить все возможные случаи. Да, можно и на уровне команды принимать такие решения.
>>МакКоннел утверждает, что TDD и тесты _уступают_ по отлову багов формальному ревью кода
Не вижу препятствий, ничто не мешает нам проводить формальные инспекции кода используя/не используя TDD.
Про уборщицу забыли рассказать :)
Странно, я наоборот считал что все сейчас двигаются в сторону разумного упрощения себе жизни.
1) "-o-border-radius" не поддерживается оперой
2) всякие фиксы и другие спорные случаи предпочитаю выносить в отдельные файлы. в идеале один для каждого браузера с «особенностями», и подгружается только по мере необходимости (определяя юзер-агент)
2) всякие фиксы и другие спорные случаи предпочитаю выносить в отдельные файлы. в идеале один для каждого браузера с «особенностями», и подгружается только по мере необходимости (определяя юзер-агент)
ТDD увеличивает издержки не давая взамен соответствующих преимуществ?
Вам тоже впадлу тесты писать? ;)
Для того, чтобы оценить TDD нужно любой серьезный проект попытаться уложить в срок.
Кроме всего прочего TDD сильно дисциплинирует. Я, например, каюсь — ленюсь писать тесты для критической логики, то есть либо все делаю через тесты либо ничего.
Думаешь: сейчас вот эту процедурку допилю и сделаю тест… Ага, щщщазз. ;)
Вам тоже впадлу тесты писать? ;)
Для того, чтобы оценить TDD нужно любой серьезный проект попытаться уложить в срок.
Кроме всего прочего TDD сильно дисциплинирует. Я, например, каюсь — ленюсь писать тесты для критической логики, то есть либо все делаю через тесты либо ничего.
Думаешь: сейчас вот эту процедурку допилю и сделаю тест… Ага, щщщазз. ;)
тесты вообще должны писаться другим человеком…
Пруфлинк, или вы фейл.
Вы знакомы c TDD?
Вы знакомы c TDD?
открой любую книжку по тестированию по…
ты в тдд действительно пишешь негативные нерегрессионные тесты или ленишься? только честно.
ты в тдд действительно пишешь негативные нерегрессионные тесты или ленишься? только честно.
Регресионные тесты у нас пишут тестеры — вкупе с UI и нагрузочными — потому что вручную тестировать слишком трудоемко получается, это очевидно. Интеграционные — совместно разработчики и тестеры — по-другому получается плохо. Unit-test — пишет исключительно разработчик, тот, кто этот unit написал.
Мне кажется, или вы путаете тестирование ПО и unit-тестирование (то, что primary в TDD), проводимое разработчиками?
Мне кажется, или вы путаете тестирование ПО и unit-тестирование (то, что primary в TDD), проводимое разработчиками?
то есть ты признаёшь, что с негативными тестами у вас никто не заморачивается?
прочитай, хотябы, это: ru.wikipedia.org/wiki/%D0%A2%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%9F%D0%9E
прочитай, хотябы, это: ru.wikipedia.org/wiki/%D0%A2%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%9F%D0%9E
Ну если тестеры это никто, то да, вы правы — у нас ими заморачиваются только эти самые «никто». Что это доказывает?
Встречный вопрос — про негативные тесты какого вида вы спрашиваете? Если про unit-test (а именно о них шла речь в оригинальной статье) — то в TDD не разделяется на positive/negative. Так что в написанных тестах какие-то normal, какие-то (например, тестирование корректной обработки исключений) — negative.
Еще раз говорю, вы смешиваете TDD, упомянутое в статье, и более широкую облать тестирования ПО. Вы еще попросите разработчиков Acceptance Tests писать.
Встречный вопрос — про негативные тесты какого вида вы спрашиваете? Если про unit-test (а именно о них шла речь в оригинальной статье) — то в TDD не разделяется на positive/negative. Так что в написанных тестах какие-то normal, какие-то (например, тестирование корректной обработки исключений) — negative.
Еще раз говорю, вы смешиваете TDD, упомянутое в статье, и более широкую облать тестирования ПО. Вы еще попросите разработчиков Acceptance Tests писать.
Существуют разные виды тестирования. Обсуждая TDD мы подразумеваем что тесты пишут сами разработчики.
психологию ещё никто не отменял… человек предпочтёт подстроить тест под своё «красивое решение», чем будет фигачить подстраиваясь под требования теста
НЛО прилетело и опубликовало эту надпись здесь
Люди, забывают публиковать контекст в котором крутятся.
Как верно замечено все имеет цену. Время=деньги, потраченные на еще один проверку/митинг по идее должно быть оправдано понижением рисков. Если же они и так незначительны то циклы и процедуры есть потеря времени=денег.
Как верно замечено все имеет цену. Время=деньги, потраченные на еще один проверку/митинг по идее должно быть оправдано понижением рисков. Если же они и так незначительны то циклы и процедуры есть потеря времени=денег.
Вообще-то цель TDD — отнюдь не в 100%-ном покрытии кода тестами (как это ни удивительно). TDD создавался как способ заставить себя задуматься каждый раз перед написанием чего-то нового — «а что же мне на самом деле надо». Т.е. это скорее инструмент проектирования, чем тестирования. Хотя тесты, конечно, тоже важный плюс :-)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Best working practices versus жизнь