С момента появления термина « всемирная паутина» в 1990 году разработка веб-приложений превратилась из обслуживания статических HTML-страниц в полностью динамические и сложные бизнес-приложения.
Сегодня у нас есть тысячи цифровых и печатных ресурсов, которые предоставляют пошаговые инструкции по разработке всевозможных различных веб-приложений. Среды разработки достаточно «умны», чтобы выявлять и исправлять многие ошибки, с которыми регулярно сталкивались первые разработчики. Существует даже множество различных платформ разработки, которые легко превращают простые статические HTML-страницы в интерактивные приложения.
Все эти шаблоны, практики и платформы разработки имеют общую основу, и все они подвержены схожим проблемам веб-разработки, вызванным самой природой веб-приложений.
Цель этих советов по веб-разработке - пролить свет на некоторые из распространенных ошибок, совершаемых на разных этапах процесса веб-разработки, и помочь вам стать лучшим разработчиком . Я затронул несколько общих тем, которые являются общими практически для всех веб-разработчиков, таких как проверка, безопасность, масштабируемость и SEO. Вы, конечно, не должны быть связаны конкретными примерами, которые я описал в этом руководстве, поскольку они перечислены только для того, чтобы дать вам представление о потенциальных проблемах, с которыми вы можете столкнуться.
Распространенная ошибка № 1: Неполная проверка ввода
Проверка пользовательского ввода на стороне клиента и сервера просто обязательна ! Все мы знаем мудрый совет «не доверяйте вводу пользователя», но, тем не менее, ошибки, возникающие при проверке, случаются слишком часто.
Одним из наиболее частых последствий этой ошибки является внедрение SQL-кода, который год за годом входит в десятку лучших по версии OWASP .
Помните, что большинство интерфейсных сред разработки предоставляют готовые правила проверки, которые невероятно просты в использовании. Кроме того, большинство основных платформ серверной разработки используют простые аннотации, чтобы гарантировать, что отправленные данные соответствуют ожидаемым правилам. Реализация проверки может занять много времени, но она должна быть частью вашей стандартной практики кодирования и никогда не откладываться в сторону.
Распространенная ошибка № 2: аутентификация без надлежащей авторизации
Прежде чем мы продолжим, давайте удостоверимся, что мы согласны с этими двумя условиями. Как указано в 10 наиболее распространенных уязвимостях веб-безопасности :
Аутентификация: проверка того, что человек является (или, по крайней мере, кажется) конкретным пользователем, поскольку он / она правильно предоставил свои учетные данные (пароль, ответы на вопросы безопасности, сканирование отпечатков пальцев и т. Д.).
Авторизация: подтверждение того, что конкретный пользователь имеет доступ к определенному ресурсу или ему предоставлено разрешение на выполнение определенного действия.
Другими словами, аутентификация - это знание того, кем является объект, а авторизация - это знание того, что данный объект может делать.
Позвольте мне продемонстрировать эту проблему на примере:
Учтите, что ваш браузер хранит текущую информацию о пользователе в объекте, подобном следующему:
{ username:'elvis', role:'singer', token:'123456789' }
При смене пароля ваше приложение выполняет POST:
POST /changepassword/:username/:newpassword
В своем /changepassword методе вы проверяете, что пользователь вошел в систему и срок действия токена не истек . Затем вы находите профиль пользователя на основе :username параметра и меняете пароль пользователя.
Итак, вы подтвердили, что ваш пользователь правильно вошел в систему, а затем выполнили его запрос, изменив его пароль. Кажется, процесс в порядке, не так ли? К сожалению, ответ НЕТ!
На этом этапе важно убедиться, что пользователь, выполняющий действие, и пользователь, пароль которого изменен, совпадают. Любая информация, хранящаяся в браузере, может быть изменена, и любой опытный пользователь может легко обновить username:'elvis' ее, username:'Administrator' не используя ничего, кроме встроенных инструментов браузера.
Итак, в этом случае мы просто позаботились о Authentication том, чтобы пользователь предоставил учетные данные безопасности. Мы даже можем добавить проверку того, что /changepassword метод может выполняться только Authenticated пользователями. Однако этого все еще недостаточно для защиты ваших пользователей от злонамеренных попыток.
Вы должны убедиться, что вы проверяете фактического отправителя запроса и содержимое запроса в своем /changepassword методе и правильно реализуете Authorization запрос, убедившись, что пользователь может изменять только свои данные.
Authentication и Authorization являются двумя сторонами одной медали. Никогда не относитесь к ним по отдельности.
Распространенная ошибка № 3: не готов к масштабированию
В сегодняшнем мире высокоскоростной разработки, ускорителей стартапов и мгновенного глобального распространения отличных идей, как можно скорее выпустить на рынок ваш MVP (минимально жизнеспособный продукт), что является общей целью для многих компаний.
Однако из-за постоянной нехватки времени даже хорошие команды веб-разработчиков часто упускают из виду определенные проблемы. Масштабирование часто является одной из тех вещей, которые команды принимают как должное. Концепция MVP прекрасна, но если зайти слишком далеко, у вас возникнут серьезные проблемы. К сожалению, недостаточно выбрать масштабируемую базу данных и веб-сервер и разделить все уровни приложений на независимые масштабируемые серверы. Есть много деталей, о которых вам нужно подумать, если вы хотите избежать переписывания значительных частей вашего приложения позже, что становится серьезной проблемой веб-разработки.
Например, предположим, что вы решили хранить загруженные изображения профиля ваших пользователей непосредственно на веб-сервере. Это совершенно правильное решение - файлы быстро доступны для приложения, методы обработки файлов доступны на каждой платформе разработки, и вы даже можете использовать эти изображения как статический контент, что означает минимальную нагрузку на ваше приложение.
Но что происходит, когда ваше приложение растет, и вам нужно использовать два или более веб-сервера за балансировщиком нагрузки? Несмотря на то, что вы хорошо масштабировали хранилище базы данных, серверы состояния сеанса и веб-серверы, масштабируемость вашего приложения не работает из-за такой простой вещи, как изображения профиля. Таким образом, вам необходимо реализовать какую-то службу синхронизации файлов (которая будет иметь задержку и вызовет временные ошибки 404) или другой обходной путь, чтобы гарантировать, что файлы распространяются по вашим веб-серверам.
Что вам нужно было сделать, чтобы избежать проблемы, в первую очередь, просто использовать общее хранилище файлов, базу данных или любое другое решение для удаленного хранилища. Реализация всего этого, вероятно, потребовала бы нескольких дополнительных часов работы, но это того стоило.
Распространенная ошибка № 4: неверное или отсутствующее SEO
Основная причина неправильных или отсутствующих передовых методов SEO на веб-сайтах - это дезинформирование «специалистов по SEO». Многие веб-разработчики считают, что они достаточно хорошо разбираются в SEO и что это не так уж сложно, но это неправда. Мастерство SEO требует значительных затрат времени на изучение передового опыта и постоянно меняющихся правил того, как Google, Bing и Yahoo индексируют Интернет. Если вы постоянно не экспериментируете и не имеете точного отслеживания + анализа, вы не являетесь специалистом по SEO и не должны претендовать на него.
Кроме того, SEO слишком часто откладывается, поскольку некоторые действия выполняются в конце. Это связано с высокой ценой проблем веб-разработки. Поисковая оптимизация связана не только с установкой хорошего контента, тегов, ключевых слов, метаданных, альтернативных тегов изображений, карты сайта и т. Д., Это также включает в себя устранение дублированного контента, создание сканируемой архитектуры сайта, эффективное время загрузки, интеллектуальную обратную ссылку и т. Д.
Как и в случае с масштабируемостью, вы должны думать о SEO с того момента, как начнете создавать свое веб-приложение, иначе вы можете обнаружить, что завершение проекта внедрения SEO означает переписывание всей вашей системы.
Распространенная ошибка № 5: действия, отнимающие время или процессор, в обработчиках запросов
Один из лучших примеров этой ошибки - отправка электронной почты на основе действия пользователя. Слишком часто разработчики думают, что решение проблемы - это сделать SMTP-вызов и отправить сообщение непосредственно из обработчика пользовательских запросов.
Допустим, вы создали книжный интернет-магазин и рассчитываете начать с нескольких сотен заказов в день. В рамках процесса приема заказа вы отправляете электронные письма с подтверждением каждый раз, когда пользователь публикует заказ. Сначала это будет работать без проблем, но что произойдет, если вы масштабируете свою систему, и вы внезапно получите тысячи запросов на отправку писем с подтверждением? Вы либо получаете тайм-ауты SMTP-соединения, превышение квоты, либо время отклика вашего приложения значительно ухудшается, поскольку теперь оно обрабатывает электронные письма, а не пользователей.
Любое действие, потребляющее время или процессор, должно обрабатываться внешним процессом, а вы как можно скорее выпускаете свои HTTP-запросы. В этом случае у вас должна быть внешняя почтовая служба, которая принимает заказы и отправляет уведомления.
Распространенная ошибка № 6: не оптимизировать использование полосы пропускания
Большая часть разработки и тестирования происходит в локальной сетевой среде. Поэтому, когда вы загружаете 5 фоновых изображений, каждое размером 3 МБ или более, вы можете не выявить проблему со скоростью соединения 1 Гбит в вашей среде разработки. Но когда ваши пользователи начнут загружать на свои смартфоны домашнюю страницу размером 15 МБ через соединения 3G, вам следует подготовиться к списку жалоб и проблем.
Оптимизация использования полосы пропускания может дать вам значительный прирост производительности, и для этого вам, вероятно, понадобится всего несколько уловок. Есть несколько вещей, которые многие хорошие веб-разработчики делают по умолчанию, в том числе:
- Минификация всего JavaScript
- Минификация всего CSS
- HTTP-сжатие на стороне сервера
- Оптимизация размера и разрешения изображения
Распространенная ошибка № 7: разработка не для разных размеров экрана
Адаптивный дизайн стал большой темой в последние несколько лет. Распространение смартфонов с различным разрешением экрана привело к появлению множества новых способов доступа к онлайн-контенту, что также связано с множеством проблем веб-разработки. Количество посещений веб-сайтов со смартфонов и планшетов растет с каждым днем, и эта тенденция усиливается.
Чтобы обеспечить беспрепятственную навигацию и доступ к содержимому веб-сайта, вы должны предоставить пользователям доступ к нему со всех типов устройств.
Существует множество шаблонов и практик для создания адаптивных веб-приложений. У каждой платформы разработки есть свои советы и рекомендации, но есть некоторые платформы, не зависящие от платформы. Самым популярным, вероятно, является Twitter Bootstrap . Это бесплатный фреймворк HTML, CSS и JavaScript с открытым исходным кодом, принятый на всех основных платформах разработки. Просто придерживайтесь шаблонов и практик Bootstrap при создании приложения, и вы получите адаптивное веб-приложение без каких-либо проблем.
Распространенная ошибка № 8: кроссбраузерная несовместимость
В большинстве случаев процесс разработки требует значительных временных затрат. Каждое приложение необходимо выпустить как можно скорее, и даже хорошие веб-разработчики часто сосредоточены на предоставлении функциональности, а не на дизайне. Несмотря на то, что у большинства разработчиков установлены Chrome, Firefox, IE, они используют только один из этих 90% времени. Обычной практикой является использование одного браузера во время разработки, и как только приложение близится к завершению, вы начнете тестировать его в других браузерах. Это вполне разумно - при условии, что у вас есть много времени, чтобы проверить и исправить проблемы, которые проявляются на этом этапе.
Однако есть несколько советов по веб-разработке, которые могут значительно сэкономить вам время, когда ваше приложение достигнет фазы кроссбраузерного тестирования:
- Вам не нужно тестировать во всех браузерах во время разработки; это требует много времени и неэффективно. Однако это не означает, что вы не можете часто переключать браузеры. Используйте другой браузер каждые пару дней, и вы, по крайней мере, обнаружите основные проблемы на ранней стадии разработки.
- Будьте осторожны при использовании статистики, чтобы оправдать отказ от поддержки браузера. Есть много организаций, которые медленно внедряют новое программное обеспечение или обновляются. Тысячи пользователей, работающих там, могут по-прежнему нуждаться в доступе к вашему приложению, и они не могут установить последнюю версию бесплатного браузера из-за внутренней безопасности и бизнес-политик.
- Избегайте кода, специфичного для браузера. В большинстве случаев существует элегантное решение, совместимое с несколькими браузерами.
Распространенная ошибка № 9: не планируют переносимость
Успение - мать всех проблем! Когда дело доходит до портативности, это высказывание вернее, чем когда-либо. Сколько раз вы сталкивались с проблемами в веб-разработке, такими как жестко заданные пути к файлам, строки подключения к базе данных или предположения, что определенная библиотека будет доступна на сервере? Ошибочно предполагать, что производственная среда будет соответствовать вашему локальному компьютеру разработки.
Идеальная установка приложения не требует обслуживания:
- Убедитесь, что ваше приложение может масштабироваться и работать в среде с несколькими серверами с балансировкой нагрузки.
- Разрешить простую и понятную настройку - возможно, в одном файле конфигурации.
- Обработка исключений, когда конфигурация веб-сервера не соответствует ожидаемой.
Распространенная ошибка № 10: антипаттерны RESTful
API-интерфейсы RESTful заняли свое место в веб-разработке и никуда не денутся. Почти в каждом веб-приложении реализованы какие-либо службы REST, будь то для внутреннего использования или интеграции с внешней системой. Но мы по-прежнему видим неработающие шаблоны и службы RESTful, которые не соответствуют ожидаемым практикам.
Две из наиболее распространенных ошибок при написании RESTful API :
- Использование неправильных HTTP-глаголов. Например, используя GET для записи данных. HTTP GET был разработан, чтобы быть идемпотентным и безопасным, что означает, что независимо от того, сколько раз вы вызываете GET на одном и том же ресурсе, ответ всегда должен быть одинаковым и никаких изменений в состоянии приложения происходить не должно.
- Не отправляются правильные коды состояния HTTP. Лучший пример этой ошибки - отправка сообщений об ошибках с кодом ответа 200.HTTP 200 OK { message:'there was an error' }
Вы должны отправлять HTTP 200 OK только в том случае, если запрос не вызвал ошибки. В случае ошибки вы должны отправить 400, 401, 500 или любой другой код состояния, соответствующий возникшей ошибке.
Подробный обзор стандартных кодов состояния HTTP можно найти здесь .
Заворачивать
Веб-разработка - это чрезвычайно широкий термин, который на законных основаниях может охватывать разработку веб-сайта, веб-службы или сложного веб-приложения.
Главный вывод этого руководства по веб-разработке - напоминание о том, что вы всегда должны быть осторожны с аутентификацией и авторизацией, планировать масштабируемость и никогда ничего не предполагать поспешно - или быть готовым иметь дело с длинным списком проблем веб-разработки!
