об 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: 2008-12-29 10:32 am (UTC)Вредная - что? Гниль?
no subject
Date: 2008-12-29 10:34 am (UTC)(no subject)
From:(no subject)
From:no subject
Date: 2008-12-29 10:36 am (UTC)no subject
Date: 2008-12-29 10:37 am (UTC)(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2008-12-29 11:24 am (UTC)no subject
Date: 2008-12-29 11:37 am (UTC)no subject
Date: 2008-12-31 12:56 am (UTC)no subject
Date: 2008-12-29 11:58 am (UTC)С одной стороны - есть набор методологий и разнообразная жизнь. Подразумевается, что под конкретный проект всегда можно подобрать наиболее подходящую методологию, универсальных решений не бывает.
С другой стороны, практически не бывает универсальных людей, которые одинаково хорошо владеют всеми практиками, чтобы непредвзято выбирать в каждом конкретном случае - всегда человек тяготеет к какому-то определённому подходу и знает его лучше. Не говоря уже про маркетинговые и прочие денежные факторы, не дающие менеджеру развернуться.
Вот я например использовал всегда только что-то waterfall-образное, прибегая только к отдельным XP/agile практикам по обстановке и очень редко. Но это по большей части было обусловлено обстоятельствами и я понимаю, что по-настоящему я agile не знаю и подозреваю, что от этого сам выбираю не ту методологию, когда выбор возможен.
no subject
Date: 2008-12-29 01:21 pm (UTC)Но вот тут мы как-то разговаривали с кандидатом, который пришел из большой конторы, и в том числе очень подробно обсуждали с ним наш development process. В конце он сказал - "мне так нравится что у вас такой зрелый agile process!". Но позвольте, ответили мы, какой нафиг agile? Ну как же, вы же говорите, что у вас любой программист увидевший проблему в дизайне может все остановить, созвать митинг и попытаться с коллегами найти решение. Но ведь это же просто здравый смысл, сказали мы, никакой agile. А он и отвечает - да вы что, у нас бы надо было сообщить менеджеру чтобы он на следующем заседании steering committee обсудил бы проблему с архитектором и тот бы тогда подготовил презентацию для старшего архитектора и .. и бла-бла
Вот тогда я понял почему многие настолько хватаются за agile. Ну действительно, по сравнению с таким это действительно революция и лучшая вещь после sliced bread
no subject
Date: 2008-12-29 01:55 pm (UTC)но тут уж всё зависит от общей вменяемости высшего менеджмента
(no subject)
From:Agile
Date: 2008-12-29 01:55 pm (UTC)no subject
Date: 2008-12-29 02:21 pm (UTC)а можно "баззвордизм" перевести? 1 ссылка в гугле попалась, но мало помогла.
no subject
Date: 2008-12-29 02:23 pm (UTC)no subject
Date: 2008-12-29 03:13 pm (UTC)Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Не могли бы Вы пояснить, какой из этих пунктов вы считаете вредным и почему?
no subject
Date: 2008-12-29 07:11 pm (UTC)(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2008-12-29 03:30 pm (UTC)no subject
Date: 2008-12-29 06:10 pm (UTC)no subject
Date: 2008-12-29 06:24 pm (UTC)no subject
Date: 2008-12-29 06:47 pm (UTC)no subject
Date: 2008-12-29 07:30 pm (UTC)(no subject)
From:(no subject)
From:no subject
Date: 2008-12-29 09:10 pm (UTC)Мне не понятно веяние, согласно которому смешиваются понятия TDD и агил. Агил хорош сам по себе и в определенных задачах. Без сомнения хорош в эволюционном макетировании, что прекрасно видно, например, в ruby on rails. Юнит-тесты хороши для библиотек и протоколов, нет сомнений. Но хороши, пока не начинают влиять на дизайн программы. Это я к тому, что без проектирования хорошие юнит-тесты, покрывающие каждый сценарий не появятся, а это уже не агил никакой. Так что TDD хорош сам по себе, когда закрывает именно вопрос кодирования сложных сценариев и автоматов, но не начинает претендовать на что-то похожее на парадигму программирования. Действительно, TDD может стать спасением, если язык сильно динамический и плохо типизируемый. И мне кажется, что в яву и C все это переползло по недостатку в этих языках большого количества простых типов на всякий случай жизни. Вот и приходится по десять раз парсить строки, проверять соответствие между запросами и схемой БД, хитрым образом сравнивать даты и т.д. и т.п.
no subject
Date: 2008-12-30 05:20 am (UTC)Юнит-тесты не покрывают сценарии использования, юнит-тесты покрывают API.
(no subject)
From:no subject
Date: 2008-12-30 12:28 am (UTC)Не согласен с Вами насчёт agile. У нас в конторе начали вводить эту методологию около года назад. В начале процесса, многие включая меня были уверены что это туфта по тем причинам которые вы тут написали. По прошествии года я полностью изменил свое мнение. Считаю что в нашей ситуации это отличная штука, если относиться к ней без фанатизма. То есть там куча дырок, но применяя common sence можно добиться хороших результатов. Может быть вы скажете что это никакой не Agile а просто обычный здравый смысл, но мы почерпнули эти принципы именно из этой методологии. И Вообще какая разница как называть.
Расскажу про свой опыт. Речь идет об огромном проекте в котором задействованы сотни /тысячи людей, десятки компонент и аппликаций с огромным количеством не тривиальных зависимостей, очень много людей на разных уровнях владеющих какой-то частью информации. Очень мало людей видяших общую картину.
Принцип недалёкого планирования и коротких итераций.
Раньше одни дизайнеры писали общую картину, передавали на более конкретние задачи другим дизайнерам, которые в свою очередь делили дальше. И так несколько ступенек. Весь процесс занимал месяцы. каждая группа/компонента получала requirements, писала design на несколько месяцев вперед и писался код. В процессе почти невозможно было понять что будет в конце. Когда код был готов и прошел тестирование он попадал к клиентам (другая компонента внутри фирмы) и все оказывалось не то и не так. Еще куча времени уходит чтобы понять, что все таки надо переделать и вернуть назад. А те уже продолжают дальше, дизайн то у них написан. С тестами таже проблема, начинауются когда почти всё готово, переделывать дорого, программисты уже пишут дальше и находятся в совсем другом контексте. Короче стандартный waterfall.
Сегодня планы идут на месяц вперед. Этот месяц вклучает в себя полный development cycle вклучая testing и adoption. Естественно есть планы и дальше но они совсем не детальние. По факту за этот год все разы когда мы примерно намечали что-то на следующую итерацию заранее, это кардинально менялось когда доходило до дела. По моему это огромный плюс что мы с такой легкостю можем менять планы. Естественно мы за это платим тем что иногда приходится переписывать, но это редкость. Все это благодоря тому что и наши клиенты (другие компоненты) не строят далеких планов, а только обшее направление и тому что у нас почти полная автомация тестов. Всё поделено на очень маленькие куски, так чтобы каждый кусок имел конкретную пользу для клиента (deliverable). Это позволяет делать очень частую интеграцию с другими компонентами и вылавливать дыры рано. Деление на такие deliverables требует очень много нудной работы, но это стоит того.
Вообще сама методология на первый взгляд отнимает кучу времени, но это всё возвращается.
Второй плюс это полная видимость прогресса. Планируя итерацию принимается во внимания каждая известная мелочь на которую тратится время (до резолюции часов), заместо всех этих примерных бафферов. Все делится на очень мелкие таски и все ежедневно отмечают индивидуальний прогресс на общем графе. Тоже
требует усилий но результат поразительний. У людей которые видят групповое продвижение ежедневно повышается мотивация.
Еще плюс, это то что каждая команда сама решает что именно она сделает в ближайшую итерацию. Это повышает проактивность и мотивацию.
На самом деле это только основные принципы и есть еще куча всего.
Итересно почему у вас такое мнение? Пробовалили ли вы работать по Agile принципам?
no subject
Date: 2008-12-31 01:19 am (UTC)Вы описали систему, в которой ни у кого не было понимания того, как на самом деле все работает, а конкретные планы строились после прохождения через несколько уровней "дизайнеров". Вы совершенно верно предсказали мою реакцию: разбить такую систему на много относительно независимых кусков, каждый из которых имеет свою функциональность и достаточно компактен, чтобы его могли обозреть сами программисты - здравый смысл. Это - плюс полная автомация тестов - самое главное, мне кажется, из тех изменений, что вы сделали, но я не считаю их характерными именно для agile, пусть их так и назвали в данном случае. Типично agile'вская часть - планы только на месяц вперед, полный цикл разработки, который должен уместиться в этот месяц - далеко не так важен, как перечисленное выше, и на мой взгляд (естественно, я не знаю вашей специфики) может скорее влиять негативно, чем позитивно. То, что планы можно менять с легкостью - это прекрасно, но если правильно наладить возможность сменить планы - главным образом, дать контроль над этой возможностью людям, которые действительно понимают систему, и не ограничивать ее жесткими рамками - то не проблема менять планы и в середине трехмесячного цикла, скажем; и цикл этот вовсе необязательно всегда должен включать запуск у клиента.
no subject
Date: 2008-12-30 11:12 am (UTC)no subject
Date: 2008-12-31 01:05 am (UTC)no subject
Date: 2008-12-30 02:50 pm (UTC)no subject
Date: 2009-02-09 09:14 pm (UTC)Программист может научиться качественно принимать решения о том, что тестировать, только после того, как покрыл много кода тестами "по принуждению". Потому что изначально веришь своему коду гораздо больше, чем надо и надеешься, что запустишь - и если есть баги, они сразу себя покажут. Потом да, можно понять, что, скажем тесты на сеттеры и геттеры бессмысленны, появиться чутьё (на основе опыта, когда человек видел, какого рода тесты склонны падать).
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)no subject
Date: 2009-02-09 11:08 pm (UTC)А TDD сам по себе тоже хорош. Пользуйтесь на здоровье
no subject
Date: 2009-02-09 11:46 pm (UTC)seoonlyblog
Date: 2011-04-09 07:03 am (UTC)karen millen outlet shop
Date: 2011-11-07 02:43 pm (UTC)http://eco-kompromat.ru/phpBB3/memberlist.php?mode=viewprofile&u=4691
http://www.irishfarming.ie/forum/profile.php?mode=viewprofile&u=119275
http://www.pixdecolombia.com/kodakfilm/memberlist.php?mode=viewprofile&u=9912
http://www.1dryeyes.com/DryEyeForum/index.php?action=profile;u=95502
Православная женщина приглашает!
Date: 2011-11-22 11:31 pm (UTC)Форум для православных людей. Работаем уже давно, хороший дружный коллектив.
Помогаем советами, утешаем в скорби. Делимся новостями и впечатлениями.
Может быть и Вы к нам ? ))
[b]Читайте на Нашем сайте:[/b]
[url=http://www.isfarinka.ru/news.php?item.124.11]молитва о замужестве матроне[/url]
[url=http://www.isfarinka.ru/e107_plugins/forum/forum_viewtopic.php?7413.0]40 лет устала быть одна[/url]
[url=http://www.isfarinka.ru/comment.php?comment.news.624]августовская божия матерь покровительница[/url]
[url=http://www.isfarinka.ru/e107_plugins/forum/forum_viewtopic.php?3682]милосердия двери молитва[/url]
[url=http://www.isfarinka.ru/news.php?item.571.11]православие молитвослов акафист пресвятой богородицы перед иконой прибавления ума[/url]
[url=http://www.isfarinka.ru/news.php?extend.630.11]молитва святого спиридона[/url]
[url=http://www.isfarinka.ru/news.php?item.729.41]икона непобедимая победа...фото[/url]
[url=http://www.isfarinka.ru/e107_plugins/forum/forum_viewtopic.php?1258]выцерковление[/url]
karen millen
Date: 2011-12-14 01:38 am (UTC)Use pelt or otherwise simply individual selection, wherever you adore furs, true or even bogus made
Date: 2011-12-21 04:26 am (UTC)[url=http://www.secretswingersociety.com/member/blog_post_view.php?postId=2028 ]http://www.matchormingle.com/member/blog_post_view.php?postId=8671 [/url]
If you're acquainted along with the North Experience Jackets,you should know essentially the good commencing level involving outlet.
[url=http://www.desidost.in/member/blog_post_view.php?postId=7056 ]http://www.certifiedpersonnel.biz/member/blog_post_view.php?postId=5239 [/url]
Statues regarding subjective aspects and creative accessories.
[url=http://ondemandlove.com/member/blog_post_view.php?postId=7471 ]http://www.malibunetwork.com/member/blog_post_view.php?postId=29050 [/url]
Bride-to-be could be the wedding party picture of the extremely beautiful scenery series, not only the marriage landscape, lovely marriage ceremony, bride can be the character Oh yea, consequently wedding brides inside choice of bridal gowns being classy and also beautiful, gentle graceful.
[url=http://thatshowimakeit.com/index.php?p=blogs/viewstory/97146 ]http://www.easycasualdate.nl/member/blog_post_view.php?postId=3673 [/url]
Dior Homme menswear kind of recent years has elevated the subversion with the males standard dress concepts, changing duration fits, this coming year has taken us all the actual mosaics of the buckskin along with wool matches.
[url=http://tsuixu.com/index.php?p=blogs/viewstory/164950 ]http://trendyloop.com/index.php?p=blogs/viewstory/220941 [/url]
Since Reiss go shopping marketed each and every moment, 1000 parts for the last framework of the apparel is sold out, produced a lot more than A hundred and fifty,Thousand kilos.
[url=http://www.buzzingnetsite.com/index.php?p=blogs/viewstory/84910 ]http://timepasssite.com/index.php?p=blogs/viewstory/165597 [/url]
Classic along with eternal is almost a set of the exact same twin babies, in the field of style, the actual classic is simple along with fast, the classic Audrey Hepburn with the black outfits, now could be to not be fashionable model, Museum or perhaps will have to live eternally inside the heads associated with enthusiasts.
[url=http://www.hug2love.com/member/blog_post_view.php?postId=11165 ]http://javanbook.javan.cc/index.php?p=blogs/viewstory/18726 [/url]
condo, took to go to Japan to wait the particular 43rd planet gymnastics title journey.
[url=http://www.phpchatsoftware.com/skadate/member/blog_post_view.php?postId=7681 ]http://relatie.mobi/member/blog_post_view.php?postId=9565 [/url]
It really is windproof, water-resistant, and really breathable delicate shell jacket so it may be utilised like a layer, a shell, or a stand-alone jacket.
[url=http://www.comeplaywithme.net/member/blog_post_view.php?postId=32553 ]http://spitters.de/index.php?p=blogs/viewstory/28624 [/url]
HyVent is often a special content that makes use of a polyurethane coating that consists of a tri-component, multi-layer system.
[url=http://thing4cars.nl/index.php?p=blogs/viewstory/192510 ]http://bigfoot.ch/index.php?p=blogs/viewstory/152262 [/url]
Well, you heard right, zero automobile any time generating cap experienced by now seemed.
chanel sale
Date: 2011-12-30 12:29 am (UTC)