Мною замечено что люди, последнее время, все чаще стали очень категоричны: нужно создавать юнит-тесты для всего(XP TDD), валидный CSS превыше всего(W3C validity), standup-митинг нужен даже с уборщицой(Scrum)…
Здесь я предлагаю Вам порассуждать на тему Best working practices versus жизнь!
Типичный случай: среднего уровня проект, логика достаточно простая, у вас короткие итерации.
И у Вас низкая цена ошибки, то есть вы не пишите банковское приложение где есть шанс потерять миллионы в случае ошибки. Тут все так: кто-то нашел ошибку, написал Вам, вы сказали спасибо и исправили.
Я с уважением отношусь к Extreme Programming(XP), но не являюсь сторонником TDD [Test-driven development] где сначала нужно создавать тесты которые описывают требования к коду, до написания самого кода, таким образом нужно создать тест для каждой фичи.
На мой взгляд ТDD увеличивает издержки не давая взамен соответствующих преимуществ (кроме проектов с высокой стоимостью ошибок). Разумным мне кажется найти баланс и использовать Unit-тесты для критической логики приложений.
“Друзья, как же так, у вас не валидный CSS на страницах: ...”
из письма в нашу компанию от пользователя сервиса.
Да, я очень люблю W3С валидаторы [W3C validators] но когда сталкиваюсь с удобством против W3C валидности выбираю удобство.
Пример стиля который создаёт закругленные края для div элементов:
Да, мне известны остальные 256 способов сделать это с валидным CSS… но этот очень приятен для взгляда.
Мне интересны любые случаи где перед вами стояла дилемма: best practice/life?
Здесь я предлагаю Вам порассуждать на тему 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?