об 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-х были развитые и полезные инфраструктуры для тестов, потому что в этих языках тесты ловят ошибки, которые в других языках ловит компилятор (а также и кучу других ошибок, конечно). Постепенно увлечение тестами перекинулось с этих языков на Джаву итд., без всяких агилей, которые нередко стремятся сейчас представить это как свое достижение.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2009-02-09 09:47 pm (UTC)Очень часто различные полезные течения опошлялись последователями N-ого поколения, копирующими лишь внешние признаки, ритуалы, и превращающие полезные паттерны в ригидные правила.
Так, например, раннее христианство отличается от того, что сформировалось в 5-7 веке, когда сформировался канон.
В то время как одним из ключевых принципов Agile на мой взгляд является необходимость модификации и постоянной подстройки процесса под конкретный проект/команду/сложившуюся ситуацию. (inspect and adapt)
Вы правильно заметили, что Agile определён достаточно расплывчато. Это так, потому что фактически каждая команда имеет свой собственный процесс - и он мутирует с течением времени.
Называют эту сущность отдельным словом с тем, чтобы отделить от традиционных/ригидных методологий - водопадной модели, итерационной (с маленькими водопадами в каждой итерации), с одной стороны, и от недисциплинированной, хаотической разработки, с другой.
Ригидный agile (оксюморон) - попытка воспринять какие-то практики как серебряные пули, в то время как agile - это скорее набор пулек из разных плюс общие принципы их использования. А точность каждого конкретного выстрела зависит от конкретного стрелка.
Маркетинговая привлекательность баззвордов, конечно, играют отрицательную роль. Знакомый работал в одной аутсорсинговой конторе и заказчики требовали Agile. В результате был имплементирован некий дубовый процесс, заключающийся главным образом в том, что не было предварительного проектирования. А других практик, которые делают это возможным, внедрено не было. Команды как целостности не было. И главное, не было предусмотрено адаптации процесса (да и некому было это делать и брать за это ответственность - команды же нет, есть отдельные индивидуумы). В результате у знакомого, естественно, сложилось отрицательное мнение об Agile.
У Agile есть две стороны - инженерные практики и практики командной работы/управления. Вы в этом посте затронули только инженерные практики (которые, как я понял, вы любите, если без фанатизма). Интересно, как вы относитесь к неинженерным практикам (Iteration Planning Meeting, Daily Scrum Meeting, Retrospective и т.д.)?
Перепостил отдельным постом
Date: 2009-02-09 10:28 pm (UTC)