Crash

Видоизмененный вариант Роман

<?php

$arr = [
    ['name' => 'ford', 'count' => 2], 
    ['name' => 'ford', 'count' => 8], 
    ['name' => 'lada', 'count' => 9], 
    ['name' => 'lada', 'count' => 2]
    ];

$res = array_reduce($arr, function($carry, $item) {
    if(!isset($carry[$item['name']]) || ($carry[$item['name']] < $item['count']) ) {
        $carry[$item['name']] = $item['count'];
    }
    return $carry;
});
var_dump($res);

1. Закопать Fuel обратно в его могилу и больше не беспокоить прах этого умершего в далекой древности старца.
2. Вместо него учить Laravel
3. Открыть для себя документацию РНР и в непонятных случаях обращаться к ней. В это трудно, конечно, поверить, но там всё написаною Эта ссылка находится в двух кликах по запросу "РНР ООП"

Честно говоря, я и сам себя часто ловлю на такой "лености мозга". Когда ты 100% можешь сам найти ответ, но спросить у знающего человека проще. но тут важно не поддаваться, и сначала пытаться самостоятельно. Для этого в любом вопросе должна быть фраза - "я искал такм-то", но не нашёл. В процессе написания этой фразы ответ сам и сыщется. В итоге в будет сэкономлено время, приобретён опыт и в интернете будет будет меньше мусора.

Есть.
1) Мобильная разработка.
2) Разработка скраперов.
3) Разработка скриптов, ботов для мессенджеров, для трейдинга и.т.д.
и.т.д. есть даже фрилансеры, которые пишут VBA скрипты для MS Excel, и зарабатывают неплохие деньги на этом. Но нужно учитывать, что заказов будет не так много, как на веб, но и конкуренция ниже (но как правильно - профессиональнее).
Еще если вы middle+, то можно посмотреть в сторону удаленной работы.

Немного банальностей:
1. Бизнес не даст ресурсов на переписывание проекта с 0: время и большие риски
2. Бизнесу как правило все-равно какое говно там крутится, лишь бы деньги приносило.
3. Если более-менее адекватное руководство - нужно донести идею постепенного рефакторинга кода по мере необходимости в процессе фикса багов и разработки новых фич и тем самым аргументировать что на разработку новых фич/фикс багов нужно больше времени.

Как я бы делал:
1. Тесты на существующие функции (если возможно, видел методы в контроллерах с мешаниной вызовов методов моделей, созданием DTO и сохранением их через репозиторий, прямых http-запросов и запросов в бд на 1000+ строк, покрыть такое тестами - невозможно)
2. Составить план рефакторинга, где отметить что и где надо сделать, коротко, в основном для команды разработчиков.
3. Постепенно рефакторить старый код по мере взаимодействия с ним.
4. Новый код - писать сразу правильно, для взаимодействия со старым кодом где нет возможности/времени его переделать - делать какие-то адаптеры, что бы не распространять токсичный код.
5. Как оперативная мера защиты от SQL иньекций можно поставить что-то вроде этого https://github.com/nbs-system/naxsi
6. Мониторинг кода, который не используется - pinba.org , по мере обнаружения такого кода - удалять безвозвратно (в крайнем случае есть VCS, я надеюсь). Начать с более высокоуровнего кода - контроллеры, напримерю. Плюс IDE в этом могут помочь и grep.
7. Как вариант - новые фичи можно пилить в отдельном проекте (v2), крутить оба и постепенно переходить на новый, со временем старый (v1) выкинуть (и начать делать новый - v3 :-) )

История из жизни.

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

В итоге он:
1) Создает юр лицо с собой во главе
2) Заключает вкусные договоры со своим постоянным клиентом. Благо накопились многолетние связи.
3) Нанимает некоторое количество программистов
4) Ставит программистам задачи по переписанию его VBA лапши на ASP.NET и по созданию новых систем.
5) Profit

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

