Содержание
- 01. Кодирование больше не мешает
- Ширина и глубина
- 02. Большое предостережение
- 03. Что говорят в Интернете
- Понять среду
- 04. Вещи, из которых мы строим
- 05. Девопс
- Понять стек
- Загадочная работа
- Удобные инструменты
- 06. Дев исправит ... возможно
- Отладка
- 07. Чего хотят пользователи
- Конкурентный рынок
- 08. Рисование и письмо
- 09. Развлекайтесь
- 10. Будьте внимательны
- Понравилось это? Прочтите это!
Разработчики должны быть больше, чем просто ворчунья, генерирующие код. Мы ожидаем большего от нашей цифровой жизни, и именно эти ребята ее строят, так что же нужно знать лучшим разработчикам? Вот чего, по моему мнению, не хватает слишком многим разработчикам. Это не исчерпывающий список, но именно эти качества превращают разумного кодера в отличного разработчика.
Но это не одно, и особенно не способность анализировать XML или оптимизировать код. Это удивительный набор навыков, которым не учат в книгах по написанию кода. Они немного лишнее.
Зачем так выходить? Потому что разработка имеет значение, но разработчики слишком часто попадают в другой мир, не всегда созданный ими. Это никогда не работает. Разработка - что-либо техническое - всегда процветает, когда знающие хау понимают больше, чем просто код.
01. Кодирование больше не мешает
Мы живем в мире, где программирование становится менее впечатляющим. Все создают сайты, некоторые из них кодируют, но вам необязательно. Создавать сайты, приложения и функции могут уже не только ботаники.
С тех пор, как появился Интернет, и люди могли учиться сами, появились разработчики-самоучки. Но даже выпускникам грозит опасность. Я получаю резюме с людьми с дипломами в области информатики, курсами искусственного интеллекта, различными средствами массовой информации и кодированием за плечами, но чего-то еще не хватает. Иногда многого не хватает.
Я не первый, кто это сказал. "Кодирование больше не мешает" - это название главы 3 из Страстный программист, который наряду с такими книгами, как Прагматическое мышление и обучение побуждать программистов совершенствоваться за пределами кода; стать ответственными и полностью человечными членами команды.
Ширина и глубина
Разработчики должны быть лучше в двух направлениях: широте и глубине. Им необходимо понимать масштабы человеческого взаимодействия в своей команде и с тем, что они создают. Им необходимо понимать всю глубину системы, с которой они работают, вплоть до операционной системы.
И это должны читать не только разработчики. Если вы работаете с разработчиками, думаю, вам стоит ожидать от них большего. Заставьте их набросать, о чем они говорят. Попросите их объяснить с помощью изображений, объектов и (это работает) вырезок людей, какой именно будет система для людей, использующих ее.
02. Большое предостережение
Я собираюсь отрицательно говорить о разработчиках, но думаю, что мне позволено, потому что я один из них. Еще потому, что по крайней мере одна вещь, о которой я здесь говорю, относится ко многим разработчикам, которых я встречаю. Хотя их работа великолепна и они знают свой код, времена конкурентоспособны. У вас должно быть преимущество, а это:
- будь более техничным
а также
- быть много более человечный
03. Что говорят в Интернете
Поиск в Google "основных навыков веб-разработки" принесет вам то, чего вы ожидаете. Знание фреймворка, x-browser, CSS и JS. В них перечислены фреймворки, которые вам следует знать, платформы, для которых вы должны писать, и новые тенденции, за которыми следует следить.
Это наши СМИ. Это то, из чего мы строим, но не они обеспечивают успех проекта. Разработчик может понять каждую деталь системы, рассказать вам обо всех особенностях API и новой технологии CSS, но при этом создать что-то непригодное для использования.
Понять среду
Разработчики, как и все, должны понимать свою среду, но они также должны понимать аудиторию, будь то пользователи, команда или другие разработчики. Им необходимо понимать, как их носитель вписывается в мир (другими словами, производственная среда) и какой эффект он имеет (как люди его используют).
Я видел, что это описывается как «широкий и глубокий» человек. Широкий, потому что вам нужно понимать мир как человек, работающий с другими людьми. Глубоко, потому что вам нужны глубокие технические знания ниже уровня вашей части проекта. Эти разработчики придадут вашему проекту огромный импульс и изменят его темп, без чего нетехнический персонал увязнет в утомительных деталях, которые перетекают из технической команды.
04. Вещи, из которых мы строим
Недавно я составил список всего, что мы используем для создания сайтов, управления хостингом и выполнения работы, чтобы люди, присоединяющиеся к нам, могли получить шпаргалку по технологиям, которые они могли бы изучить в первые несколько недель. Мы считали, что люди знают эти вещи, поэтому, чтобы дать новичкам толчок, мы перечислили все, что мы используем каждый день.
Я ожидал увидеть полдюжины технологий, но в итоге получил гораздо больше. Этот список - «что мы используем» - включает в себя обычные CMS, языки программирования и браузерные технологии, а также набор инструментов, которые команда даже не помнила. Все дело в мышечной памяти. Набрав 'git', 'phing', 'thor' в командной строке, мы даже не думали, что кто-то может этого не делать.
Инструменты сборки; CI; git для контроля версий считались само собой разумеющимся, но, оглядываясь назад, они почти не появлялись. Появились модные (и это цинично, что некоторые агентства добавляют их ?!), но часто без конкретного опыта.
Эти инструменты важны для ускорения разработки проекта, поэтому убедитесь, что у вас гораздо более богатый набор инструментов, чем ваш язык, CMS и пара фреймворков. Вам нужны развертывание, тестирование, CI, строгий контроль версий (в командах, а не самостоятельно), и вам нужно понимать их основные концепции, а не просто несколько руководств.
05. Девопс
Эти дополнительные инструменты и уловки прекрасно вписываются в то, что люди называют девопами. Devops идет вразрез с двумя традиционными принципами: производство, которое поддерживает работу, и разработка, которая создает новые вещи (и часто останавливает работу). Разобщенность приводит к тому, что два лагеря мало симпатизируют друг другу.
Разработчики, не обладающие производственными знаниями, чаще создают код, непригодный для производственной среды, используя конфигурацию или функции, которых еще нет в производственном стеке. Поскольку они не осведомлены о проблемах производственной среды, они пишут код для завершения функции, а не развертывают ее в производственной среде.
Эти мелкие детали могут вызвать болезненные задержки, усугубляемые тенденцией отправки управления сервером за границу.
Понять стек
Devops сама по себе огромная область, охватывающая непрерывное развертывание и много автоматизации. Это обширное резюме, но главное, что должны понимать разработчики, - это стек, на котором они работают. Недостаточно делегировать это администратору сервера, вы должны понимать, как платформа влияет на ваш код.
Если вы работаете с Rails, прочтите код Rails и узнайте, как Ruby выполняется Apache. Если вы работаете на Java, знайте о параметрах конфигурации. Если вы используете Perl, узнайте, как устанавливать модули Perl и настраивать их.
Загадочная работа
В списке «что мы используем» содержится много всего этого, и хорошие разработчики вскакивают на него, чтобы понять, как выполняется вся эта загадочная работа. И как только они его получат, развертывание станет быстрее, работа станет более гладкой, и все будут счастливы.
Непрерывное развертывание и связанные с ним практики DevOps становятся настолько стандартом, что любой разработчик или компания, не практикующие это, настраиваются на то, чтобы их обойти. Кто-то другой начнет это делать, и тогда они будут быстрее вас.
Удобные инструменты
Поиск в Google по запросу 'DevOps' даст вам представление об инструментах, которые используют эти парни. Речь не идет о PHP и MySQL или Rails. Речь идет о доставке программного обеспечения и сохранении рискованных частей проектов. Они сосредоточены на развертывании, автоматизации и обеспечении максимально быстрой работы конвейера от разработчика до производственной среды.
Вы обнаружите, что этот стиль разработки дает вам разработчиков, которые лучше работают друг с другом, а также с другими отделами и компаниями. Если они работают с API от третьей стороны, они поймут проблемы, которые могут возникнуть на другой стороне. Работая с администраторами серверов, они поймут, что им нужно установить, и узнают, как их программное обеспечение размещается на рабочих серверах. Обратное может быть болезненным ...
06. Дев исправит ... возможно
Этот поисковый запрос «необходимые навыки веб-разработчика» дает хороший ответ Майкла Грира (технический директор The Onion) на Quora:
- Лень: дважды отказывается что-либо делать: пишет для этого сценарий или алгоритм.
- Трусость: думает о тестировании, беспокоится о нагрузке и влиянии кода.
- Безрассудство: постоянно пробует что-то новое, запускает идеи того же дня
Трусость - хороший способ выразить «внимание к деталям». Отладка и тестирование - это 99 процентов жизни разработчика, о котором никто не упоминал, когда они попадали в W3Schools или начинали курс по вычислениям.
Способность исправлять приложения требует отличных навыков решения проблем, а не только отладки кода. Иногда решение для пользователей, которые не могут загрузить свои счета, состоит в том, чтобы сделать страницу доступной для печати, а не тратить день на создание PDF-файлов. Иногда ссылка может заменить неделю разработки, но этого элегантного решения не будет, если разработчики решают проблемы просто путем написания большого количества строк кода.
Несмотря на наличие множества инструментов, тестирование - прекрасное слепое пятно для многих разработчиков. Используйте модульные тесты, селен, инструменты нагрузочного тестирования и профилирования, такие как xhprof. Анализ таких вещей, как New Relic, чтобы уменьшить занимаемое вашим приложением место. И рассмотрите все это как часть работы разработчика: это ваш код, убедитесь, что вы знаете, что он работает так, как задумано, а не надеетесь, что это так.
Отладка
Отладка - тоже больной вопрос. Не как использовать отладчик, а как отладить проблему - поэтому я бы добавил в список Майкла Грира:
- Нетерпение: агрессивно игнорирует несущественную информацию, чтобы найти и решить настоящую проблему.
Это краеугольный камень всех методов отладки. Игнорирование несущественного и нахождение смысла в релевантном. К сожалению, многие склонны часами или днями рабски отбивать несущественное, решая проблему, пробуя одно и то же 10 раз.
Есть много книг (к сожалению, не та, которую я предложил издателю, которого я не назову) по отладке, и каждый разработчик должен прочитать их все. Действительно отличный разработчик может отлаживать проблемы в системе, не видя ни строчки кода.
07. Чего хотят пользователи
Поймите, что люди вокруг вас пытаются делать. Наслаждайтесь кодом - любите искусство создания идеальных отступов для файлов CSS или оптимизации приложения rails - но помните, что все это сделано для определенной цели.
Разработчики должны понимать бизнес, операции и бизнес-процессы, потому что их сотрудники помогают им управлять. Обладая этими знаниями, разработчики могут создавать программное обеспечение и приложения, которые помогают пользователям, но часто кажутся необычно продуктивными. Это может быть из-за того, что они быстро набирают текст или прекрасно разбираются в стеке, но, скорее всего, из-за того, что они знают, чего хотят пользователи.
Конкурентный рынок
Возвращаясь к моей исходной точке зрения, разработка становится проще, а рынок хороших разработчиков становится более конкурентоспособным. Любой разработчик, который сможет понять бизнес-требования и предложить что-то отличное для их удовлетворения, будет иметь преимущество. Понимание рынка, клиентов и того, почему люди расстаются с деньгами, - все это помогает.
Узнайте, какие данные будут меняться со временем. По мнению разработчиков, они должны согласовывать новые технологии с задачами, которые у вас есть сегодня или которые вы ожидаете в будущем. Таким образом, когда вы предлагаете директору или клиенту новую причудливую идею, она будет основана на том, чего на самом деле хотят клиенты, и вы получите на нее бюджет / время. (Напротив, хуже всего будет свидетелем того, как разработчики торгуют своей новой любимой технологией как решением всех наших проблем.)
У разработчиков есть полный контроль - нужно ли им знать, что каждое поле в базе данных означает для конечного пользователя? Если мы изменим данные, что увидят пользователи? Есть ли лучший способ помочь пользователям? Слишком часто администраторы БД считают, что мир - это плохое отражение их базы данных, а не их база данных, которая является плохим представлением реального мира. В мире беспорядок и удивительно много крайностей. Боритесь с этим, админы БД.
08. Рисование и письмо
Рисование - это самый прямой способ сообщить, на что будет похоже. Разработчики должны уметь рисовать свои идеи на доске, бумаге и пивных циновках.
Разработчики должны иметь возможность создавать прототипы на бумаге, печатать скриншоты и делать на них каракули, просто чтобы сообщить о своих намерениях. Не верьте разработчику, который кивает, говорит, что понял и открывает свой редактор.
Недорого: лучшее кодирование начинается с рисования как быстрого прототипа. Чаще терпите неудачи и убедитесь, что все разработчики вокруг вас делают то же самое, так как у вас больше шансов на успех.
09. Развлекайтесь
А что, если вам нужно потратить 10 часов на решение проблемы, перемещая ссылку? Наслаждайтесь этим, даже если это просто задача выполнить работу.
Самое худшее отношение разработчиков (или кого-либо еще) - это апатия к тому, чего пытается достичь команда. К сожалению, это обычное дело, потому что разработчики видят себя вне того, чего добивается команда. (Страстный программист ставит вопрос: «Насколько увлекательнее вы могли бы сделать свою работу?» - попробуйте.)
И будьте готовы показать свою работу, как это происходит в обратном порядке: не расширяйтесь, попробовав пару руководств по Ruby до 'Experience of Ruby'!
Разработка веб-приложений и приложений - все еще молодая профессия, но набор навыков, необходимых действительно великим разработчикам, расширяется. Всем следует ожидать большего от разработчиков, потому что чем раньше мы выйдем из неприятной задней комнаты и включимся в творческий процесс, тем лучше будут результаты.
10. Будьте внимательны
Чтобы довести это число до 10-го раунда, я добавлю еще одну вещь. Оставайся проницательным. Найдите конкуренцию. Худшее из всего - изолированное.
«Всегда будь худшим парнем в каждой группе, в которой ты играешь».
Худшее - на самом деле, очень плохое - программисты, программисты, дизайнеры учатся своему делу и почивают на лаврах. Без кардиостимулятора слишком легко замедлиться, и, не видя конкуренции, становится привычкой видеть себя выше среднего.
Итак, будь наихудшим, найдя лучшее. Присоединяйтесь к проектам вне работы, вносите свой вклад и ищите отзывы и критику, потому что чем больше критики вы получите, тем меньше людей будут давать вам в будущем. Когда вы угадываете, чего они хотят, лучше, чем они, тогда вы - разработчик ниндзя, которого все хотят.
Дэн Фрост - технический директор веб-компании 3EV, предоставляющей полный спектр услуг, - официального партнера AWS. Он занимается разработкой CMS и веб-приложений уже семь лет.
Понравилось это? Прочтите это!
- Как создать приложение
- Лучшие бесплатные веб-шрифты для дизайнеров
- Узнайте, что будет дальше с дополненной реальностью
