«Кодирование»

Вопросы для интервью (BlogPost)

1-Опишите одну вещь, которую вы изучаете сегодня в классе.

Перебор объектов и массивов — очень распространенная задача, которую разработчики выполняют каждый день. Ваша задача понять, почему, как и когда это делать. Сегодня мы рассмотрим, как и когда использовать циклы. Что касается причин, подумайте о списке твитов, которые вы могли публиковать в прошлом году. Где-то в одной из баз данных Twitter есть массив всех отправленных вами твитов. Когда вы запрашиваете просмотр своих твитов, вызывается функция, и через нее передается ваш массив. Эта функция перебирает каждый из ваших твитов и возвращает их на ваш телефон.

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

2-Что такое «использовать строго»;? каковы преимущества и недостатки его использования?

Директива «use strict»

Директива "use strict" была новой в ECMAScript версии 5.

Это не утверждение, а буквальное выражение, игнорируемое более ранними версиями JavaScript.

Цель "use strict" — указать, что код должен выполняться в «строгом режиме».

В строгом режиме нельзя, например, использовать необъявленные переменные.

3-Объясните «подъем».

Подъем — это стандартное поведение JavaScript для перемещения объявлений наверх.

Объявления JavaScript поднимаются

В JavaScript переменная может быть объявлена ​​после ее использования.

Другими словами; переменная может использоваться до того, как она была объявлена.

4- Объясните важность стандартов и органов по стандартизации

В 1990 году — на заре Интернета — Тим Бернерс-Ли создал программу под названием WorldWideWeb. Это был первый веб-браузер. Это позволяло людям записывать информацию, которую затем могли читать другие через Интернет. Вскоре после его изобретения другие использовали эту технологию и создали конкурирующие веб-браузеры. Каждый веб-браузер имел сходство друг с другом, но ни один из них не был полностью одинаковым. Браузеры будут поддерживать проприетарные функции или по-разному отображать HTML, CSS и JavaScript.

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

Например, если один браузер поддерживает функцию CSS position:fixed…

.header { position: fixed }

Заголовок будет отображаться в верхней части страницы.

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

Учтите, что хотя старые технологии, такие как position:fixed, никуда не делись, новые технологии, браузеры и устройства создаются и используются разработчиками и потребителями. Без стандартов развитие быстро выйдет из-под контроля.

Охват пользователей

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

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

Новые технологии

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

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

Даже старые технологии

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

Когда органы по стандартизации принимают решение о стандартах, они стремятся к обратной совместимости. По мере того как новые технологии устаревают, техническое обслуживание может оставаться эффективным. Со стандартами вы можете быть уверены, что ваш сайт, использующий position:fixed, будет вести себя одинаково, даже если будут созданы новые правила CSS и выпущены новые браузеры для их поддержки.

Оставаться в силе

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

Открытие

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

Как появляются стандарты

В Интернете стандарты обсуждаются и принимаются группами заинтересованных лиц и организаций, называемых органами по стандартизации. Органы по стандартизации публикуют документы, описывающие различные стандарты для соответствующих технологий. Некоторые из этих документов включают…

Рекомендации, опубликованные Консорциумом World Wide Web или W3C, основателем и нынешним руководителем которого является Тим Бернерс-Ли.

Стандарт жизни от Рабочей группы по технологиям веб-гипертекстовых приложений или WHATWG

Документы запроса комментариев (RFC), опубликованные Internet Engineering Task Force или IETF.

Существуют и другие органы, имеющие отношение к веб-стандартам, такие как ISO, Ecma International, Консорциум Unicode и IANA.

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

5-Какие действия вы лично предприняли в последних проектах, чтобы повысить удобство сопровождения вашего кода?

Раньше я думал, что знаю, что это такое, пока я действительно не начал думать об этом… «обслуживаемый»… что именно делает код пригодным для сопровождения?

Для меня, если код должен поддерживаться, это означает, что мы можем ожидать пересмотра кода, чтобы внести в него какие-то изменения в будущем. Код всегда «изменяем», независимо от того, в каком состоянии он находится. Значит ли это, что код должен легко изменяться? Однако, если бы наш код был масштабируемым/расширяемым, его не нужно было бы напрямую менять, потому что он будет «меняться» (адаптироваться) бесплатно и автоматически.

Я также видел, как удобство сопровождения кода взаимозаменяемо со стандартами кодирования. Использование последовательного шаблона или стиля кодирования действительно делает код более удобным для сопровождения? Более читаемый и более последовательный? Конечно, но как это улучшает ремонтопригодность?

