Как не запутаться на этапе программирования задачи?

[Алексей_2012]

Ребят, давно задавался вопросом, собственно сначала мои рассуждения....

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

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

Ручку и листок бумаги никто не отменил, конечно, но все же хочется интерактивности...

Извините, старался доступно объяснить, я надеюсь меня поняли)

[f.hump]

захотел сделать одно, сделал, добавил другое - нужно переделывать первое.

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

[Алексей_2012]

Отлично сказано, вот интересно, а системные аналитики так же рассуждают? Если я не ошибаюсь, то они тоже заняты программированием своей же задачи+распределение ролей в команде)

Так что мой вопрос вполне легален и имеет право на жизнь.

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

[Utkin]

вот интересно, а системные аналитики так же рассуждают?

Нет, у них есть хитрый план, строгое выполнение которого и должно приводить к успеху.

Если я не ошибаюсь, то они тоже заняты программированием своей же задачи+распределение ролей в команде)

Чистая профессия исключает программирование. Это уже совмещение ролей.

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

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

и всегда приходится что-то дорабатывать.

Если проект требуется дорабатывать не после эксплуатации, а во время сборки/программирования значит Вы не составили план проекта и/или не занимаетесь его управлением.

[Smitt&Wesson]

Сообщение от Алексей_2012

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

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

[MihalNik]

Сообщение от Алексей_2012

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

М.Фаулер - Рефакторинг.
И всякие "гибкие методологии".

Сообщение от Алексей_2012

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

См. UML

[Алексей_2012]

Ms Visio или bpwin проще на ваш взгляд?

[Utkin]

Ms Visio или bpwin проще на ваш взгляд?

Не проще - это очень общий взгляд на систему.
Для проекта - UML (бесплатно ArgoUML)
По UML пишите ТЗ и спецификацию (дополнительно вся документация, что не вошла в ТЗ, например, правила именования переменных/методов/классов, виды нотаций, оформления кода, правила/порядки/инструкции, методика работы с системой контроля версий и пр.).
для управления проектом - Project Expert (бесплатно - Project Libre)

[Pavia]

ISO 9000
ГОСТ

Оба стандарта говорят что проект проходит несколько стадий. И на каждой стадии проект переписывается. Так что с этим надо смериться.

В программировании часто приходится поддерживать проект, дорабатывать развивать его. Поэтому подходы описанные в ISO и ГОСТ не годятся.

Тут всё просто надо научиться планировать своё время.
Не спешите выполнять задачу. Выписываете все новые задачи в список.
Раз в день, неделю, месяц, четверть года. Вы пробегаетесь по списку дел и выбираете те, которые надо выполнить в ближайшее время. А есть те на которые не нужно тратить своё время.

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


Как определить нужные задачи? Основной критерий это деньги. Их легко перевести в трудозатраты (человеко/часы). Но в любом случае нужно ТЗ. Которому надо следовать и не делать того что выходит за рамки ТЗ.

А вот что-бы не запутаться в проекте нужно его документировать. Для этого придумано множество различных схем. Все схемы можно найти в стандарте UML.
"Гради Буч, Джеймс Рамбо, Ивар Якобсон-Язык UML. Руководство пользователя-ДМК Пресс (2006)"
"Гради Буч-Объектно-ориентированный анализ и проектирование с примерами на С++-Невский Диалект (2000)"
Вторая книга-честно не очень удачная.
А рисовать схемы лучше в Ms Visio 2012 и более новых версиях.

А для того что-бы не переделывать программы есть хороший подход использовать патерны.
(Библиотека программиста) Э. Гамма, Р. Хелм, Р. Джонсон, Д. Влиссидес-Приемы объектно-ориентированного проектирования. Паттерны проектирования-ДМК Пресс (2010)
Если в них поверить, то они значительно облегчат вашу работу.

[Utkin]

Оба стандарта говорят что проект проходит несколько стадий. И на каждой стадии проект переписывается. Так что с этим надо смериться.

Это только вариант. Вы не обязаны его придерживаться. Но чего-то придерживаться все равно надо

Если в них поверить, то они значительно облегчат вашу работу.

В них нужно не верить, а иметь опыт использования. Только потом уже можно будет на них опираться в работе.