Мы все хотели установить какой-нить форум внутренний. Но наш АйТи ограничил нас до MS SharePoint. Там есть форум, но посты надо писать в HTML коде.  Просто афигеть. В каком веке живем?

Паша, а есть ли что-нибудь бесплатное похожее на вышеупомянутую тулзу? Очень хочется ...

IMHO, во внутреннем форуме вообще смысла нет. Если очень хочется, то есть вполне легальные обходные пути. Установка любого форума на свою рабочую машину, или использование Groove, например.

http://www.reviewboard.org/

Собственно расскажу о своём (не очень большом) опыте разработки в соответствии с процессами...

1. Одна из контор, в которых я работал использовала CMMI...
Типичная вещь - code review...перед каждым коммитом собираются 3-5 человек, и высказывают тебе все замечания, которые в итоге оформляются как faults...собственно после фикса всех замечаний и делается коммит, который Configuration Manager-ы затем сливают с мэйн-бранчем(хотя это, может быть, ClearCase-specific task). Из плюсов такого подхода могу отметить то, что как правило замечания, действительно, как правило, делаются существенные (при условии, что никто не забил на подготовку к ревью). Из минусов - в крупном проекте (over 900 000 LOC) - зачастую девелоперы забивают на подготовку, и выдумывают фолты прямо по ходу ревью. В результате существенные косяки иногда легко пролетают ревью.

2. Во второй работает Agile...
Как таковая, разработка по TDD не используется, Unit Test-ы пишутся, но уже после реализации функционала. 
Continious integration в виде билда после каждого коммита, а также каждую ночь на билд машине собираются все проекты.
Сам я в Agile-методологии, можно сказать, новичок, так что ничего более путного сказать тут не могу  

Поставил style cop, разве что...наверно скоро руки дойдут до его настройки...

Вот именно. А то ругается на всякую хрень. Я например константы в CamelCase ну никак не приму. ИМХО, константы должны быть в ALLCAPS. Да и потом все эти префиксы приватных полей тоже не люблю. Хотя в нашей конторе стандарты говорят писать myField. Лучше писать простые и небольшие классы, тогда и отпадет нужда в этих различиях. Действительно, если и методы короткие, то ничего не стоит отличить local variable от class field, даже если оба написаны lowerCamelCase, а вот всякие префиксы _field, myField, m_field ... только делают код противным. ИМХО конечно.

Пишите короткие классы с короткими методами, и нужда во всяких walkaround-ах просто отпадет сама собой.

Его бесполезно включать на существующих проектах. Единственный вариант - в следующем проекте прикрутить заранее.

Continious integration вполне и без agile работает. А если пишете тесты после кода, то это точно не Agile. Agile это скорее общий подход к процессу, чем набор инструментов. Типа веселые офигенно мотивированные профессионалы очень круто и бодро пишут тру-софтину, без всякой там документации, ведь рабочий продукт круче, и кастомер с ними на той же волне. И, кстати, по Agile - если есть рабочий продукт - то тесты и документация не нужны, ведь все уже работает. Шутка, но в ней доля правды.

У нас peer code review, уже после коммита. Хотя, для >100k LOC строгие ревью вполне оправданы.

neutrino, в StyleCop можно свои правила писать. Кстати, стандартные правила - это просто уточненный Design Guidelines for Class Library Developers

Ну почему же, есть ненулевая вероятность, что все соблюдали гайдлайны по максимуму 




В последнее время, я всё чаще слышу от коллег фразы типа "неплохо бы попробовать TDD", но пока это только слова.



Так топик и процессы затрагивает вроде как 

Ну почему же. Специально для этого сделана утилитка ExcludeStyleCop, которая вырубает проверку в уже существующих файлах, а проверяет только новые (скажем так). Скчать ее сорцы можно на странице проекта.
Что она делает -- добавляет атрибуты ко всем сорцам в файле проекта. Новые файлы создаются без этого атрибута и поэтому участвуют в анализе. Позднее, как команда присмотриться к копу, эти атрибуты можно постепенно убирать.


Вот начал с ерунды, а потом себя же опроверг.
Agile к тестам никакого отношения не имеет. Вообще-то ведется очень много спрорв что такое Agile и что можно им считать, а что нет. 
ИМО, самые главные принципы Agile прописаны в его манифесте. 

Ни слова о тестах. Так же ни слова об отказе от документации и проч. Здесь просто выставлены приоритеты (просто примеры): 
Зачем нам крутая платформа разработки, модный процесс, CI сервер, ... если каждый из разработчиков что-то там ваяет втихаря?
Зачем нам тесты и документация, если нет работающего ПО? 
Зачем указывать на следование контракту, если заказчик недоволен?
Зачем следовать плану, который уже месяц назад потерял актуальность?



