Методики разработки ПО

← →
by © (2004-08-04 17:02) [0]

Кто разрабатывает ПО командами больше одного человека, поделитесь информацией. Используете ли вы в своей работе методологии такие как ХР, RUP и пр. Или пишете петодом code and fix, пишем и правим. Что сейчас наиболее востребовано в мелких, средних, крупных проектах?

← →
Игорь Шевченко © (2004-08-04 17:09) [1]

> Что сейчас наиболее востребовано в мелких, средних, крупных
> проектах?

Мозги разработчиков и постановщиков, как ни странно.

> Используете ли вы в своей работе методологии такие как ХР,
> RUP и пр.

Серебряной пули все равно нету, так что с бору по сосенке (особенно полезной) собирается.

← →
by © (2004-08-04 17:14) [2]

Что серебряных пуль нет и что мозги нужны это да. Но существуют какие-то подходы? Сначала все пишется и рисуется в диаграмах, а потом кодирование. Или пишем без планирования, как в ХР. Или составляем примерный план-проект приложения, немного документируем, апотом итерациями?

← →
Sergey_Masloff (2004-08-04 17:51) [3]

Везде по-разному. Ни одна из технологий не дает гарантированного результата, так что какой смысл выяснять кто что использует. Лично я сейчас разрабатываю (во главе микрогруппы) одну довольно крупную и достаточно независимую подсистему. Так вот дал себе слово что пока не будет полной структуры придумано и описано никто ни строчки кода не напишет. Уже месяца два ушло на придумывание (конечно в фоновом режиме - есть и другие задачи) пока я не готов дать сигнал к началу кодирования. Но меня это даже радует. А что писать я уже знаю на 99%.

← →
by © (2004-08-04 17:56) [4]

to [3] Sergey_Masloff (04.08.04 17:51)
а у вас уже есть полная поставновка задачи? или вы её сами ставите?

← →
Vovchik_A © (2004-08-04 18:14) [5]

2by © (04.08.04 17:56) [4]
>а у вас уже есть полная поставновка задачи?

Сначала нужно от некоторых иллюзий отказаться

← →
Игорь Шевченко © (2004-08-04 18:15) [6]

> Так вот дал себе слово что пока не будет полной структуры
> придумано и описано никто ни строчки кода не напишет

Получается ?

← →
Sergey Masloff (2004-08-04 20:23) [7]

Игорь Шевченко © (04.08.04 18:15) [6]
>Получается ?
Пока да. Но тяжело ;-) Но зато уже 2 раза приходил к выводу что изначальный дизайн не годится даже. Если бы сразу писали то еще и к первому из двух выводов наверное не пришли. Была у меня мысль тут тему завести описывая эксперимент по разработке без кодирования. Но чувствую не потяну по времени.
Сейчас у меня уже совершенно четко сложился дизайн хранилища анных и общий дизайн системы (укрупненные модули). Причем по паре модулей уже знаю все как писать то есть осталось только пальцами стучать ;-) Но буду до победного.

by © (04.08.04 17:56) [4]
>а у вас уже есть полная поставновка задачи? или вы её сами >ставите?
Конечно нет. Самые общие пожелания заказчиков + взаимодействие со службой поддержки + некоторые свои соображения. Конкретную задачу буду стаить я.

← →
Гаврила © (2004-08-04 20:43) [8]

> Sergey Masloff

Мы так делали, столкнулись с тем, что когда началось кодирование, вся система полетела к чертям. И вернулись обратно к полу-итерационому, полу-по-структуре методу. Причем с итерационным изменением структуры

← →
Игорь Шевченко © (2004-08-04 20:49) [9]

> Но буду до победного

Удачи :) Если получится вытерпеть. У нас базовые структуры тоже небыстро разрабатываются, но есть посредники между программистами и постановщиками. Я все-таки считаю, что программист должен разбираться в том, как наиболее эффективно превратить поставленную задачу в работающую программу, а не делать постановку, исходя из расплывчатой предметной области. Голова не резиновая, программисту лучше знать программирование, а не углубляться каждый раз в дебри той или иной предметной области. IMHO, разумеется.

← →
Sergey Masloff (2004-08-04 20:53) [10]

Гаврила © (04.08.04 20:43) [8]
Верю. Но все же хочется попробовать ;-) Тем более надо мной дамоклов меч не довлеет - прямого указания к реализации задачи еще не было, я как бы предвижу пожелания. Так что время есть. Это раз.

