@Gaba-Zhaba

Как накидать логику работы будущей программы?

Есть задача написать программу на C++. Но, прежде чем что-то сделать, нужно накидать план действий.

Как правильно накидать логику будущей программы что бы потом не переделывать в середине или в конце? Есть ли на это какие ни будь инструкции, шпаргалки, стандарты и шаблоны?
Т.к. в ЯП я не силен (начинающий), хочется делать мало ошибок. Но я не знаю с чего начать, как построить логику будущей программы, какие инструменты и ресурсы использовать, как все это потом упаковать в готовый продукт и т.д.
  • Вопрос задан
  • 166 просмотров
Пригласить эксперта
Ответы на вопрос 6
gbg
@gbg
Баянист. Тамада. Услуги.
Вы не научитесь писать и проектировать программы, если самостоятельно не набьете на этом шишек.

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

После нескольких таких заездов по граблям вы получите опыт - ошибки и трудности, с которыми вы начнете сталкиваться будут такие, что ни в книге сказать, ни на StackOverflow прочитать.
Ответ написан
longclaps
@longclaps
Накидываю: никак. Хочется делать мало ошибок - не делай ничего. Если проект для тебя важен - найми исполнителя.
Какие уж тут насмешки! Мы рыдаем на тебя глядючи. Нет в программировании царских путей.
Ответ написан
@oleg_ods
Если проект очень важный, посмотри в сторону методологии TDD.
Ответ написан
@MikUrrey
Это называется "архитектура". Если вы начинающий и хотите создать приложение с более-менее хорошей архитектурой, попробуйте какой-нибудь известный в вашем стеке фреймворк. Фреймворки зачастую диктуют свою архитектуру или имеют готовые шаблоны проектов, в которых предусмотрена "тысяча мелочей". Так же вникание в премудрости архитектуры можно / нужно начать с изучения паттернов (factory, dependency injection, adapter и т.п.) и подходов (MVC, TDD, SOLID, DRY и т.п.)

А вот что касается именно бизнес-логики, тут все слишком специфично и зависит от предметной области. Я бы посоветовал в ходе разработки временами задумываться на тему "как потом я смогу расширить этот модуль/класс/метод, не редактируя его код?". Это временами даёт очень годные идеи.
Ответ написан
KirasiH
@KirasiH
Раньше было лучше
Возьми листик начерти как будет работать своя программа. Я когда на питоне пишу большие программы с классами всегда так делаю чтобы не запутаться в коде.
Ответ написан
@cicatrix
было бы большой ошибкой думать
Начинается всё на листке бумаги. Если проектируешь один, то никаких формальных схем описания придерживаться не нужно. Просто так, чтобы самому было понятно, что и как.

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

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

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

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

Ну вот уже после всего этого, начинай писать код. Тебе будет легко и приятно. Ты будешь примерно представлять, сколько ты уже сделал, и сколько ещё осталось. Баги будут вылавливаться тестами, и ты не будешь писать лишний код, которым никто не будет пользоваться в дальнейшем.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы