| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Системный анализ, проектирование и UML > Разбор большой задачи на простые, по которым |
| Автор: КунгФуЧайник 28.11.2012, 13:03 |
| Надесь, запостил в правильную ветку. В основном всегда так: нужно написать программу (даже небольшую), пишу кучу процедур-функций, проверки разные (от дурака, в основном), чтобы кнопка выбора файла была доступна, только если программно не найден файл и т.п. Так трачу день, два - и все равно никак не получу результат. Чувствую, что нет движения, что затянуло, как в болото. В результате через неделю бросаю. Недавно было так: нужно написать внешнюю обработку (начинающий 1сник), после раздумий определил, какие процедуры ключевые, т.е. которые не просто дадут видимый результат, а приблизят работу к завершению (а все остальное - как бы надстройка, обвес, смысла от которого без этого "ядра" никакого, пустая трата времени). Далее, после того, как добавил в код такие процедуры, осторожно выбираю, какую процедуру написать следующей, чтобы меня опять не засосало в болото (до этого бывало даже так, что, не дописав одну процуедуру, брался за другую - потому что оказывалось, что для того, чтобы ее дописать, нужна другая процедура, либо результат, полученный от другой процуедуры, а та другая процедура еще и близко не написана). И так потихоньку продвигаюсь. Побочный эффект офигенный - чувствую, что не зря трачу время, выше самооценка, готов писать в режиме нон-стоп. Но опыта в построении списка задач таким образом у меня нет, поэтому все время скатываюсь к болотоу, стоит только перестать контролировать себя. Скорость в итоге очень низкая. Есть ли какие-нибудь правила, рекомендации, методики, чтобы научиться: определять, из каких задач состоит будущая программа, в какой последовательности их выполнять и какие выполнять в первую очередь, чтобы видеть, что разработка каждый день продвигается? з.ы. Интересует "серьезная" разработка: крупные программные проекты на с, с++ и т.п. языках. |
| Автор: Cтpaнник 7.5.2013, 13:26 |
| Ключевое для тебя понятие: декомпозиция. А вообще, разработка идет обычно таким путем: Сбор требований -> Анализ -> Разработка архитектуры (подсистемы, отдельные функциональные модули...) -> Проектирование (классы, функции...) -> Кодирование -> Тестирование и отладка -> Сборка. И вот при таком порядке разбить даже большую работу на этапы с ясно обозначенными целями и критериями их достижения уже нетрудно. У тебя же, судя по всему, разработка начинается сразу с кодирования..... |
| Автор: ida 23.5.2013, 12:08 | ||
Устройтесь на работу. Там даже обезьяна за полгода научится ) |
| Автор: КунгФуЧайник 23.5.2013, 17:16 | ||||
Про декомпозицию знаю. Но не достает практики, чтобы навык сформировать.
Не в моем провинциальном городе. И не с моим скудным навыком программирования. |
| Автор: ida 30.5.2013, 23:15 | ||
К сожалению, тогда вам ничто не поможет. Или точнее так - тогда вас не интересует серьезная разработка, не обманывайте ) |
| Автор: КунгФуЧайник 31.5.2013, 12:21 | ||
Вы правы, не интересует. Извиняюсь, что ввел в заблуждение - меня интересует именно превращение задачи из бесформенного состояния, когда не знаешь, с какой стороны подступиться и с чего начать, в понятную и четкую структуру: из каких элементов состоит, как взаимодействуют между собой, с чего начать делать. Мне думается, что такими задачами могут быть не только программы (простые и сложные), но и алгоритмы. Мне это интересно больше с точки зрения логики (анализа, проектирования - не знаю, каким словом правильнее назвать), чем с точки зрения программирования. Но, так как есть интересные задумки, а знакомых программистов нет и нет возможности заказать фрилансерам, то и разработкой приходится интересоваться. |
