10 распространенных ошибок веб-разработчиков


Оглавление (нажмите, чтобы открыть):

10 распространенных ошибок веб-разработчиков

Группа: Главные администраторы
Сообщений: 14349
Регистрация: 12.10.2007
Из: Twilight Zone
Пользователь №: 1

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

Использование старого HTML

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

для создания макета страницы; применяют или

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

Последствия: Использование HTML десятилетней «свежести» может привести к излишнему усложнению разметки страницы и, как следствие, к непредсказуемости её отображения в разных браузерах. И далеко не только в Internet Explorer.

Как избежать: Для начала перестаньте использовать

для создания структуры страницы и применяете его только для вывода табличных данных. Ознакомьтесь с более современными инструментами. Используйте HTML для описания самого контента, а не способов его отображения. А для корректного отображения применяйте CSS.

«У меня в браузере всё работает»

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

Последствия: Будьте готовы к тому, что сайт, «заточенный» под один браузер, в других будет выглядеть просто ужасно.

Как избежать: Конечно, тестировать свой сайт во всех существующих браузерах и их версиях было бы пыткой. Но нужно хотя бы периодически проверять, как ваш сайт выглядит в некоторых наиболее популярных браузерах. Сегодня для этого есть бесплатные инструменты: виртуальные машины, сканеры сайтов. Например, с помощью http://browsershots.org/ или https://www.browserstack.com/ можно сделать снэпшоты того, как будет рендериться конкретная страница на всевозможных платформах. Работая с CSS, убедитесь, что «сбросили» все значения по умолчанию.

Кстати, если вы используете какие-то специфические CSS-решения, заточенные под конкретные браузеры, то обратите внимание на характерные для разных вендоров префиксы вроде -webkit-, -moz- или -ms-. Чтобы быть в курсе текущих тенденций, можете изучить эти ссылки:

Там описывается, почему стоит отойти от использования подобных префиксов. Практические рекомендации, как работать без префиксов, можно найти здесь: http://davidwalsh.name/goodbye-vendor-prefixes.

Плохие формы ввода

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

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

Как избежать: Во-первых, удостоверьтесь, что вы безошибочно донесли до пользователей, какая именно информация вам от них нужна. Если вы просите ввести «адрес», то уточните, какой: рабочий, домашний, электронный? Чтобы дополнительно подстраховаться, используйте проверку корректности вводимых данных. Неважно, как это будет сделано на стороне браузера, главное, чтобы на сервере были уже проверенные данные. Никогда не используйте сцепленные T-SQL выражения для работы с полученными от пользователей данными без подтверждения корректности по каждому полю ввода.

Слишком большие ответы на сетевые запросы

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

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

Как избежать: Не думайте, что раз интернет из года в год становится быстрее, то это оправдывает раздувание размеров страниц. Вместо этого оптимизируйте свои проекты ради ускорения обмена сетевыми пакетами. Основная причина, по которой страницы становятся «тяжёлыми», — изображения. Чтобы минимизировать их влияние:

  1. Спросите себя, действительно ли необходима вся используемая вами графика? Откажитесь от ненужных графических украшательств. Можно воспользоваться сетевыми инструментами, чтобы определить, какие изображения нуждаются в дополнительном сжатии.
  2. Уменьшите размер изображений. Например, с помощью Shrink O’Matic или RIOT.
  3. Используйте предзагрузку. Это не ускорит первичную загрузку, но зато даст преимущество при просмотре других страниц сайта. Подробности можно почерпнуть из статьи: https://perishablepress.com/3-ways-preload-. avascript-ajax/

Миницифируйте залинкованные CSS- и JS-файлы. Для этого есть множество инструментов, например, Minify CSS и Minify JS.

И наконец, старайтесь использовать наиболее современную версию HTML и внимательно используйте тэги и

10+ ошибок веб-разработчиков с примерами

Ошибки делают все — а расплачивается кто-то один.

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

В итоге: мало того, что сайт сдается с опозданием, так еще и продвижение затягивается. Всё из-за каких-то постоянных доработок.

Какой там выигрыш в конкурентной борьбе! — нужно хотя бы отыграть потраченные деньги.

А ведь этого можно избежать.

Эта презентация вооружит вас. В ней собрано 10 наиболее частых и наиболее болезненных ошибок разработчиков (а также «факультативные» ошибки, которых также стоит опасаться). Вы без труда найдете их и сможете исправить.

Как пользоваться презентацией:

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

Смотреть презентацию и не платите за ошибки!

Комментарии к “ 10+ ошибок веб-разработчиков с примерами ”

Женя, приложи, пожалуйста, ссылку на что-нибудь полноэкранное

