Уже 7 месяцев применяю принципы TDD. Здоровая для качества кода штука. Вот каk я делаю:
1) сначала осмысливаю задачу
2) делаю поверхностный дизайн
3) пишу тесты
...

TDD (Test Driven Development) или  XP не запрещают делать первичный дизайн. Просто не надo егo изначально продумывать дo костей. V этоm нет смысла, т.к. зачастую оn меняется в процессе разработки.

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

neutrino, сколько человек в команде, как внедряли, как контролируете, чем из фреймворков пользуетесь? win/web проекты? как организуете тесты? на базе/без? 

PashaPash, Я выбрался козлом отпущения. Всего из 30 программеров пользуются ТДД - 5. Я первый в нашей комманде (12 человек). Я буду как раз контролировать процесс перехода с нативного программинга на ТДД для нашей комманды.
Тогда расскажу как дела обстоят в другой комманде.

Внедрять очень сложно. Основной фактор - нежелание людей писать тесты а тем более писать их до собственно программинга.

Контролируем пока никак. Мы используем Решарпер. У него есть какие-то методы контроля качества кода. Есть человек, который этим занимается. Но пока все глухо. Очень не хочетя делать код ревью. Думаю если перейти на парное программирование, то проблема контроля решится сама собой. Но начальство против этого подхода. Еще не осознало всю прелесть парного программинга.

NUnit + ReSHarper, PostSharp (в основном, конечно Laos). Для логгинга юзаем Log4NET.

Проэкты только Win

Как организуем тесты? Немного не понял вопрос. Каждый пишет тесты для своего кода. Есть отдел, который занимается интегрированными тестами - QA. Понятия не имею как он работает. Тесты пишутся в отдельном проекте. Группы тестов складываются по темам в TestFixture-ы ... Например у меня есть AcceptanceTests, PerformanceTests ...

На базе чего?

тесты прогоняете на базе данных или без нее?  Хотя, для win не так актуально.

У нас web, с ним чуть попроще.

У нас примерно так:
1. asp.net mvc, обязательные тесты на уровне контроллеров. Именно TDD-тесты, а не Acceptance/Performance. Т.е. скорее автоматические Regression тесты.
2. CruiseControl.net
 - билд при коммите, с прогонкой тестов не на базе данных, на стабе.
 - ночной билд, с прогонкой тех же тестов на базе данных + деплоймент
3. MSTest + родной MSTest-овый контроль покрытия. Фейл билда при уменшении покрытия на 0.1% от прошлого билда. сурово, но более-менее работает 
4. Студийные FxCop, StyleCop и фейл билда при предупреждениях
5. Обязательный ревью вообще всех изменений, в Crucible.

Первые пару коммитов девелоперы ругались, потом привыкли. 

Насчет парного программирования - я после 4 часов парного программинга обычно выжат полностью, могу только тупить в монитор. Хотя, тут наверное зависит от напарника. 

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

Решил подключиться к теме обсуждения.
Знать и уметь применять шаблоны проектирования сейчас уже совершенно необходимо иначе топорную систему ничто не спасет от мусорной корзины. Но часто не имея достаточной информации, сложно грамотно спроектировать точки эволюции системы. Сейчас дочитываю уже третий толмуд по теме проектирования ОО-систем (Крег Ларман "UML и шаблоны проектирования"). Он несколько раз указывает на то, что не стоит применять паттерны только ради их применения. Надо трезво оценивать пользу и вред их применения. 
Сам стараюсь их применять по мере необходимости в своих мини-проектах для пробы пера. На работе, как я уже упоминал, мне очень сложно заниматься проектированием и рефакторингом, т.к. собранной конкретной информации по целям и задачам мало; а мышление некоторых для сложной системы на уровне "нажми кнопку -  получишь сообщение Привет" иногда начисто убивает желание что-то совершенствовать.   
Хочу попутно выяснить у социума: есть ли члены команд с внедренным процессом разработки типа RUP (Rational Unified Process)? Если есть, то какая численность и уровень команды? Кто отвечает за претворение в жизнь тех или иных этапов внедрения?

PashaPash, эффективное время работы программиста в день 2-3 часа в обычном проекте и 3-4 (возможно больше, но не думаю) при..., скажем так, более организованном и командном подходе (не хочу говорить agile). 

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

Предлагаю попробовать снизить время работы в паре до 1,5 часа (чисто условно, но 2, ИМО, тоже много) с небольшим перерывом (сделайте себе кофе, переговорите о том что сделали, сделаете, на те же фишки зайдите...).

