С чего начинать проект?

← →
cyborg © (2006-10-15 09:56) [0]

Посоветуйте. Не важно какой (проект).
Для одного человека (не для команды ).
Хочется по уму, а-то у меня всегда всё спонтанно (придумал - написал - придумал - написал), под конец нагромождения кода и модулей получается, где мозг поломать можно, и впоследствии расширять трудно.

← →
boriskb © (2006-10-15 10:01) [1]

cyborg © (15.10.06 9:56)
С чего начинать проект?

С проектирования.

← →
Nic © (2006-10-15 10:06) [2]

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

← →
Чапаев © (2006-10-15 10:07) [3]

Может, стоит пока отложить начинание проектов и почитать о проектировании? ;-)

← →
cyborg © (2006-10-15 10:07) [4]

> [1] boriskb © (15.10.06 10:01)

Об этом я и спрашивал, хотелось бы сообщения об этом видеть посодержательнее, а не одним словом.

← →
cyborg © (2006-10-15 10:09) [5]

> [3] Чапаев © (15.10.06 10:07)

Я готов, пиши сюда, почитаю :), собственным опыто, так сказать, поделись.

← →
boriskb © (2006-10-15 10:19) [6]

cyborg © (15.10.06 10:07) [4]

Для меня лично при "зачатии" новой задачи самым сложным было - предвидеть ее развитие. У любого, сколько нибудь сложного, проекта будет "жизнь". Как она будет развиваться? Что потребуется от меня в связи с этим?
Частенько не угадывал.

А собственно понятие "проектирование"...
Конечно надо книги читать, и спрашивать у опытных, НО!

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

cyborg © (15.10.06 10:07) [4]
хотелось бы сообщения об этом видеть посодержательнее
Если ждешь "конкретных шагов - алгоритмов", то они в книгах.
И в разных - разные :))

← →
Nic © (2006-10-15 10:21) [7]

Например, есть задача написать мультимедийный диск с кучей информации. Ставим задачу:
1) Выглядеть должно так-то (рисуем на бумаге макет);
2) информация должна иметь следующую структуру (рисуем структуру);
3) смотрим как это сделано другими людьми (похожие проекты);
4) начинаем разрабатывать;
5) релиз.

Вот я начал писать коммерческий проект. Я поступил так:
1) Изучил около 30 аналогов;
2) продумал структуру проекта и GUI;
3) начал реализовывать в соответствии со структурой.
4) ... пока в процессе.

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

← →
Чапаев © (2006-10-15 10:26) [8]

> Если ждешь "конкретных шагов - алгоритмов", то они в книгах.
> И в разных - разные :))

Неплохой "путеводитель": Берлинский Константин "Набор серебряных пуль".

> Выглядеть должно так-то (рисуем на бумаге макет);

Имхо это должно быть отнюдь не первым шагом.

← →
cyborg © (2006-10-15 10:27) [9]

> [6] boriskb © (15.10.06 10:19)

Может есть уже некие "обязательные правила/действия"? Что нужно предусмотреть, чего не нужно делать ни в коем случае, как изначально структурировать программу, чтобы лежало всё по полочкам и понятно было, чтобы в мусорную кучу потом не превратилось. У кого какой опыт в этом деле рассказывайте :)

← →
Nic © (2006-10-15 10:28) [10]

> Чапаев © (15.10.06 10:26) [8]

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

← →
Чапаев © (2006-10-15 10:30) [11]

> верстка в html

Э... Надеюсь, это не о мультимедийном диске речь?..

← →
MeF Dei Corvi © (2006-10-15 11:09) [12]

Несколько шутливое описание основных концепций экстремального программирования:
http://exprogramming.ru/Articles/MisconceptionXP-II.html

