Dark Hole

Очистить массив, не трогая добавленные свойства и методы:
ar.length = 0

С вашими значениями (вы забыли return в методе sum()):

var ar = [1, 2, 3];
ar.sum = function() {
    return this.reduce(function(a, b) {
        return a + b;
    });
}

ar.length = 0;    // значений больше нет, но метод sum() остался
ar.push(5, 6, 7); // добавляем новые значения
ar.sum()          // 18

Стандартный ответ на вопрос как, когда и что учить:
пили проекты, решай реальные задачи, все остальное тлен.

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

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

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

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

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

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

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

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

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

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

Безопасно. Указанием "../" в URI подняться выше root нельзя.