Что делать с тем, что я постоянно переписываю почти весь код?

История с тостера от программиста, который зациклился на идеальной реализации игрового проекта

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

Вообще вопрос, как мне кажется, озвучивает проблему расстановки приоритетов либо, возможно, скрытую прокрастинацию.

С одной стороны, возможно автор вопроса всей душой хочет сделать код идеальным, что для учебного проекта просто замечательно. S.O.L.I.D., KISS, DRY, шаблоны, вёрстка, игровая логика, игровой баланс — много за что можно зацепиться, полировать код до блеска.

Чтобы суметь вовремя остановиться, я бы рекомендовал прочитать пару статей про MVP (Minimal Viable Product, минимальный жизнеспособный продукт). Разработка может быть построена циклами, ограниченными по времени. Можно описать конечную цель продукта, расписать детали реализации, из всего этого выделить важное для очередного цикла, реализовать и изучить реакцию пользователей.

MVP (Minimal Viable Product): От идеи к реализации. От реализации к оценке. От оценки к очередной идее. (источник)

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

Как надо и как не надо делать MVP (Minimal Viable Product) (источник)

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

Пример оценки очередного цикла MVP — делать за одну итерацию срез по нескольким аспектам удовлетворённости, а не отдельный аспект (author/copyright holder: Jussi Pasanen)

Основным критерием оценки при расстановке приоритетов на очередной цикл реализации может выступить удовлетворённость пользователя. Как ему нравится набор возможностей (functionality), стабильность (reliability), удобство использования (usability), визуальная привлекательность (design). По каждому аспекту проводится оценка (например, анкеты-опросники и статистика использования функций продукта). Я тут много рассказывать не хочу. Есть более умные источники, чем эта статья.

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

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

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

Я всегда готов общаться и развивать продукт, но без помощника не обойтись — и это, кстати, легко можно поручить (делегировать). Помощник ищется на биржах труда по словам «Удалённая поддержка клиентов», а обучается по книге «Клиенты на всю жизнь» .

Например, автор вопроса представил себе идею коммерческого проекта, но нет навыков маркетинга, рекламы. Можно попробовать найти кого-нибудь, кому это было бы интересно. Могу предложить поискать себе союзников среди студентов экономических и рекламных специальностей, на каких-либо общих ресурсах, у них тоже бывают форумы и группы в вКонтакте. Они тоже получат практику, которой им очень не хватает.

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

А ведь это тоже MVP. В этой ситуации сам программист является продуктом, как бы это странно не звучало. А работодатель — это покупатель. Цель выпуска «продукта» — быть «арендованным», то есть быть нанятым на работу. Формально ведь это не продажа, а аренда, так? В качестве аспектов удовлетворённости можно рассмотреть требования в целом к вакансиям по интересующемуся направлению, или к одной конкретной вакансии. Если кандидат реализует требование вакансии, то работодатель более расположен к кандидату. Ну, если честно, иногда могут взять на работу и за «закрытие» всего одного-двух требований. А в целом, если в требования перечислены 6 пунктов, то надо иметь навыки по всем шести.

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

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

Со стороны работодателя я скажу, что никому эта домашняя поделка (pet project) на самом деле не нужна, она для галочки. Она показывает, что кандидат с вёрсткой знаком, фреймворк освоил, сам умеет проектировать, программирует в стиле ООП с применением шаблонов и общепризнанных принципов построения качественного кода (опять же S.O.L.I.D, KISS, DRY). Работодателей устроит, если автор на словах расскажет идею проекта, из всего проекта пришлёт два-три самых классных отлично оформленных файла исходного кода, пару-тройку скриншотов и может быть покажет вёрстку «изнутри», то есть исходный код HTML, может быть даже покажет один работающий модульный тест или работу части проекта даже со своего ноутбука.

Нужно от реализации перейти к сбору метрик. То есть пройти собеседование. Варианты после собеседования: предлагают стажировку, дают тестовое задание небольшого объёма для проверки навыков, берут на работу, а может быть отказывают. Бояться этого не надо, это один цикл из процесса, за ним будет следующий. Если постепенно улучшать «продукт» (то есть программиста), то будет всё более и более привлекателен для «покупателя» (то есть работодателя).

На этом у меня всё. Надеюсь, я ответил на вопрос.

P.S. Автор вопроса учится в МГУ, делает игровой проект в свободное время, для коммерческой эксплуатации. Пока не ищет работу, потому что трудно совмещать с учёбой, а зря. Перспективы, по-моему, хорошие. В любом случае на работу берут за навыки, которые нужно получать ещё во время учёбы.

Свои варианты ответа на этот вопрос вы можете дать автору через Toster.ru, а со мной поспорить можно в комментариях.