Отрывок из неё:
Ахиллес: Думаю да. Современные нетривиальные системы слишком сложны, чтобы дизайн поместился в голове одного человека, так что Вам все-таки понадобятся диаграммы. Черепах: А как вы думаете, можно ли этого избежать? Ахиллес: Ну, система должна быть достаточно простой, чтобы ее понимал один человек. Черепах: И Вы опять правы! Мы делаем систему маленькой. Каждый раз мы добавляем в нее небольшие кусочки функциональности, так что наш дизайн остается простым. Ахиллес: Но ведь вся система не простая, вы можете кодировать маленькими кусочками, но вам же все равно надо сначала иметь дизайн всей системы. Черепах: Да нет, не надо. Судя по количеству ошибок, которые делают люди, совершенно невозможно хорошо спроектировать систему до того, как она построена. Ахиллес: Но вы не можете проектировать систему после того, как она построена. Черепах: Нет, но можно проектировать в процессе построения. Ахиллес: Как же? Черепах: Рабочие задачи очень маленькие, обычно не больше, чем на пару часов работы. Такими небольшими задачами легко управлять, особенно если над ними работают сразу два человека. Когда разработчики пишут код, они по ходу дела обдумывают и обсуждают как и что сделать. Ахиллес: И это деятельность по дизайну - вы немного проектируете, немного кодируете? Это как итеративная разработка, но в гораздо меньшем масштабе.

← →
Ученик чародея © (2006-10-15 15:40) [13]

> cyborg © (15.10.06 09:56)
>
> Посоветуйте. Не важно какой (проект).
> Для одного человека (не для команды ).
> Хочется по уму, а-то у меня всегда всё спонтанно (придумал
> - написал - придумал - написал), под конец нагромождения
> кода и модулей получается, где мозг поломать можно, и впоследствии
> расширять трудно.

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

← →
Думкин © (2006-10-16 05:43) [14]

> Чапаев © (15.10.06 10:30) [11]
> > верстка в html
>
> Э... Надеюсь, это не о мультимедийном диске речь?..

А что не так? Чем не подходит язык разметки текста для мультимедийного диска?

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

← →
Nic © (2006-10-16 08:43) [15]

> Чапаев © (15.10.06 10:30) [11]

Вот этот проект (я о нём уже как-то писал на этом форуме):
[!] Осторожно, скриншоты довольно тяжеловесные.
http://forum.mirgames.ru/index.php?showtopic=2298

Ученик чародея © (15.10.06 15:40) [13]
А не лучше ли логику проекта вынести вне модулей с формами?

Думкин © (16.10.06 05:43) [14]
ОЧень интересный подход ;) Уже взял на заметку.

← →
Alien1769 © (2006-10-16 14:01) [16]

>
> cyborg © (15.10.06 09:56)
> Посоветуйте. Не важно какой (проект).
> Для одного человека (не для команды ).
> Хочется по уму, а-то у меня всегда всё спонтанно (придумал
> - написал - придумал - написал), под конец нагромождения
> кода и модулей получается, где мозг поломать можно, и впоследствии
> расширять трудно.

Сначала надо узнать чего хочет потенциальный заказчик. Встреча с ним много прояснит и не надо будет делать лишнее. Это конечно зависит от области/отрасли производства. Сначала реши чего ты хочеш.

← →
BiN © (2006-10-16 14:06) [17]

> По взрослому - с бизнес-плана начинать надо.

По-взрослому с ТЗ начинать надо.

← →
Думкин © (2006-10-16 14:07) [18]

> BiN © (16.10.06 14:06) [17]

Это смотря у кого какая взрослость. :)

← →
Sergey13 © (2006-10-16 14:09) [19]

> [17] BiN © (16.10.06 14:06)
> По-взрослому с ТЗ начинать надо.
А для этого сначала надо заказчика найти. 8-)

← →
Cash © (2006-10-16 14:55) [20]

Уф-ф-ф-ф... Ну вот... а мне места не оставили! :) Даже не знаю что и
добавить!