И два - передо мной пример нашей системы. Схема данных была продумана полностью ДО того как систему начали писать. Результат - за 8 лет схему изменять не пришлось. Сервер отмасштабировался от персоналки до практически мейнфрейма, пользователей стало раз в 1000 больше - а схема та же. Самые неожиданные задачи при реализации ложатся (причем отлично ложатся) на старую схему. Да что там - за все время может пара полей в таблицы добавилась. Честно говоря завидую ребятам которые у истоков этого стояли и хочу попробовать хоть что-то подобное сам забацать ;-)

← →
Гаврила © (2004-08-04 21:00) [11]

>>Sergey Masloff (04.08.04 20:53) [10]
Это твой первый подобный опыт ?
У нас был первый, может быть, в следующий раз было бы и получше.
А так получилось, что на уровне UML-диаграмм, при коллективном мозговом штурме, все таки осталась куча неучтенных ситуаций. Лишь самые крупные элементы структуры остались без изменений

← →
Sergey Masloff (2004-08-04 21:07) [12]

Игорь Шевченко © (04.08.04 20:49) [9]
Скорее согласен. К сожалению, как таковых, постановщиков у нас нет. Так что предметную область приходится знать очень хорошо. Но с другой стороны мы не софтвер-хаус так что область предметная широко не варьируется.
Тем более в данном конкретном случае задачу никто вообще четко не поставит - это вобщем-то задача внутренней интеграции компонентов ИС не связанная напрямую с бизнесом.
<offtop>
Да и программирование... что-то чем дальше в лес тем толще партизаны. Читаю того же Юаня или Танненбаума и все больше чувствую себя просто ничтожеством как программиста :( Надо хоть качествами проектировщика пробелы компенсировать. Правда оглянусь вокруг - вроде на фоне не так все плохо. Да и стараюсь все же работать над собой в плане повышения программистской квалификации. Посмотрим что получится.
</offtop>

← →
Sergey Masloff (2004-08-04 21:08) [13]

Гаврила © (04.08.04 21:00) [11]
>Это твой первый подобный опыт ?
Ну да. Хотя в принципе сразу кодировать никогда не бросался но тут решил довести до абсолюта ;-)

← →
Игорь Шевченко © (2004-08-04 21:20) [14]

Sergey Masloff (04.08.04 21:07)

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

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

> задача внутренней интеграции компонентов ИС не связанная
> напрямую с бизнесом.

Тогда можно даже позавидовать. Интересно.

> Читаю того же Юаня или Танненбаума и все больше чувствую
> себя просто ничтожеством как программиста

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

← →
Гаврила © (2004-08-04 21:21) [15]

> Sergey Masloff (04.08.04 21:07) [12]

> К сожалению, как таковых, постановщиков у нас нет

Вот вот вот. И у нас так же. Результат я описал. Боюсь, у тебя будет то же самое.
Причем, отсутствие постановщиков и было главной причиной неудачи

← →
Sergey Masloff (2004-08-04 21:49) [16]

Игорь Шевченко © (04.08.04 21:20) [14]
>Но тем не менее, есть куда стремиться :)
Вот именно. Только это и утешает ;-)

Гаврила © (04.08.04 21:21) [15]
Да знаю. В принципе, далеко не первый мой проект (даже как руководителя уже не первый). Но еще не все надежды растерял ;-)

← →
Lenor (2004-08-04 22:04) [17]

> Кто разрабатывает ПО командами больше одного человека

А кто - командами меньше одного человека?..

← →
Rule © (2004-08-04 22:24) [18]

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

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

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

← →
Гаврила © (2004-08-04 23:17) [19]

> надо было выбивать из заказчика все что он хочет и притом
> насильно

передумает, зараза :-)))

← →
by © (2004-08-05 10:03) [20]

