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


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

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 или из описания в Я.Каталоге.

12 распространенных ошибок веб-разработчиков. Часть II

7. Ненужные свойства

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

Я объединяю их, а селекторы отделяю друг от друга запятой (,):

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

8. Не используют альтернативные шрифты

В идеальном мире каждый компьютер имел бы любой шрифт, какой вам захочется. К сожалению, мы живем в несовершенном мире. Не учитывая @font-face, веб-разработчики ограничены несколькими так называемыми безопасными шрифтами (Arial, Georgia, serif и. т. д.).

Однако шрифты наподобие Helvetica, которые есть не на каждом компьютере, тем не менее, использовать можно. Решением служит стек шрифтов (font stack).

Стек шрифтов предоставляет разработчикам альтернативные шрифты.

Можно добавить альтернативные шрифты:

Теперь, если у пользователя Helvetica не установлен, он будет видеть сайт со шрифтом Arial, а если и это не сработает, то шрифт переключится на любой установленный шрифт из серии san-serif.

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

9. Лишний пробел

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

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

10. Не систематизируют CSS в логическом

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

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

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

11. Используют одну таблицу стилей

Мнение субъективно. Поэтому проявите терпение и выслушайте мои доводы.

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

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

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

12. Не включают таблицу стилей для печати

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

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

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

Собеседование: 8 самых распространенных ошибок программистов

Изучим ошибки и поймем, как их избежать

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

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

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

Мы изучили более 20 000 интервью, которые проводились на нашей платформе для собеседований с программистами Pramp. Рассмотрели взаимные отзывы, сгруппировали их по тематике и выявили статистически значимые тенденции.

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

В конце вы найдете описание методологии, примененной нами для написания статьи.

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

Давайте сначала бросим взгляд на проблему с высоты птичьего полета:

Общее количество всех столбцов составляет более 100%, поскольку некоторые отзывы описывают более одной ошибки.

#1: Написание кода до записи наброска решения

Частота ошибки на собеседовании: 20.66%.

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

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

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

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

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

#2: Слабые знания основ Computer Science

Частота ошибки на собеседовании: 20.05%.

Понравится вам это или нет, но большинство ключевых тем собеседований с программистами сегодня по-прежнему вращаются вокруг проблем, связанных с структурами данных и алгоритмами (DS&A). Это справедливо как для стартапов так и крупных компаний, таких как Dropbox, Airbnb, Uber & Palantir и, конечно же, для таких гигантов, как Google, Facebook, Amazon & Apple.

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

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

Примечание переводчика: в англоязычной литературе DS&A — аббревиатура для фразы Data Structures & Algorithms – структуры данных и алгоритмы.

Помимо Pramp.com, вот список ресурсов, которые мы рекомендуем:

  1. Отличный курс от Courcera, предоставляющий всю важную информацию об алгоритмах и структурах данных, необходимую каждому серьезному программисту: Алгоритмы, часть 1, Алгоритмы, часть 2.
  2. «Cracking Coding Interviews» Гейла Лаакманн Макдауэлла — хорошая книга, в которой есть примеры задач, решения и рассказы о том, как разные компании подходят к найму.
  3. Два хороших бесплатных учебных курса, посвященных тому, чтобы помочь вам добиться успеха в техническом собеседовании:
  • Подготовительный курс по техническому собеседованию от Udacity & Pramp
  • Подготовка к собеседованию по программной инженерии от Coursera

#3: Успокойтесь

Частота ошибки на собеседовании: 15.80%.

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

Совет. Самое распространенное когнитивное искажение – думать, что ваши мысли очевидны и понятны для других. Выполняя задачу, объясняйте каждый шаг рассуждений. Говорить и писать код одновременно для многих из нас не является естественным. К счастью, есть отличная платформа, которая поможет вам практиковаться :). Если волнение мешает правильно высказывать мысли, можете попробовать эти методы, чтобы овладеть собой.

#4: Слабое знание языка программирования

Частота ошибки на собеседовании: 12.56%.

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

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

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

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