Nic ©, очень завидую, по белому! Ты и младше и не учился этой теме
спецально, а знаешь гораздо больше! Нет! Уйду, ей богу уйду на работу! :)

Думкин © (16.10.06 05:43) [14]:
Очень профессиональный подход! Это, на мой взгляд, единственно правильный
метод осмысления и постановки задачи.

Ученик чародея © (15.10.06 15:40) [13]:
Не менее правильный и не менее рациональный метод формализации задачи!

Alien1769 © (16.10.06 14:01) [16]:
Это пик! База! Без этого ответа нет смысла что либо писать!

А! Вот и наскреб на свой пост! ^^
Думаю, насколько уже стало ясно из комментариев, понятно, что я под
вышеперечисленными постами не подразумеваю решение одной проблемы.
Хотя все эти посты дают решение основного вопроса товарища cyborgа.
Надо только это привести к нормальной форме, нормализовать так сказать.

Итак! У товарища cyborgа есть задача, точнее ее словесное описание.
Что с ней надо сделать? Что ваще такое задача? Задачей мы можем назвать
неудовлетворение, не так ли? Неудовлетворение или чувство беспокойства.
Да уж блин, и как же это неудовлетворение закодить??? :)
Задачу необходимо осмыслить! То есть ответить на три вопроса:
- Каково условие задачи?
- Каково заключение задачи, что будет считаться результатом задачи.
- Каков критерий, позволяющий определить верен ли полученный результат.

Далее, уже осмысленную задачу надо бы формализовать. Т. е. записать ее
с помощью одного из формальных языков. Математика, логика, физика, или
библия Ктулху накрайняк! ^^
Ну? Записали??? Сразу видно, что задача уже кажется проще!

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

Во! Алгоритм есть. А как его записать? Для записи алгоритмов есть четыре
метода:
- алгебраический метод, основывается на представлении алгоритма в виде
равенств. В свою очередь делится на:
* операционный
* денотационный
* аксиоматический
- Табличный метод базируется на использовании таблиц решений.
- Графический метод, ну тут я думаю ясно!
- логический - базируется на использовании предикатов.

Ну, вот, хорошо, есть алгоритм и он записан! Можно вздохнуть спокойно,
переходим к любимому делу. Выбираем инструментальное средство
разработки, базовую систему работы ПС и условия его работы.
(т.е. компилятор, ОСь и мин. требования)
И только после этого садимся топтать клаву! :)

Я очень много пропустил, очень много недосказал, об очень многом не
объяснил. Ну дак, елы-палы :), мне это шесть недель читали, а я тут в
один пост впихнуть должен? ^_^

← →
Курдль © (2006-10-16 15:17) [21]

Забавно, что про заказчика т.е. того, кому этот проект реально нужен, упомянуто только в 16-м посте! :)

> Cash © (16.10.06 14:55) [20]

> Ну, вот, хорошо, есть алгоритм и он записан! Можно вздохнуть
> спокойно,
> переходим к любимому делу. Выбираем инструментальное средство
> разработки, базовую систему работы ПС и условия его работы.
>
> (т.е. компилятор, ОСь и мин. требования)
> И только после этого садимся топтать клаву! :)

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

← →
Alien1769 © (2006-10-16 15:45) [22]

> Забавно, что про заказчика т.е. того, кому этот проект реально
> нужен, упомянуто только в 16-м посте! :)

я шото темы не понял :))

← →
Cash © (2006-10-16 16:00) [23]

Курдль © (16.10.06 15:17) [21]:
Ну дак яж говорю, что о многом умолчал. В данном случае это значит,
что я умолчал о мно-о-о-о-о-(x256)-о-гом. :)
Просто дело в том, что я еще мало что помню. ^^

К концу семестра лектор книгу выпустить обещает, я себе уже заказал
с его личным автографом. :)

← →
Alien1769 © (2006-10-16 16:03) [24]

