Найкращий спосіб навчитися кодувати - це кодувати: Дізнайтеся архітектуру додатків, будуючи програми

Практика ідеально підходить від Бенджаміна Стюдінгера (CC BY-NC-ND 2.0)

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

Немає іншого шляху. Найкращий спосіб навчитися - це заскочити і почати будувати, але це може бути дуже страшним. З чого ви починаєте?

Користувачі та автентифікація?

Ви можете подумати, що керування користувачами та автентифікація - це перший перший крок. Ви помиляєтесь Перш за все, паролі застаріли, тому всі ваші нові програми повинні використовувати аутентифікацію без паролів.

По-друге, автентифікація користувачів є величезним ризиком для безпеки, і його не слід залишати новачкам ні за яких обставин. Сотні мільйонів облікових даних для входу були викрадені у великих компаній із спеціалізованими експертами з питань безпеки, які не роблять нічого, крім цілодобової роботи над тим, як поліпшити безпеку. Дуже добре, що деякі ваші дані для входу були вкрадені.

Це не просто небезпечно для вашої програми, якщо ви накрутите автентифікацію користувачів, це небезпечно і для ваших користувачів, оскільки вони можуть використовувати ті ж дані для входу для інших програм, як їх постачальник електронної пошти чи їх банківський рахунок. Іншими словами, якщо хтось викраде паролі у вашої програми, він може їм скористатися, щоб нанести реальну шкоду в районах, які не мають нічого спільного з вашим додатком.

Пам'ятайте, що автентифікація користувачів є величезним ризиком для безпеки, і його не слід залишати новачкам ні за яких обставин.

Я рекомендую більшості програм делегувати завдання аутентифікації стороннім постачальникам аутентифікації, таким як Facebook, Twitter або подібні. Навіть великі програми, підтримувані великим бізнесом, які мають законні причини та ресурси для управління власними стратегіями аутентифікації користувачів, повинні використовувати популярні бібліотеки, протестовані на бойові дії, а не згортати власну автентифікацію з нуля.

Але є багато крихітних програм для одного користувача, які можна створити для того, щоб взагалі не потребували автентифікації користувача, і деякі додатки, які могли б отримати користь від автентифікації користувачів, зможуть додати цю функцію пізніше.

Один хороший спосіб розпочати перехід до реальних додатків - це створити додатки на основі браузера за допомогою програми "localStorage", що підтримує лише одного користувача, а потім збільшити масштаб від цієї основи. Ви можете додати декілька користувачів та підключення до бази даних пізніше, після того як ви освоїли основи сучасної архітектури додатків на базі клієнта.

Вступ до архітектури додатків на стороні клієнта

То як виглядає сучасна архітектура додатків на стороні клієнта? Ще кілька років тому в ньому панували архітектури MV *, такі як MVC, MVP, MVVM тощо.

Більшість з них стосується того, як координувати моделі (дані) та вид (UI / Презентація). Важливою концепцією в архітектурі додатків є розділення проблем.

