darksladen

Реально если начнете сами делать, правильно боитесь.
Лучше устроиться на пол года в компанию, диву дадитесь как вы много не знаете.
Конечно устраиваться надо туда, где как-раз делают крупные проекты и а не все подряд.
Тоесть не веб студия, а компания с бизнесом своим.

Когда будете устраиваться, сказать, что хотите чего-то серьезного хотите расти и пахнуть!
Попробуйте, кухню надо знать с разных сторон

Про GitHub.

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

2) Создал себе на Гитхабе две дополнительные организации внутри своего аккаунта.
- «paulradzkov-forks» — для форков чужих проектов.
- «paulradzkov-heaven» — кладбище для старых проектов, куда перемещаются все неактуальные проекты.
Эти две дополнительные организации позволяют очистить основной аккаунт от мусора. В нем теперь только несколько актуальных проектов, в которых легко ориентироваться.

3) Перемещаю все старые проекты из Дропбокса на Гитхаб в «paulradzkov-heaven». Проектов много, это долго, но освободилось уже несколько гигов (т.к. там кроме кода psd-исходники, архивы с инсталляторами и прочее). Место в облаках заканчивается, а на Гитхабе — резиновое.
Это кладбище уже пригодилось, когда у меня попросили поискать исходники проекта, над которым я работал 3 или 4 года назад, а я через минуту ответил им ссылкой на нужный репозиторий. Не пришлось никуда лезть, распаковывать, искать, запаковывать, отправлять почтой или закачивать в облако.
Повторюсь, что на Гитхабе классный поиск по исходникам: если нужно посмотреть, как что-то сделал в старом проекте, но не помнишь в каком — можно довольно быстро найти искомое без возни с архивами.

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

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

ЗЫ Перед тем, как хвататься за Evernote, я бы посоветовал посмотреть, как оттуда можно извлекать свои заметки (экспорт, при необходимости уйти в какой-нибудь другой сервис). Это не так просто. Это касается любого SaaS, который вы планируете использовать в качестве базы знаний.

https://monosnap.com/welcome , льёт на FTP
https://app.prntscr.com/ru/

prnt.sc
disk.yandex.ru/screenshot/

1. Если модель переданная в API не будет изменена - то можно отдать Accepted = 202
2. Если подразумевается изменение модели, или хоть одного поля, - то нужно вернуть Ok = 200, в body положить новую модель.

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

1) Отдавать нужно json строку с кодом ответа/статусом и тд, чтобы можно было на клиентской стороне обработать ответ и произвести необходимые действия.
2) В контроллере никакую логику не пишем. Она выносится в сервисный слой. (Это я про эту фразу "есть контроллер, в котором есть метод добавления товара в корзину").
3)

Также непонятно, что должен делать такой метод при обычном запросе не через ajax.. Делать редирект на предыдущий урл или корзину например?

Это уже вам решать. Тут все зависит от потребности. Хотя, я бы вообще не стал этот маршрут приспосабливать для "обычного запроса", создал бы другой специально для этого.