Наоборот, есть ненулевая вероятность того, что разработчики устанут и не будут обращать на них внимание.


Как человек, который применял его около полугода скажу: в большинстве случаев бесполезная трата времени и сил.
ИМО, TTD есть смысл применять только для функциональности, которую ты не совсем представляешь как реализовывать. Т.е. как метод проектирования.
Сами же тесты нужны либо для критической функциональности (высокая цена ошибки -- очень редко бывает) либо для функциональности в которой ты не совсем уверен.


СУВ, ivashkanet

Это сообщение отредактировал(а) ivashkanet - 6.11.2009, 10:20

Так давай, делись деталями процесса  Или делись полным списком инструментов. Т.к. TDD, CI и прочее - это инструменты, которые почти никакого отношения к процессу не имеют.


Там же была фраза про шутку, нет?
Сам по себе манифест Agile, IMHO, это манифест здравого смысла. А про мотивированных девелоперов и проч - это обычное поверхностное понимание Agile. Опять же IMHO. Потому что когда начинающий мененджер видит "Работающее ПО, чем исчерпывающая документация", он читает его как "все ресурсы на написание кода и новых фич, 0 ресурсов на документацию". И дальше у него в мозгу возникает цепочка:
- ресурсы всегда заранее ограничены
- всегда есть запросы на новые фичи (если проектом кто-то пользуется)
- всегда есть выбор - сделать новую фичу, или задокументировать существующий кусок.
- лучше работающее ПО, чем исчерпывающая документация + реагирование на изменения, чем следование плану
И он решает что надо делать yet another feature, а документация подождет.

Проблема в том, что манифест в чистом виде говорит "лучше", но не говорит насколько. Что бы ты, как мененджер, выбрал
1. Проект с 100 реализованными фичами, без документации
2. Проект с 99 реализованными фичами, с полноценной документацией и ровной архитектурой


Может ты просто не умеешь его готовить?  Например, почти все начинают при TDD писать Unit-тесты, что действительно бесполезная трата времени.
IMHO (надо наверное в подпись вынести), TDD бесполезно применять одному, и не очень приятно применять в чистом виде вообще. 

Тесты окупают себя при:
- Хоть немного нетрививальном функционале
- Команде из более чем 2-х человек, с хоть какой-то текучкой
- Выделении времени на рефакторинг
- Наличии test-friendly фреймворка
- При потециальном росте проекта в будущем.

Писать тесты под мелкое win-приложение для одного юзера - бесполезное дело. Не писать тесты для средних размеров web-приложения - очень серьезная ошибка.

Еще одна неочевидная (IMHO) вещь - тест начинает окупать себя не в момент написания. PROFIT приходит когда он вдруг падает при сборке билда, и кривой билд не попадает к QA.


Разработчик не может охватить стоимость ошибки полностью. Стоимоть функционального бага, попавшего в билд это стоимость
- ручной проверки и обнаружения
- прогонки бага через bugtracker, поиска виновника
- время фикса
- повторной сборки билда

Цена ошибки в функционале высока вообще всегда, и обычно превышает дневную ЗП разработчика. 