Ось деякі проблеми, які ми хотіли б окремо:

  • Презентація / перегляд (макет, стиль, маніпуляція з DOM)
  • Обробка подій / дії (захоплення та перетворення вхідних даних від користувачів та зовнішніх повідомлень у дії в додатку)
  • Маршрутизація / URL-адреси (переведення URL-адрес у дії)
  • Бізнес-логіка (правила для управління даними)
  • Керування станом клієнта / модель / магазин (структури даних на пам'яті клієнта)
  • Постійність даних та введення-виведення сервера (довготривале зберігання даних, AJAX, SSE)

Архітектура MVC виглядає приблизно так:

MVC-діаграма з

У MVC модель випромінює події зміни, а представлення відповідає на запит про поточний стан та оновлення. Контролер прослуховує перегляд подій та реагує, оновляючи стан, а також потенційно маніпулюючи поданням, або вибираючи новий вид у відповідь на зміни маршруту.

При двосторонніх прив'язках даних зміни подання безпосередньо відображаються в моделі, не проходячи через контролер. Уявіть, що замість того, щоб просто запитувати стан, подання також може безпосередньо оновити стан. Це двостороння зв'язування в двох словах.

Введення користувача може викликати оновлення стану, що може викликати зміну DOM, що може викликати інше оновлення стану, яке може викликати більше змін у DOM тощо. Швидко стає важко зрозуміти, як зміни можуть каскадувати і впливати на стан вашої програми, і випадково ввести нескінченні петлі стає легко.

Прикладом цього є Angular 1. Angular 1 намагався керувати цією складністю, взявши під контроль петлю оновлення стану інтерфейсу (називається циклом дайджесту). Щоб уникнути нескінченної рекурсії обміну повідомленнями, цикл дайвінгу мав обмежений провід на 10 циклів, але це все ще залишало багато місця для однієї події для відправлення каскаду, який би спричинив багато змін у DOM, що може спричинити більше цикли. Окрім того, що вона була складною і складною для розуміння, вона також була частою причиною проблем із продуктивністю в Angular, оскільки одна зміна може викликати великий каскад оновлень.

У 2013 році Facebook оголосила React: нову структуру з відкритим кодом для створення компонентів інтерфейсу користувача. React не хвилює, як ви обробляєте оновлення даних, але він не підтримує двостороння прив'язка даних. Натомість вам рекомендується використовувати однонаправлений потік даних, з'єднуючись React на щось на зразок архітектури Flux.

React & Flux докорінно змінили те, як ми створюємо додатки для веб-платформ, і ідея однонаправленого потоку даних поширилася і на програми Angular та Ember.

Архітектура Flux виглядає приблизно так:

Flux Архітектура

Замість поширення змін через велику кількість слухачів подій, у режим перегляду передаються функції зворотного виклику, які підключаються до зворотного виклику слухача події DOM. Зворотний виклик створює об'єкт дії, який надсилається до магазину, де керуються змінами стану.

Коли ви додаєте серверний ввід / вивід до суміші, це може виглядати так:

Потік із входом / виходом сервера

Окрім перегляду зворотних дзвінків, у багатьох додатках також будуть прослухані події для зв'язку з сервером. Дії інтерфейсу можуть також відправляти запити сервера та передавати оновлення серверу. Отже, зворотний виклик дії з подання може викликати запит або оновлення сервера, а слухач подій, що надсилаються сервером, може викликати подальші дії, які можуть бути відправлені в магазин тощо.

Можливо, ви чули про Redux, який зараз є найпопулярнішою альтернативою Flux. Він додає концепцію чистих функцій для маніпулювання магазином, званих редукторами. Редуктори спрощують, як міркувати про магазин, гарантуючи, що кожен вид оновлення стану може бути незалежно керований та протестований, а у редукторів немає побічних ефектів, а це означає, що зрозуміти вплив будь-якої конкретної дії просто. Щоб отримати чудовий огляд архітектури Redux, перегляньте цю слайд-колоду.

Для своїх перших додатків вам, мабуть, не потрібно мати справу з усією цією архітектурою. До цих оновлень архітектури ми дійшли, створивши великі програми, де необмежений спільний доступ до стану додатків може стати заплутаним і безладним. Ці абстракції дають нам чітку схему для всіх змін стану додатку, але вони, ймовірно, є надмірними для тривіальних додатків.

Спочатку ви можете підключити слухачів подій і безпосередньо маніпулювати станом своєї програми у відповідь, і це нормально. Навчіться ходити, перш ніж бігати. Коли ви готові перейти до складніших додатків, ознайомтеся з відмінними курсами Дана Абрамова, «Початок роботи з Redux» та «Створення реагуючих програм із ідіоматичним Redux».

Практикуйте програми

Кожен розробник потребує портфоліо коду. Програми для практик - це відмінний спосіб створити його.

Під час вивчення вищезгаданих курсів ви будете піддані дуже часто використовуваному прикладу програми "Список справ". Я рекомендую вам слідувати разом з навчальними посібниками і скласти один разом.

Але які ще цікаві додатки ви могли б створити? Однією з найскладніших речей щодо навчання кодуванню є створення хороших ідей для створення додатків.

Є веб-сайти, які об’єднують і класифікують ідеї програм за голосами. Однозначно погляньте на тих, якщо ви шукаєте ідеї.

Студенти «Дізнайтесь JavaScript з Еріком Елліоттом» знайдуть новий список студентських проектів, куратор із короткими списками функцій. Як додатки, так і функції мають рейтинги складності: "базовий", "проміжний" та "просунутий", щоб допомогти студентам відповідати викликам до їх поточного рівня навчання.

Приклад проекту: Відхилення

Студентський проект Learn JavaScript з Еріком Елліоттом.

Хочете працювати як команда? Знайдіть приятеля кодування в чаті для студентів.

Ви повинні програти, щоб виграти.

Навчіть себе:

  • Отримайте підвищення
  • Продавайте більше
  • Розвивайте більше бізнесу
  • Домовляйтеся про кращі пропозиції

У грі є одне правило:

Ви повинні бути відхилені людиною хоча б раз на день.

Запитуйте речі, що не входять у вашу зону комфорту, і ви виявите, що виграєте набагато більше.

Виграш = 1 бал. Відхилення = 10 балів.

Як довго ви можете тривати свою відмову у відриві?

Базовий рівень

Створіть інтерфейс користувача, який дозволяє відслідковувати ваш рахунок. Додайте текст для запиту, якого ви запитували, і дві кнопки: "Прийнято" або "Відхилено". Для асинхронних запитів, таких як електронні листи або повідомлення, записуйте бал у момент отримання відповіді, а не в той момент, коли ви запитуєте.

Використовуйте HTML + CSS і зберігайте запис даних у локальному сховищі.

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

Середній рівень

  • Додайте API для зберігання даних за допомогою веб-служби та бази даних.
  • Додайте автентифікацію та відстежуйте кількох користувачів. Підказка: Redis, Mongo або RethinkDB були б хорошими кандидатами в базу даних.
  • Соціальні входи, такі як Facebook або Twitter, були б хорошими варіантами аутентифікації (простішими та безпечнішими, ніж логіни / паролі).

Просунутий рівень

  • Поділіться своїм рахунком і змагайтеся зі своїми друзями у Facebook.
  • Для кожного користувача зберігайте таблицю лідерів у колі своїх друзів.

Додатковий кредит

  • Додайте мобільні додатки

Втілювати:

  1. Виділіть репо
  2. Реалізуйте своє рішення.
  3. Відкрийте проблему за допомогою посилання на вашу вилку.

Щоб отримати кредит, потрібно відкрити випуск із посиланням на вашу вилку.

Переглянути проект на GitHub.

Дізнайтеся JavaScript з Еріком Елліоттом

Ерік Елліот є автором "Програмування програм JavaScript" (O'Reilly) та "Дізнатися JavaScript з Еріком Елліоттом". Він сприяв досвіду програмного забезпечення для Adobe Systems, Zumba Fitness, The Wall Street Journal, ESPN, BBC, та найкращих виконавців звукозапису, включаючи Usher, Frank Ocean, Metallica та багато інших.

Він проводить більшу частину свого часу в районі затоки Сан-Франциско з найкрасивішою жінкою світу.