можешь посоветовать сервис?

Думаю имеет смысл начать с поиска плагина для вордпресса, типа http://wordpress.org/extend/plugins/groupdocs-viewer/ (я не ставил, но описание вроде про то)

1. По какому принципу поисковая машина выбирает текст для сниппета? Как ей помочь «взять» нужный кусок текста в сниппет?

2. Какой из url лучше применять?
http://www.site.ru/kolbasa или http://www.site.ru/колбаса (который будет по факту кодом «%5%7%6%7…»)

Не важно какой урл. Хоть /index23.php. Название урла в результатах поиска возьмется из H1 и ссылки навигации, если структуру составить правильно. Для сео это уже не очень актуально, но, для удобства понимания пользователем куда он попадет, можно называть /kolbasa.

Поисковая машина выберет сниппет по принципу первого упоминания слова или фразы в нужном пассаже. Заголовок H1 никогда не будет показанным первым, так что в первом абзаце страницы, где содержится нужное слово нужно написать максимально полезный для пользователя текст, который и будет показываться в результатах поиска. Для главной страницы сейчас зачастую выводится текст из мета-тега description или из описания в Я.Каталоге.

10 самых распространенных ошибок, которые делают разработчики на WordPress

Разработчики на WordPress в погоне за быстрыми результатами часто совершают одни и те же ошибки. Перед вами 10 советов, которые помогут с ними бороться.


Включайте режим отладки

Зачем использовать отладку, если код работает нормально? Отладка — это встроенная функция в WordPress, которая поможет отобразить все ошибки PHP, предупреждения и уведомления (включая устаревшие функции). С отключенной отладкой тяжело регистрировать нештатные ситуации, возникающие на сайте, что в конечном итоге может принести массу проблем. Кроме того, ошибки могут привести к существенному снижению скорости открытия страниц. Каждый раз, добавляя новый скрипт или пользовательский код в WordPress, включайте отладку (но не забывайте отключать её при введении новой функциональности в эксплуатацию).

Чтобы активировать режим отладки, нужно отредактировать файл wp-config.php в корневом каталоге установки WordPress:

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

Не добавляйте все скрипты в верхнюю часть сайта

Хотя в WordPress есть множество популярных скриптов, многие разработчики добавляют дополнительные скрипты в wp_head . Это может привести к сильному снижению скорости загрузки страниц.

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

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

ZIP Service, Москва, можно удалённо, от 100 000 ₽

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

Создавайте дочерние темы и не меняйте файлы движка

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

Чтобы создать дочернюю тему, поместите файл style.css в подкаталог папки дочерней темы и наполните подобным содержимым:

В приведенном выше примере создается дочерняя тема, основанная на теме «WordPress Twenty Sixteen». Важной строкой этого кода является слово Template , которое должно соответствовать имени каталога родительской темы, с которой вы клонируете шаблон.

Такие же принципы применяйте к основным файлам WordPress: не нужно изменять файлы движка, постарайтесь использовать функции и фильтры CMS так, чтобы ваши изменения не были перезаписаны после обновления. Подключаемые функции позволяют вам переопределить некоторые базовые функции, но этот подход используется всё реже и заменяется фильтрами. С фильтрами достигается тот же результат, что и с подключаемыми функциями: изменение вывода функций WordPress. Не забывайте добавлять в код if ( !function_exists() ) при использовании подключаемых функций, поскольку несколько плагинов, пытающихся переопределить одну и ту же подключаемую функцию без этой оболочки, будут приводить к фатальной ошибке.

Не используйте хардкодинг

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

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

Другим плохим примером хардкодинга является запись пользовательских запросов. Например, в качестве меры безопасности мы меняем установленный по умолчанию префикс WordPress из wp_ на нечто более уникальное, например, wp743_ . Наши запросы не сработают, если мы когда-нибудь переместим наш сайт на WordPress, поскольку префиксы таблиц могут меняться между средами. Чтобы этого не произошло, мы можем ссылаться на свойства таблицы класса wpdb :

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

Не давайте постоянно индексировать ваш сайт

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

Как показано ниже, в настройках чтения WordPress есть флажок, который гласит: «Попросить поисковые системы не индексировать сайт» (хотя это не гарантирует, что поисковые системы отработают данный параметр):

Поэтому, если вы хотите надёжно предотвращать индексацию вашего сайта поисковыми системами, отредактируйте файл .htaccess и вставьте следующую строку:

Перепроверяйте работоспособность плагинов