Разработка собственного проекта – единственный способ на практике освоить язык программирования. Нет идей? Вбейте простой поисковый запрос в Google.

#5: Отсутствие тестирования

Частота ошибки на собеседовании: 10.33%.

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

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

Совет. Рекомендуется трижды использовать тесты во время собеседования. В первый раз – сразу после того, как ваш интервьюер закончил задавать вам вопросы по вашему коду. Используйте один-два примера, чтобы проверить, что вы поняли вопрос (подробнее см. # 6 ниже). Второй раз после того, как вы набросали свое решение. Используйте нетривиальный тестовый пример, чтобы вместе с интервьюеров пройтись по вашему псевдокоду и проверить его правильность. Наконец, как только вы закончите программировать свое решение, проверьте еще раз, что в вашем коде нет ошибок.

#6: Неправильное понимание вопроса

Частота ошибки на собеседовании: 9.11%.

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

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

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

#7: Игнорирование граничных случаев

Частота ошибки на собеседовании: 8.31%.

Не учет граничных случаев, может являться признаком неразвитых навыков решения задач программирования. Во-первых, если ваш алгоритм не обрабатывает все корректные данные — решение является неполным. Во-вторых, не учитывая граничные случаи, вы упускаете возможность придумать более удачный алгоритм решения. Например, в задаче «Поиск недостающего числа» прямое («силовое», грубое) решение заключается в том, чтобы вычесть сумму входного массива из общей суммы (1, …, n). Однако при достаточно большом «n» решение будет неверным из-за переполнения целочисленного значения. Осознание этого граничного случая заставит вас подумать о более подходящем решении. И действительно, используя побитовый оператор XOR, мы можем разработать решение, которое больше не подвержено переполнению (более подробно см. второе решение в ссылке выше).

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

#8: Сырой код

Частота ошибки на собеседовании: 7.69%.

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

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

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

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

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

Выводы

Если вы дочитали статью до этого места, вы, возможно, заметили, что значительная доля всех ошибок, допущенных кандидатами, имеет мало общего с техническими навыками. Фактически, не технические ошибки (№ 1, № 3, № 6) составляют 44% всех ошибок.

Мастер Йода рекомендует:  Как мы на РИТ++ 2020 ходили обзор фестиваля для тех, кто делает Интернет

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

Именно этим мы занимаемся в Pramp. Мы бесплатно предоставляем комплексную площадку для проведения собеседований. Она уже помогла тысячам программистов избежать ошибок на собеседованиях. Готовы ли вы к собеседованию?

Методология

Чтобы идентифицировать ошибки и рассчитать их частоту, мы рассмотрели данные о последних 20 000 интервью с программистами, проведенных на Pramp.

Сначала о самой платформе. Pramp — бесплатная «точка-точка» площадка для тренировки и самопроверки программистов. Проще говоря, мы проверяем разработчиков программного обеспечения с помощью видеочата и совместно используемой среды программирования, чтобы имитировать проведение собеседований по программированию.

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

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

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

Мы проанализировали ответы в более чем 20 000 интервью на вопрос «Что было не так хорошо».

Первым шагом в нашем анализе было выяснение повторяющийся «категории ошибок» в ответах пользователей на вопрос «Что было не так хорошо?» В форме обратной связи. С этой целью мы выбрали случайные 1 068 интервью из 20 000 интервью. При таком размере выборки результаты статистически значимы (уровень достоверности 95% и допустимая погрешность менее 3%). Затем мы перечислили вручную эти 1 068 ответов.

Мы определили девять категорий. Восемь из них ‑ упомянуты в статье. 9-я категория была «Другая». Эта категория включала отзывы, которые либо не говорили ничего значимого (например: «Вы отлично поработали, мне нечего добавить», «Ничего не могу придумать» и т.д.), или что указывает на проблему, частота которой не была статистически значимой (например,

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

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

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

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

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

1. Пуристы

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

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

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

2. Деятели

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

Деятели живут в стартапах, внедряя все эти инструменты для плавного производства. Характерным признаком типичного деятеля является использование таск-менеджеров, таких как Grunt или Gulp.

3. Полиглоты

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

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

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

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

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

5. Претенциозный

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

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

6. Повторный пользователь

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

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

7. Отладчики

Отладка сама по себе является навыком. Ее истинная сила может быть выявлена ​​только тогда, когда на странице отображается «Внутренняя ошибка сервера 500». Отладчики способны не только отлавливать и устранять ошибки в своем собственном коде, но и в кодах, написанных другими (что само по себе является кошмаром разработчика)!

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

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

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

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

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

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

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

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

Ну, что? Нашли себя или своего знакомого в одной из категорий?

Всем успешной работы и творчеств!

8 наиболее распространенных ошибок разработчиков Backbone.js

Backbone.js — это минималистичный фреймворк, предоставляющий простой набор структур данных и функций, которые вы можете использовать для создания клиентской части веб-приложения. Со схожей структурой моделей и представлений вы уже, вероятно, встречались в бэкенд-разработке. Модели и коллекции в Backbone.js очень простые, но содержат ряд полезных функций, например, возможность легко интегрировать их с REST JSON API. В то же время они являются достаточно гибкими и могут использоваться почти в любой практической ситуации.

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

Ошибка #1: Игнорирование функциональных возможностей Backbone.js

Backbone.js является минималистичным, но он (вместе с Underscore.js) обеспечивает множество функций, которые легко покрывают самые основные потребности, возникающие при разработке современного веб-приложения. Одна распространенная ошибка, которую делают начинающие разработчики, заключается в том, что они воспринимают Backbone.js как еще один клиентский MVC-фреймворк. Хотя это довольно очевидно, но когда дело касается Backbone.js, действительно важно тщательно изучить его основы. Фреймворк очень небольшой по размеру, но именно это делает его отличным кандидатом для детального изучения. Стоит изучить его небольшой и прекрасно документированный исходный код .

Backbone.js предоставляет минимум, необходимый для создания структуры веб-приложения, и в этом есть определенное преимущество. С его расширяемостью и множеством плагинов , Backbone.js можно использовать для создания по-настоящему удивительных веб-приложений. Некоторые из наиболее очевидных особенностей Backbone.js доступны через модели, коллекции и представления. Роутер и Backbone.history обеспечивают простой, но элегантный механизм маршрутизации на стороне клиента. Библиотека Underscore.js является зависимостью Backbone.js, она прекрасно интегрирована в фреймворк. Во-первых, модели и коллекции используют ее возможности, а во-вторых, функции самой библиотеки в вашем распоряжении.

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

Ошибка #2: Модификация DOM в обработчиках событий

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

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

Могут возникать редкие ситуации, когда прямые манипуляции с DOM имеют смысл, но затраты, связанные с поддержанием такого кода, почти никогда не оправдываются. Использовать Backbone.js для чего-то подобного — это ошибка.

Ошибка #3: Недооценка стоимости отрисовки

В Backbone.js настолько легко отрисовать DOM по желанию или в обработчике события, что мы часто не задумываемся, насколько это влияет на общую производительность веб-приложения. Есть много ситуаций, приводящих к слишком частому вызову метода render представления. Часто это может показаться не критичным, так как современные браузеры становятся все более производительными. Но с ростом веб-приложения и объемов данных падение производительности становится все более и более очевидным.

Можно наблюдать такую ситуацию с помощью выдуманного примера, где мы отображаем небольшую коллекцию моделей в виде списка:

В этом примере, мы отрисовываем представление всякий раз, когда модель добавляется в коллекцию. Это будет прекрасно работать. Однако, поскольку событие «add» срабатывает каждый раз, когда модель добавляется в коллекцию, представьте себе получение большого списка моделей с сервера. Метод render будет вызываться несколько раз для каждой модели. Достаточно большая коллекция может повесить приложение. А иногда достаточно и небольшой коллекции при высокой сложности рендеринга представления.

Быстрое решение этой проблемы заключается в том, чтобы просто не вызвать метод render для каждой модели, которая добавляется в коллекцию. В таких ситуациях, модели будут добавляться в коллекцию партиями, и можно сделать так, чтобы метод render не вызывался повторно в течение определенного количества времени. В Underscore.js есть для этого удобная функция «_.debounce». Все, что вам нужно, это изменить обработчик события:

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

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

Ошибка #4: Неиспользуемые обработчики событий

Неиспользуемые обработчики событий могут возникнуть независимо от того, какой JavaScript-фреймворк вы используете. Несмотря на то, что Backbone.js позволяет легко избежать этой проблемы, подобная ошибка по-прежнему оставляет потенциальную возможность утечки памяти в приложении. Компонент Event в Backbone.js позволяет объектам JavaScript легко реализовать функционал, основанный на событиях. В представлениях, где большая часть функционала основана на событиях, легко сделать такую ошибку:

Навешивание события в этом фрагменте кода не очень отличается от первого примера. Мы всего лишь изменили «this.listenTo(this.model, . )» на «this.model.on(. )». Поскольку метод «.on()» используется в других библиотеках JavaScript, он является более более привычным и часто используется начинающими разработчиками. И это хорошо, если потрудиться вызвать метод «.off()» для удаления обработчика, когда он уже не нужен. Но это делается редко, что и является источником утечки памяти.

Backbone.js предлагает простой способ решить эту проблему за счет использования метода «object.listenTo()». Он позволяет объекту, для которого вызван «listenTo()» самому отслеживать события, на которые он подписан, а также легко удалить обработчик. Представления, например, автоматически перестают отслеживать все события после вызова метода «remove()».

Ошибка #5: Создание монолитных представлений

Минимализм Backbone.js обеспечивает огромную гибкость в плане архитектуры веб-приложения. Модели, коллекции и представления являются строительными блоками веб-приложения. Важно держать их легковесными и специфичными, насколько это возможно. Но представления часто становятся тяжелыми с точки зрения кода. На самом деле, лучше не делать огромные монолитные представления, которые выполняют все функции приложения. Одно огромное представление «AudioPlayer» со всей логикой можно логически разделить на несколько представлений, например представление для плейлиста, представление для элементов управления, представление для визуализатора и т.д. Состав таких представлений зависит от конкретного приложения.

При правильном разделении, когда каждое представление делает что-то конкретное и делает это правильно, разработка веб-приложений с Backbone.js становится приятнее. Такой код легче поддерживать, его легче расширять или изменять в будущем. Есть и другая крайность, поэтому в конечном итоге важно не переусердствовать. Представления Backbone.js предназначены для того, чтобы сделать удобной работу с моделями или коллекциями. Это может стать подсказкой, как правильно структурировать приложение. Ян Шторм Тейлор поделился ценными идеями в блоге, которые можно иметь в виду при реализации представлений.

Ошибка #6: Непонимание того, что Backbone.js может быть адаптирован к не-RESTful API

Backbone.js работает с JSON на основе RESTful API из коробки. Все, что вам нужно — это jQuery (или его замена, например, Zepto). Тем не менее, Backbone.js чрезвычайно расширяем. На самом деле, он может быть адаптирован для использования в других типах интерфейсов или с другими типами форматов кодирования.

Компонент Backbone.Sync отвечает за взаимодействие фронтенда и бэкенда. Он предоставляет набор атрибутов, которые вы можете легко переопределить, чтобы настроить способ взаимодействия Backbone.js с API. Механизм синхронизации по умолчанию легко изменить, например, сохранять данные в localStorage вместо бэкенд-сервиса.

Существует множество плагинов , позволяющих кастомизировать механизм синхронизации Backbone.js. Например, плагин Backbone.dualStorage позволяет использовать одновременно и бэкенд-сервис, и localStorage для сохранения данных. Когда приложение переходит в автономный режим, плагин использует localStorage для сохранения и получения данных, а также отслеживает изменения, которые синхронизируются с сервером позже, когда появится доступ в интернет.

Хотя использовать Backbone.js с RESTful-бэкендом просто, это не значит, что только с ним и может работать Backbone.js. С некоторыми изменениями в механизме синхронизации, вы можете адаптировать его к широкому спектру API и форматов кодирования.

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

Ошибка #7: Сохранение данных в представлении вместо модели

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

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

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

Ошибка #8: Использование jQuery .on() вместо делегирования событий

Backbone.js имеет, на мой вгляд, один великолепный способ обработки событий DOM. Неиспользование его добавляет кучу проблем. Функция добавления обработчика события jQuery .on() удобна, но часто доставляет много хлопот в долгосрочной перспективе. Например, когда элементы удаляются из DOM, jQuery автоматически удаляет все обработчики событий, связанные с использованием .on(). Это означает, что любой обработчик события DOM, который вы привяжете в представлении, необходимо будет привязать заново, если вы удалите корневой элемент из DOM’a, а потом вернете его обратно.

В примере выше, чтобы заново привязать обработчики событий, нужно будет всего лишь вызвать метод delegateEvents() представления. Очень важно понимать, как эти события связаны. Вместо того, чтобы связывать события с элементами, указанными в селекторе, Backbone.js на самом деле связывает обработчик события с корневым элементом представления. Это отлично подходит для решения большинства задач. Изменение или замена дочерних элементов DOM не требует повторного связывания событий для новых элементов. Существующие обработчики продолжать работать.

В то же время, это мешает отслеживать некоторые события. Например, событие «scroll» объекта window или дочернего элемента. В случае дочернего элемента, вы можете создать вложенное представление, где этот элемент будет корневым и навесить обработчик в нем.

Заключение

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

Мастер Йода рекомендует:  Естественные ключи против искусственных ключей

Нашли опечатку? Orphus: Ctrl+Enter

© getinstance.info Все права защищены. 2014–2020

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

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

This sponsored post features a product relevant to our readers while meeting our editorial guidelines for being objective and educational.

Может показаться, что существует несметное количество способов, как добиться выполнения определённой задачи — создать веб-сайт, который будет хорошо работать в современном интернете. Веб-разработчики должны определиться какой хостинг и какое место для хранения данных использовать, какие инструменты использовать при написании HTML, CSS и JavaScript, как будет реализован дизайн и к помощи каких JavaScript библиотек/фреймворков стоит прибегать.

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

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

Список ниже не подразумевает определённого порядка:

1. Написание устаревшего HTML

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

для создания лейаута, или

Последствия: написание HTML из прошлого десятилетия влечёт за собой создание сложной, непонятной разметки, которая будет вести себя по разному в зависимости от браузера. И это не будет работать в последних версиях современных браузеров, к примеру Microsoft Edge и даже в предыдущих версиях Internet Explorer (11, 10, 9).

Как избежать этого: перестаньте пользоваться элементами

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

2. «Всё прекрасно работает в моём браузере. «

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

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

Как избежать этого: конечно это не совсем практично тестировать веб-сайт в каждом браузере и каждой версии во время разработки. Однако вам следует иметь определённый интервал, по прошествии которого стоит проверить как сайт выглядит в разных браузерах, это будет правильный подход. На сегодняшний день, существуют бесплатные инструменты призванные вам помочь в этом, вне зависимости от платформы на которой вы работаете: бесплатные виртуальные машины или site scanners. Такие сайты как Browserhots или BrowserStack показывают снимки, как страница отображается в разнообразных браузерах/версия/платформах. Visual Studio также может продемонстрировать страницу над которой вы работаете в разных браузерах. При написании CSS, советую «сбросить» все стили по умолчанию, meyerweb.com.

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

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

3. Некачественные формы

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

Последствия: большинство вещей могут (и скорее всего так оно и есть) пойти не так как задумывалось, когда вы ожидаете получать данные от пользователя. Страницы с данными в какой-то момент могут не отвечать или данные не соответствуют, задуманной схеме данных. Гораздо серьёзнее намеренное вторжение в базу данных сайта, возможно с помощью внедрения вредоносного SQL-кода (OWASP: Топ 10 2013-A1-SQL внедрений).

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

4. Сервер отдаёт перегруженные страницы

Ошибка: Страница переполнена различной графикой и/или изображениями высокого качества, при этом их фактический размер уменьшен, посредством атрибутов height и w > . Файлы CSS и JavaScript связанные с этой страницей очень большие. Исходники HTML разметки могут также быть чрезвычайно переполненными и сложными в своём содержании.

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

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

  1. Задайте себе вопрос: «Неужели все графические элементы, так необходимы?» Если нет, уберите ненужные изображения. Вы можете проверить сайт здесь, чтобы определиться какие изображения стоит сжать.
  2. С помощью инструментов Shrink O’Matic или RIOT можно уменьшить размер изображения.
  3. Настройте предзагрузку изображений. Это не увеличит начальную скорость загрузки, но позволит другим страницам на сайте использовать уже загруженные до этого изображения, гораздо быстрее. Чтобы понять как это работает ознакомьтесь с данной статьёй.

Другой способ улучшить скорость загрузки — минифицировать CSS и JavaScript файлы. В этом вам может помочь широкий выбор различных инструментов, к примеру Minify CSS и Minfy JS.

До того как мы перейдём к следующей теме, напомню, чтобы вы старались писать современную HTML разметку (смотрите ошибку 1) и хорошо подумайте прежде чем использовать инлайн или

Какие типичные ошибки в программировании совершают новички — отвечают эксперты

Нам в редакцию Tproger пришел вопрос от подписчика, которым мы хотим поделиться с вами:

«Какие типичные ошибки в программировании совершают новички?»

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

Ильназ Гильязов , эксперт курса «Профессия веб-разработчик» университета digital-профессий Нетология

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

Сегодня существует большое количество источников информации различной степени качества: начиная от классики Computer Science, написанной 10-15 лет назад, до современных школ обучения, где преподают практики. Я бы рекомендовал с особой осторожностью относиться к современным инфо-бизнесменам, за неделю обещающих из вас сделать программиста.

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

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

Ключевые критерии: наличие практики по изучаемому материалу и приближенность практики к реальной жизни.

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

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

Андрей Коваленко , со-основатель и CTO Voximplant

Главная ошибка новичка заключается в том, что он спешит. Вместо того, чтобы изучать язык, платформу или фреймворк, он вводит вопрос в Google/Stack Overflow и просто копирует результат. Это плохо не только потому что без системных знаний невозможно понять новые технологии «изнутри», но и просто потому что в скопированных ответах могут быть ошибки. Если не разобраться досконально, вместо кода получится «лоскутное одеяло» из кусков Stack Overflow, в котором сам автор разбирается крайне поверхностно. Как следствие, развивать это решение дальше будет крайне сложно.

Михаил Субботин , преподаватель израильской высшей школы IT и безопасности HackerU

Я бы задал этот вопрос иначе: «Какие опасности подстерегают новичка в программировании?». По моему мнению, самая главная из них — самоуверенность. Если новичок решил задачу с первого раза, то у него может сложиться впечатление, что все легко и можно расслабиться. Но это не так — наоборот, если задача была решена, надо работать еще больше, чтобы выйти на тот уровень, на котором возникают ошибки, или ты не можешь предложить решение. Иначе тебя обойдут те, кто не был столь уверен в своих знаниях, но много и усердно работал. С другой стороны, решение задачи может быть не самым оптимальным, но без стремления найти другие решения и «поиграть» с ними новичок может запомнить свое первое решение и предлагать его всегда, даже если оно больше не уместно.

Андрей Кузьмичев , заместитель генерального директора RU-CENTER

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

Какие же основные ошибки могут совершать начинающие программисты?
1. Не пытаться искать информацию. Если вы начинающий программист, наверняка кто-то уже сталкивался с вашим вопросом, и решение есть в открытом доступе, мануалах, FAQ и т/ д. Поиск ответа также может показать выбранное решение проблемы с другой стороны. И возможно, это решение только ухудшит ваш проект. Очень полезно использовать опыт других программистов.
2. Не бросать неверное решение. Если Вы поняли, что выбранное решение – не самое лучше, смело отбрасывайте его и начинайте заново. Плохой код и много “костылей” в программе не сделают её удобной для эксплуатации, даже если в итоге она заработает.
3. Ошибка вытекает из пункта два – ухудшать, а не улучшать код. Всегда нужно стараться, пусть и понемногу, улучшать код, но не ухудшать его временными решениями.
4. Не планировать. В этом вопросе важно найти оптимальный вариант, т.к. чересчур подробное планирование может только затруднить подготовку проекта. Нет идеальных планов, но, особенно для крупных проектов, планирование необходимо.

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

Диана Гомонова , руководитель отдела маркетинга в веб-студии Craft Group

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

Сергей Вересов , руководитель проектного офиса «Павелецкая» компании «Первый БИТ»

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

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

3. Использование объектов не по назначению. Связано также с недостатком опыта. Это можно исправить регулярной практикой в команде и постоянным изучением инструментов работы.

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

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

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

Кирилл Меженцев , программист группы разработки карты рассрочки «Совесть»

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

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

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

Перерабатывать. Работая с утра до полуночи, не отдыхая и не высыпаясь, вы берете у себя здоровье и силы в долг. Когда-то придётся его вернуть. Если я не справляюсь с нагрузкой за рабочие

8 часов, значит: а) я не настолько компетентен и переоценил свои способности, б) у меня проблемы с тайм-менеджментом, и я взял больше работы, чем реально выполнить за это время. Оба варианта – повод задуматься и исправить положение. Перерабатывая вы делаете хуже не только себе, но и работодателю. Кому нужен неделями не высыпающийся сотрудник, который от усталости не может перевернуть бинарное дерево? Да, бывают случаи, когда дедлайн горит, все пошло не так и «надо было вчера». Но после таких ситуаций обязательно нужно отдохнуть и провести оценку: что я должен сделать, чтобы не допускать этого в будущем?

