Как сделать веб-сервис и не утонуть в процессе?

Question

[wawa]

Есть идея веб-сервиса, довольно сложного (для меня).
Как подступиться к его созданию?
Просто взять и начать писать код - начинаешь тонуть в этом, путаться. Всё в голове не помещается, надо как-то организовать этот процесс.
Кто как делает? Какой-то софт используется? Как принято браться за такие проекты, организовывать процесс разработки? Можно ссылок накидать.
Буду благодарен.

UPD:
Многие сошлись на том, что нужно сконцентрировать силы над MVP, т.е. какой-то одной главной фиче. Тогда вопрос: схему БД прорабатывать тоже только в рамках это фичи или всю полностью? Если первое, то появятся ли родовые проблемы в схеме из-за того что я просто не учел дальнейшее развитие? если второе - можно утонуть. Или я что-то не понимаю.

Answer 1

[Дмитрий Дарт]

1. Выделить одну главную функцию сервиса
2. Сделать её, сверстать и выкатить, это будет MVP
3. Не заморачиваться с вёрсткой
4. Не заморачиваться с методами авторизации
5. Не думать про нагрузку, не заниматься оптимизацией кода и БД
6. Если поймали себя на мысли что вы думаете какой паттерн тут применить вы в Ж, просто пишите код, который работает!!
7. Не совмещать написание сервиса, который вы РЕАЛЬНО хотите запустить с изучением чего-то нового (языка, БД). Утоните в учёбе и никогда не запустите.

Это всё на своём опыте написания проекта говорю вам а не голословно ))

Comments

[Anton Mashletov]

7. Не совмещать написание сервиса, который вы РЕАЛЬНО хотите запустить с изучением чего-то нового (языка, БД).

Абсолютно не согласен. Только так и проходит РЕАЛЬНОЕ изучение и опыт. Но! Нужно пробовать новое маленькими порциями (попробовать новую библиотеку, например). А не так, типа всю жизнь писал на PHP+MySQL+Jquery и тут резко решил новый проект в виде микросервисов на Go с использованием докера.

[SpideR-KOSS]

Anton Mashletov, да как сказать. Я вот начал изучение NodeJS. Во первых JavaScript, а раз ява значит и jQuery. Раз NodeJS значит по любому Express со всеми ее необходимыми модулями. Базу взял MongoDB, а значит Mongoose как бы само собой разумеется. Решил сразу делать небольшой проект чтобы практиковаться на ходу. Для удобства работы с CSS нужно изучать Sass, но его же нужно компилировать, а значит нужен Gulp. Ах да, шаблонизатор! Но мы же не будем писать на голом HTML+CSS, поэтому пожалуйста, Bulma, или Semantic UI, или Bootstrap.
По началу все это казалось сумашествием, но спустя пару недель привык. Хотя я только начал. Боюсь представить что там впереди...

[Yan-s]

SpideR-KOSS, говорят же: маленькими порциями. Да и вообще, прежде чем сказать "вот на этой новой штуке и буду писать проект!", надо провести исследование чтобы оценить как это вообще должно работать и не увязнем ли в этом. Исследование заключается в основном в проверке идеи на практике, запилить за минимум времени мелкую фигню, но так чтобы задействовать все основные мутные моменты и задействовать весь планируемый стек. После чего будет представление и о технологии и о том с какой стороны к ней подходить.

[Дмитрий Дарт]

Anton Mashletov, ну можно конечно и так, но это риск большой если проект будет реальный... Например я взял MongoDB, запихал туда по незнанию кучу реальных данных, потом понял что она хороша для данных вида ключ-значение и там нет WHERE с AND и OR, но проект уже написан и запущен, переписывать полпроекта и тревожить пользователей переносом данных нет желания, в итоге появляется врождённый архитектурный косяк. Я всё же за отдельные маленькие учебные проекты.

[fedot1325]

Дмитрий Дарт, ключ-значение это редис или что-то подобное, монга - object oriented. Ключевых слов WHERE, AND, OR нет, но это не значит, что нельзя писать запросы с этими условиями. Джоинов нет, но они не понадобятся, если правильно составить схему.

[Дмитрий Дарт]

fedot1325, мне-то зачем вы это говорите? Я это знаю, как и то что

если правильно составить схему

с этим как раз и возникают по неопытности проблемы

[wawa]

Дмитрий Дарт, можете ответить на UPD пожалуйста?

[Дмитрий Дарт]

wawa, Я бы продумывал почти полностью, ну или хотя бы на развитие 2-3 больших фич вперёд. Т.е. если у меня сейчас связь в БД 1 к 1 и я могу обойтись одной таблицей, но потом варианты добавятся и будет связь один ко многим, то уже сейчас можно добавить промежуточную таблицу где будут значения только одной категории (пока). Если сейчас нет ролей юзеров но будут, то просто создаёте в БД столбец "роль" а в коде его забираете и проверяете функцией-загшушкой которая пока всегда true отдаёт например. Хотя это усложнит понимание кода сторонними людьми сейчас. Но если вы один, то ок.
На всю жизни архитектуру всё равно не спроектировать, но на ближайший год развития проекта можно...

[Владимир Хаттер]

SpideR-KOSS, пи*ц впереди...

[alex-1917]

SpideR-KOSS,

Но мы же не будем писать на голом HTML+CSS, поэтому пожалуйста, Bulma, или Semantic UI, или Bootstrap

смешно до слёз... почему не будем-то??? вам же выше советуют - делать максимально голым приложение, потом обвесите...

Answer 2

[Никита Трофимов]

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

Comments

[wawa]

Никита Трофимов, можете ответить на UPD пожалуйста?

[Никита Трофимов]

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

Answer 3

[Tobster]

Используйте подход MVP - только не путать с model view present

Ссылка: https://ru.wikipedia.org/wiki/Минимально_жизнеспос...
(minimum viable product, MVP)

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

Организацию труда выполняйте в нечто вроде Trello

Ну и конечно старайтесь подключить к разработке как можно больше людей, которые реально чтото делают постоянно, а не просто посмотрят и уйдут, для этого есть GitHub, на каждую даже самую маленькую фичу не больше одной ветки делать в гите, иначе утонет профессионал даже с 20 летним стажем.

Answer 4

[JohnDaniels]

Примечательно, что вариант "сидеть и работать" даже не рассматривается

Comments

[wawa]

Это вытекает из всех ответов выше. Хотя кэпу место всегда найдется:)

[Сергей Соколов]

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

Answer 5

[Сергей Горностаев]

Сначала прокачайте голову на проектах попроще.

Answer 6

[asd111]

Сначала нужно спроектировать весь проект и только потом начинать писать.
1. Расписываешь все урлы и пишешь какие данные будут приходить на данный урл и какие будут уходить.
2. Проектируешь базу данных.
3. Пишешь код.
Почитай что нибудь на тему жизненного цикла программного обеспечения, там разъясняется как писать большие проекты.

Comments

[wawa]

asd111, можете ответить на UPD пожалуйста?

Answer 7

[Виктор]

Отнеситесь к работе как к бизнесу.

1. Напишите себе ТЗ как будто хотите продукт заказать.
2. Посмотрите на ТЗ и оцените стоимость работ исходя из своих расценок
3. Подумайте окупятся ли инвестиции вашего времени и какие риски
4. Подумайте как упростить работу
...
99. Начинайте писать код, по своему ТЗ

Comments

[wawa]

Виктор, можете ответить на UPD пожалуйста?

Answer 8

[Евгений Воробьев]

Сначала идешь в библиотеку..

htmlbook.ru

php.net

Итд..

А потом делай что захочешь