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

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

Вот уже почти пол года прошло с того момента как я всерьёз занялся изучением веб программирования и погрузился в разработку некоего проекта — браузерной игры   Я себе поставил цель. Сделать проект за 2-3 месяца. Я думал, что вот это тот срок, который мне уж точно позволит доучить html и css (скорее css, в html учить то нечего) и хотя бы поверхностно (в достаточной мере для моих нужд) js и php (а точнее yii2) и попутно аккуратно сделать мой проект. Но время шло. Я уже мог сказать, что я на терпимом уровне оствоил все нужные мне технологии и уже начинал потихоньку ускоряться в разработке самого проекта. Я очень люблю работать над интерфейсами и даже считаю, что у меня это достаточно хорошо получается. Но на этот реально хороший результат я трачу колоссальное количество времени. Я могу пол дня потратить на обдумывание 30 вариантов дизайна одной кнопки, прийти домой, наконец-то выбрать окончательный вариант и только к вечеру наконец реализовать эту кнопку (я конечно утрирую, всё конечно ни на столько печально, но всё же). А так же я постоянно недоволен своим кодом. Точнее сначала я доволен, продолжаю работу, но потом, через неделю другую я начинаю думать об этом участке кода и придумываю более оптимальное решение, а продолжать дальше у меня руки опускаются, пока я не поправлю этот код. И вот прошло уже далеко не 2-3 месяца, а почти пол года, а проект завершен в лучшем случае на 70%. Да я двигаюсь дальше, но это происходит крайне медленно, хотя я сижу над ним с утра до ночи. И да, проект реально улучшается и с точки зрения дизайна и с точки зрения оптимизации. Но за это время я переписал каждую часть проекта по меньше мере 5-6 раз с чистого листа. И я понятия не имею сколько ещё мне понадобится времени на его завершение. Хотя результаты меня всё же радуют и я вижу в проекте светлое будущее. Сейчас я поступил в ВУЗ второй раз, на сей раз это МГУ (факультет ВМК) и боюсь времени у меня на мой проект будет гораздо меньше. Что Вы можете мне посоветовать с точки зрения организации своей работы, разработки проектов и пр.? Что я делаю не так? Или же это нормально?

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

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

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

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

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

От идеи к реализации. От реализации к оценке. От оценки к очередной идее.

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

MVP - как делать и как не делать

MVP — как делать и как не делать

 

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

 

Пример оценки очередного цикла MVP

Пример оценки очередного цикла MVP — делать за одну итерацию срез по нескольким аспектам удовлетворённости, а не отдельный аспект.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Павел Волынцев

Уже более 15 лет занимаюсь разработкой веб-проектов. Fullstack Senior Developer. IT евангелист — доношу свет знаний об информационных технологиях. Профессиональные цели: Дать людям возможность дать людям больше.

Читайте также:

  • Дмитрий Игнатухин

    я свой блог http://dyblog.ru тоже переписываю уже 2 раз 😀 сейчас вроде как норм сделал

    • Да, оформлено неплохо. Откуда статьи берёшь?
      Скажи пожалуйста, вот эта статья http://dyblog.ru/vklyuchenie-predubezhdenij/ — это механический перевод? А что является источником?