Алексей Рузин , ведущий разработчик Kokoc Group

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

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

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

Но лучше написать так:

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

Например, такой код:

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

5. Погоня за модными технологиями.
Как правило, новые технологии имеют превосходство в одних областях за счет проигрыша в других. До тех пор, пока у начинающего программиста нет понимания этих особенностей, лучше использовать проверенные временем универсальные решения. Например, если программист разрабатывает приложение, которое хранит какие-то данные, не стоит спешить использовать самое последнее NoSQL-решение, только потому, что это модно. В большинстве случаев подойдет обычная SQL база-данных (MySQL, PostrgreSQL, SQLite) с большим объемом документации, стандартизированными подходами, описанными и давно решенными проблемами.

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

Александр Донсков , системный архитектор REG.RU

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

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

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

Бывают ошибки с использованием неподходящих инструментов. Многие джуниоры, не успев дописать свой первый hello world, уже бегут осваивать новые технологии и прорывы в мире ПО,при этом не желая изучать фундаментальные вещи, которые являются основой всего современного стека технологий и кардинально не меняются десятилетиями. Как следствие появляется несколько значительных проблем:

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

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

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

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

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

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

Ошибки начинающих верстальщиков

Какие ошибки допускают верстальщики в начале пути и как их избежать, чтобы не портить впечатление о своей компетентности и профессионализме?

