Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: 1 [2]  Все   Вниз
  Печать  
Автор Тема: Паттерны проектирования  (Прочитано 60039 раз)
0 Пользователей и 2 Гостей смотрят эту тему.
Igel
Опытный

ru
Offline Offline
Пол: Мужской

« Ответ #30 : 04-09-2006 12:50 » 

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

Ёжики, это не только ценные шкурки...
Igel
Опытный

ru
Offline Offline
Пол: Мужской

« Ответ #31 : 04-09-2006 16:29 » 

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

Ёжики, это не только ценные шкурки...
Антон (LogRus)
Глобальный модератор

ru
Offline Offline
Пол: Мужской
Внимание! Люблю сахар в кубиках!


WWW
« Ответ #32 : 05-09-2006 05:27 » 

На счет тестов и документации - не делали ничего. Просто проект уже в стадии. Т.е. документация какая-то уже есть, что-то уже сделано.
Хм. по идее надо сначала тесты потом код.
про документацию: программа хорошо документирована на языке C++ Улыбаюсь
Записан

Странно всё это....
Alf
Гость
« Ответ #33 : 05-09-2006 06:48 » 

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

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

ru
Offline Offline
Пол: Мужской
Внимание! Люблю сахар в кубиках!


WWW
« Ответ #34 : 05-09-2006 06:58 » 

Alf, это шутка такая. Улыбаюсь
Записан

Странно всё это....
Alf
Гость
« Ответ #35 : 05-09-2006 07:48 » 

Понял, шутка хорошая Улыбаюсь

А на самом деле документацию пишет та же пара, совещаясь вдвоем?
Записан
Антон (LogRus)
Глобальный модератор

ru
Offline Offline
Пол: Мужской
Внимание! Люблю сахар в кубиках!


WWW
« Ответ #36 : 05-09-2006 08:03 » 

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

Странно всё это....
Alf
Гость
« Ответ #37 : 05-09-2006 08:39 » 

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

ru
Offline Offline
Пол: Мужской
Внимание! Люблю сахар в кубиках!


WWW
« Ответ #38 : 05-09-2006 12:12 » 

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

Странно всё это....
Igel
Опытный

ru
Offline Offline
Пол: Мужской

« Ответ #39 : 05-09-2006 12:52 » 

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

Ёжики, это не только ценные шкурки...
Dimka
Деятель
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #40 : 05-09-2006 14:57 » 

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

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

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

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

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

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

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

Из всего сказанного следует, что должность техписателя непосредственно в разработке программных систем скорее лишняя. Исключение могут составлять только огромные или забюрократизированные проекты - в них выгодно выделить специального человека для "делопроизводства". Такой человек является и писателем, и библиотекарем всей обширной проектной документации, и секретарём руководства проекта - необходимым буфером между разработчиками и разными бюрократами.
« Последнее редактирование: 05-09-2006 15:01 от dimka » Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Антон (LogRus)
Глобальный модератор

ru
Offline Offline
Пол: Мужской
Внимание! Люблю сахар в кубиках!


WWW
« Ответ #41 : 06-09-2006 05:16 » 

dimka, согласен

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

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

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

Странно всё это....
Alf
Гость
« Ответ #42 : 06-09-2006 07:25 » 

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

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

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

ru
Offline Offline
Пол: Мужской

« Ответ #43 : 06-09-2006 12:14 » 

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

Ёжики, это не только ценные шкурки...
Igel
Опытный

ru
Offline Offline
Пол: Мужской

« Ответ #44 : 06-09-2006 13:11 » 

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

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

Ёжики, это не только ценные шкурки...
Alf
Гость
« Ответ #45 : 06-09-2006 13:54 » 

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

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

Мнение Бека:

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

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

ru
Offline Offline
Пол: Мужской

« Ответ #46 : 06-09-2006 14:38 » 

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

Ёжики, это не только ценные шкурки...
Антон (LogRus)
Глобальный модератор

ru
Offline Offline
Пол: Мужской
Внимание! Люблю сахар в кубиках!


WWW
« Ответ #47 : 06-09-2006 17:43 » 

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

Странно всё это....
Антон (LogRus)
Глобальный модератор

ru
Offline Offline
Пол: Мужской
Внимание! Люблю сахар в кубиках!


WWW
« Ответ #48 : 07-09-2006 05:33 » new

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
Записан

Странно всё это....
Страниц: 1 [2]  Все   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines