Во-первых, я должен рассказать вам, почему я создаю службу встреч. В первом посте (Мне нужна служба планирования / назначения — № 1), которой я поделился, я сказал, что у меня есть проект, которому нужна служба планирования, потому что мое приложение в первую очередь ориентировано непосредственно на диетологов. И консультантам, которые консультируются с диетологами, нужны встречи, а диетологам нужно устанавливать доступные им временные интервалы в календаре. Вот почему этого проекта.
Как определить особенности?
Это самый сложный вопрос, потому что сначала вы должны знать продукт или проект, над которым вы работаете, и вы должны определить функции с этой областью. Если вы потеряете прицел, все может сойти с ума. Проект может включать слишком много функций, настроек или обходных путей, которые не нужны. Это может наложить так много ответственности на проверку, и это довольно важная проблема, которую следует избегать. Сначала мы должны решить, что является нашим MVP (минимально жизнеспособным продуктом). Это должно быть главной целью. Поэтому я подумал, что мне нужно определить функции уровня продукта и функции уровня инфраструктуры/программного обеспечения. Поскольку я разработчик программного обеспечения, включающий в проект так много инфраструктурных/программных функций, я лимб.
Я очень люблю экспериментировать с новыми технологиями. Я пытаюсь добавлять в свой проект все новые и новые вещи и в какой-то момент не могу начать работать над фичами продукта. Это очень раздражает, и, на мой взгляд, это прокрастинация технического специалиста. Продукт остается, проект остается, но стек технологий всемирно известен, а без продукта известный стек бесполезен.
А также добавление в продукт такого количества необязательных или не требуемых на данный момент функций также может убить вашу атмосферу. Потому что добавление такого большого количества функций в продукт в самом начале может привести к выгоранию, даже если вы будете думать о дорожной карте.
И в этот раз я решил использовать все инструменты, которые я уже хорошо знаю, и заложить в продукт только фичи MVP.
Программное обеспечение / инструменты инфраструктуры
Это мое счастливое место, чтобы писать и решать, но на этот раз я сосредоточусь только на MVP, поэтому я остановлю себя на этом. (Я не уверен, что это сработает, но, по крайней мере, я попробую).
- Язык Go
Я разработчик мобильных приложений, но мне очень нравится писать на Go. Я уверен в написании бэкенда на Go. Я уже пишу слишком много простых, промежуточных серверных приложений, так что это хорошая отправная точка и не слишком эффектно. - Nginx
Я начал использовать его примерно 5–6 лет назад в своих хобби-проектах, веб-сайтах и т. д. Для меня он прост в использовании и, самое главное, прост для понимания. - Let’s Encrypt
Требуется SSL-защита (не требуется, когда я начинаю разработку проекта), и Let’s Encrypt подходит как нельзя лучше. С certbot так просто настроить. - Docker
Как я уже сказал, я разрабатываю мобильные устройства и плохо разбираюсь в инфраструктуре, но для работы со средами подходит Docker. И я уже знал, как обращаться с «докеризацией». Я не пишу свои собственные Dockerfile(ы) с нуля, у меня нет такого уровня знаний, но я в основном использую готовые Dockerfile(ы) с открытым исходным кодом и меняю их в соответствии со своими потребностями. - MySQL
Мне нужна база данных и все. Можно использовать варианты NoSQL, такие как MongoDB (я знаю об этом, я использовал его много раз), или я могу использовать PostgreSQL (я использовал несколько раз). Но я считаю, что мой продукт не требует подхода NoSQL, он может быть очень ценным, но если он вам не нужен, то все, он для вас бесполезен. И PostgreSQL — очень сильный и надежный подход, но я им не пользовался. Так что понимание может занять время, и это время украдет время моего продукта MVP. - Redis
Я все еще не уверен, стоит ли его использовать, но для хорошего уровня кэширования неизменяемых данных он может подойти для этого проекта. - RabbitMQ
Я не буду использовать только одну монолитную структуру. Я буду использовать очень много вещей с микросервисами, и им нужно обмениваться данными и обрабатывать события. Например, отправка электронных писем, смс, уведомлений и т. д. Так что RabbitMQ для победы. И я знаю, что могу использовать и Кафку, но у меня нет никаких знаний, кроме теоретических, которыми я никогда не пользуюсь, поэтому у меня нет с ней практики. А с Go мне так легко использовать RabbitMQ. - И все остальное может появиться по пути
Я могу забыть добавить несколько других вещей в программные инструменты. Но в рамках этой дорожной карты я не буду включать слишком много вещей, которые для меня являются экспериментальными. Но в пути продукт и проект могут потребовать других вещей.
Особенности продукта
Эта глава немного сложна, потому что я никогда не создаю никаких продуктов, охватывающих планирование/встречи. Но первая попытка будет MVP, поэтому я только что подумал о необходимых частях продукта. Думать о продукте масштабно — это хорошо, но если вы начнете откусывать большой кусок, это может вызвать проблемы, такие как перекладывание работы на плечи, плохо рассчитанные сроки и многое другое. Имея это в виду, я действительно думал о нескольких ключевых функциях продукта.
- Уведомление
Уведомление владельца календаря и клиента — ключевые функции, в противном случае нет смысла создавать встречу, если мы не напомним обеим сторонам. - Обработка отпуска в странеs
Сначала я планирую использовать его в своем основном проекте, и он будет охватывать только Турцию, поэтому сначала я не буду добавлять другие страны, но с этой функцией добавить любую другую страну будет легко. - Подход только через API
Первая фаза приложения будет состоять только из API и не будет включать какой-либо пользовательский интерфейс. На первом этапе я не думаю о том, что мои встречи станут полноценным продуктом, это будет просто побочная функция для моего основного проекта. - Временные интервалы
Пользователи будут выбирать и создавать личные временные интервалы в течение недели, как и во всех других продуктах для встреч. - Продолжительность собрания
Пользователи могут устанавливать продолжительность собрания для каждого дня или часа. - Выбор встречи
Владелец календаря также может создать встречу для клиентов, чтобы владелец мог выбирать встречи. - Интеграция с календарем
Мне все еще не нужна полная интеграция с календарями, но она должна быть в продукте на первом этапе. Поэтому я добавлю интеграцию календаря Google, Microsoft и Apple.
Заключение
Определение функции продукта и перечисление программных инструментов может показаться простым делом, но для создания хорошего проекта MVP вам придется подумать дважды или даже больше. Потому что это может быть меньше, чем нужно, или это может быть слишком много работы для первой фазы приложения.
Я все еще не совсем согласен с этими пунктами для функций продукта и программных инструментов, но, по крайней мере, прямо сейчас у меня есть стартовая позиция.
Что дальше?
Я планирую создать среду разработки и постараюсь поделиться постами об изложении среды разработки.
Этот пост впервые появился в моем блоге по адресу https://taluttasgiran.com/2023/02/appointment-api-features-that-should-exist/.