Зачем проверять, включена ли функция плагина, если он активен? Конечно, в 99 % случаев это так, однако этот один процент может привести к тому, что ваш сайт будет выводить некоторые ошибки PHP. Чтобы этого не произошло, мы можем проверить, активен ли плагин, прежде чем использовать его функции. Если функция плагина вызывается через фронтенд, то нужно включить библиотеку plugin.php в код, чтобы вызвать функцию is_plugin_active() :

Этот метод обычно достаточно надёжный. Однако могут быть случаи, когда автор изменил имя основного каталога плагина. Более надёжным методом было бы проверить наличие класса в плагине:

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

Не загружайте слишком много ресурсов

Зачем выборочно загружать ресурсы для страниц? Нет веской причины загружать стили и скрипты для плагина, если этот плагин не используется на странице, на которой находится пользователь. Используя плагины только тогда, когда это необходимо, мы сможем существенно ускорить время загрузки страниц. Возьмем, например, сайт WooCommerce, где нам нужно, чтобы плагин загружался только на торговых страницах, что позволит снизить нагрузку на сайт. Для этого следует добавить следующий код в файл шаблона functions.php :

Сценарии также можно удалить с помощью функции wp_dequeue_script ($ handle) через дескриптор, с которым они были зарегистрированы. Аналогично wp_dequeue_style ($ handle) предотвратит загрузку таблиц стилей. Но, если это технически сложно для вас, можно установить Plugin Organizer, который обеспечивает выборочную загрузку плагинов на основе определенных критериев, таких как тип сообщения или имя страницы. Рекомендуется отключить любые кэширующие плагины, такие как W3Cache, чтобы изменения стали заметными.

Не оставляйте панель управления в верхней части сайта

Можно ли оставить панель администратора WordPress видимой для всех? Да, вы можете позволить своим пользователям получить доступ к страницам администратора. Но если вы хотите, чтобы ваш сайт выглядел профессионально, вы должны отключить панель администратора для пользователей и оставить её только для себя:

Этот код нужно вставить в файл functions.php вашей темы. Таким образом, панель будет отображаться только для администратора сайта. Используя current_user_can ($) , можно добавить пользователю любую роль, а также исключить его из панели управления.

Используйте фильтр GetText

Можно использовать CSS или JavaScript для изменения ярлыка кнопки, что с этим не так? Да, можно. Однако вы добавляете лишний код и тратите дополнительное время, чтобы отобразить кнопку, когда вместо этого вы можете использовать один из самых удобных фильтров в WordPress — gettext . Используя этот фильтр совместно с textdomain , мы можем изменять текст до загрузки страницы. Если изменяемый текст находится в теме, найдите строку кода load_theme_textdomain ($ domain) .

На примере WooCommerce рассмотрим, как изменить текст, который появляется для заголовка «Related Products». Вставьте следующий код в файл functions.php вашей темы:

Этот фильтр применяется к переведённому тексту с помощью функций интернационализации __() и __e() , если textdomain определен с помощью вышеупомянутых функций.

Меняйте значения для постоянных ссылок

По умолчанию WordPress использует строку запроса с идентификатором post , чтобы вернуть запрашиваемый контент. Такой формат ссылок будет неудобным для использования, кроме того, это может сказаться на индексации вашего ресурса поисковыми системами. Включение постоянных ссылок, например, в режим «Произвольно», поможет поднять ранжирование страниц, ведь там могут также находиться ключевые слова. Лучше всего это делать сразу после установки WordPress. Вы можете выбрать формат ссылок на экране «Настройки постоянных ссылок»:

Заключение

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

6 ошибок начинающих веб-разработчиков и как их избежать

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

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

1. Надежда на jQuery


JQuery это библиотека JavaScript, создающая слой абстракции для DOM-манипуляций, управления событиями, анимаций и многого другого.

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

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

Рекомендация: Изучите JavaScript, как свои пять пальцев. У Кайла Симпсона есть тысячи отличных (и бесплатных) книг, которые помогут вам изучить этот язык вдоль и поперек.

2. Надежда на фреймворки JavaScript

React, Vue и Angular в настоящее время являются самыми «горячими» фреймворками в JavaScript-сообществе. Но одна из самых больших ошибок, совершаемых начинающими разработчиками, – изучение этих инструментов без хорошего понимания JavaScript.

Хотя знание популярных фреймворков JavaScript и умение работать с ними является ценным навыком на рынке труда, вам нужно сначала изучить JS, а уж затем выбирать фреймворк. Если вы не знаете основ языка, вы никогда не сможете понять, какие функции выполняются «под капотом» этих фреймворков.

