iqhater

Попробуй поднять 300 кг, если никогда до этого не занимался тяжелой атлетикой.
Думаешь через 5 месяцев станет легко?

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

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

Попробуйте следовать https://www.atlassian.com/ru/git/tutorials/compari...

К проблеме которую вы описали:

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

Не сливайте feature-ветку пока она не будет полностью протестирована и code-rewiew'ирована.
Склеивайте комиты в feature-ветке, чтобы их в итоге было не больше 1-3.

Из собственного опыта могу сказать, что чем крупнее и неспешнее проект - тем проще следовать git-flow.
А вот когда 1-2 разработчика и нужно вот сейчас ещё вчера запилить 10 фич... бывает сложновато.

Это вопрос дисциплины и организованности. Как ставятся задачи, как вы фокусируетесь на текущей фиче (нельзя носиться по всему проекту и фиксить по пути всё что под руку попалось). Организации самого проекта в конце концов - как изолированы компоненты и т.д.

Задавать окружающим вопросы. Ртом. Повторять пока не станет понятно

Бенчмарки - это хорошо, но очень важно понимать что именно там меряли и почему результаты именно такие.

Несколько лет назад я тоже делал бенчмарки Python, PHP, Node, Go.
Для меня были важны две вещи:
1 - скорость ответа сервера/кол-во запросов в секунду
2 - объём сервиса в памяти, т.к. от этого зависит стоимость ресурсов

На тесте, где сервисы не делали запросы в базу - из всех четверых лучше всего отработал Go с приличным отрывом, цифры, к сожалению, уже не помню.

Но вся эта разница сошла на нет, как только добавился всего один простой SQL запрос в базу, в таблицу с 10 строками. И на этом фоне разница по скорости ответа была меньше 10%.

Иными словами если ваш сервис работает с базой - критической разницы по скорости работы между Go/Rust/PHP/Node/Java, особо не будет.

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

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

Один экземпляр Go занимал в памяти порядка 6мб RAM, при том, что Pytho+Django порядка 60мб.
Node уже не помню сколько, но что-то близкое к Python'у.

Вот тут уже, когда серверов у вас будет много - количество серверов с Go у вас будет в 10 раз меньше, соответственно расходы за эти сервера у вас будут в 10 раз меньше :)

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

Где-то читал статью, что у людей было API на порядка 40 серверов на Node, после переписывания на Go - серверов осталось два, из которых второй запасной :)

Не надо загружать ветки. Ветка - для разработки. master - для "боевого кода".

Релизуем фичу в ветке, проверяем, если считаем, что все ок, мержим ее в мастер.
На коммит в мастер стартует CI/CD, который прогоняет тесты (они ведь у вас есть, правда?) и, в случае успешной сборки, проливает код на прод.

"Хацкаем" метод метод, пишем в глобал результат, юзаем результат.

Math.floorOrig = Math.floor;
Math.floor = (n) => {
  window.num = Math.floorOrig(n)
  return window.num;
}

function getNum() {
  const num = Math.floor(Math.random() * 10);
}

getNum();

console.log(window.num);

Еще можно просто переопределить саму функцию.

function getNum() {
  const num = Math.floor(Math.random() * 10);
}

function getNum() {
  return Math.floor(Math.random() * 10);
}

console.log(getNum());

Добро пожаловать в дивный мир фронтенд фреймворков.
Поисковики увидят (гугл точно, но в целом с горем пополам), но если вам важна индексация, то вам надо осваивать SSR.

Попробуйте c# в смысле net core. Как по мне стройная архитектура и отличная ide покроет все остальные минусы. Все это ставится на самом дешевом линукс хостинге. Не студия конечно а сам проект. В связке с angular or react будет вообще супер. Впрочем я сам предпочитаю vue

Если вы действительно собираетесь писать все-все с нуля, то язык безразличен, и даже разница между Django и Laravel, в сущности, невелика.
Другое дело, что велосипеды сплошь и рядом не так эффективны и просты, как это кажется "на берегу". Поддержка их и добавление фич могут быстро оказаться дороже, а результат - хуже, чем использование готовых решений. А с ними, насколько я могу судить, у РНР получше, если речь о вебе и обычных для него задачах.
Особенно для новичков-велосипедистов, для которых открытием оказывается, что то, что они полгода лелеяли и изобретали из головы, имеет столько готовых решений...