об agile и tdd (программистское)
Dec. 29th, 2008 12:04 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
avvaЭта запись будет интересна только программистам.
Свою точку зрения на Agile programming и TDD (Test-Driven Development), которую несколько раз в прошлом высказывал в комментариях, выношу в отдельную запись.
Agile, на мой взгляд - почти целиком вредная гиль. Даже в тех случаях, когда в рамках агиля говорят что-то разумное (а это случается, потому что агиль невероятно расплывчат и слабо-определен, будучи в основном феноменом маркетинга, и его можно повернуть в разные стороны), это все равно часто компрометируется съедающим мозг баззвордизмом и приводит к ердуне.
TDD я воспринимаю как крайний случай такой вообще говоря невероятно полезной штуки, как активное и тщательное тестирование (главным образом я говорю о юнит-тестах). Тесты - потрясающе полезная штука, когда их принимают всерьез; поддерживание юнит-тестов для всего вокруг высвобождает много времени и сил на осмысленные занятия, позволяет писать код смело, быстрее и свободнее, делает возможным активный рефакторинг.
TDD, как радикальный вид серьезного юнит-тестинга, на мой взгляд бывает очень полезен, но не всегда универсально применим. Я не убежден в этом до конца, но мне кажется (и встречались такие случаи), что есть проекты и ситуации, когда TDD просто "не идет", и лучше сначала заняться чем-то вроде зондирующего программирования: поиграть с несколькими основными возможностями, получить с помощью реального, пусть и очень простого и скелетного, кода лучшее представление о том, что мы собственно хотим сделать и какое поведение ожидаем от данного куска, а потом добавить к нему тесты. Если вместо этого силой тянуть TDD, может получиться медленно и более коряво. Так мне кажется (хотя опыта и наблюдений не так много, чтобы делать уверенные выводы). С другой стороны, несомненно есть ситуации, в которых TDD может быть полезен.
Я бы сказал, что активное и тщательное тестирование на порядок важнее выбора "TDD или не TDD".
Из-за того, что TDD часто представляют как часть agile (или extreme programming, предыдущей инкарнации той болезни, которая сейчас называет себя agile), литература по нему и энтузиасты его часто оказываются заражены агилевским баззвордизмом и радикализмом (т.е. считают, что нужно TDD всегда и везде, и тот, кто решил в каком-то конкретном случае написать сначала код, а потом тест к нему - всегда предатель и ренегат). Я же вижу интерес к тестированию как что-то, что здоровым образом выросло независимо от моды на всякие агили. У очень динамических с точки зрения типизации языков (perl, python, Smalltalk, Lisp итд.) еще с середины 90-х были развитые и полезные инфраструктуры для тестов, потому что в этих языках тесты ловят ошибки, которые в других языках ловит компилятор (а также и кучу других ошибок, конечно). Постепенно увлечение тестами перекинулось с этих языков на Джаву итд., без всяких агилей, которые нередко стремятся сейчас представить это как свое достижение.
Свою точку зрения на Agile programming и TDD (Test-Driven Development), которую несколько раз в прошлом высказывал в комментариях, выношу в отдельную запись.
Agile, на мой взгляд - почти целиком вредная гиль. Даже в тех случаях, когда в рамках агиля говорят что-то разумное (а это случается, потому что агиль невероятно расплывчат и слабо-определен, будучи в основном феноменом маркетинга, и его можно повернуть в разные стороны), это все равно часто компрометируется съедающим мозг баззвордизмом и приводит к ердуне.
TDD я воспринимаю как крайний случай такой вообще говоря невероятно полезной штуки, как активное и тщательное тестирование (главным образом я говорю о юнит-тестах). Тесты - потрясающе полезная штука, когда их принимают всерьез; поддерживание юнит-тестов для всего вокруг высвобождает много времени и сил на осмысленные занятия, позволяет писать код смело, быстрее и свободнее, делает возможным активный рефакторинг.
TDD, как радикальный вид серьезного юнит-тестинга, на мой взгляд бывает очень полезен, но не всегда универсально применим. Я не убежден в этом до конца, но мне кажется (и встречались такие случаи), что есть проекты и ситуации, когда TDD просто "не идет", и лучше сначала заняться чем-то вроде зондирующего программирования: поиграть с несколькими основными возможностями, получить с помощью реального, пусть и очень простого и скелетного, кода лучшее представление о том, что мы собственно хотим сделать и какое поведение ожидаем от данного куска, а потом добавить к нему тесты. Если вместо этого силой тянуть TDD, может получиться медленно и более коряво. Так мне кажется (хотя опыта и наблюдений не так много, чтобы делать уверенные выводы). С другой стороны, несомненно есть ситуации, в которых TDD может быть полезен.
Я бы сказал, что активное и тщательное тестирование на порядок важнее выбора "TDD или не TDD".
Из-за того, что TDD часто представляют как часть agile (или extreme programming, предыдущей инкарнации той болезни, которая сейчас называет себя agile), литература по нему и энтузиасты его часто оказываются заражены агилевским баззвордизмом и радикализмом (т.е. считают, что нужно TDD всегда и везде, и тот, кто решил в каком-то конкретном случае написать сначала код, а потом тест к нему - всегда предатель и ренегат). Я же вижу интерес к тестированию как что-то, что здоровым образом выросло независимо от моды на всякие агили. У очень динамических с точки зрения типизации языков (perl, python, Smalltalk, Lisp итд.) еще с середины 90-х были развитые и полезные инфраструктуры для тестов, потому что в этих языках тесты ловят ошибки, которые в других языках ловит компилятор (а также и кучу других ошибок, конечно). Постепенно увлечение тестами перекинулось с этих языков на Джаву итд., без всяких агилей, которые нередко стремятся сейчас представить это как свое достижение.