Рекомендация: Заложите хороший фундамент из знаний основ JavaScript, прежде чем погружаться во фреймворки. Это намного более ценный навык, чем знание отдельного фреймворка. Кроме всего прочего, это обеспечит вам преимущество на собеседовании, когда вам станут задавать технические вопросы. Если у вас будет глубокое понимание JavaScript, вы не возникнет проблем с освоением нового фреймворка.

3. Использование Bootstrap

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

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

Рекомендация: Изучите CSS Flexbox и Grid для адаптивного веб-дизайна, изучите основы CSS, а после этого изучите Sass. Если у вас возникают проблемы с проектированием вашего приложения, поищите вдохновение в dribbble или посмотрите шаблоны на Wix или Squarespace.

4. Отказ от модульности при программировании

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

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

Также вы можете подумать об использовании JavaScript-фреймворка или библиотеки вроде React или Vue. Обе они очень облегчают реализацию модульных компонентов, однако, прежде чем браться за них, убедитесь, что вы понимаете vanilla JavaScript.

5. Неиспользование семантического HTML

Просматривая портфолио и проекты кандидатов, я часто замечаю чрезмерное использование

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

6. Незнание адаптивного дизайна

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

Рекомендация: Пройдите курс-другой по адаптивному дизайну. Научитесь пользоваться медиа-запросами для придания различных стилей вашему приложению. Изучение Flexbox и CSS Grid также будет очень полезным. Возможно, вы даже захотите применять подход «mobile first».

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

5 распространенных ошибок в веб-дизайне, которые бесят пользователей

Разработка интерактивного интерфейса или веб-сайта – нелегкая задача. Вы должны собрать всё о вашей аудитории, проанализировать и спланировать её поведение. Новые технологии делают процесс исследования проще. Однако они же работают в обратную сторону: в век технологий пользователей сложно чем-то удивить.

Глянцевые изображения и ховеры больше не впечатляют пользователей. Анимации и гифки тоже – любой может сделать такое на своём телефоне. Так как же удивить своих пользователей? Как сделать их счастливыми и поддержать конверсию?

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

1. Слишком много инноваций

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

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

2. Запутанная навигация

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

Очень часто в гонке за индивидуальностью вместо обычных названий выбираются максимально странные. Вместо шаблона «home, about, contact, blog» мы видим «наша вселенная, следуй за нашим путем» и т.д. Конечно, пользователи оценят вашу креативность в названиях – когда наконец-то смогут понять, что к чему относится.

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

3. Ненависть к пустому пространству

Давным-давно у разработчиков сайтов была тенденция: размещать на сайте максимальное количество информации. Реклама и тонна материалов были повсюду. Но сейчас это не так. Люди любят минимализм во всём – вот хороший пример.

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

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

4. Неиспользование контраста

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

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

Дональд Эмерсон, дизайн-блогер в Writemyx

Убедитесь, что в вашем дизайне достаточно контраста, чтобы показать пользователю, куда идти и что делать.

5. Сложные формы

Формы – это боль. Никто не любит их заполнять. Но они – необходимое зло, ведь являются оптимальным способом узнать пользователя получше.

Тем не менее, они не должны выглядеть уродливо и раздражать. Что к этому приводит? Ну, во-первых, длинные формы, которые требуют от вас слишком многого. Если ваша форма – бесконечный опрос, в конце которого нужно ещё и заполнить капчу, то она обречена на провал.


Простота – залог успеха. Оставьте только имя-фамилия-электронная почта (и пароль, если этого требует ситуация). Не просите слишком много. И ради бога, проверьте и сами свою форму. Слишком часто в Интернете ты сталкиваешься с тем, что заполняешь форму, пропускаешь «необязательные пункты», которые потом подчеркиваются красным. Хм, разве так работает принцип необязательности?

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

10 наиболее распространенных типов веб-разработчиков

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

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


1.
Пуристы

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

Они используют JavaScript вместо JQuery каждый раз. Они не видят никаких проблем в применении чистых языков и традиционных способов. Дополнительные библиотеки равны наворотам для них.

Имейте в виду, это не означает, что они не используют все это в реальной жизни. Трудно не применять новые языки, когда в каждой вакансии в наши дни просят «опыт в JQuery».

2. Исполнители

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

Исполнители обычно работают над стартапами и готовы реализовать все заготовки в бесперебойном производстве цифровых продуктов. Еще один верный признак Исполнителя – это использование различных сервисов для постановки задач.

3. Полиглоты

Полиглоты – это те, кто использует сразу несколько языков программирования. Причем использует их мастерски, как жонглер в цирке. Тем не менее, работа только на одном языке программирования практически невозможна в веб-разработке; вы не сможете избежать этой участи, даже если вы разработчик серверной. Таким образом, если вы знаете, по крайней мере, 4-5 языков программирования, вы можете похвастаться тем, что вы полиглот.

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

