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

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

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

Вопрос: есть ли у кого-нибудь опыт приведения в
порядок подобного проекта, если в нем участвует
только 1 человек?

Система работает с Oracle, есть средства разработки
бизнесс-логики, Java API, скрипты, exe файлы.

J>Вопрос: есть ли у кого-нибудь опыт приведения в
J>порядок подобного проекта, если в нем участвует
J>только 1 человек?

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

Здравствуйте, v111, Вы писали:

J>>Вопрос: есть ли у кого-нибудь опыт приведения в
J>>порядок подобного проекта, если в нем участвует
J>>только 1 человек?

V>Начни с установки системы контроля версий, узнай и пользуйся командой label (или аналогом), документируй изменения. Для одного человека больше и не надо ничего.

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

Не перестараться, но как минимум сделать так, чтобы и сам разработчик понимал и
другому программисту мог объяснить.

Здравствуйте, v111, Вы писали:

V>Начни с установки системы контроля версий, узнай и пользуйся командой label (или аналогом), документируй изменения. Для одного человека больше и не надо ничего.

и от этого в проекте сама собой заведётся грамотная архитектура?

BZ>и от этого в проекте сама собой заведётся грамотная архитектура?

гыгыгы, мне тоже смешно.

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

Здравствуйте, v111, Вы писали:

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

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

J>Это тоже, но сперва надо как-то следить за технологиями, выбирать нужные,
J>проектировать решение, разделить разработку на роли/этапы.

Word тут главная тулза. Документ, задающий правила игры (что-то типа development policy), там описаны технологии и вносятся изменения при решении использовать другие. Документ с требованиями, рисками, планом, бюджетом — на очередную версию (пусть это будет business requirements). Документ с дизайном тоже по одному на версию. Можно еще что-то типа release notes — какие реально изменения вошли в версию. Изменения текстовые связаны с реальными изменениями в коде в системе контроля версий через метки. Стараться каждую фичу, баг чекинить более менее законченным объемом, чтоб при просмотре истории чекинов было понятно какие куски кода менялись в связи с чем. Новые работающие версии приложения выпускать как можно чаще — не пытаться впихнуть кучу функционала за месяц в одну версию, лучше если кажд несколько дней будут добавляться несколько фич — проще проверять результаты работы приложения и распараллеливать задачи, если неск человек будут работать.

J>Не перестараться, но как минимум сделать так, чтобы и сам разработчик понимал и
J>другому программисту мог объяснить.

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

Здравствуйте, jeeist, Вы писали:

V>>Начни с установки системы контроля версий, узнай и пользуйся командой label (или аналогом), документируй изменения. Для одного человека больше и не надо ничего.

J>Это тоже, но сперва надо как-то следить за технологиями, выбирать нужные,
J>проектировать решение, разделить разработку на роли/этапы.

CMMI Development — http://ru.wikipedia.org/wiki/CMMI
Абстрагируясь от конкретных технологий таких как система контроля версий, язык моделирования и т.д., эта методология разделяет процесс разработки ПО на четко выделенные области, для каждой из которых существует набор входной информации и некий результат на выходе.

Здравствуйте, jeeist, Вы писали:

(рассказ о трудной судьбе поскипан )

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

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

полученную картину попытаться изобразить в чем-то типа visio (варианты: rose, dia...).

это про архитектуру.

теперь про планирование процесса.
(я тут уже писал) берем лист бумаги. на нем проводим линию. это время. ставим на линии точки с метками, типа здесь будем деплоить модуль 1, здесь будем деплоить фикс, здесь будем тестировать новомодную фишку.
если(!) приходит понимание последовательности шагов, берем че-то типа ms project (аналоги не помню) и расписываем красивую картину проекта.

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

где-то так.
p.s. а нафига?
во

Здравствуйте, BulatZiganshin, Вы писали:

BZ>и от этого в проекте сама собой заведётся грамотная архитектура?

А с чего она заведется?
И так ли ценна грамотная архитектура в проекте на одного человека?

А поставить нормальную систему контроля версий и навести порядок в коде — это ценно в любом случае.
Это конечно не весь процесс, но твоя ирония совершенно не по делу.

