Организация работы над большим проектом

← →
lipskiy (2002-06-12 00:21) [0]

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

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

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

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

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

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

Спасибо.

← →
drpass (2002-06-12 00:38) [1]

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

//todo 1 -oLipskiy -cИнтерфейс : Добавить сообщение об ошибке

В любое время, открыв Todo list, ты сможешь найти это место в тексте и вспомнить, что там нужно сделать.
Во-вторых, не ленись использовать мастер диаграмм Delphi - это не только интересное и бесплатное CASE-средство, но и хорошая вещь для документирования структуры модуля.
В третьих, документируй процедуры, для этого может пригодиться мастер из GExperts, который вставляет заголовки комментария.
Ну и, честно говоря, вообще трудно вести проект, который делается "не в основное рабочее время". Лично я с большим трудом переключаюсь между задачами. Еще хуже, чем Windows 2.10 :)

← →
Agent Smith (2002-06-12 09:17) [2]

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

← →
NailS (2002-06-12 14:11) [3]

Просто два слова
Rational Rose

← →
iZEN (2002-06-12 18:28) [4]

Просто две фразы:
Extreme Programming и UML-рефакторинг.

Ресурсы:
http://www.xprogramming.ru/
http://xp.mchook.net/

← →
lipskiy (2002-06-13 01:37) [5]

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

drpass © (12.06.02 00:38)
Насчет комментариев о недоделках. Блин! Спасибо! Такие комментарии я давно приучился делать, но я не знал что в IDE есть для этого сервис - ToDoList. Обязательно переделаю под него все свои пометки. Что интересного с этим листом можно делать? Смотреть список, зачеркивать, быстро переходить к месту в коде, добавлять новую пометку, еще что-то? Кстати, где задать список категорий, само запоминается только одно последнее, каждый раз вводить?
Хорошая вещь этот ToDoList, спасибо еще раз.

> Во-вторых, не ленись использовать мастер диаграмм Delphi
!!! Я вообще никогда не ленюсь что-то упорядочивать, ораганизовывать, структурировать и т.п. Этим я люблю заниматься и считаю что это необходимо делать в любой работе. Но не всегда я знаю как именно это сделать. Еще раз сорри за серость - что за мастер диаграмм??? Это где, как? Я кажется опять что-то очень интересное пропустил...

> документируй процедуры, для этого может пригодиться мастер из GExperts
Имеется ввиду тотальное комментирование кода? О, к этому я тоже давно себя приучил. Если не об этом, то о чем? А что за мастер из GExperts?

> Ну и, честно говоря, вообще трудно вести проект, который
> делается "не в основное рабочее время". Лично я с большим
> трудом переключаюсь между задачами. Еще хуже, чем Windows
> 2.10 :)

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

Agent Smith © (12.06.02 09:17)
Если не ноу-хау, можешь рассказать об этой схеме, как ты ее строишь? Можно на мыло. Про бумагу согласен полностью, единственное, что мне в этом не нравится - при многократном редактировании сильно изнашивается носитель.

NailS © (12.06.02 14:11)
Ох, не силен я в английском...

iZEN (12.06.02 18:28
Аналогично - смысл слов не дошел.
А насчет экстремального программирования я раньше уже читал. Это слишком глобально и ориентировано в основном на командную работу. Но кое-что полезного можно почерпнуть и оттуда.

Спасибо всем за все!
Но вопрос мой еще не закрыт :)
Если че - пишите :)

← →
Agent Smith (2002-06-13 07:46) [6]

2lipskiy
Могу по-подробней. Когда я только задумал проект, у меня не было возможности начать сразу его реализовывать и поэтому я начал его продумывать, развивать идеи. И так получилось, что сначала я хотел сделать интерфейс программы (а она не маленькая!)полностью русским, потом пришла мысль сделать его на английском, а еще через некоторое время захотел сделать так, чтобы я в любой момент смог сделать локализатор к моей проге на любой язык, поэтому решено было создать файл локализации, на подобии ini-файла и считывать из него все caption. А потом я представил себе, что если бы эта мысль напала бы на меня месяцем позже, то мне пришлось бы убить пару дней на переделку всего этого. Вот поэтому я и рекомендую составлять такие схемы. На счет их структуры. Опыта составления этих схем у меня не много, но все же могу кое-что посоветовать: желательно составить несколько схем по разным частям программы, или просто по разной направленности. Также удобно создать одну главную схему, в которой описывается вся программа в целом с ссылками(!) на другие, более локальные и подробные схемы. Опять же говорю: в схемах больщой упор нужно делать на настройки программы, чтобы знать, откуда что считывается. Приведу пример: ты хочешь запоминать положение нескольких форм на экране и считывать это из специального ini-вайла (или реестра), причем делать это или нет выбирает юзер в настройках твоей программы. А за настройки ты, допустим, еще не брался, а когда настанет очередь настроек, боишься забыть про формы или что-то перепутать. Вот по-этому в на самом старте проекта ты можешь создать ini-файл(или раздел в реестре), забить его исходными (пока не изменяющимися данными) и прописать считывание этих данных при запуске программы. Разумеется, еще ничего работать не будет, но ты можешь записать в схему имя ini-файла (или раздела в реестре:) и указать, что откуда считывается настройка. В дальнейшем, когда руки дойдут до настроек в программе, ты просто заглядываешь в схему и видишь адрес, откуда эти настройки считываются, следовательно ты знаешь, куда их нужно записывать. Удачи!
ЗЫ: Если будешь реализовывать такой метод, потом намыль мне, хочу узнать, стоит ли рекомендовать его кому то еще :)

