Паттерны проектирования

[Igel]

Забыл добавить, что время разработки в общем снижается. В общем - это применение остальных практик ХР.
Да и вообще, сегодня попробовал парное программирование. 3 задачи решили за небольшое время. Так-бы я неделю отдал на разработку, т.к. понимаю, что человек устает, есть практика работчего дня и пр...
В моем случае выводы таковы:
- Ускорение работы за счет организации. Вдвоем за одним компом не особо похалтуришь.
- Вдвоем решать задачи кодирования быстрее получается. Пока смотришь, что человек пишет (все равно у него какая-то часть под моторику занята), уже кучу вариантов разбираешь.
- Да еще практика для менее опытного человека. Хотя это тормозит работу.

[Igel]

Альф, понимаю.
Дело в том, что трудозатраты реальные скорее всего были-бы не недельные, но в плане на них было заложено столько.
Начали не все практики пробовать, а попытались поиграть в планирование - не особо удачно, но расписали по часам сколько займет работа. После выполнения сравнили. в 2 раза быстрее сделали. Причем задачи не одинаковой сложности.
На счет тестов и документации - не делали ничего. Просто проект уже в стадии. Т.е. документация какая-то уже есть, что-то уже сделано.

[Антон (LogRus)]

На счет тестов и документации - не делали ничего. Просто проект уже в стадии. Т.е. документация какая-то уже есть, что-то уже сделано.

Хм. по идее надо сначала тесты потом код.
про документацию: программа хорошо документирована на языке C++

[Alf]

про документацию: программа хорошо документирована на языке C++

Не очень понятен этот пункт... То есть руководство оператора, требования к операционному окружению, описание форматов входных/выходных данных и т.д. забиты в виде комментариев в самом коде? Или используются специальные комментарии XML, подобно Java  и C#, которые потом специальной утилитой можно собрать в виде удобного документа?

[Антон (LogRus)]

Alf, это шутка такая.

[Alf]

Понял, шутка хорошая

А на самом деле документацию пишет та же пара, совещаясь вдвоем?

[Антон (LogRus)]

нет, документацию пишет, сотрудник у которого есть такая задача(согласование ТЗ, draft, request), во время кодирования документация не формируется.

[Alf]

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

[Антон (LogRus)]

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

[Igel]

1. Предлагаю тему отдельную создать. Пусть модератор перенесет то, что про ХР написали.
2. LogRus - только начал, с тестами проблема. В принципе делали диалоги, т.е GUI. Хотя по ходу дела пришлось править и другой модуль. Поэтому собственно вопрос - как делать тесты?
3. Alf, по идее надобность докментации в ХР отрицается, т.к. все  равно окончательный проект не будет соответствовать изложенному в документации. Вторая часть - исходный код с комментариями - для разработчика лучшая документация. Тесное общение разработчиков, смена направлений работы (парное программирование) и пр. позволяют держать в курсе дела всех разработчиков. И если документация используется для того, чтобы проект не заглох из-за текучки кадров, то нужно ее убрать, оставшиеся просто передадут свои знания о системе.
Что там еще было? В дальнейшем документацию можно составить по исходникам, дабы возникнет такая нужда.
Кстати как-то давно видел разработки, которые по исходникам проводили создание технической документации, вплоть до помощи. И даже в одном месте видел внедренную практику внесения стандартизованных комментариев.

[Dimka]

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

Вот наша компания себе позволяет, и я бы не сказал, что этот подход "очень правильный" по следующим соображениям:

1) Технический писатель должен одновременно отлично владеть языком (языками), знать правила составления текстов и в то же время разбираться в том, о чём он пишет.

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

3) Разработка документов по архитектуре выполняется архитектором. Если архитектор будет только думать, а писатель только писать, всё равно необходимо будет наладить между ними взаимодействие, чтобы архитектор сумел объяснить писателю, что от него требуется. В результате часть рабочего времени этой пары будет уходить на коммуникацию. Технический писатель не может иметь квалификацию на уровне архитектора, иначе он бы не работал техническим писателем, или ему пришлось бы платить бОльшую зарплату, нежели архитектору, чтобы удержать на должности. Итого имеем, что разработку проектных документов, описание архитектуры должен выполнять архитектор собственноручно - так будет и быстрее, и надёжнее по содержанию, хотя литературные достоинства такого документа могут страдать.

4) Разработка коммерческих предложений, договоров с заказчиком и ТЗ - опять же выгоднее, чтобы этим занимались специалисты: сотрудники отдела продаж, юристы и архитекторы проектов.

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

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

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

[Антон (LogRus)]

dimka, согласен

ТЗ у нас составляют те кто называются архитекторами
перед ним есть запрос на разработку от продажников или руководства
техписатели готовят конечную документацию для клиента: описание настроек, help и т.п.

и главное нам не говорят, КАК нам это делать

Igel, с тестами обычно, так определяем примерный интерфейс, пишем тест адаптированный под этот интерфейс, это юнит или функциональный тест к каждому классу подход индивидуальный, далее разрабатывает то к чему создали тест в процессе разработки если меняется интерфейс адаптируем тест. всё дело загоняется в скрипты и тесты запускаются после каждой сборки проекта(или в ручную перед отгрузкой в CVS), отчет в виде HTML каждое утро.