17 Сентябрь 2020

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

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

Верстка таблицами

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

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

Не указан тип страницы

Не забудьте указать для браузера, какая версия HTML-разметки использована на странице. Для этого применяется тег DOCTYPE.

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

В HTML5 указание типа страницы выглядит так: .

Недопустимые имена HTML и CSS файлов

Чтобы избежать проблем со страницами, стилями и ссылками внутри проекта нужно помнить несколько простых правил именования файлов:

  • Символы, допустимые в названии – это дефис и нижнее подчеркивание.
  • Использование только латиницы с нижним регистром в начале названия (допустимо так — camelCase).
  • Отсутствие пробелов, вместо них используйте допустимый символ – дефис.

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

Использование тегов не по назначению

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

    Использование тега
    (разрыв строки) для создания списка. Создавайте нумерованные и ненумерованные списки при помощи тегов

      и

        соответственно.

      должен использоваться на странице однократно и только по своему назначению – содержать заголовок страницы. Этот элемент очень важен для SEO-оптимизации сайта.
      Использование тега

      . Это тег-контейнер, и добавить внутрь него текст без других тегов будет семантически неграмотно.

    1. Использование тегов и для манипуляций с текстом. Для этого существуют теги , и другие.

Неприменение семантических тегов

Для того чтобы HTML-документ был структурирован, в HTML5 появились новые теги. Они помогают более грамотно описать содержимое.

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