но вот что я действительно думаю обо всем этом, я знаю, что означает, что код, вероятно, прост, компактен и легко читается. Вероятно, следует принципу KISS. Когда я слышу, как кто-то говорит о том, что их код можно обслуживать… эээ… я как бы не понимаю реального точного значения того, что они говорят. Если кто-то другой сможет прочитать это через 6 месяцев и понять смысл это менее чем за 5–10 минут, это ремонтопригодно! :)

6-Почему расширение встроенных объектов JavaScript не является хорошей идеей?

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

JS поставляется с важными встроенными объектами, которые мы можем использовать для текста, чисел, логических значений, данных, дат и многого другого. Когда мы познакомимся с этими встроенными объектами, мы обнаружим, что хотим сделать больше, чем то, что предоставляет JS, именно здесь мы создаем наши собственные встроенные объекты, следовательно, «Расширение встроенного JS объекты».

Например, мы можем легко инкапсулировать наш код с помощью функции.

function regexIt(input) { // do something with input and return input; }

и используйте его, вызвав функцию regexIt и передав аргумент, как показано ниже:

var result = 'Hello World'; regexIt(result);

Теперь, скажем, например, эта функция стала настолько полезной, что она должна быть частью методов объекта JS String. Вы знаете, что в JS String есть replace(), indexOf(), slice(), substring(), toUpperCase(), toLowerCase(), split(), и это лишь некоторые из популярных. Мы используем эти методы, как показано ниже:

var foo = 'Hello World, Foo Bar'; foo.split(',');

Если мы хотим, чтобы наша функция regexIt стала методом объекта JS String, то есть чтобы можно было использовать ее вот так, foo.regexIt() вместо regexIt(foo), нам нужно будет использовать прототип.

прототип

prototype давайте вставим нашу пользовательскую функцию в эти объекты JS. Все объекты в JS содержат свойство prototype, даже переменные, которые мы объявляем. Поскольку у нас нет доступа к исходному коду JS, поэтому мы не можем вставить нашу пользовательскую функциональность в объект String, возясь с исходным кодом JS, мы используем prototype объекта String как еще один подход для вставки нашей функциональности.

String.prototype.regexIt = function() { /* Since were attaching our custom function to String object, we don't need an argument instead, we use 'this' to access our argument as it points to the String value attached. */ var input = this; // do something with input and return input; }

Теперь мы можем использовать наш метод regexIt, как показано ниже:

var result = 'Hello World'; result.regexIt();

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

• кирупа

Споры

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

• В будущем JavaScript может реализовать собственную версию вашего пользовательского метода (используя то же имя), и это переопределит ваш пользовательский метод.
• Изменение поведения текущих встроенных объектов JS не является хорошей практикой, поскольку это нарушает его функциональность по умолчанию и нарушает ваш код, используя этот конкретный встроенный метод или свойство объекта JS.

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

7-Почему вообще рекомендуется оставить глобальную область веб-сайта такой, какая она есть, и никогда ее не трогать?

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

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

• Труднее читать код и рассуждать об этом, когда кажется, что переменные появляются из воздуха (но на самом деле из глобальной области видимости).
• Любой может обновить глобальную переменную из любой точки программы в любое время (и из любого потока, если их несколько).
• Общий запах кода — если вам лень ставить переменную только там, где она должна быть, то какие еще углы вы срезаете?
• Вероятно, вы столкнетесь с конфликтами имен глобальных переменных. Поскольку существует только одно пространство имен, вы, скорее всего, удвоите имя переменной.

Глобальные переменные особенно вредны для JS.

Мало того, что все вышеперечисленные пункты верны (и некоторые другие, которые я не включил), но и глобальные переменные в JS могут быть особенно проблематичными. Это связано с тем, что JS по умолчанию присваивает всем переменным глобальную область видимости, если только они не определены явно в другом месте. Вот пример:

1
2
3
4
5
6
function badlyScoped() {
    globalVariable = "I'm a global variable";
}
badlyScoped();
console.log(globalVariable); // logs "I'm a global variable"

Ну разве это не страшно! Мы думали, что создаем локальную переменную, поскольку она была определена внутри функции, но нет! Мы забыли ключевое слово var, которое делало бы переменную локальной. Вот исправленная версия:

1
2
3
4
5
6
function wellScoped() {
    var localVariable = "I'm a local variable";
}
wellScoped();
console.log(localVariable); // throws: "localVariable is not defined"

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

' "Веб-разработка"

@AustinCodingAcademy”