Всё тоже самое, но только изначально компания внешняя... Сделала заказ и поняла, что стоит тут копать и переиспользовать разработки.

Вариант 3. Основатель такой компании работал над некими проектами, как описано выше, но компания замкнулась на основном заказчике и не шла в тренде... Все :)

Можете глянуть freecodecamp, целый раздел посвящен es6.
Так же можно просто писать знакомые задачи с возможностями es6+
Ps вот кстати статья, мало ли: ES6 по-человечески

Упрощаю вопрос:
Я запланировал сделать это за две недели, но ошибся в оценке. Что делать?
Ответ на мой взгляд очевиден:
Извиниться, признать ошибку, сделать выводы. Все остальное (типа привлечение доп ресурсов, введение ночных смен и т.п.) это попытка прикрыть свою ошибку как менеджера за счет компании.

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

Если пишите на PHP - пишите дальше на PHP.
Для перечисленного на PHP - есть pthreads.
Добавлю это.

Если хотите большую ЗП, язык программирования - не главное!
Главное - ваше умение и способность создавать востребованный, удобный, конкурентоспособный, производительный и легко масштабируемый бизнес-сервис за минимальное время и стоимость.

Так делайте НЕ типовой проект что бы выйти из зоны комфорта. Вы пытаетесь думать где применить варежки на Юге, хотя надо поехать на Север и там им сразу найдется применение.

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

Вот вы сделали проекцию своего мнения на всех, а кто-то всё свободное и часть рабочего времени тратит на эксперименты, а зарабатывает мало ))

какие узкие места в разрабатываемых проектах можно закрывать посредством Go, Elixir

Если там нагрузка будет только тестовая от вас то и PHP везде справится, а так... запилите pet-проект с API, откройте его миру бесплатно, немного продвижения и тогда вы увидите как текущие средства не справляются с нагрузкой и придёт время применять другие технологии.

Понятное дело, что как ни думай как в песочнице поработать экскаватором - все решения будут так себе.

Делаю скрипт для проверки битых ссылок в админке
Должна быть стандартная практика на этот случай

Тестированию -- тестовые инструменты

Почему бы не сделать это через Codeception? А именно через приемочные тесты....
Через драйвер PhpBrowser работают куки и сессия и можно залогиниться и собрать все ссылки :) И он ставится через композер вместе с самим Codeception, явный недостаток перед веб-драйвером -- он не может ждать (например запросы через аякс)

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

Примерный вид готового приемочного теста:

// Тут предварительно логинимся (метод amLogin() не родной, 
     // надо создать его в классе AcceptanceTester)
     public function _before(AcceptanceTester $I)
    {
        $I->amLogin('admin', 'admin');
        $I->amOnPage('/admin');
    }

    /** Ниже добавляем через аннотацию провайдер всех ссылок 
     * и данный тест будет выполняться для каждой ссылки в админке
     * @dataProvider linksInAdminPanel
     * 
     *  Или вычесать все ссылки с каждой страницы в методе
     *  и записать в массив и потом по ним идти, проверяя -- была ссылка или нет
     *  
     */
    public function linkIsCorrect(AcceptanceTester $I, \Codeception\Example $pageAdmin)
    {
        $I->amOnPage($pageAdmin['url']);
        $I->seeResponseCodeIs(HttpCode::OK);
    }

    // Перечень ссылок в админке
    protected function linksInAdminPanel()
    {
        return [
            ['url' => '/admin/users'],
            ['url' => '/admin/settings'],
            ['url' => '/admin/products'],
            ....
        ];
    }

Комментировать можно и не "попадая" на хабр, а если статьи писать не планируете то зачем вам полноценный аккаунт?

Обычно анализ начинают с включения журнала медленных запросов (slow query log). Туда записываются все запросы, анализирующие больше заданного количества строк и занимающие больше заданного времени.
Если этого не хватает, то можно включить общий журнал запросов (general query log). Туда уже попадают все запросы и информация о подключении/отключении клиентов.