yalex1442

Как правило, хорошая защита по входам в мультиметрах сочетается с автоматическим выбором предела и считается не элементом защиты от дурака (это тривиально), а признаком более высокого класса аппаратуры.
Что же касается защиты от него, родного, то могу посоветовать такой аппарат - HoldPeak HP-890CN, в котором она реализована конкретно: при установке переключателя в определённое положение специальные шторки открывают только те гнёзда для щупов, которые годятся для этого типа измерений, и наоборот - если щупы вставлены, то в неподходящие положения переключатель поставить не удастся.
Дополнительный бонус этого мультиметра - повышенная точность: край шкалы у него 5999 в отличие от привычных всем нам 3,5 разрядов (1999). Ну и разумеется, автоматический выбор предела. Пользуюсь им уже полгода и не нарадуюсь. Покупал на Али с некоторыми сложностями (продавец пытался запудрить мне мозги).

Проверять в контроллере валидность значения капчи - нормальная практика.

Если используются стандартные формы, то в FormType можно передать опцию вида "show_capcha" и в buildForm() иходя из значения "show_capcha" показывать поле капчи или нет.

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

Как вы написали, контроллеры должны обрабатывать HTTP запросы, вот пусть они этим и занимаются. Берут запрос, забирают и обрабатывают данные, просят сервисы что-то сделать (а не делают сами) и потом выплевывают результат работы этих сервисов наружу.

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

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

А еще было бы неплохо попрактиковать TDD но это если вам позволяет время. Вообще настоятельно рекомендую перейти на практику TDD (почитайте Кента Бэка на эту тему).

И еще говорят, что считается правка composer библиотеки напрямую изменяя код в vendor не хорошим, как дополнять либы новым функционалом?

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

1) выкинуть codeigniter и переписать все на reactphp
2) вместо того что бы выдумывать наркоманию не парьтесь и делайте как все, stateless апишки и все такое. keep-alive минимизируют расходы на установление http соединения, а для оптимизации работы с базой можно просто использовать persistent connections и тд.
3) выкинуть codeigniter и переписать на любом фреймворке использующим PSR-7 или symfony/httpkernel, вооружиться php-pm.

Такая специальность, а вас на PHP тянет пфф.... Учите С++ раз вы учитесь, это серьезный язык и это программа, а уже PHP, Python, Java, JavaScript факультативно по интересу, в свободное время. У вас первый курс, пока вы доучитесь у вас ещё 300 раз поменяется мнения, желания и хотения, как бы потом не пожалели.