Почему мы должны использовать несжатые файлы для разработки?

Question

Мне было интересно, зачем нам нужны несжатые файлы для разработки и уменьшенные для производства? Я имею в виду, каковы преимущества использования несжатых файлов перед минимизированными?

Они дают вам более качественные сообщения об ошибках или просто, если мы хотим что-то найти, мы можем просмотреть код несжатых файлов?

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

Answer 1

Может быть несколько причин, по которым можно предпочесть несжатые [unminified] файлы во время разработки. Некоторые причины, по которым я могу придумать:

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

2. Если используется диспетчер кода, переменные могут быть переименованы, и они не будут интуитивно понятны относительно того, как они на самом деле называются в базе кода

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

4. Это позволяет отладку быть более простой, удобочитаемой и интуитивно понятной.

5. Минимизация и искажение кода выполняются ОСНОВНО для повышения эффективности доставки этих ресурсов с сервера конечному пользователю (клиенту). Это гарантирует, что клиент может быстро загрузить сценарий, а также снижает затраты веб-сайта / организации на доставку этого сценария пользователю. Так что это может считаться дополнительным ненужным шагом при запуске кода во время разработки. (Активы уже доступны локально, поэтому дополнительные затраты на полезную нагрузку незначительны)

TLDR. Сокращение и искажение кода может занять много времени (особенно когда мы генерируем файлы карт и т. Д.), Что может задержать время между изменениями и временем, когда эти изменения видны на локальном экземпляре. Это также может затруднить разработку, сделав ее более трудной / менее интуитивно понятной для отладки

Answer 2

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

(function(_){var window=this,document=this.document;var ba,ea,fa,ha,la,na,oa,pa,qa,sa,ra,ta,wa,xa,za,Aa,Da,Ea,Fa,Ga,Ia;ba=function(a){return function(){return _.aa[a].apply(this,arguments)}};ea=function(a){return ca(_.p.top,a)||ca(da(),a)};_.aa=[];fa="function"==typeof Object.create?Object.create:function(a){var b=function(){};...

и так далее. Это читабельно для вас? Я так не думаю. Он вообще не читается.

Для лучшего понимания кода вам нужно распаковать его. Это добавит некоторые дополнительные пробелы и отформатирует код намного удобочитаемым способом. так это будет выглядеть так:

(function(){
  var b = j(),
      c = k (b);
})();

Позволяет переходить от одного фрагмента кода к другому и обнаруживать код или искать вашу ошибку внутри.

Кроме того, для производства вам нужно не только минимизировать код, но и сжать его. Так что было бы неплохо использовать для этого библиотеку Uglify. Он удаляет ненужные пробелы, переименовывает переменные, объекты и функции для гораздо меньших имен, таких как a или b12. Увеличивает скорость скачивания.

Надеюсь, это поможет вам.