Здравствуйте, v111, Вы писали:

V>Архитектуру конечно описать, можно даже красивую картинку с прямоугольничками и овальчиками туда запихнуть. Но все равно самый главный источник информации о системе — исх код. Должна поддерживаться легко прослеживаемая связь между изменением в тексте требований и соотв изменением в коде.

1) выделенное доказать сможете?
2) значит код зависит от другого, требований например?
3) вопрос был про архитектуру. код влияет на архитектуру, или наоборот?
во

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

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

В качестве тула можно использовать UML.

V>>Архитектуру конечно описать, можно даже красивую картинку с прямоугольничками и овальчиками туда запихнуть. Но все равно самый главный источник информации о системе — исх код. Должна поддерживаться легко прослеживаемая связь между изменением в тексте требований и соотв изменением в коде.

B>1) выделенное доказать сможете?
А зачем? Мне это очевидно, кому нет — на здоровье, сколько людей столько и мнений :-]

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

B>2) значит код зависит от другого, требований например?
Когда к идеальной сферической системе приложен полный и исчерпывающий набор документов с требованиями, постоянно синхронизируемыми идеальным сферическим аналитиком-дизайнером-разработчиком, согласен. В реальном мире документируется дай бог процентов 60 (ну пусть 80) функционала, и реальное состояние постоянно от содержимого документов вместе с фиксами и мелкими доделками уплывает.

B>3) вопрос был про архитектуру. код влияет на архитектуру, или наоборот?
Вопрос был про процесс, про архитектуру в гайдлайнзы к аффтарам всяких ms .net frameworkoфф, enterprise library, книг по архитектурным паттернам и заметкам Торвальдса (и тд и тп) В форум с такими вопросами по-моему не стОит

Спасибо за ответы!
Хотя слова "процесс" и "архитектура" мне, похоже, не следовало упоминать
Это актуально, но не самое актуальное.

J>Система работает с Oracle, есть средства разработки
J>бизнесс-логики, Java API, скрипты, exe файлы.
Уточню:
Саму систему трогать нельзя. Есть бизнес-логика —
можно добавлять rules (типа триггеры или обработчики событий).

Нужно посылать сообщения с использованием данных системы (несколько видов).

Проблема в том, что возможности rules ограничены, поэтому
часто надо вызывать exe файлы, скрипты или веб-страницы.

