Советы по реализации проекта

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

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

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

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

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

Хотелось бы увидеть различные советы по поводу того, как бороться с этой проблемой.
Что нужно делать, или с чего вобще стоит начать, чтобы грамотно сверстать проект, если ты лишь мысленно понимаешь суть алгоритма (задачи), который нужно реализовать (решить)?
Или нужно перед стадией написания кода сидеть n-ое кол-во часов(дней) обдумывать в точности как алгоритм будет реализован на ЯП или заниматься теоритическим проектированием класса (классов) посредством составления UML-диаграмм или что там сейчас для этих целей используется?

0

Ferrari F1, Вот мне кажется, что когда ты садишься уже непосредственно писать код, то ты уже должен понимать, что он будет содержать, а не

Сообщение от Ferrari F1 что придет в голову, то и пишу

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

0

Вопрос еще не снят

0

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

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

1

Evg, спасибо за ответ.
Хотел бы еще мнений... например, magirus'а или DrOffset'а

0

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

это - годный подход.
в миру ещё называется "прототипированием".
я его ещё иногда называю: "щенки и котята".

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

значит нужно поиметь опыт.
значит нужно потренироваться на кошках.

самое главное - не тратить на прототип много времени.
можно смело забить болт на любые проверки,
забить на delete,
и писать goto хоть в каждой строке.

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

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

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

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

здесь есть два пути:

1.
на решение задачи изначально выделяют доп.
время на неизбежный рефактор.
такое практикуют школы TDD

2.
работает? отлично.
все, забейте и не парьтесь.
в след. раз напишите лучше.

1

hoggy, ваши слова обнадеживают)

0

Сообщение от Ferrari F1 Хотел бы еще мнений...

Я солидарен с hoggy.

Сообщение от hoggy суть проста: если вы не в теме, то как бы вы ни старались, но без опыта, все равно с высокой степенью вероятности получится хлам.

Есть, например, программы, которые написаны очень хорошо. Как их авторы такого добились? Очень "просто". Они всю жизнь идут в этом направлении. Досконально знают предметную область и написали уже не один десяток версий, с каждым разом улучшая свой результат. Тут ровно так же, как в спорте.
Что касается архитекторов в больших компаниях, то это тоже люди не с потолка. Они точно так же досконально знают предметную область, поэтому могут прогнозировать изменения в проекте, чтобы заложить это в архитектуре. Они могут детально спроектировать взаимодействие абстракций внутри программы (в виде диаграмм или графиков), потому что представляют себе очень хорошо что должно получиться в результате.

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

2