За пределами теоретической информатики люди редко пишут код ради того, чтобы он просто существовал. Обычно мы пытаемся решить с его помощью какие-то реальные задачи: что-то посчитать, визуализировать, автоматизировать. Но существование кода отнюдь не бесплатно, он требует времени на написание и поддержку. Если смотреть на код со стороны изначальной задачи, то он представляет из себя необходимое зло: принося со своим существованием один род проблем, код решает другие. И наша задача, как хороших программистов, сделать так, чтобы новых проблем было как можно меньше.
Мы, программисты, любим технологии, иначе мы бы вряд ли отдавали им такое количество своего времени. Многие любят наблюдать за новыми языками программирования, пробовать многообещающие фреймворки, сервисы, базы данных, хотя в конечном итоге это лишь инструменты для решения проблемы.
Я предлагаю начать с самого важного.
Выделяем основу
Итак, вам известна проблема. Примера ради допустим, что мы создали настольную игру, и нам захотелось перенести её в онлайн, чтобы игроки со всего мира могли принять участие в нашем турнире.
С чего вы начнёте разработку? Наберёте команду для создания проекта с любимым фреймворком? Развернёте базу данных? Напишите основу сайта? На самом деле, это всё может подождать, для проблемы это не так важно.
Для начала предлагаю реализовать наиболее близкий к реальному миру модуль - бизнес-логику. Именно здесь описываются все основные сущности и алгоритмы. В нашем случае мы могли бы описать игровое поле, игроков, их предметы и правила игры. Используйте простые типы, доступные в вашем языке: структуры, классы, массивы и т.д.
Не вдавайтесь в детали на этом этапе. Если вам нужна база данных, хранилище файлов или другие сервисы, опишите требуемое поведение при помощи интерфейсов. Мы займёмся ими позже.
У нас должен получиться довольно формальный модуль, который можно легко протестировать. Так как мы определили интерфейсы для всех сторонних сервисов, мы можем заменить их заглушками. Например, вместо базы данных можно создать простое хранилище в оперативной памяти. Сейчас важно проверить работу основных алгоритмов: игроки могут сделать свой ход в правильном порядке, они не могут нарушить правила игры, и их действия корректно отражаются в состоянии партии.
Выбираем фреймворк
Надеюсь, к этому времени вы представляете, в какой форме ваше приложение будет доступно пользователям: нативное приложение, веб-сайт, 3D-игра. Может быть даже в нескольких вариантах сразу! В любом случае вам вполне могут быть полезны различные фреймворки, библиотеки или игровые движки. Люди не первый раз сталкиваются с различными проблемами и собрали готовые решения для них.
Как выбрать подходящий фреймворк? Единого ответа не существует. Мне кажется, фреймворк как минимум не должен быть основой вашего проекта, не должен быть его незаменимой частью. Мы не всегда можем добиться 100% изоляции, но при возможности стоит хотя бы постараться. Структурируйте свой проект так, чтобы его основа, бизнес-логика, как можно меньше знала о менее важных деталях, таких как фреймворки.
Таким же образом стоит относиться ко всем сторонним сервисам. Используйте интерфейсы или их аналоги в вашем языке, чтобы отделить сервисы от основы приложения.
Проверяем на практике
Нет смысла доводить вашу программу до совершенства, если никто потом не будет ей пользоваться. Доведите свой проект до минимально-пригодного состояния и выпускайте его в свет! Предложите хотя бы небольшой группе людей опробовать его, чтобы понять, может ли он принести пользу.
Несовершенный проект можно улучшить, если он будет востребован. Куда обиднее осознать, что ваша идеальная программа, на которую вы потратили целый год, никому не нужна.
Заложите прочный фундамент для вашего проекта в виде модульной архитектуры, напишите необходимый минимум кода и покажите ваше творение миру.