Неправильное именование классов

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

Обратитесь также к методологии БЭМ (Блок-Элемент-Модификатор). С помощью БЭМ вы создаете древовидную структуру документа, используя при этом общие правила формирования имен. Например, дефис ( — ) разделяет слова в именах, одинарное подчеркивание ( _ ) отделяет имя модификатора от имени блока, а двойное подчеркивание ( __ ) отделяет имя элемента от имени блока.

Использование блочного элемента внутри строчного

Блоки и строки – это два основных типа элементов в HTML.

Блоки помогают выстраивать структуру страницы. К ним относятся

и так далее.

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

Невнимательность к деталям макета

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

Отклонение от Pixel Perfect

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

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

Использование изображений в высоком разрешении

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

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

Не сброшены изначальные настройки CSS в браузере

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

Чтобы сбросить отступы всех элементов страницы используют стилевые свойства CSS – margin и padding.

Также можно подключить специальный настраиваемый CSS файл, который обеспечивает кроссбраузерность HTML-элементов. Пример такого файла – Normalize.css, и найти его вы можете на сайте проекта.

Отсутствие проверки страницы валидатором

Еще не было такой ситуации, когда проверка кода валидатором помешала бы разработчику. Используйте W3C validator для поиска мелких незамеченных ошибок, например, незакрытый тег или пропущенная строка. Для проверки кода этим онлайн-сервисом вам просто нужно указать доменную ссылку на сайт и запустить процесс нажатием кнопки «Check».

