Best working practices versus жизнь

    Мною замечено что люди, последнее время, все чаще стали очень категоричны: нужно создавать юнит-тесты для всего(XP TDD), валидный CSS превыше всего(W3C validity), standup-митинг нужен даже с уборщицой(Scrum)…

    Здесь я предлагаю Вам порассуждать на тему Best working practices versus жизнь!


    Unit-testing на любой случай


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

    Я с уважением отношусь к Extreme Programming(XP), но не являюсь сторонником TDD [Test-driven development] где сначала нужно создавать тесты которые описывают требования к коду, до написания самого кода, таким образом нужно создать тест для каждой фичи.

    На мой взгляд ТDD увеличивает издержки не давая взамен соответствующих преимуществ (кроме проектов с высокой стоимостью ошибок). Разумным мне кажется найти баланс и использовать Unit-тесты для критической логики приложений.

    CSS markup


    “Друзья, как же так, у вас не валидный CSS на страницах: ...”
    из письма в нашу компанию от пользователя сервиса.

    Да, я очень люблю W3С валидаторы [W3C validators] но когда сталкиваюсь с удобством против W3C валидности выбираю удобство.

    Пример стиля который создаёт закругленные края для div элементов:
    .rounded-corners {
    border-radius: 5px;
    -webkit-border-radius: 5px;
    -moz-border-radius: 5px;
    -o-border-radius: 5px;
    -khtml-border-radius: 5px;
    }

    Да, мне известны остальные 256 способов сделать это с валидным CSS… но этот очень приятен для взгляда.

    Мне интересны любые случаи где перед вами стояла дилемма: best practice/life?
    Поделиться публикацией

    Комментарии 37

      +1
      С приходом html5 я посчетал что для интернет приложения будет наиболее предпочтительна «xml верстка» (свои теги + html5 теги) проекта соответственно верстка не пройдет валидацию а в том же css используются плюшки css3, включая border-radius. Для решаемых задач — это оптимально, для понимания кода — это оптимально. Исходя из того что приложения узкопрофильное, для девелоперов — ie6 и тд не являются ЦА — это снова оптимально.
      Это пример из последних практик. Конечно за долгоое время накопилось случаев когда лучше сделать «не валидно», но зато доступоно всем пользователям — это из веб-девелоп. А например в гейм деве подобное встречается всюду, взгляните на игровые ресурсы и если есть возможность и желание на код…
        0
        validator.w3.org/check?uri=http%3A%2F%2Fsmileg.akmedia.ru%2Fhtml%2Fteplo%2F&charset=%28detect+automatically%29&doctype=Inline&ss=1&group=1&user-agent=W3C_Validator%2F1.654
        +4
        >> Best working practices versus жизнь

        Позвольте не согласиться с предложенной постановкой проблемы. На то они и best practices, что:
        а) пришли из жизни, а не из абстрактных учебников, и не одним человеком было проверено, что с ними получается лучше;
        б) это практика, т.е. опробованно опытом. Если ваша практика указывает другое — выдавайте другие, свои best practices с описанием границ применимости. А вы зачем-то на эти бочку катите :)

        У меня из практики пришло такое понимание, что эту диллему (practice/life) обычно поднимают разработчики, которые сначала обзывают МакКоннела теоретиком, а потом плачут, две недели перед релизом силясь разобраться, что ж тут такого они поменяли в середине спринта в пятницу вечером, после чего SSL отвалился :)

        А еще вопрос — как вы определяете, где проходит граница между «TDD реально поможет» и «TDD обуза» на практике?
          +3
          Черд: правильно — «дилемму»
            0
            лично я проверяю так, если функция (алгоритм) достаточно простая и логически легко воспринимается, то обойтись можно и без теста. если же разнобой форматов данных и какие-то сложные вычисления, то лучше написать пару тестов использующих каки-то «крайние» случаи, чтобы потом не беспокоиться
              0
              Вы думаете масштабами компании. Иногда нужно за месяц набрость небольшой сайт или программу в одного программиста. И тут проще делать без всех этих TDD и прочих валидаторов. И зачастую этот проект затем живёт очень долго и очень редко в нём, что-то правится.
                0
                  –2
                  > а) пришли из жизни, а не из абстрактных учебников, и не одним человеком было проверено, что с ними получается лучше;

                  «Абстрактные учебники»? Что это? Если это внеочередной наезд на математику — так там тоже все из жизни, и не одним человеком было проверено.

                  Ну так, strawman argument + butthurt. Не сдержался.
                    0
                    «Абстрактные учебники» в данном случае означает (насколько я понимаю) «абстрактные, оторванные от реальности, рассуждения». Про «наезд на математику» — у вас случайно нет мании преследования? :-)
                      0
                      Я имел в виду, что меня беспокоит следующая мысль: если best practices не есть life, то что тогда?

                      P.S. Я стесняюсь спросить — что, в самом деле батхёрт? )
                        0
                        lurkmore.ru/%D0%91%D0%B0%D1%82%D1%85%D1%91%D1%80%D1%82
                      0
                      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 обуза» на практике?
                      Если логика простая то можно обойтись без теста.
                        0
                        Боюсь, что невозможно определить, что такое «простая логика». И что такое «логически легко воспринимается», как предложили выше :) Вам это кажется простым, мне (второму члену команды) — сложной.
                        Так что тут придется на глаз, либо определять политику на уровне крманды, разработка каких модулей будет покрываться тестами, а каких — нет.

                        >>К сожалению нет доказательств, ни моей, ни Вашей теории

                        Зато есть опытные данные. МакКоннел утверждает, что TDD и тесты _уступают_ по отлову багов формальному ревью кода ) У тестов несколько другое назначение — выработка опытным путем будущего API проектируемого компонента.
                          0
                          Тьфу, блин, ниже то же самое написали :(
                            +1
                            >>Боюсь, что невозможно определить, что такое «простая логика».
                            Согласен, это не строго формально.
                            Но у нас это работает лучше чем набор формальных правил которые определяют когда нужно писать тест. Трудно охватить все возможные случаи. Да, можно и на уровне команды принимать такие решения.

                            >>МакКоннел утверждает, что TDD и тесты _уступают_ по отлову багов формальному ревью кода
                            Не вижу препятствий, ничто не мешает нам проводить формальные инспекции кода используя/не используя TDD.
                              0
                              Категорически согласен :) У нас так и есть — и первый пункт, и второй
                        +1
                        Про уборщицу забыли рассказать :)
                          0
                          Странно, я наоборот считал что все сейчас двигаются в сторону разумного упрощения себе жизни.
                            0
                            1) "-o-border-radius" не поддерживается оперой
                            2) всякие фиксы и другие спорные случаи предпочитаю выносить в отдельные файлы. в идеале один для каждого браузера с «особенностями», и подгружается только по мере необходимости (определяя юзер-агент)
                              0
                              ТDD увеличивает издержки не давая взамен соответствующих преимуществ?
                              Вам тоже впадлу тесты писать? ;)
                              Для того, чтобы оценить TDD нужно любой серьезный проект попытаться уложить в срок.
                              Кроме всего прочего TDD сильно дисциплинирует. Я, например, каюсь — ленюсь писать тесты для критической логики, то есть либо все делаю через тесты либо ничего.
                              Думаешь: сейчас вот эту процедурку допилю и сделаю тест… Ага, щщщазз. ;)
                                –2
                                тесты вообще должны писаться другим человеком…
                                  +1
                                  Пруфлинк, или вы фейл.

                                  Вы знакомы c TDD?
                                    –1
                                    открой любую книжку по тестированию по…

                                    ты в тдд действительно пишешь негативные нерегрессионные тесты или ленишься? только честно.
                                      +1
                                      Регресионные тесты у нас пишут тестеры — вкупе с UI и нагрузочными — потому что вручную тестировать слишком трудоемко получается, это очевидно. Интеграционные — совместно разработчики и тестеры — по-другому получается плохо. Unit-test — пишет исключительно разработчик, тот, кто этот unit написал.

                                      Мне кажется, или вы путаете тестирование ПО и unit-тестирование (то, что primary в TDD), проводимое разработчиками?
                                        –2
                                        то есть ты признаёшь, что с негативными тестами у вас никто не заморачивается?

                                        прочитай, хотябы, это: 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
                                          +1
                                          Ну если тестеры это никто, то да, вы правы — у нас ими заморачиваются только эти самые «никто». Что это доказывает?

                                          Встречный вопрос — про негативные тесты какого вида вы спрашиваете? Если про unit-test (а именно о них шла речь в оригинальной статье) — то в TDD не разделяется на positive/negative. Так что в написанных тестах какие-то normal, какие-то (например, тестирование корректной обработки исключений) — negative.

                                          Еще раз говорю, вы смешиваете TDD, упомянутое в статье, и более широкую облать тестирования ПО. Вы еще попросите разработчиков Acceptance Tests писать.
                                            –1
                                            при написании тесткейсов важна систематичность и непредвзятость. у вас этого нет, как следствие — низкое качество тестов.

                                              0
                                              Ок, вам-то оно виднее, чего у нас нет =)
                                    +1
                                    Существуют разные виды тестирования. Обсуждая TDD мы подразумеваем что тесты пишут сами разработчики.
                                      –1
                                      психологию ещё никто не отменял… человек предпочтёт подстроить тест под своё «красивое решение», чем будет фигачить подстраиваясь под требования теста
                                        0
                                        Э-э-э… Просто к сведению — в TDD (которое и обсуждается всеми, кроме Вас) тесты пишутся до кода. О какой подстройке теста под «красивое решение» может идти речь, если этого решения ещё нет?
                                          –2
                                          есть идея как это реализовать… да и подкорректировать тест постфактум — тоже не проблема…
                                            +1
                                            Вы это счас на полном серьезе говорите? Бредогенератор детектед
                                              –2
                                              сними розовые очки…
                                • НЛО прилетело и опубликовало эту надпись здесь
                                    0
                                    Люди, забывают публиковать контекст в котором крутятся.

                                    Как верно замечено все имеет цену. Время=деньги, потраченные на еще один проверку/митинг по идее должно быть оправдано понижением рисков. Если же они и так незначительны то циклы и процедуры есть потеря времени=денег.
                                      +2
                                      Вообще-то цель TDD — отнюдь не в 100%-ном покрытии кода тестами (как это ни удивительно). TDD создавался как способ заставить себя задуматься каждый раз перед написанием чего-то нового — «а что же мне на самом деле надо». Т.е. это скорее инструмент проектирования, чем тестирования. Хотя тесты, конечно, тоже важный плюс :-)

                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                      Самое читаемое