Большинство имеющихся методологий адаптировано на командную разработку(RUP, XP, TSP и т.д.).
Я являюсь независимым разработчиком и хотела бы упорядочить свой процесс разработки.
Большинство моих проектов — небольшие проекты на 2-3 человеко-месяца (изредка и больше). Все они не стоят на месте, а потихоньку обрастают дополнительными возможностями по требованию заказчика.
Подскажите, какая из методологий больше всего подходит в моем случае?
Здравствуйте, ZORK, Вы писали:
AVK>> Абсолютно.
ZOR>?
Что непонятно? Все методологии заточены прежде всего на повышение эффективности работы команды. В случае работы в одиночку все эти навороты просто не имеют смысла
Здравствуйте, AndrewVK, Вы писали:
AVK>Что непонятно? Все методологии заточены прежде всего на повышение эффективности работы команды. В случае работы в одиночку все эти навороты просто не имеют смысла
Там не только про эффективность команды, но и про эффективность ведения проекта. И то что касается именно эфективности ведения проекта пременимо к работе в одиночку. При чем даже из RUP можно кое что почерпнуть, но при этом прада возникает гора дополнительной работы, и в одиночку проект становится вести не реально .
Но вот из XP точно можно взять тестирование и refactoring, и это сильно помогает, если даже ты один на проекте.
AVK>Что непонятно? Все методологии заточены прежде всего на повышение эффективности работы команды. В случае работы в одиночку все эти навороты просто не имеют смысла
Я прочитала занятную статеечку http://www.interface.ru/fset.asp?Url=/rational/f_process.htm "Разработка программного обеспечения группой в составе одного человека" где описано, как RUP можно применить для одного человека. Никто и не говорил, что нужно брать определенную методику и тупо ей следовать один к одному. Вопрос был в том, какую из методик эффективнее всего заточить для разработки в одиночку.
Но то, что какая-либо методология нужна(хотя бы своя собственная), у меня сомнений не вызывает.
Здравствуйте, Nata1111, Вы писали:
N>...как RUP можно применить для одного человека.
Насколько я понял, там не только про RUP — в списке литературы, в конце статьи, первым идет Extreme Programming Explained . И, увы, в этой статье ней нет ничего про тестирование, refactoring, bugtracking и т.д.. Там только про то как записывать и сортировать свои мысли.
Здравствуйте, ZORK, Вы писали:
ZOR>Насколько я понял, там не только про RUP — в списке литературы, в конце статьи, первым идет Extreme Programming Explained . И, увы, в этой статье ней нет ничего про тестирование, refactoring, bugtracking и т.д.. Там только про то как записывать и сортировать свои мысли.
Вот поэтому вопрос и возник. Попробую для начала поверхностно с XP ознакомится. Мне лично идея рефакторинга очень нравится.
А что там еще помимо pair programming можно исключить? Ведь наверняка куча избыточной документации.
Знаю я этот сайтик. Там если все читать, никакой жизни не хватит
ON>там должно быть о Personal Software Process и вообще много вкусного для менеджеров
О PSP я немного почитала. Вряд ли я смогу точно выполнить его базовый принцип — четкое планирование работы по времени. Никогда не могу точно вычислить, сколько времени займет та или иная работа.
Здравствуйте, Nata1111, Вы писали:
N>Большинство имеющихся методологий адаптировано на командную разработку(RUP, XP, TSP и т.д.). N>Я являюсь независимым разработчиком и хотела бы упорядочить свой процесс разработки.
N>Большинство моих проектов — небольшие проекты на 2-3 человеко-месяца (изредка и больше). Все они не стоят на месте, а потихоньку обрастают дополнительными возможностями по требованию заказчика.
Мне кажется, что нужно просто упорядочить ммм... артефакты в терминологии RUP. Ну то есть — документы с постановками, исходники, сообщения об ошибках и расширениях и пр.
N>Подскажите, какая из методологий больше всего подходит в моем случае?
Та, которая тебе больше всего нравится. Всё равно впоследствии ты её перезаточишь.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, ZORK, Вы писали:
ZOR>RUP точно не подходит. А XP то что надо, но при это важно пропустить pair programming, чтоб не пришлось с собой разговаривать
Согласен, к тоому же Nata1111, вы в жизни все эти вещи не один раз делали, просто не "задавались" вопросами "А какая это метода ?".
Поэтому удобный для вам способ будет наверное "компиляцией" из XP и ваших соображений.
Здравствуйте, blandger, Вы писали:
B>Согласен, к тоому же Nata1111, вы в жизни все эти вещи не один раз делали, просто не "задавались" вопросами "А какая это метода ?".
Конечно не задавалась. Ведь главное в разработке — результат. Изучение методологий началось после того, когда я обнаружила, что мне очень часто приходится переделывать уже написанный код. Вот теперь ищу причины. Пока нашла одну причину в виде: "Писать Пробные решения для уменьшения риска". Я частенько делала исследования прямо в проекте. Прдолжаю изыскания
B>Поэтому удобный для вам способ будет наверное "компиляцией" из XP и ваших соображений.
Наверное так и будет, я уже наметила, чего мне не достает. Только пока мучают сомнения, а действительно ли нужны Test Cases для каждого класса. Мне кажется, что их написание съедает уйму времени.
Здравствуйте, Nata1111, Вы писали:
N> Мне кажется, что их написание съедает уйму времени.
Используя готовые решения, типа, JUnit, написание теста занимает не больше чем написание просто дополбнительного кода необходимого для дебага, и более того при написании некоторых классов, код теста можно рассматривать как постановку задачи, то есть время экономится на бумажной работе. Вообщем, вроде как должен быть суммарный выигрышь а не проигрышь.
Что касается общего тестирования проекта — автоматического совместного запуска тестирования всего проекта, то тут действительно съедается ресурс, но это можно отложить, как мне кажетмя, до первого релиза проекта.
Здравствуйте, Nata1111, Вы писали:
N>Конечно не задавалась. Ведь главное в разработке — результат.
Конечно!
N>Изучение методологий началось после того, когда я обнаружила, что мне очень часто приходится переделывать уже написанный код.
Хорошо реализованный рефакторинг — очень полезная вешь.
Вот чего мне не хватает например в VS2003, и других средах — так это такого же качества рефакторинга, как в IDEA IntelliJ (java). Там это сделано очень удобно и по работе время от времени приходиться успешно им пользоваться.
N>Вот теперь ищу причины. Пока нашла одну причину в виде: "Писать Пробные решения для уменьшения риска". Я частенько делала исследования прямо в проекте.
Вот и пример, вы уже это делали без XP.
N>Только пока мучают сомнения, а действительно ли нужны Test Cases для каждого класса. Мне кажется, что их написание съедает уйму времени.
Ищите "середину" для себя. Писать тесты стоит писать для "критичных" классов/компонент, если не хочется писать сразу "для всего".
Например, "воткнулись" раз на то, что надо проверить корректность работы класса/компонента — постарайтесь написать test-case, обычно бывает так, что он пригодиться еще не раз, т.к. если уже раз столкнулись, то потом скорее всего еще раз понадобиться "проверка", вот тут готовый tesе-case и пригодиться.
Потом "по опыту" — писать test-case-ы "проще" писать для "низкоуровневых" компонент, т.к. чем "крупнее" проверяемая сущьность, тем больше логики она содержит, тем больше "тестовых данных" надо "предоставить", тем больше "всяких условий" соблюсти и т.д. В итоге — писать и поддерживать "полное тестрование" такого программного компонента достаточно проблематично, и получается, что "овчинка выделки не стоит".
Хотя иногда "простенький тест" для "крупного" компонента тоже полезен, просто для того, чтобы проверить, что выполнение метода/логики "не валиться с ошибкой", или оно "валиться" и хочется "более точно" найти место ошибки. Начинаем запускать тесты "отдельных компонент в цепочке", если "глазами/в логах" не совсем ясно где это происходит. А вот "корректность" обработанных данных для "крупного компонента", иногда проще "посмотреть глазами" (в результирующих — базе, документах и т.д.), т.к. "вытаскивание" тестового значения может оказаться "проблематично" внутри теста или его значение "не линейно зависимо и не постоянно" для сравнения.
Здравствуйте, ZORK, Вы писали:
ZOR>Используя готовые решения, типа, JUnit, написание теста занимает не больше чем написание просто дополбнительного кода необходимого для дебага,
To Nata111, именно про него мы и говорим. JUnit а его реализаций под разные языки/платформы — множество, всегда можно найти.
ZOR>>Используя готовые решения, типа, JUnit, написание теста занимает не больше чем написание просто дополбнительного кода необходимого для дебага,
B>To Nata111, именно про него мы и говорим. B>JUnit а его реализаций под разные языки/платформы — множество, всегда можно найти.
Так, JUnit я сейчас найду и посмотрю.
А теперь такой вопросец: Где-нибудь можно посмотреть, как эти test cases пишутся? Нужны конкретные примеры, желательно в привязке к C++.
Здравствуйте, Nata1111, Вы писали:
N>Так, JUnit я сейчас найду и посмотрю.
JUnit — это под java.
Знаю NUnit под .NET.
Под С++ не слышал, сталкиваться не приходилось.
N>А теперь такой вопросец: Где-нибудь можно посмотреть, как эти test cases пишутся? Нужны конкретные примеры, желательно в привязке к C++.
Да там же с ним и будут примеры.
В java — расширяется класс TestCase, переопределяются методы "инциализации" и "очистке ресурсов" (если надо), пишутся методы самих test-case.
Чтобы у тебя не вызывало удивления (не знаю как это будет для С++ unit-а) — но для JUnit методы "ининта и очистки" выполняются соответственно "до и после" КАЖДОГО метода test-case.
Удачи.
Сообщение опубликовано обалденной софтиной << RSDN@Home 1.1 beta 1 >>