4. Перфекционисты

Что приходит на ум, когда вы слышите слово «перфекционист»? Нет, я не имею в виду тех, кто стремится написать самый совершенный, безупречный код. Реальные Перфекционисты — это те, кто выходит за рамки кодирования. Они оставляют комментарии, обращают внимание на названия переменных и ведут различную документацию – например, подробные отчеты о проделанной работе.

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

5. Искусствоведы

С точки зрения веб-разработки, давайте просто говорить, что родным языком этой группы является CSS. Формы, цвета, анимация, фильтры и все другие визуальные вещи – это их родная стихия. Хотите встретить их? Центр обитания таких разработчиков — Codepen.

Они не дизайнеры, или, может быть, они являются ими где-то в глубине души, но в жестоких жизненных реалиях они — разработчики. Они выражают свое искусство через код, а не с помощью Adobe Illustrator или After Effects.

6. Запасливые

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

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

7. Книжные черви

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

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

8. Отладчики

Умение исправить ошибку – это сила. Это понимаешь только тогда, когда страница показывает «Ошибка 500». Отладчики могут не только поймать и исправить ошибки в их собственном коде, но в кодах, написанных другими разработчиками.

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

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

9. Исследователи

Для Исследователей, код – не просто код. Это чудесная тема для поста в блоге, или обсуждения на форуме. Нет, это не проповедь, а только обмен знаниями.

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

10. Общительные

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

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

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

H Несколько советов начинающим веб-разработчикам в черновиках Recovery Mode

.collapse»>Содержание

В мире разработки новые вопросы у программистов возникают каждый день. Ещё больше вопросов возникает если ты начинающий разработчик. Новые технологии первое время даются с трудом. Из-за споров опытных программистов непонятно за изучение чего взяться. Почему нужно делать так, а не так? Где найти информацию касательно того или того? Почему лучше делать так, чем так? И главный вопрос, у кого спросить?

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

Viewport

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

Не когда вы сверстали десктопную версию сайта и собрались начать адаптировать. Ни, боже упаси, после того как сделали адаптивную верстку. Всегда перед началом верстки. Перед!

Шрифты

Шрифты всегда была и будет моя самая нелюбимая часть верстки. Их нужно правильно подключить, правильно настроить и это на первых этапах вызывает головную боль(хотя казалось бы, в чем могут быть проблемы). Дальше по пунктам.


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

Второе. Не используйте Google Fonts как единственный способ подключения шрифта. Так же загружайте шрифт в директорию проекта и подключайте локально. Если вы сделаете это, то когда вы решите поверстать на компьютере на котором нет интернета у вас, хотя бы, не возникнет вопрос, почему у меня перестал работать шрифт.

Третье. Используйте Google Fonts (это не реклама, это реально удобно).

Четвертое. Используйте сервис Font2Web. Он практически полностью искореняет возможные проблемы с подключением шрифта.

Пиксель перфект верстка и динамичные сайты

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

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

Используйте Stack Overflow

Странно звучит для некоторых, но все же. Когда начинаешь постигать веб-разработку ты ещё не знаешь о куче крутых штук и сервисов помогающих в работе. И одна из самых важных и первых вещей для разработчика, это научиться пользоваться сервисом stack overflow. Для тех кто не знает, это сервис для разработчиков, где можно задать свой вопрос и получить ответ от других программистов. Так же база вопросов и ответов хранится, поэтому прежде чем задавать вопрос всегда необходимо проверить, может кто-нибудь уже задавал его ранее. Для тех кто плохо дружит с английским есть русская версия сайта(база вопросов/ответов там по-меньше, но так же отлично развивается).

Учитесь постепенно!

Это действительно важно. Много начинающих разработчиков на первых порах обучения очень сильно метаются между технологиями. Сегодня хочу учить html, завтра попробую jquery, потом попробую boostrap, на следующий день php, а может react выучить попробовать?

Пожалуйста, успокойтесь. Даже если ваша цель в итоге стать офигенным back-end программистом на php в любом случае в начале выучите html и css. Когда он станет вам понятен попробуйте узнать азы javascipt. Даже если вы не планируете писать код на нем, javascript для веб-разработчика обязательный стандарт поэтому эти знания точно лишними не будут. И когда вы сможете быстро и без запинок на гугленье сделать так чтобы при клике на кнопочку «меню», меню появлялось и при повторном клике пропадало, смело можете переходить к php.

Ещё один совет касательно изучения javascript. Сейчас многие опытные программисты могут меня захейтить, но этот совет мне дал именно более опытный программист, когда я только начинал. Javascipt проще начинать учить с библиотек.

