Теория разработки проектов

[craz]

Есть множество практик, описывающих те или иные способы создание систем. Такие как TDD, XP и наверное еще множество других.

Так же существует множество учебников по самому языку, по его парадигмам и паттернам проектирования на нем.

Но существуют ли источник описывающие создание систем с нуля? (Если знаете ссылки поделитесь)
Не будем вдаваться в частности о ТЗ, предположим, что все таки для ТЗ, выбрана модель XP. То есть требования к системе составляются во время проектирования.

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

Как бы я себе представлял себе такие рекомендации

1) Создание структуры проекта
а) такая-то такая-то структура позволит то-то
б) в данной структуре имееться возможность того-то того-то, но в тоже время то-то и то-то совсем не явно.

Опять же как пример, большинство хоть каким-то образом, но видело ZF: есть соглашения по структуре проекта, соответственно которой строиться скелет и т.д. Но в тоже время подходя к решению уже конкретных вопросов, таких как например работа с таблицами users/profiles/posts - обычная "социалка". Должна создаваться модель для работы с данными. Создаваться контроллере и виды оттображения. Все эти действия понятны. Если учесть что решается частная задача. Но в тоже время если решать комплексную задачу возможно есть более общий подход?

К примеру, создавать скелеты интерфейсов, скелеты моделей. На выходе, получая пустые объекты, способные что-то делать, не не оперирующие данными..

Короче как правильно какие шаги?

 

[atv]

Но существуют ли источник описывающие создание систем с нуля?

В начале было слово...

Разработка, это есть решение задачи. Если нет условия задачи, от какое может быть решение?... Пойди туда не знаю куда, принеси то не знаю что.

выбрана модель XP. То есть требования к системе составляются во время проектирования.

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

Как бы я себе представлял себе такие рекомендации

Ты про какую структуру, файлы на диске? Да хоть в одной директории сложи, функциональность проекта порносайта это не ограничит

 

[Mols]

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

 

[craz]

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

К примеру задача, написание CMS. К этой задаче прилагаются "хотелки"/"блювалки" от других существующих CMS - в итоге задача не формализована, а состоит из листа требований, ТЗ как такового нет, или если есть это ТЗ проект-менеджера: вода замешанная на воде ну вы знаете... То есть технический аспектов нет ни в каком виде, я считаю - это практически Пойди туда не знаю куда, принеси то не знаю что. - Но согласитесь, это не может никак влиять на конечный вариант.

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

+1, но
Я считаю что именно составляются приняв во внимание предыдущий пример, получаем на входе "Хочу CMS", первая итерация, к примеру CMS, с шаблонизатором на xslt, на выходе какой-то свой новый формат шаблонизации - требования не уточняются, а именно заводятся новые.

Ты про какую структуру, файлы на диске? Да хоть в одной директории сложи, функциональность проекта порносайта это не ограничит

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

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

Именно этого опыта я и попытался почерпнуть своим вопросом.

 

[Mols]

Именно этого опыта я и попытался почерпнуть ...

Сам такой же)))
Хочется почерпнуть... ищу где, но пока безрезультатно.

 

[craz]

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

 

[grigori]

кто ж тебе серьезно ответит на серьезный вопрос после всей лажи, что ты пишешь

 

[craz]

кто ж тебе серьезно ответит на серьезный вопрос после всей лажи, что ты пишешь

На Вас и не рассчитывал в принципе.

p.s. каюсь, на работе пока скучно, когда нет холиваров а все ньюсы прочитаны так и подмывает написать какую нить фигню чтоб кого нить цепануть) "Человек на Луне" - хороший фильм)))

 

[Mols]

grigori
Мне ответьте )))
У меня тот же вопрос.
Думаю тут у 95% такой вопрос или есть или будет.
Ну или уже был, но через время будет ещё не один раз

 

[craz]

grigori
Мне ответьте )))
У меня тот же вопрос.
Думаю тут у 95% такой вопрос или есть или будет.
Ну или уже был, но через время будет ещё не один раз

Надо было дописать "Умоляем ответьте"!

 

