О JavaScript, фреймворках и найме

Недавно мой коллега и друг Кевин Эннис написал интересную статью под названием Вы неправильно думаете о фреймворках. Там есть отличная цитата, которую я хотел бы обсудить:

«Я хочу сказать, что, преувеличивая важность фреймворков, мы получаем целую армию технических специалистов, а не инженеров. Делая вид, что Ember или Angular могут решить все наши проблемы, мы создаем ложное впечатление, что простое изучение «правильного» фреймворка - это все, что вам нужно, чтобы быть эффективными. Но это не так ».

- Кевин С. Эннис, эсквайр

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

Если в примечании Кевина говорится, что из фреймворков часто делают лучше техников, чем инженеров, возникает вопрос ...

Как я могу стать более эффективным разработчиком JavaScript?

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

Ответ: Изучите JavaScript.

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

1) Разберитесь в подъеме.

Этот фрагмент вас смущает?

var foo = 'bar';
(function() {
  console.log( foo ); // logs `undefined`
  var foo = 'baz';
})();

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

В Starry мы фактически применяем руководство по стилю JS, которое требует, чтобы все объявления переменных располагались в верхней части заданной функции, чтобы устранить любую двусмысленность.

Приведенный выше фрагмент кода не прошел бы наши автоматизированные тесты CI, и для успешного прохождения его пришлось бы переписать следующим образом:

var foo = ‘bar’;
(function() {
  var foo;
  console.log( foo ); // logs `undefined`
  foo = ‘baz’ ;
})();

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

2) Понять прототипы.

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

На технических собеседованиях я часто спрашиваю следующее:

// How would we set up the inheritance chain, such that
// Bar inherits from Foo?
function Foo() {
  console.log(‘Initializing…’);
  this.init();
}
Foo.prototype.init = function() {
  console.log(‘Initialized!’);
};
function Bar() {
}
var bar = new Bar();
// should log ‘Initializing…’ and ‘Initialized!’

Некоторым это может показаться тривиальным - и я думаю, что это так, - но на самом деле большинство инженеров, которые были обучены абстракции высшего порядка для создания приложений (а-ля Angular, Ember и др.), Возможно, никогда не столкнулись с ситуацией, когда наследование представляло собой очевидную (или даже полезную) закономерность.

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

Некоторые могут утверждать, что наследование несущественно для эффективного проектирования приложений, особенно для одностраничных веб-приложений. А тем, кто сказал бы: я категорически не согласен.

3) Понять закрытие.

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

1) Модуль оценки должен иметь свойство с именем score. Каждый раз, когда это целое число изменяется каким-либо образом, шаблон ДОЛЖЕН также обновляться.

Есть 101 способ добиться этого. Но понимание замыканий предлагает действительно краткую и понятную реализацию:

function ScoreModule() {
  this.tmplString = ‘Score: {{ score }}’;
  this.elem = document.querySelector(‘#my-score-elem’);
  (function() {
    var score = 0;
    Object.defineProperty( this, ‘score’, {
       get: function(){
         return score;
       },
       set: function( val ) {
         score = val;
         this.elem.innerHTML = template(
           tmplString, { score: score }
         );
       }
    });
  }).call( this );
}
var scoreModule = new ScoreModule();
scoreModule.score = 5; // auto templating abound!

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

Но все используют [Framework X], разве я не должен погрузиться в рыночную жизнь ?!

Абсолютно! Я большой поклонник Backbone / Marionette и призываю людей выбирать правильный инструмент для работы, а также для той культуры, которую вы хотите создать в своей организации. Будь то React / Flux, Angular, Ember или Backbone; им всем есть что предложить. Прочтите документы / исходники и найдите то, что вас волнует.

Но это пристрастие к инструментам не должно затмевать ваше желание и способность развивать экспертные знания веб-платформы, особенно языка JavaScript.

Если что-то из этого находит отклик у вас - я нанимаю инженеров по JavaScript, пишите: [email protected].

Первоначально опубликовано на spmurrayzzz.com

О JavaScript, фреймворках и найме