Алексей Васильевич

Перейдите на нормальный TDD для начала

Предлагаю определить Junior, Middle, Senior следующим образом, чтобы было понятно, куда двигаться:

• Junior - вы только-только начали ориентироваться (в языке или , может быть, в предметной области, в которой работает компания), поэтому вам говорят что делать и как это делать. Вы задаёте вопросы "почему так, а не вот так?" и получаете ответы (иногда ищете сами). Для вашей работы готовы все необходимые каркасы,
  вы делаете то, что для остальных очевидно. Вы с удовольствием фигачили бы код килобайтами, но пока много не знаете/не понимаете, поэтому основное время проводите в изучении: статей в интернет, мануалов по языку, чужого кода
  
• Middle - вы хорошо ориентируетесь (в язые или, может быть, в предметной области, понимаете употребляемый окружающими жаргон и можете поддержать беседу, рассказать о том, что узнать про это в интернете или конференциях), поэтому самостоятельно решаете как делать то, что вам говорят сделать, иногда оспаривая те или иные решения и предлагаю свои. Вы фигачите код килобайтами и даже мегабайтами и решаете не только стоящие перед вами задачи, но и учитесь делать что-то неизвестное ранее. Порой даже уговариваете менеджеров соглашаться на нереальные сроки и работаете по вечерам допоздна, лишь бы попробовать какую-то новую технологию/фреймворк/язык/etc
  
• Senior - вы свободно ориентируетесь (и в языке, и в предметной области, и в имеющемся в компании коде, вводите в обиход новые жаргонные словечки, которые подхватывают все), поэтому самостоятельно решаете как сделать и что сделать на основании целей и проблем, описанных руководством/заказчиком, иногда отговариваете их делать что-то ради того, чтобы сфокусировать команду и себя на важных вещах. Основная масса кода, который значится за вами в репозиториях сделаны в одном из первых коммитов, и включает в себя настройку подключенных фреймворков и создание каркаса для наполнения его силами Middle и Junior разработчиков. Вы отговариваете и убеждаете всех вокруг не делать то, чего делать не нужно, присматриваете за тем, чтобы Junior'ы (в большей степени) и Middle'ы (в меньшей степени) действовали согласовано и трактовали заложенный в проект каркас так, как вы это подразумевали.
  

Есть чёткая логика для этой ситуации:
1. На фреймворке лишь проверяем тип данных:
item_id - целое положительное?
1.1 Да - значит передаём в шаблон формирования запроса к БД
1.2 Нет - генерируем ошибку фреймворку, как невалидность входных данных пользователя.
2. на существование - проверяет запрос сохранения в базе через WHERE, таким образом - один запрос, вместо двух и проверку - мы отдаём базе и ловим код выполнения запроса.
Если запрос добавления в базу не был успешным:
2.1 либо запрашиваем детальную информацию об ошибке,
2.2 либо НЕ запрашиваем и сразу генерируем ошибку добавления фреймворку.

Шпаргалка выглядит так:
1. Валидируем данные перед их непосредственным использованием.
2. Если принимающая сторона (модуль системы) делает валидацию без последствий для безопасности и с сохранением логики необходимой обработки - всегда отдаём валидацию на принимающую сторону (в данном примере - это сервер БД).

ИМХО Зависит в том числе и от того, будете ли выдавать ошибку или нет и насколько подробную

Ну по современным тенденциям код не комментируют, а пишут документацию.
https://www.phpdoc.org

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

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

PS: уметь кодить и помнить что-то - две абсолютно разные вещи. Практика и теория тут не подходят для сравнения.

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

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

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

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

И вот тут, чтобы действительно справляться, необходимо ПОНИМАТЬ, как это работает, почему так а не иначе, и как с помощью этого решать поставленные задачи. Если чего-то не хватает, или оно работает не так как надо, а это весьма частые явления, то ПОНИМАНИЕ процессов дает свободу РЕШАТЬ эти тупиковые, казалось бы, вопросы.

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

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

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

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

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

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

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

BEGIN
  SAVEPOINT bak_trn; -- опционально
  SELECT FROM ... ;
  INSERT INTO ... ;
EXCEPTION  -- опционально
   WHEN OTHERS THEN
      ROLLBACK TO bak_trn;
      RAISE;
END;
COMMIT;

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

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

https://github.com/instanceofpro/awesome-backbone

Go, erlang