Я вообще никогда не уверен полностью в функциональности, потому что видел как тривиальные баги заворачивались по 3-4 раза. Разработчики склонны переоценивать свой скилл по написанию безбажного кода, и вообще склонны переоценивать свою роль в создании софта (IMHO 

Добавлено @ 21:22
PS Спасибо за ExcludeStyleCop 

Это сообщение отредактировал(а) PashaPash - 6.11.2009, 21:23

И то и другое подпадает под условия подписанного NDA 

Абсолютно не согласен. Как уже было сказано - используемый подход к написанию тестов и аджайл не особо связаны.


Ну.. вообщем, да, но, если речь не идёт о большом рефакторинге продукта или изменении корневых фич. Аджайл - это принцип облегчённого процесса разработки, но всё-таки не принцип "давай-давай быстрей писать!" 


ИМХО, TDD - это зло. В чистом виде, по крайней мере. Впрочем, как и любая крайность...


  


Ээ.. Что-то я не понял. Во-первых, я не мыслю TDD без юнит-тестов. А, во-вторых, я не считаю, что юнит-тесты - это бесполезная трата времени.


Если речь про юнит-тесты - то:
1. Само собой проект должен быть не маленьким.
2. Само собой должен быть тест-фреймворк (а как вообщше иначе?!).
Но, самое главное, когда ИМХО полезны тесты:
1. На начальном этапе проекта, когда толком нельзя "нормально" отлаживать внутренние вещи. Хотя такой ситуации ИМХО просто не должно быть - надо писать в обратном порядке 
2. Если планируется разработка или (особенно) переработка, затраная в архитектурном плане.

см выше про шутку  И заодно про понятие "лучше" в принципах Agile. Agile тоже зло в чистом виде, как и любой подход при применении без оглядки на реальную ситуацию.

+1, потому TDD в чистом виде мы тоже не используем.


Один Unit Test тестирует модуль - наименьшую часть приложения, которую можно отдельно протестировать. Функцию, класс, взаимодействие двух классов, но не больше. Т.е. если ты пытаешься протестировать сайт, то пишутся
- тесты на UI
- тесты на каждый метод BL
- тесты на DataAccess
При этом тесты "плывут" при смене архитектуры, и очень дороги в поддержке. На этом внедрение TDD на Unit-тестах обычно и умирает, оставляя в разработчиках жгучую ненавить к TDD в целом 

В TDD тесты - это автоматические regression-тесты. Один тест покрывает тест-кейс, одно или несколько действий на UI, и заодно задейстованные при этом куски BL/DataAccess. TDD тесты не затрагиваются внутренностями архитектуры, и спокойно переживают рефакторинг, расширение архитектуры и прочие внутренние вещи. Основная цель автоматической регрессии - проверить что не поломался функционал в целом, а не какие-то "модули".


1. А если маленький, но вырастет в будущем? У меня софтина из списка с 3 кнопками вырасла в 4 сервиса + тонкий client + штук 5 сервисов внешних. При этом добавлялись только мелкие фичи 
2. Есть ес-но

насчет когда полезны
1. На протяжении всей жизни проекта, и чем больше раз тест падал, тем полезнее. читай - чем раньше тест написан, тем полезнее.
2. Если планируется рефакторинг - сомневаюсь что тесты "вдруг" появяться в момент, когда решат порефакторить. А писать тесты на старый код - дорого и неприятно. 

Общий смысл списка когда полезны - если бы могли видеть будущее, заранее знали что через год надо будет рефакторить, то сегодня написали бы тест. 
Тесты - это как ремни безопасности. Они полезны только когда попадаешь в аварию. Так зачем их пристегивать все остальное время?

Я, кстати, поговорил с местными QA сегодня. По статистике они чаще всего заворачивают билды из-за ошибок типа "страница не открывается" и "падает по кнопке Save". Т.е. на абсолютно тривиальном функционале, который написан уже года 2 назад, где и логики как таковой нет. Но который девелоперы все еще умудряются случайно ломать. Девелоперы вменяемые, архитектура ровная. Полный прогон билда, кстати, 6 человеко-дней. Название проекта не скажу, ибо NDA ;) Это к вопросу о стоимости ошибки. Бесполезно мне доказывать что тесты не нужны  Потому что все аргументы выше доказывают что тесты не нужны лично вам, потому что лично вы - тот самый несуществующий девелопер, который НИКОГА не лажал (а на самом деле просто лень и нежелание увидеть полную картину)

Хотя, мелкие проекты (до 200 часов), мы типа под Agile вполне колбасим без тестов 

Ну.. Аджайл проповедует чаще смотреть на реальную ситуацию. Аджайл проповедуте нетяжеловесный менеджмент, лёгкость смены тасков и ориентиров. Моё ИМХО 


Абсолютно верно 


Я не считаю, что это есть TDD. Вообще - регрессион-тестирование не может относится к разработке (именно к разработке в плане девелоперов, а не организации проекта). ИМХО, это задача QA-команды. Я не говорю, что это обязательно мануальное тестирование - но в любом случае это не связано с написанием основного кода (что не скажешь о юнит-тестах). А на начальном этапе ни о каком регрессион - речи по определению нет.


Ну.. это уже вопрос менеджмента  Ничего нельзя предсказать, но.. надо уметь правильно рассчитывать...


Мм.. Я не согласен. Я считаю, что писать тесты на "старый код" - это нормально. Если планируются изменения, затрагивающие этот код. Более того, при наличии времени это даже preferred way.


Да, если бы знал. А если не знал - лучше не напишу, чем напишу..


Ну.. Ошибки бывают у всех - и.. это нормально. Обычный рабочий момент. Но, если страница не открывается на разрабатываемой (или затрагиваемой) функциональности и девелопер этого не замечает, то.. это странно. Но для "рядовых" билдов - это вполне нормально. ИМХО, конечно..


