⚡ Kotobotov ⚡

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

Требования и хотелки часто меняются

автоматическое тестирование - это самое первое что снижает стоимость разработки и количество багов.

минимальными багами, но фактически багов бывает достаточно много.

кем считается? сколько это минимальными, сколько это достаточно много?
какие-то не понятные величины, очень сложно понять что вы вообще имеете ввиду и кто такое количество установил.
вам нужно написать автоматизированные тесты - они все должны проходить до релиза.
-------
1) Каждая функция должна быть покрыта хотя бы одним тестов, все тесты должны быть пройдены. Количество багов выявленных самим программистом должно быть равно нулю - передает другому тестировщику именно потому что он их уже найти не может.
2) Да может, в небольших продуктах тестировщики не нужны,
Аргументы за тестировщиков - иногда сложно самому находить ошибки в своем же коде (предвзятый взгляд).
Аргумент против - лишняя координация работы + бестолковые обезьяны сколько бы не копались все равно не смогут грамотно оттестировать продукт, для создания хороших тестов нужны хорошие разработчики которые более менее понимают про полноту и эквивалентность функций, могут создать генераторы тестов и тд.

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

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

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

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

производительность БД выше чем у файловой системы

никто тебе не даст смыслов, если у тебя нет задач и "боли".
тебе нравиться делать интернет магазины и лэндинги на пхп -> отлично делай.
не зачем тебе высокопроизводительные инструменты для обработки данных на многоядерных системах и кластерах

Гет запрос кэшируется, как на стороне пользователя в его браузере (чего нет с пост запросами), так и на стороне сервера (зависит от настроек уже).
Тоесть если запросы от пользователя повторяются, то лучше в ГЕТ запросе дату размещать.
П. С.
Есть техническое ограничение на длину URL, поэтому большие данные передаются только в "теле" запроса.
Вобще лучше спецификацию разных запросов почитать и примеры посмотреть, чем абстрактно рассуждать.
Уверен сами разберетесь в итоге, где и что именно вам лучше использовать.

не надо сразу делать что-то большое, собирать все идеи и пытаться их соеденять -> сфокусируйтесь, в начале на том что действительно критически важно и нужно пользователям, затем постепенно развивайте проект.
ну и само собой сервисы прототипирования - стоящая вещь.

ну если вы просто хотите показать портфолио, никаких проблем добавить эти картинки в гит.
Почему обычно не добавляют - потому что тогда данные на основе которой отслеживаются изменения сильно "разбухают", при этом нет никакой необходимости отслеживать изменения этих файлов.

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

>это вообще нормально или нет?
да это нормально, разработка всегда идет от плохого к хорошему, постепенными улучшениями, никогда сразу не создаются хорошие версии продукта.
С этим разобрались
Разработчик самостоятельно решает какой должен быть минимально приемлемый уровень качества. Если вы считаете такой уровень не достаточным, значит нужно заранее задавать эти стандарты хотя бы в виде тестов.
Почему такая система сложилась? -
возможно это как-то завязано на системе мотивации которую вы используете, например вы оплачиваете только за выполнение таски (значит самая первая и самая примитивная версия сразу выдается клиенту)
Возможно сами требуете скорейшего выполнения задачи. Как вариант конечно разработчик не знает как сделать лучше (это тоже не проблема, надо просто еще взять сотрудника у которого квалификация будет чтоб подтянуть команду).
Тестеров в начале не стоит набирать - лучше платите своим разработчикам чтоб они друг друга работу тестировали, что позволит им самим качественно вырасти.
По поводу посчета возврата к задаче -> при желании можно сколь угодно долго находить баги в любой задаче (вы не можете конечным алгоритмом охватить бесконечно сложную реальность). Так что это бессмысленно.
Самое худшее что вы можете сделать - начать накладывать какие-то санкции, за то что программист якобы НЕ сразу выдал "идеал в вакууме".
Качество всегда будет стоить дополнительных денег и времени.
Остается постепенно искать баланс между качеством, стоимостью и затраченным временем.
По поводу оценки компетенций, да она понятно у них она очень низкая - вы же не гугл и не эпл, и даже не сбербанк технологии, вам гарантированно закрыт доступ не то что к крутым, даже к разработчикам условно "среднего уровня", все что вам остается взять то что осталось на рынке, и научится с этим хоть как-то работать. Ну конечно попробуйте искать людей с более высокой квалификацией, может кто и найдется, но принципиально уровнем выше вы просто в свою компанию не найдете (гарантирую)

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

место поиска значения не имеет, результат будет тотже самый как вы и описали.
Видимо нужно сильнее продумать чем вы можете заинтересовать толкового специалиста.
Доля + зарплата вполне себе типовая схема. Только за долю или только за зарплату толкового специалиста тоже не привлечь. Должно совпадать множество факторов

Для человека не в теме оценить будет невозможно, вам нужен партнер который как минимум является сам компетентным разработчиком и поэтому может более менее оценить компетентность других разработчиков.
на что обращать внимание:
1. Репутация на рынке
Важно чтоб они дорожили этой репутацией.
2. Стандарты и процессы.
Не так важно делали они похожие проекты или нет, важно чтоб в целом у них были выстроенны процессы таким образом чтоб не залажать разработку, поэтому обратите внимания какие стандарты и подходы они используют в работе.
3. Умение работать на основе постоянно меняющихся требований.
4. Релевантный опыт в вашей области тоже не помешает, хотя он как правило не сильно важен.

можно стратегию привязать к времени поиска решения, к каждому следующему этапу переходить после окончания лимита времени на поиск решения. например:
за 5 минут не нашел ошибку сам в коде, начинаешь логи дополнительные выводить
через 15 минут в логах ничего не прояснилось начинаешь гуглить,
за 20 минут чтения ссылок в гугле не нашел ответ, начинаешь задавать вопрос коллегам
ничего с коллегами минут за 20 не получилось, обращаешься к сообществам
если таким макаром проблема не решена часа за 2, то или забиваешь на проблему, и переключаешься на другие задачи либо меняешь подход/фреймворк/работу)

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