Это открывает новые возможности, но слишком неограниченные
1 вариант — это несколько VBScriptов, которые подключаются к Oracle.
2 вариант — Программы (C#, .NET) вызывают веб-сервис Axis (Java EE, JDBC на Tomcat).
3 вариант — все делают JSP и постоянно работающие Beans (Java EE, JDBC на Tomcat).
4 вариант — все делает просто JSP (Java EE, JDBC на Tomcat).

Вопрос, как следить за разными технологиями, изучать их, но так,
чтобы не приходилось 4 раза переписывать систему, позже осознавая, что правильно
было бы выбрать 1 вариант?

J>Спасибо за ответы!
J>Хотя слова "процесс" и "архитектура" мне, похоже, не следовало упоминать
J>Это актуально, но не самое актуальное.

Да уж, всех обманул

J>Это открывает новые возможности, но слишком неограниченные
J>1 вариант — это несколько VBScriptов, которые подключаются к Oracle.
J>2 вариант — Программы (C#, .NET) вызывают веб-сервис Axis (Java EE, JDBC на Tomcat).
J>3 вариант — все делают JSP и постоянно работающие Beans (Java EE, JDBC на Tomcat).
J>4 вариант — все делает просто JSP (Java EE, JDBC на Tomcat).

Думаю тебе в вебдевелопменте надо это все спросить. Там перцы как раз такими вещами озадачиваются.

J>Вопрос, как следить за разными технологиями, изучать их, но так,
J>чтобы не приходилось 4 раза переписывать систему, позже осознавая, что правильно
J>было бы выбрать 1 вариант?\

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

А пока про систему ни фига не ясно, выбрать один из 4-х способов ее реализации можно подкидыванием монетки.

На самом деле все достаточно просто. Есть текст сообщения, типа "Задание <ID/> выполнил <EMPLOYEE/>", есть
запрос типа SELECT ID, EMPLOYEE FROM TASKS WHERE ID=12345.

Выполняю запрос, обрабатываю текст, отправляю сообщение, записываю что-то в лог-файл.

Желательно так, чтобы можно было "передать дела" следующему администратору,

В результате пришел к выводу, что с Java/Java EE проблем не меньше плюс
такую систему далеко не каждый освоит, так что лучше не умничать и
использовать скрипты.

По-этому я имел ввиду не "тот" процесс, а процесс оценки разных технологий
и решений как в этом примере.

J>>Это открывает новые возможности, но слишком неограниченные
J>>1 вариант — это несколько VBScriptов, которые подключаются к Oracle.
J>>2 вариант — Программы (C#, .NET) вызывают веб-сервис Axis (Java EE, JDBC на Tomcat).
J>>3 вариант — все делают JSP и постоянно работающие Beans (Java EE, JDBC на Tomcat).
J>>4 вариант — все делает просто JSP (Java EE, JDBC на Tomcat).

V>Думаю тебе в вебдевелопменте надо это все спросить. Там перцы как раз такими вещами озадачиваются.

J>>Вопрос, как следить за разными технологиями, изучать их, но так,
J>>чтобы не приходилось 4 раза переписывать систему, позже осознавая, что правильно
J>>было бы выбрать 1 вариант?\

V>Вопрос — что реально нужно от системы (насколько она должна быть масштабируемой, насколько она будет большой сама по себе, будут ли правила часто меняться и тд). Когда поймешь что должна из себя представлять система, уже можно углубляться в технические детали и выбирать подходящее решение.

V>А пока про систему ни фига не ясно, выбрать один из 4-х способов ее реализации можно подкидыванием монетки.

В принципе всю функциональность можно описать
3-5 строчками+каждый объект типа DataChanger:

params=getParams();
queryResult=DataFromDatabaseGetter.processQuery(query, params);
processedMessage=Replacer.replace(message, result);
sendResult=MailSender.send(processedMessage)
Logger.log(sendResult);

params=getParams()
dataChangeResult=DataChanger(operation, params);
Logger.log(dataChangeResult);

Проблема в основном в том, что изменять данные
можно через Java API или программу импорта XML файлов.

Иначе все можно было бы реализовать (почти) элементарно
и очевидно.

Здравствуйте, v111, Вы писали:

V>>>...самый главный источник информации о системе — исх код.

B>>1) выделенное доказать сможете?
V>А зачем? Мне это очевидно, кому нет — на здоровье, сколько людей столько и мнений :-]

гм... ок. принято.

V>Потому что система и есть результат обработки ее исх кода, больше в ней ничего нет и взяться неоткуда

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

вот сейчас я сижу и пытаюсь врубиться в новый для меня проект. самые старые файлы — 2001 года. пол-гига исходников. 20 тысяч файлов классов. так вот я совершенно не согласен, что для меня правильный путь понимания работы системы — чтение исходных кодов.

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

V>>Потому что система и есть результат обработки ее исх кода, больше в ней ничего нет и взяться неоткуда

B>если мы считаем, что система работает так, как ее написали в коде — то да.
В каждый момент времени именно так и работает ;-]

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

B>вот сейчас я сижу и пытаюсь врубиться в новый для меня проект. самые старые файлы — 2001 года. пол-гига исходников. 20 тысяч файлов классов. так вот я совершенно не согласен, что для меня правильный путь понимания работы системы — чтение исходных кодов.

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

Здравствуйте, v111, Вы писали:

J>>Вопрос: есть ли у кого-нибудь опыт приведения в
J>>порядок подобного проекта, если в нем участвует
J>>только 1 человек?

V>Начни с установки системы контроля версий, узнай и пользуйся командой label (или аналогом), документируй изменения. Для одного человека больше и не надо ничего.

А если речь идет в основном о бизнес-логике, правах?
Есть возможность экспорта/импорта с помощью XML,
но объем несколько мегабайтов и бизнес-логика зашифрована.