То есть совсем простые вещи необходимо уметь делать на нативном js, но если какие-то функции и методы типа JSON.stringify или Array.prototype даются с трудом, то можно повременить. Выучите jQuery, сделайте парочку самых простых сайтов с его использованием. Попробуйте Vue.js, попробуйте собрать на нем какое-нибудь веб-приложение. С каждой выученной библиотекой понимание js будет все лучше и лучше. А там вы и сами не заметите как вернетесь к более глубокому постижению нативного javacript.

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

Выявляем и исправляем 7 частых ошибок веб-дизайна

О распространённых ошибках в веб-дизайне рассказывает Евгений Полев, UX Team Lead в Weblium.

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

Неадаптированные формы ввода данных

Современный сайт должен быть адаптирован под мобильные устройства. Это истина, с которой спорить бессмысленно. К счастью, большинство компаний это понимают и не экономят на мобильной версии сайта. Но проколы с адаптацией контента всё же случаются в самых, казалось бы, очевидных местах — формах ввода данных.

Формы для заполнения есть на всех сайтах. Это может быть подписка на рассылку, ввод данных, таких как имя, email или телефон, или самое банальное — логин и пароль.

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

ТОП-100 лучших SEO-агентств России 2020

Кто лучше всех в России умеет продвигать сайты в поисковых системах – и к кому лучше обратиться за продвижением сайта своей компании?

Ответ – в свежем рейтинге SEO-компаний за 2020 год по версии RUWARD.

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

Форма должна автоматически выводить клавиатуру, наиболее подходящую для заполнения.

Например, если это поле email, то клавиатура должна быть с «собачкой» @, а если это номер телефона — то должна выводиться цифровая клавиатура. Это стандартные возможности HTML-вёрстки, но до сих пор очень часто разработчики не используют этот функционал.

Потеря фокуса человека на странице

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

Привлекать внимание нужно к каким-то конкретным местам на странице, а не ко всем сразу.

Одно из самых простых решений — использовать в этих местах акцентный цвет или какой-то дизайнерский элемент.

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

На примере мы видим, что ещё на этапе каталога пользователю предлагают принять участие сразу в нескольких акциях, хотя он ещё даже не определился с товаром. В результате пользователь просто не знает, куда смотреть — на продукт, на розыгрыш автомобиля или поездки.

Но что делать, если у вас и правда много акций и вы хотите сообщить о них посетителям?

Важно понимать, в какой именно момент можно повлиять акцией на решение человека.

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

Наличие акций играет роль на этапе, когда человек уже определился с моделью и думает, купить товар здесь или в каком-то другом месте. Размещать акции лучше на карточке товара, где-то рядом с кнопкой купить или ценой как её оправдание.

Игнорирование призывов к действию

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

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

На примере видим, что кнопка призыва к действию выглядит, как тег к полю. К тому же, призыв к действию Be awesome совсем неочевидный для формы подписки на рассылку.

Отсутствие отклика системы

Если страница грузится дольше 2–3 секунд — пользователю кажется, что ваш сайт сломался, и в результате он уходит. Если вы знаете о том, что для загрузки страниц вашего сайта необходимо больше времени, просто покажите, что запрос получен. Например, поставьте прелоадер, который будет сообщать, что сайт загружается.

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

  • подключить опцию сжатия данных протокола HTTP;
  • оптимизировать изображения: проверьте, что вы загружаете картинки в формате JPEG, а не PNG;
  • используйте сервисы для упрощения и сжатия кода: к примеру, JSCompress.


В меню скрыты действительно важные пункты

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

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

Однако не всегда гамбургер-меню — лучшее решение.

На примере целых три важных пункта меню спрятаны: News, About и Contact. К тому же, один из них — контакты, которые потенциально конвертируют посетителей в лиды. А это значит, что большинство посетителей просто покинут сайт, так и не попав на страницу, которая бы могла превратить их в клиентов.

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

Непонятно, где пользователь сейчас находится

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

Например, в ритейловых магазинах есть целая зона в 10 метров при входе. Здесь у посетителя идет «акклиматизация»: он сканирует помещение, анализирует то, что видит. То же самое происходит с посетителем, когда он попадает на новый сайт или отдельную страницу. И чем быстрее вы расскажете, что это за страница, и то ли это, что искал пользователь, тем быстрее он продолжит свой путь.

Добавьте понятный заголовок на страницу, «хлебные крошки», которые указывают путь к странице, выделите пункт в меню — так пользователь быстрее сориентируется, где находится.

Отсутствие контекстной навигации