Кроме того, советую сделайть план того, что бы собираетесь делать. С ним намного проще не отвлекаться на посторонние вещи. С помощью него ваше эффективное время станет еще эффективнее. И обязательно ему следуйте. Успели выполнить раньше? Остановитесь. Не успеваете (это видно задолго до конца 1,5 часов)? Урежте план. Со временем вы будете составлять планы ровно на эти 1,5 часа с легкостью.



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

ivashkanet, отличные советы, но лично у меня PP приносит пользу только при 
- фиксе или дизайне чего-то сложного
- обучении нового человека каким-то внутренним фишкам проекта

Т.е. PP - это скорее исключение из общего процесса, чем регулярная практика. К тому же частичные альтернативы, тот же peer code review, имеют (опять же, лично для меня) несколько преимуществ
- оставляют артефакты, хотя бы в виде комментов
- не требуют одновременного участия 
- позволяют разделить знания между n>2 людьми
- не так сильно выедают моск 
- проще воспринимаются PM-ами (те не забывают делить результат на 2)

Насколько я знаю, практически все используют парное программирование, в том или ином виде, просто не называют его PP. Но я не хотел бы преувеличивать/преуменьшать значение PP, или считать его серебряной пулей. 

Почти всегда есть другие, более дешевые способы поднять эффективность - донесение до разработчиков понятия flow, например. Планы на полтора часа (или на 40 минут), отключенный IM, проверка почты раз в 4 часа... работают для одного человека так же хорошо, как и в парном программировании. Даже, возможно, лучше  

PS что-то всех в оффтоп унесло....

Это сообщение отредактировал(а) PashaPash - 28.10.2009, 16:12

PashaPash, Кстати, спасибо. Теперь думаю и мы внедрим FxCop. А что такое StyleCop? Кстати, у решарпера есть такая тема: CleanUp Code. Очень полезная штука. Иногда решает большинство жалоб FxCop-а.

А это хто? Ну ладно, щац я тебя замучаю. Пойду гуглить  Фенькс за тулзы.

Добавлено через 1 минуту и 50 секунд

Это я как пример fixtures привел. 

neutrino, StyleCop - майкросовтовская проверялка стиля кода - порядка методов, имен параметров, пробелов между скобками. Лучше использовать сразу с StyleCop for ReSharper.

У меня PP используется только при передаче знаний. Да и то за счет моего личного времени. Ибо руководство не понимает пользы (да и не хочет понять). Так же как и код ревью и дизайн ревью. 
Наш тимлидер вообще построил такую систему, что каждый обособленно делает свой таск и совершенно не в курсе что делает сосед. Обсуждать такой подход отказывается. Хотя уже несколько раз проект отгребал по этой причине.


+100 
Только планы у меня сразу на весь кусок работы (1-2 недели расписаны по таскам 1-3-8 часов). 



Надо выделять темы. Ты же у нас модер. Работай  

PashaPash, 

Рульная тулза. А че у тебя за контора? Что-то больно серьезный подход.

Выделять особо некуда, только если в курилку. Организация работы это скорее тема для PM, а не для рядовых программистов.

Logic Software. Подход суровый на основном проекте, потому что на прошлой версии (текущем релизе) мы, как выразился ivashkanet, пару раз сильно отгребли :( На аутсорсе и на мелких проектах все не так строго.

Хорошо когда ПМ-ы это понимают и действительно стараются улучшать работу. Но часто "спасение утопающих становится делом рук самих утопающих".


Эхх мечты, мечты. Я не то что Crucible, я ревью хотя бы важных тасков (до и после/дизайн и код ревью) добиться не могу. Во дают  

Я не согласен  А тему надо выделить куда-нибудь отдельно.. Почитать интересно  

Пока оставил топик в этом разделе, как .net-specific.


Спасение утопающих вообще всегда дело рук самих утопающих :( Оставь в стратегическом месте распечатку по теме - и жди 

По поводу внедрения ccnet/Сrucible/tdd/чего угодно. 
Всегда есть куча способов:
1. Убедить PM-а/Тимлида, показав им статью вроде The Joel Test: 12 Steps to Better Code или Best Practices for Peer Code Review. Во второй есть графики, а графики для PM-ов и выше - серьезный аргумент. no joking.
2. Поставить <что-то> на своей машине и активно использовать. Сделать стандартом de-facto. Очень хорошо срабатывает для ccnet 
3. Самому стать тимлидом и творить что угодно
4. Сменить работу