← →
Виктор Щербаков (2002-06-13 09:24) [7]

to lipskiy ©
А может тебе сюда?
http://www.nexus.odessa.ua/files/books/booch/
Очень хорошая книга. Должна помочь в организации проекта.
Лично я, когда начинаю говорить о ней, говорю с междометиями и без падежей. Так что смотри сам.

← →
lipskiy (2002-06-13 19:45) [8]

2 Agent Smith
Спасибо, надо обмозговать, идея ясна.
Только вот конкретно - как это нагляднее ты рисуешь? Я кроме блок-схемы и просто текста ничего другого не представляю...

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

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

← →
Китаец Ла Ме (2002-06-13 20:09) [9]

2lipskiy
в паскале не было событий.
Интересно, как правильно рисовать БСхемы с событиями?
:)

← →
Shaman_Naydak (2002-06-13 21:14) [10]

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

Так что советую воспользоваться Power Designer 9 (обрати внимание на версию) от Sybase..

← →
lipskiy (2002-06-13 22:33) [11]

2 Китаец Ла Ме
Вот уж тут проблемы не вижу. Событие - это не есть что-то принципиальное иное, нежели свойство или метод. Сами события можно вообще не рисовать, а рисовать только их обработчики.

2 Shaman_Naydak
А иде-ж такую взять? На ихнем сайте только седьмая, и за деньги...

← →
iZEN (2002-06-15 00:31) [12]

Для lipskiy.
Без теории никуда.
См. книжки по проектированию на моей страничке
http://www.beep.ru/~izen/
в разделе "Ссылки"->"Библиография"->"Разное".

Советую обратить внимание на следующие книги:
1. "Приемы объектно-ориентированного проектирования. Паттерны проектирования" Гамма, Хелм, Джонсон, Влиссидес;
2. "Экстремальное программирование" К. Бек;
3. "Объектно-ориентированный анализ и проектирование с примерами приложений на C++" Гради Буч;
4. "UML. Основы", 2-е издание М. Фаулер, К. Скотт;
5. "Язык UML. Руководство пользователя" Г. Буч, Д. Рамбо, А. Джекобсон;
6. "Унифицированный процесс разработки программного обеспечения" А. Якобсон, Г. Буч, Дж. Рамбо.

Советую читать в порядке: 3, 4, 1, 2 и др..

← →
iZEN (2002-06-15 00:39) [13]

/**Agent Smith © (13.06.02 07:46):
<...>так получилось, что сначала я хотел сделать интерфейс программы (а она не маленькая!)полностью русским, потом пришла мысль сделать его на английском, а еще через некоторое время захотел сделать так, чтобы я в любой момент смог сделать локализатор к моей проге на любой язык, поэтому решено было создать файл локализации, на подобии ini-файла и считывать из него все caption. А потом я представил себе, что если бы эта мысль напала бы на меня месяцем позже, то мне пришлось бы убить пару дней на переделку всего этого.<...>
*/

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

← →
Agent Smith (2002-06-15 06:44) [14]

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

← →
Agent Smith (2002-06-15 07:02) [15]

lipskiy, помнишь, как в школе на уроках истории рисовали схемы правления царей и т.п.? Вытаскиваем из принтера не использованный:) лист бумаги, чертим в центре квадрат(или что-нибудь иное, по вкусу). Он обозначает главный модуль и главную форму. От него идут стрелки к другим квадратам (другим модулям и формам), ес-но стрелки подписяваются. Например стрелку от главного квадрата к квадрату формы настроек можно подписать так: "чтение настроек из файла "ххххх.ххх"". Если что-то не влезает в лист(а по идее так и должно быть), то стрелку ведем к границе листа. Там, у этой самой границы, даем ссылку на др. отдельный лист. И все в этом духе. Желательно сделать отдельный лист, в котором простым текстом записываются идеи, которые ты хочешь реализовать, но обдумывать их пока не имеет смысла, т.к. недостаточно данных. А потом с других листов давать ссылки на этот лист+номер идеи. Разумеется это только основа схемы, в работе появляются новые решения и их можно отобразить на бумаге.

← →
iZEN (2002-06-15 08:22) [16]

Для Agent Smith © (15.06.02 06:44).

Ну, например в Java можно пойти двумя путями.

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

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

Но возникают вопросы другого плана: слово на разных языках может иметь различную длину -- отсюда "плавающий" интерфейс.

← →
Agent Smith (2002-06-15 10:25) [17]

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

← →
Agent Smith (2002-06-15 10:26) [18]

iZEN, по-моему, мы немного отклонились от темы ветки...

← →
iZEN (2002-06-15 10:41) [19]

По теме:
http://www.maxkir.com/sd/methyperproject_RUS.htm

Организация работы над большим проектом Найти похожие ветки