Да, сама концепция «запустил набор тестов-получил ответ, где баги» мне нравится.
Во многих случаях действительно получалось, что изменение в одной части системы нарушало что-то в другой,
но становилось это видно только тогда, тогда добираешься до проверки той другой части.
Вот только подскажите, как бы ее начать применять и не забить на полпути? :)
Еще одна проблема, которая возникает при внедрении TDD — непонятность с объемом:
если есть 25 объектов, и у каждого по 6-7 функций, то выходит, что нужно минимум 150 тестов, не учитывая
комплексных, которые работают с несколькими объектами или функциями.
Как быть?
Или где об этом почитать :)? (не теорию, а именно практические аспекты применения)
Все используем, но по поводу тестов: для многих функций мы не пишем тесты только потому, что написание теста занимает столько времени, за сколько можно написать еще пару-тройку функций :)
В основном, если пишем тесты, то для, скажем так, «вычислительных функций», в которых зашит некий алгоритм с достаточно сложной логикой.
Т.е. если функция выбирает данные с базы и возвращает некий объект, то для такой функции тесты, по-моему, излишни.
Хотя, с точки зрения TDD это, может и неверно, но все-таки надо применять гибкий подход: иногда писать тесты, а иногда и нет :)
Писали, кстати, на ASP.NET, но как и во многих случаях, когда проект реализуется на ASP.NET, забыли про пользователей:
ASP.NET часто генерит кучу ненужного кода.
Вот, к примеру, хидден-поле VIEWSTATE.
Уверен, что 99% хранимой во вьюстейте инфы им абсолютно не надо.
И вроде бы используют аяксные библиотеки, но что-то их действия мало заметно.
Мы лично после перебора многих cms решили писать свою.
Причины:
1) большинство цмс ориентированы на то, чтобы на их базе создать готовый сайт,
при минимуме кодинга, т.е. это скорее CMF, чем CMS (тот же Друпал)
А заказчик все равно хочет какой-то изврат, и все равно приходится писать.
2) сложность хороших cms (cmf)
Действительно, если заказчику нужен только сайт из десяти страниц и загрузка прайса,
то проще сверстать это все в хтмл и написать пару php функций.
3) непонятный для заказчика бэкэнд
Не все заказчики привыкли мыслить тегами или новостями. Им проще — «А как изменить информацию на этой странице?»
Потому мы написали бэкэнд с типичными для заказчика понятиями (раздел, категория т.п.) и
ядро (парсинг урлов, выборка данных т.п.).
А пользовательскую часть каджый раз делаем заново, под определенную структуру сайта заказчика,
и в редактировать он может в пределах того, что разрешено. Допустим, если в разделе «Новости» не должно быть подкатегорий,
то из бэкэнда и не получится добавить категорию. Пользовательская часть тоже, соответственно, отображает новости без категорий.
Также без шаблонизаторов, или, скажем, PHP шаблоны. По типу: <b><?=$item->Title;?></b>
В итоге получили:
— удобно для заказчика: он видит бэкэнд в точности повторяющий структуру сайта;
— удобно для нас: надо писать только пользовательскую часть, фактически, вывод информации;
— ненагруженно, быстро, присутствуют только основные функции.
Фактически мы получили просто свой небольшой CMF, который частично упрощает работу.
Если про техническое — то напрямую зависит от камеры.
А если про сюжетно-композиционное — то да, от фотографа.
И то, с такой камерой и хорошими объективами можно добиться таких фотографий,
которых не сделаешь, к примеру, всякими д40.
ГРИП, передача деталей, динамический диапазон и т.п.
Потому лучше иметь и камеру хорошую, и руки :)
Во многих случаях действительно получалось, что изменение в одной части системы нарушало что-то в другой,
но становилось это видно только тогда, тогда добираешься до проверки той другой части.
Вот только подскажите, как бы ее начать применять и не забить на полпути? :)
Еще одна проблема, которая возникает при внедрении TDD — непонятность с объемом:
если есть 25 объектов, и у каждого по 6-7 функций, то выходит, что нужно минимум 150 тестов, не учитывая
комплексных, которые работают с несколькими объектами или функциями.
Как быть?
Или где об этом почитать :)? (не теорию, а именно практические аспекты применения)
В основном, если пишем тесты, то для, скажем так, «вычислительных функций», в которых зашит некий алгоритм с достаточно сложной логикой.
Т.е. если функция выбирает данные с базы и возвращает некий объект, то для такой функции тесты, по-моему, излишни.
Хотя, с точки зрения TDD это, может и неверно, но все-таки надо применять гибкий подход: иногда писать тесты, а иногда и нет :)
Но страница у них вышла более 700 кб.
о_О
Писали, кстати, на ASP.NET, но как и во многих случаях, когда проект реализуется на ASP.NET, забыли про пользователей:
ASP.NET часто генерит кучу ненужного кода.
Вот, к примеру, хидден-поле VIEWSTATE.
Уверен, что 99% хранимой во вьюстейте инфы им абсолютно не надо.
И вроде бы используют аяксные библиотеки, но что-то их действия мало заметно.
Причины:
1) большинство цмс ориентированы на то, чтобы на их базе создать готовый сайт,
при минимуме кодинга, т.е. это скорее CMF, чем CMS (тот же Друпал)
А заказчик все равно хочет какой-то изврат, и все равно приходится писать.
2) сложность хороших cms (cmf)
Действительно, если заказчику нужен только сайт из десяти страниц и загрузка прайса,
то проще сверстать это все в хтмл и написать пару php функций.
3) непонятный для заказчика бэкэнд
Не все заказчики привыкли мыслить тегами или новостями. Им проще — «А как изменить информацию на этой странице?»
Потому мы написали бэкэнд с типичными для заказчика понятиями (раздел, категория т.п.) и
ядро (парсинг урлов, выборка данных т.п.).
А пользовательскую часть каджый раз делаем заново, под определенную структуру сайта заказчика,
и в редактировать он может в пределах того, что разрешено. Допустим, если в разделе «Новости» не должно быть подкатегорий,
то из бэкэнда и не получится добавить категорию. Пользовательская часть тоже, соответственно, отображает новости без категорий.
Также без шаблонизаторов, или, скажем, PHP шаблоны. По типу: <b><?=$item->Title;?></b>
В итоге получили:
— удобно для заказчика: он видит бэкэнд в точности повторяющий структуру сайта;
— удобно для нас: надо писать только пользовательскую часть, фактически, вывод информации;
— ненагруженно, быстро, присутствуют только основные функции.
Фактически мы получили просто свой небольшой CMF, который частично упрощает работу.