Максим Павлов

Это сложный вопрос, на который нет однозначного ответа. Лично я для себя нашел следующие выходы: не связываться вообще с языками, в которых очень низкий порог входа (Javascript, PHP). Пытаться спорить и воспитывать коллег (это тяжело и дает плоды только на очень длинной дистанции). Менять работу.

Те, кто говорят, что только хипстеров заботит красота кода: я еще не видел успешного проекта с говнокодом. Множество раз меня звали на проекты, я отказывался после первого взгляда на код, и больше я никогда об этих проектах не слышал. Когда люди пишут четыре одинаковых метода под разными именами, когда используют разработку копи-пастой, однобуквенные имена переменных, и т.п., они в итоге сами увязают в своем говнокоде, и проект не взлетает. Остается за ним дурно-пахнущее нечто, что никто не берется поддерживать и развивать, в итоге, проект тихонько загибается.

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

Мы стараемся не запускать эту проблему посредством code review, пытаясь распределить нагрузку по ревью между наиболее опытными участниками. Если в коде есть проблемы - тикет возвращается на доработку с замечаниями. Даже если банально не мержится с главной веткой. Попробуйте наладить этот процесс.

Также мы всё собираемся настроить Continuous Integration. Jenkins может прогонять по коду проверку на соблюдение стандартов и покрытие тестами, а затем показывать результаты в красивом виде. Если чей-то коммит показывает более чем N ошибок в расчёте на единицу объёма кода - можно возвращать на исправление.

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

Ещё пара идей.

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

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

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

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

Может потому что response.body это js объект и его не надо парсить?

Object.assign()

kenwheeler.github.io/slick
См. пример с center mode

true - положительный результат
false- отрицательный результат
null - отсутствие результата.