> К концу семестра лектор книгу выпустить обещает,

или методичку ?

← →
Cash © (2006-10-16 16:24) [25]

Выпускает не наша типография (не универская).
Одним словом, выйдет книга, дам наколку. Если интересно.

← →
Курдль © (2006-10-16 16:35) [26]

> Cash © (16.10.06 16:24) [25]
> Выпускает не наша типография (не универская).
> Одним словом, выйдет книга, дам наколку. Если интересно.

А event себе забить можешь? Шибко хочется почитать труды настоящих ученых по этому вопросу.

← →
Cash © (2006-10-16 18:12) [27]

Курдль © (16.10.06 16:35) [26]:
А еслиб я знал, что такое event... :) То наверное смог ба! ^^

← →
Jeer © (2006-10-16 18:28) [28]

> Курдль © (16.10.06 15:17) [21]
>
> Забавно, что про заказчика т.е. т

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

Если же чел делает штучные вещи, то, как говорится - "за дело отвечаю".

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

← →
Думкин © (2006-10-16 18:51) [29]

> Курдль © (16.10.06 15:17) [21]

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

← →
Cash © (2006-10-16 20:02) [30]

Думкин © (16.10.06 18:51) [29]:
> Странно но почему то многие считают, что тип проекта существует один - тот в котором он пашет.

Согласитесь, товарищь, так считают в основном те, кто знает о науке
разработки программных средств только по наслышке.

Шутка ли, когда я, будучи вооруженным этими знаниями, проанализировал
свои прошлые работы... Одним словом, метод проектирования с шагом назад
и алгоритмизаця методом исчисления задач. Ужасъ! :)

← →
cyborg © (2006-10-16 21:30) [31]

Главная мысль вопроса - как, чтобы в мусорную кучу не превратилось?
Поначалу всё получается, в середине получается, а под конец - мусорная куча. И так всегда почему-то получается :)

← →
Ketmar © (2006-10-16 21:35) [32]

>[31] cyborg(c) 16-Oct-2006, 21:30
как только начинает образовываться куча -- это сигнал, что пора перепроектировать с учётом ошибок и переписать.

← →
cyborg © (2006-10-16 21:35) [33]

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

← →
Kolan © (2006-10-16 21:47) [34]

> В конце концов получаетс чёрти что, вроде работает, но совсем
> не расширяемо

И тут приходит рефакторинг...

← →
Другой © (2006-10-16 21:59) [35]

cyborg © (16.10.06 21:35) [33]

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

← →
Ketmar © (2006-10-16 22:08) [36]

>[35] Другой(c) 16-Oct-2006, 21:59
>себе оправдание, что мол "пишите первую систему на выброс".
а я это опытным путём выяснил. %-)

← →
Kolan © (2006-10-16 22:09) [37]

> "пишите первую систему на выброс"

Если честно, после написания системы кажется что предшествующая только на выброс :)

← →
Ketmar © (2006-10-16 22:12) [38]

>[37] Kolan(c) 16-Oct-2006, 22:09
>Если честно, после написания системы кажется что
>предшествующая только на выброс :)
это нормально. %-) иначе бы было не "написание", а "расширение". %-)

← →
Думкин © (2006-10-17 05:55) [39]

> cyborg © (16.10.06 21:35) [33]

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

← →
ИА (2006-10-17 06:22) [40]

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

← →
Джо © (2006-10-17 06:39) [41]

I"m, похоже, stuck in 3-годичном проекте, с объемом ~100 тыс. строк. На рефакторинг сил не хватит, а наличие большого кол-ва "темных мест", о которых и вспомнить без содрогания невозможно — вводит в ступор. И сие наводит на мысль "писать отныне совсем-совсем по-другому"... :)

← →
Джо © (2006-10-17 06:39) [42]

В очередной раз :)

← →
Lamer@fools.ua © (2006-10-17 09:49) [43]