[grigori]

в принципе, это неплохая тема для мастеркласса на devconf ...

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

вообще, тема довольно объемная

 

[craz]

в принципе, это неплохая тема для мастеркласса на devconf ...

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

вообще, тема довольно объемная

это проектирование на стадии начала - это даже не составление UML диаграмм классов и EER(M) бд.
Кстати UML и EER я бы тоже не стал рассматривать как часть принадлежащую больше к повествованию о будущей разработки, нежели к самой непосредственной разработке
Вот они очертили круг идеологических проекций системы, дальше что?
По сути вы говорите о том, что они составили ТЗ кстати, но представим себе тимлида=генератора идея, в таком случае время на передачу идеи в голову тимлида не потребуется, все спецификации уже сформированы, а если даже не сформированы, то не нужны для контроля из вне, ибо как я понимаю контролировать себя лучше не по спецификациям, так?

 

[Adelf]

ERP-схем бд

TDD, XP

У тебя похоже большая каша из аббревиатур в голове.

контролировать себя лучше не по спецификациям, так?

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

 

[craz]

У тебя похоже большая каша из аббревиатур в голове.

Конкретнее пожалуйста, без скатывания топика во флейм?

Да не ERP - ошибся EER(M) должно быть(надо было все таки слазить в гугл)

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

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

 

[grigori]

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

потом по выбранной модели разработки начинается собственно работа

 

[craz]

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

потом по выбранной модели разработки начинается собственно работа

Иметься ввиду ТЗ не менеджера-проектов я так понимаю. В таком случае может быть кто-то имеет бесконечное кол-во доброты, чтобы показать ТЗ системы на php, из которого были бы понятен сабж топика?

 

[Mols]

grigori
Можно было сказать короче.
"Определяетесь со всеми важными моментами и начинаете"
Только есть мнение, что "потенциально узкие места" всё ж таки лучше не искать.
А мониторить по факту.

 

[craz]

grigori
Можно было сказать короче.
"Определяетесь со всеми важными моментами и начинаете"
Только есть мнение, что "потенциально узкие места" всё ж таки лучше не искать.
А мониторить по факту.

ага или даже так
1. Идея
2. ТЗ
3. ???????
4. PROFIT

 

[Adelf]

Конкретнее пожалуйста, без скатывания топика во флейм?
....
Сам с собой я разговариваю в таком состоянии в котором о программировании речи идти не может.

Кто еще во флейм то скатывается...

Я когда разрабатываю "свои" проекты(их всего два пока) начинаю с пустого листа в OpenOffice.org Writer. Вначале идет описание идеи без программирования. Что? Зачем? Кому нужно? Сколько таких? Юз-кейсы... Есть понятие "бизнес-план", но я не знаю что там конкретно описывают. Пишу для себя.
Потом идет документ технический. Там описывают все те моменты, которые не выглядят очевидными.
При написании идет большой диалог в голове. С самим собой. Такой формализм очень помогает отметать идиотские идеи, а нормальные обтачивать, удаляя ненужное и придумывая нужное.
Когда придумывается группой(типа "брейншторм", бывают такие, и технические тоже) - тут полезность формального описания идеи возрастает. У себя в голове некоторые гении и могут удержать свои мысли. А мысли нескольких очень сложно запомнить каждому.

Дальше из документов уже вырастают либо роадмап(как было на первом), либо тупо забиваются крупные таски в redmine(как на втором).

Чем больше народу работает над проектом, тем больше важность спек. Я сейчас участвую в проекте.. на написание спек трачу больше времени чем на собственно implementation. Хз правильно это или нет, но так люди работают и у них(заказчиков моих) хорошо получается.

 

[Mols]

craz
Ну стеб стебом, но по сути на форуме более детального чем "ТЗ, выбираем, определяемся, рисуем...." ждать глупо.
И даже если и кто-то отважится что-то писать. (допустим, что этот "кто-то" действительно в силах это сделать), то один фиг это нереально.
ИМХО только практика.
Жаль только, что таких организаций по пальцам... по крайней мере в Донецке я таких не знаю.