Если вы хотите, чтобы пользователь не закрыл страницу, а продолжил путь по сайту, дайте ему возможность сделать это, кликая по ссылкам. Например, если вы пишете статью о холодильниках, добавляйте ссылки на товар. Если вы ведёте блог — давайте ссылки на другие статьи. Здесь важно помнить, что вставлять линк нужно именно в том месте, где пользователь столкнулся в информацией. Это работает просто: человеку стало интересно, о чём вы сейчас говорите, он нажал и перешёл на страницу. Контекстная навигация — наиболее естественна для человека.

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

Исправить эти ошибки просто, а результат превзойдёт ваши ожидания. Больше довольных посетителей, больше лидов, а как результат — больше клиентов и продаж. А ведь именно к этому вы и стремитесь, не так ли?

10 самых распространенных ошибок веб-дизайна

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

1. Непродуманный макет

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

Чтобы основные ошибки веб-дизайна не попали на ваш следующий макет:

    Всегда используйте сетку (gr >

2. Неудобная навигация

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

Помните о следующем:

  1. Пользователь ожидает, что горизонтальная навигация будет располагаться вверху, а вертикальная — слева.
  2. Если разделов немного, не используйте выпадающие меню.
  3. Больше всего внимания привлекают пункты, которые идут вначале и в конце. Поэтому размещайте все самое важное вначале, а последним пунктом пусть будут данные для связи.

3. Непоследовательность в дизайне страниц

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

Чтобы дизайн был консистентным:

  1. Используйте на всех страницах одну и ту же цветовую схему.
  2. Следите за тем, чтобы расстояния по вертикали и горизонтали между элементами макета везде были одинаковыми.
  3. Заголовки на разных страницах должны быть одинакового размера.
  4. Не меняйте расположение навигации на разных страницах.
  5. Придерживайтесь единого оформления ссылок.
  6. Используйте иконки, выполненные в одном стиле.
  7. Обеспечьте единство оформления форм.

4. Неудачная цветовая схема

Цвета, которые не подходят под тематику или резонируют с ней, повлияют на восприятие сайта. Используя сливающиеся цвета, вы рискуете потерять посетителя в первые же секунды:

Ошибки в дизайне веб-страницы выше связаны с неудачным выбором цветов и сразу заметны. Чтобы избежать их, учтите следующее:

  1. Имеются ли у компании корпоративные цвета. Если да, то их следует использовать при создании дизайна для сайта.
  2. Какая у сайта цель. Теория цвета говорит, что красный — это цвет страсти и воодушевления, он привлекает внимание и побуждает к действию, в то время как синий — цвет спокойствия и уверенности, он говорит о надежности и вызывает чувство доверия к бренду. Если вы свободны в выборе цветов, уделите время тому, чтобы подобрать те, которые максимально соответствуют цели сайта.
  3. Существуют ли изображения и фотографии, которые требуется использовать. В таком случае вам понадобиться использовать цвета, которые будут хорошо с ними сочетаться.
  4. Используйте 3 разных цвета. При этом рекомендуемое соотношение составляет 60%, 30% и 10%. Помните, что чем больше цветов вы используете, тем тяжелее будет создать гармоничную и сбалансированную страницу.

5. Дизайн выглядит плохо на некоторых разрешениях экрана

Этот недостаток также входит в топ-10 ошибок веб-дизайна и может проявляться по-разному: например, у пользователей с меньшим разрешением экрана появляется горизонтальная прокрутка.

Чтобы дизайн выглядел хорошо на большинстве разрешений:

  1. Самые важные блоки должны находиться верху страницы, чтобы пользователям не приходилось много скроллить.
  2. Проверьте, удобно ли читать текст в разных колонках, учитывая их ширину.
  3. Убедитесь, что все ли элементы остаются на нужных местах и ничего не съезжает.

Проверьте, верно ли это для разных разрешений экрана в диапазоне от 800 x 600 до 1280 x 1024. Кроме того, вы можете предложить клиенту создать адаптивный сайт, чтобы эти ошибки веб-дизайна больше не беспокоили клиентов, которые заходят на сайт.

6. Отсутствие свободного пространства

Разумеется, основная, функция веб-сайта — это предоставлять информацию. Но принцип «чем больше, тем лучше» здесь не работает:

Информацию нужно подавать так, чтобы между блоками текста оставалось достаточно свободного места. Это поможет:

  1. Улучшить читаемость и общее восприятие текста.
  2. Привлечь внимание к тексту, просто окружив его пустым пространством.
  3. Создать ощущение элегантности и открытости.


7. Слишком сложные формы регистрации

Дни, когда пользователям приходилось заполнять множество полей и по несколько раз вводить данные в поля с валидацией, давно прошли:

Делайте формы максимально простыми — дополнительные данные всегда можно запросить позже, не раздражая пользователя:

8. Неразумное использование изображений

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

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

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

9. Незаметные контактные данные

Это особенно критично для магазинов — контактная информация должна быть доступна на каждой странице сайта и быть достаточно заметной:

10. Отсутствие поиска

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

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

Больше кода, не значит лучше

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

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

Многие разработчики могут подумать, что подход с написанием классов даже в таком простом случае может показать представителям компании, что кандидат разбирается в основных принципах ООП, а также заботится о дальнейшем сопровождении и развитии кода. На самом же деле зачастую гораздо приятнее видеть, что разработчик может провести грань между «демонстрационным заданием» и «проектом с 10 годами поддержки в будущем».

Не нужно забывать о том, что код тестового задания будет читать человек, у которого, возможно, не так много времени на его доскональное изучение. Краткость — сестра таланта!

Нет единого стиля

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

Создание «велосипедов»

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

Зачастую такое желание связано с незнанием (или плохим знанием) стандартной библиотеки использующегося языка или тех библиотек и фреймворков, которые применяются в решении. Наиболее популярные велосипеды — isdigit, to_string, directory_iterator и т.д. Не нужно забывать, что многие компании были бы не против использования сторонних библиотек и решений в проекте: чтобы не проделывать работу, которую уже давно сделали другие разработчики, стоит не стесняться уточнить этот момент как можно раньше.

«Плохие» наименования сущностей и некорректная декомпозиция классов и функций

Пояснять здесь что-то излишне — печально, когда путь до директории называется s, а число, прочитанное из файла, хранится в переменной под названием mynumber.

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

Неверная организация логирования

Частично этот пункт связан с предыдущим, то есть с неспособностью продумать грамотную декомпозицию функций. Печально видеть, когда get_file_content(const std::string& file_name) самостоятельно пишет в лог в случае ошибок при открытии файла или считывании из него данных. Гораздо лучше пробрасывать информацию о произошедшей ошибке уровнем выше, где она и будет обрабатываться должным образом.

Многим кандидатам будет полезно узнать, что функция std::ifstream::read сама пишет в лог.

Применение слишком низкоуровневых инструментов

Как это ни странно, но многие разработчики так и норовят использовать в своих решениях такие low-level API, как WinAPI или POSIX API, даже тогда, когда аналогичные средства доступны и в стандартной библиотеке соответствующего языка. Некоторые делают это ради того, чтобы показать, что работа с низкоуровневыми интерфейсами не является для них существенной проблемой, кто-то стремится к «увеличению производительности», и лишь немногие делают это из-за того, что они по-настоящему хорошо знакомы с данным API.

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

Преждевременная оптимизация

Частично этот пункт уже был затронут выше, но здесь речь идёт не столько об использовании WinAPI / POSIX, сколько об усложнении общей архитектуры приложения ради получения решения, которое работает лишь немного быстрее.

Чем проще читается решение, тем меньше времени потратит на него представитель нанимающей компании, а это повышает шансы кандидата перейти на следующий этап отбора. Важно помнить — разработчики чаще читают код, чем его пишут, так что всегда следует задумываться о тех людях, которые будут поддерживать создаваемое решение. Будет ли им удобно разбираться в проделанных кандидатам оптимизациях? Увеличат ли они время, затрачиваемое на внесение изменений в код, и стоят ли они того?

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

Создание неуниверсальных решений

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

Что самое интересное, зачастую на написание универсального решения будет затрачено немногим больше времени, чем на написание частной версии. Так зачем мучать себя и других?

Использование магических чисел

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

Иногда это 256 для буфера, содержащего путь до файла, 8 в качестве размера thread pool и 512 в качестве размера для содержимого файла.

Следует помнить, что в большинстве API есть соответствующие инструменты для подобных сущностей — в WinAPI есть MAX_PATH, в стандартной библиотеке C++ и boost есть hardware_concurrency, а размер буфера, хранящего содержимое файла, можно и не задавать вовсе — вместо него достаточно просто использовать std::string.

Отсутствие RAII

Если речь идёт о языках, по своей природе располагающих к автоматическому освобождению ресурсов, этим надо пользоваться в 99% случаев. Вместо new и delete — умные указатели, вместо fopen и fclose — std::fstream… В общем, идея понятна.

Автор: Никита Трофимов, разработчик ПО

Мастер Йода рекомендует:  Stack Overflow выпустила новую версию зарплатного калькулятора
Добавить комментарий