[Alf]

3. Alf, по идее надобность докментации в ХР отрицается, т.к. все  равно окончательный проект не будет соответствовать изложенному в документации.

Я полагаю, тут Бек или сильно лукавит, или неточно изложил свои мысли. Представь себе, ты мне заказываешь софт, я тебе приношу ворох .exe и .dll, возможно, еще и исходники. У тебя возникает масса вопросов: как это все инсталлировать, в какую среду, как настроить, с какими опциями запускать и т.д. А я гордо парирую, что я использую идеологию ХР и посему документацию отрицаю. В крайнем случае читай исходники, их всего-то 30.000 строк, там все прекрасно видно. Вряд ли я после этого у тебя хоть копейку заработаю, да и друзьям накажешь не подпускать меня близко.

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

[Igel]

LogRus , а примеры можно глянуть?

[Igel]

Я полагаю, тут Бек или сильно лукавит, или неточно изложил свои мысли. Представь себе, ты мне заказываешь софт, я тебе приношу ворох .exe и .dll, возможно, еще и исходники. У тебя возникает масса вопросов: как это все инсталлировать, в какую среду, как настроить, с какими опциями запускать и т.д. А я гордо парирую, что я использую идеологию ХР и посему документацию отрицаю. В крайнем случае читай исходники, их всего-то 30.000 строк, там все прекрасно видно. Вряд ли я после этого у тебя хоть копейку заработаю, да и друзьям накажешь не подпускать меня близко.

В корне неверно. Сопроводительная документация не отрицается. Подразумевается что для создания продукта разработчиками создается куча документации, на которую тратится море сил и времени, а результат этого не стоит.

Разработчики могут экономить на внутренней документации, особенно если при данной технологии она становится только балластом. Но от внешней никуда не денешься. Я в основном ей интересовался, причем в условиях, когда нет специального отдела документации, ее делают те же разработчики.
[/quote]

[Alf]

Хорошо. Допустим. Откатываем транзакцию в исходную точку:

3. Alf, по идее надобность докментации в ХР отрицается...

Мнение Бека:

Хорошим примером являются средства из категории CASE, которые позволяют вам целиком и полностью определять поведение всей системы при помощи графических изображений. Часто эту методику называют генерацией кода (code generation), или автоматической генерацией кода, однако для меня это — язык программирования. В этом случае я возражаю не против картинок, а против попыток хранения одной и той же информации о системе в двух разных синхронизированных между собой представлениях.

(самизнаетеоткуда, стр. 145).

Не видно никакой документофобии, и прослеживается явный намек на UML. Полный отказ от документации - это уже какое-то радикальное течение, экстремизм внути экстремального программирования. Бек так далеко не заходит.

[Igel]

Ну-у, Альф, какая документофобия? Я же написал "по идее". Ежу понятно, что без определенных планов, схем, каких-то ТЗ что-то не сделать. Просто проводится идея - "меньше писанины, больше общения". Т.е. не нужно писать что я должен сделать, когда не знаю что делать.

[Антон (LogRus)]

LogRus , а примеры можно глянуть?

боюсь, что пока нет. не кодю я дома на работе хватает выше крыши. кстати пример чего?
С утра придумаю пример напишу(если не забуду).
кстати в тестах используем boost::test удобная штука.

[Антон (LogRus)]

Igel, о тестах
1. садимся определяем интерфейс класса.
2. пишемем unit_test под интерфейс
пример (использую код из другого сообщения)
тест класса processdata:

Код:

template<class data>
class processdata
{
public:
	template <class indata, class outdata>
	bool doNext(indata i, outdata o);
}

struct test_data
{
	long i;
}

struct testindata
{
	test_data d;
	bool res;
	bool get(test_data& i){ d = i; return res;}
}

struct testoutdata
{
	test_data d;
	bool res;
	void put(test_data& o){ o = d;}
}

int test_main(int argc, _TCHAR* argv[])
{
	test_data d;
	testIndata in;
	testIndata out;
	in.res = true;
	in.d = d;
	processdata p;
	// предполагается, что test_data::i увеличится на еденицу и вернётся значение
	// которое вернул testindata::get
	// проверяем
	BOOST_CHECK_EQUAL (p.doNext(in,out), true);
	BOOST_CHECK_EQUAL (out.d.i, 1);
	// или так, если нельзя просто вывести в cout значени переданные в BOOST_CHECK_EQUAL
	BOOST_CHECK(out.d.i == 1);
	return 0;
}

тест выведет на экран ошибки если они есть и вернёт количество ошибок в коде возврата испольняемого файла теста
это число можно проверить во внешнем скрипте и сформировать отчет
если тест долже прерватся на любой ошибке заменяем BOOST_CHECK_EQUAL на BOOST_REQUIRE_EQUAL c BOOST_CHECK аналогично
можно также просто вывести придупреждение BOOST_WARN_EQUAL и BOOST_WARN