Блог веб-разработчика v 1.0.0
Symfony2, AngularJS, React, Gulp, PhpStorm и много других страшных слов

7 признаков того, что не стоит нанимать веб-разработчика

9 лет назад
9050 просмотров
CSS HTML JavaScript Полезности

1. Он все знает и никогда не гуглит

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

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

2. Он не форматирует код

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

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

3. Он знает HTML5 и CSS3

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

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

Не ведитесь на маркетинговые HTML5 и CSS3. Сможет ли он сделать так: http://pattle.github.io/simpsons-in-css/ Если ответ будет "да", можете начинать сильно удивляться и просить показать, и, если он и правда понимает, как подобное работает, вам очень повезло.

4. Он верстает "топорно"

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

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

5. Он уверен, что pureJS знать важнее <библиотеки>

Почему же не стоит нанимать разработчика, который отвергает JS библиотеки? Давайте вспомним "старые отмазки" от библиотек: Вес и Скорость.

Времена, когда мы экономили байты в погоне за скоростью загрузки страниц давно прошли. Лишние 15, 30, даже 500 Кб большинство пользователей не заметит. Само-собой не стоит встраивать в страницу лишний и ненужный код, но не стоит так же бояться добавить библиотеку для "вон той единственной фичи". От этого никому плохо не станет, а поддержка в будущем облегчится за счет использования библиотеки. Разработчикам: без фанатизма, мегабайты кода ради полифила в пару строк встраивать не стоит.

Скорость. Вы правда думаете, что нашли разработчика который сможет написать манипуляцию с DOM на уровне скорости jQuery? Вряд ли. Разработчик считает что Angular работает слишком медленно медленно? Скорее всего он использует его не там и так. Популярные библиотеки уже хорошо оптимизированы под свои конкретные задачи и веб-разработчик должен понимать это, а не "писать все на pureJS с нуля потому что это круто и быстро работает".

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

6. Он наполовину дизайнер

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

Безусловно, есть исключения из этого правила, но редко.

7. Он точно знает за сколько <это> сделает

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

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

Что еще почитать
Создание CSS спрайтов с помощью Gulp
8 лет назад
13710 просмотров
Урок по созданию CSS спрайтов с помощью таск-менеджера Gulp. В отличие от других инструментов: средонезависимо, быстро, удобно, переносимо, настраиваемо.