Валидный код – это не только код, который соответствует стандартам, но и важная часть SEO-оптимизации сайта.

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

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

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

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

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

1. Пуристы

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

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

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

2. Деятели

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

Деятели живут в стартапах, внедряя все эти инструменты для плавного производства. Характерным признаком типичного деятеля является использование таск-менеджеров, таких как Grunt или Gulp.

3. Полиглоты

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

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

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

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

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

5. Претенциозный

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

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

6. Повторный пользователь

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

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

7. Отладчики

Отладка сама по себе является навыком. Ее истинная сила может быть выявлена ​​только тогда, когда на странице отображается «Внутренняя ошибка сервера 500». Отладчики способны не только отлавливать и устранять ошибки в своем собственном коде, но и в кодах, написанных другими (что само по себе является кошмаром разработчика)!

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

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

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

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

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

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

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

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

Ну, что? Нашли себя или своего знакомого в одной из категорий?

Всем успешной работы и творчеств!

7 самых распространённых ошибок в юзабилити веб-сайта

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

Неброские заголовки

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

Длительная загрузка страниц

Люди – существа нетерпеливые, а интернет-пользователи и подавно. Сотрудники Bing доказали на примере, что скорость загрузки страниц очень сильно влияет на успешность веб-ресурса. Так, 4% посетителей покинут сайт, если загрузка станицы будет всего на 2 секунды дольше, чем у сайтов-конкурентов. Большая часть оставшихся пользователей будет испытывать раздражение, что тоже никак не повысит доверие к ресурсу. При нынешнем выборе товаров и услуг вряд ли кто-то захочет дожидаться загрузки именно вашей страницы, если другие ресурсы откроются моментально. К слову, скорость загрузки является основным критерием в ранжировании сайта поисковой системой Google.

Нечитабельный контент

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

Игнорирование особенностей чтения

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

Проблема навигации

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

Правило трёх кликов – миф

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

Длинный неструктурированный текст

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

10 лет работаем с лидерами рынков и молодыми амбициозными компаниями

— Реализуем любой сервис с нетипичным функционалом;

— Переезды на Битрикс, интеграции со всем на свете;

— Налаженная система менеджмента: четкое соблюдение дедлайнов и ТЗ

Добавить комментарий