Хм.. Ну, в нашей компании большинство проектов укладываются (без учёта размера команды) в это время. А тот ограниченный список, что не укладывается - либо обречён на "сложную" судьбу, либо разрабатывается "линейно" (т. е. существующая архитектура "идеальна" и достаточно "наслаивания" независимых фич).

ИМХО> Тесты до кода писать просто интереснее, Тесты после кода писать нудно. Если проводится рефакторинг старого кода, то тесты на старый код писать необходимо.

А что такое ТДД в чистом виде?   Когда все и вся пишется через тесты? Если да, то это конечно крайность.

Проект просто оказался нужен, и породил сразу много мелких "хотелок". А т.к. он был внутренним, то хотелки пришлось реализовывать. :( Любой востребованный софт будет обрастать функционалом. Если не обрастает - значит
- софт идеален (не верю)
- софт никому не нужен и никто им не пользуется


Полноценные regression-тесты - ес-но задача для QA. Я просто хотел показать что TDD-тесты по смыслу и по подходу ближе к регрессии, чем к unit-тестам. Автоматическая регрессия вообще применима начиная со второго билда. Если билды при коммите кода - то фактически при втором коммите.

"Тесты до/во время кода" тупо дешевле "тестов после" примерно в N раз, N > 10. Т.е написать код, а потом покрыть 10% существующего кода == написать тот же код, сразу покрытый тестами. Опять же, возвращаясь к agile-подходу - ценится возможность внести незапланированные изменения, а не планировать их заранее. И опять же, ценится рабочий продукт, в полном смысле этого слова, а не когда работает только новый функционал.

Ага, а потом появляется шеф, и говорит: что-то ваш тим, Любитель, валит уже 4 билда подряд на каких-то мелочах? доколе? ... лишить компота...снизить зп...все уволены. Потому что 4 билда - это 3-4k$ (условно), и это уже не первый раз.


У нас пока примерно такой подход:
 - Долго пишется один толстый проект (скажем, 20к часов) , под ним обкатывается архитектура, с тестами, dsl, полноценными доками и проч. Где-то между CMMI и Agile.
 - Параллельно в разработке висят 1-2 проекта на той же архитектуре, без тестов и проч. Сплошной Agile, хоть никто и не догадывается.

Я, кстати, работаю совестью первого проекта и манагером группы вторых 

Немного в сторону от темы, но хорошо пересекается с "когда полезны тесты".Технические долги. Очень трезвый взгляд на тесты, рефакторинг, архитектуру и прочие тудушки.

Добавлено через 4 минуты и 32 секунды

Вот поэтому чистый TDD никто и не любит. Я пробовал, действительно крайность, даже на полноценном тестовом фреймворке с рюшекчами, где можно выжать 99% покрытия бизнес логики обычными тестами перед кодом.

Ну.. по крайней мере, я всегда ТДД именно так понимал  Вроде как, само понятие TDD наталкивает на такое определение.


Обрастать может и будет - но всё-таки в большинстве случаев это именно "обрастание", а не "разрастание". То есть "коренная" архитектура не затрагивается. Хотя, конечно, это исключительно из моего (оч скромного) опыта.


Ну.. теоретически - само собой. Но называть это регрессион-тестирование - язык не поворачивается. Когда в проекте ещё ничего толком нету, регрессион-тестирование заключается в запуске приложения девелопером при разработке новой функциональности. Хотя, конечно, опять-таки - универсального ответа нет, надо смотреть по ситуации.


Хм.. Всё-таки тогда хотелось услышать твоё понимание ТДД. В первую очередь - какие тесты? И кто их пишет? Как? И насчёт покрытия функционала/кода тестами - тоже интересно (грубо говоря, достаточно доли).


Да, конечно, дешевле. Но, я думаю, явно не настолько. И плюс, самое главное, опять-таки - всё зависит от ситуации..


Вот именно! Т. е. понадобились тесты - давай добавим. И архитектура, тест-фреймворк и пр. должны позволять это сделать с минимальными затратами. А писать тесты ради того, что они могут понадобиться - я это не поддерживаю.


Ну.. всё хорошо в меру. Когда я говорил, что это нормальнач рабочая ситуация - я ж не имел ввиду, что билд валится после каждого комита   Ну, бывает кривой комит.. вечером в пятницу...  Т. е. это нормально - но, конечно, в меру.


Ну.. Если проекты подобны - я бы просто считал бы это ветками того же проекта.

А вообще, что-то мы с тулзов совсем перешли на менеджмент.