в том то и дело что полное и правильное планирование никак не получается с первого раза ((.
Заказчик всегда передумает. А в реальность такова что он диктует условия. У меня был только один проект, длительностью год, который развивался эволюционно, без полной переделки. И то только потому, что предметную область я знал лучше чем заказчик, знал как должно быть.
Но и в этом случае один серьёзный участок пришлось переписать полностью, так как вмешался другой фактор - изменение политики государства.

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

← →
Гаврила © (2004-08-05 10:19) [21]

> Что мне понравилось в подходе ХР - не делайте того что сейчас
> ненужно

А это разве только в XP утверждается ? По моему, просто очевидная вещь

← →
Игорь Шевченко © (2004-08-05 10:25) [22]

> Что мне понравилось в подходе ХР - не делайте того что сейчас
> ненужно.

Что мне в этом не понравилось, так это то, что в дальнейшем чаще всего оказывается, что это было нужно. И в базовую архитектуру уже поздно вносить изменения.
Методика XP, по моему скромному мнению, хороша для небольших проектов, где работы команде из трех человек максимум на месяц-другой. Все, что требует больше времени или участников, должно разрабатываться несколько иначе, что бы там Кент Бек не писал. Иначе Тришкин кафтан получится в итоге.

← →
Vovchik_A © (2004-08-05 10:25) [23]

2Игорь Шевченко © (04.08.04 20:49) [9]

Совершенно согласен. Для этого существуют постановщики и методологи.

>>Sergey Masloff (04.08.04 21:49) [16]

Игорь Шевченко © (04.08.04 21:20) [14]
>Но тем не менее, есть куда стремиться :)
Вот именно. Только это и утешает ;-)

Идеал потому и идеал, что недостижим :), ИМХО, конечно :)

Мы меняли техзадание за последние 4 раза за последний год. И тоже вплоть до 180 градусов.

← →
Vovchik_A © (2004-08-05 10:30) [24]

Последнюю строку в Vovchik_A © (05.08.04 10:25) [23]читать как

Мы меняли техзадание 4 раза за последний год. И тоже вплоть до 180 градусов.

← →
Alex Konshin © (2004-08-05 10:33) [25]

http://home.earthlink.net/~akonshin/Workflow_in_PTC.html

> Игорь Шевченко © (05.08.04 10:25) [22]

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

Гаврила © (05.08.04 10:34) [26]

> Сдается мне, что конечной целью первоначальной разработки
> схемы является как раз обеспечение возможности вносить в
> дальнейшем добавления, не влекущие за собой какую-либо переделку

А для этого и нужно в будущее смотреть и порой делать то "что сейчас не нужно".

← →
Sergey_Masloff (2004-08-05 10:40) [28]

Alex Konshin © (05.08.04 10:33) [25]
>http://home.earthlink.net/~akonshin/Workflow_in_PTC.html
Мы все читали ;-)
Когда будет продолжение потому что очень интересно, серьезно.

Дык лень же. Да и не менеджер я(не хочу и языков иностранных не знаю (с) Чапаев), потому мне не интересны тонкости их бюрократии. А что касается техничекого исполнения, то и там столько всего, что нормальному человеку это знать вредно - мозгов не хватит. Тут зачастую главная проблема найти человека, который знает, у кого спросить. Просто удивительно, как все это работает.
:)

Попытался сохранить страницу, но оказалось что я тоже это скачал уже. Можно писать продолжение :)

← →
Sergey_Masloff (2004-08-05 10:53) [31]

Игорь Шевченко © (05.08.04 10:25) [22]
>Методика XP, по моему скромному мнению, хороша для небольших >проектов, где работы команде из трех человек максимум на месяц->другой.
Игорь, по этому вопросу мое скромное мнение полностью такое же. Чему я очень рад так как у нас некий нездоровый интерес к этой технологии растет в последнее время а я что-то не совсем верю во все это. Хорошо что не один я ;-)

Sergey_Masloff (05.08.04 10:53)

> Игорь, по этому вопросу мое скромное мнение полностью такое
> же. Чему я очень рад так как у нас некий нездоровый интерес
> к этой технологии растет в последнее время а я что-то не
> совсем верю во все это. Хорошо что не один я ;-)

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

Может, я чего не понял из объяснений Кента Бека, но прочитав две его книжки, серебряной пули не увидел. Кроме всего прочего мне не нравится стиль изложения: "А что это там такое синее ? А это море, сынок" (с). Такое ощущение, что читатели по умолчанию считаются полными дебилами, которыми иначе, как на примере комиксов, объяснить что-либо невозможно.
IMHO, разумеется :)

Но и жесткие методологии типа RUP не являются же серебрянной пулей или все таки являются? Планирование необходимо, помогает рисование диаграм, но когда рисование из средства превращается в цель, разве это хорошо?

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

Alex Konshin © (05.08.04 11:21) [35]

> Это хорошо, когда к рисованию допускаются только люди в
> здравом уме

Где ж их взять-то ? :)

Методики разработки ПО Найти похожие ветки