>пиши как считаешь нужным и учись на ошибках.

Умные, в отличие от дураков, учатся на своих ошибках.
А мудрые, в отличие от умных, учатся не только на своих, но и на чужих ошибках.

Мудрые, в конце концов, приходят к неизбежному выводу, что "все суета сует и всяческая суета" :)

← →
ИА (2006-10-17 10:12) [45]

>Умные, в отличие от дураков, учатся на своих ошибках.
>А мудрые, в отличие от умных, учатся не только на своих, но и на чужих ошибках.

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

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

← →
ИА (2006-10-17 10:32) [47]

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

Увы. Самый жуткий код что я видел в жизни был, э, результатом работы команды.

> Ведь в группе всегда есть свои корпоративные стандарты

Которые меняются раз в пол-года по назначению нового манагера.

>есть узконаправленные специалисты именно по проектированию (архитекторы).

Которые в жизни своей ничего лично не написали. Закон Паркинсона никто не отменял...

>Да и просто групповой подход всегда дает больше знаний каждому отдельному программисту.

Да, одна группа пишет базу, вторая - морду, третья - вебморду.

Впрочем, бывает и все не так плохо...

> ИА (17.10.06 10:32) [47]

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

> [46] Курдль © (17.10.06 10:20)

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

В проекте могут принимать участие и не программисты, а еще и дизайнеры и прочие напонители. В итоге, просто группы не получится.

> Джо © (17.10.06 11:01) [49]
> Вы, надеюсь, представляете, что метания группы по поводу
> "как же писать этот чертов проект" — вещь гораздо более
> жуткая (и по внешним проявлениям, и по последствиям), нежели
> те же метания у "одиночки"? :)

Да! Это наверное "душераздирающее зрелище" (с) :)
Однако, у группы, как правило, есть управляющая структура, включающая от спонсора проекта и управляющего комитета до проджект менеджера. И на любой из ступеней управления будет вполне логичным избавиться от "творческой группы", в которой существуют подобные метания.

> [51] Курдль © (17.10.06 11:12)
> И на любой из ступеней управления
> будет вполне логичным избавиться от "творческой группы",
> в которой существуют подобные метания.

Избавление от группы мятущихся даже в "полдень" проекта — вещь не менее душераздирающая, как по внешним проявлениям, так и по (катастрофическим) последствиям :)

> Джо © (17.10.06 11:39) [52]
> Избавление от группы мятущихся даже в "полдень" проекта
> — вещь не менее душераздирающая, как по внешним проявлениям,
> так и по (катастрофическим) последствиям :)

Тяжко, но не смертельно. Я был на одном проекте, где "в полдень" были выгнаны все субподрядчики из разных городов и даже стран(доля которых была в проекте 90%), срочно набраны специалисты, обучены и осертифицированны. В результате - все сдано в срок и даже с меньшими затратами.

Только один вопрос: что такое "осертифицированны"? Я серьезно.

> [56] Думкин © (17.10.06 11:51)
>
> > Джо © (17.10.06 11:47) [55]
>
> Сдали экзамен на сертификат. Например, по Ораклу.

А, спасибо.

← →
Petr V.Abramov (2006-10-17 14:12) [58]

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

> Тяжко, но не смертельно. Я был на одном проекте, где "в
> полдень" были выгнаны все субподрядчики из разных городов
> и даже стран(доля которых была в проекте 90%), срочно набраны
> специалисты, обучены и осертифицированны. В результате -
> все сдано в срок и даже с меньшими затратами.

Я тоже был. Тока разогнали не оутсорсинг, а департамент в москве с набором программистов в глубинке (начали с ростова на дону). В целях экономии. Фирму колбасило пол-года.

← →
Petr V.Abramov (2006-10-17 14:45) [60]

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

> свеженанятым сказать " все ж сделано до вас"

вам только чуток подправить :)

С чего начинать проект? Найти похожие ветки