Когда программисты видят понятие «full stack», у них, вероятно, возникают две реакции

1. Офигеть, это здорово, мощно!

2. Да что ты вообще знаешь? Full stack — это просто быть посредственным во всём

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

Исходя из моей личной практики,начинающий full stack-разработчикдолжен освоить как минимум следующие навыки:

• Веб-фронтенд-разработка — освоить как минимум один фронтенд-фреймворк;
• Серверная бэкенд-разработка — освоить как минимум один бэкенд-фреймворк;
• Эксплуатация серверов — освоить настройку и обслуживание Linux-серверов;
• Клиентская разработка — освоить как минимум одну из платформ iOS и Android;
• Базы данных — освоить SQL- и noSQL-базы данных.

А получение«full stack»звания должно как минимум требовать в одиночку завершить создание продукта, по-настоящему пройти через коммерческую эксплуатацию, а также попасть впросак из-за собственнойглупостибесчисленное количество раз.

Из этого видно, что планка для full stack довольно высока. Дело не в том, что овладение пятью вышеперечисленными навыками делает вас full stack; как минимум нужно добавить «apprentice», чтобы уточнить. Именно потому, что слишком многие ученики называют себя full stack, другие думают, что «full stack» — синоним «посредственности во всём».

Однако название этой статьи — почему вам стоитпопробоватьfull stack, так что я хочу обсудить не то, стоит ли быть full stack, а именно попытку.

Чужие и свои

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

• Серверные разработчики не понимают клиента, поэтому после проектирования API просто несут чушь;
• Дизайнеры не понимают клиента, поэтому проектируют взаимодействия и при этом несут чушь;
• Разработчики клиентской стороны не понимают сервер, поэтому несут чушь об API;
• Разработчики клиентской стороны не понимают продукт, поэтому несут чушь о требованиях;
• Продакт-менеджеры не понимают требования, поэтому несут чушь команде.

Если не считать того, что продакт-менеджеров в последнем случае следует сжечь на костре, первые четыре конфликта ещё можно спасти.

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

Если серверная сторона не понимает клиента, очень легко спроектировать API, не соответствующий клиентским механизмам. В этом случае, если клиентский программист терпеливо объясняет, и на согласование каждого API уходит день-два, это ещё приемлемо; если нет — это приводит к спорам.

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

Если споры между техническими специалистами — это война холодным оружием, то встреча с ещё более непрофессиональным продакт-менеджером или начальником означает начало ядерной войны.

"Ты всего лишь меняешь веб-страницу — можешь сделать это за десять минут?"

"Неужели этот эффект так сложно сделать? Давай я сделаю его за тебя!"

"Завтра запуск, поторопись!"

"Меня не волнует, какие у вас технические сложности, вы просто должны это сделать!"

И такие сцены постоянно разыгрываются почти в каждой компании.

Постарайтесь понять технологию другой стороны

Сначала расскажу о своей траектории технологического роста.

Я начал пользоваться Linux в средней школе; моей основной системой была Ubuntu. Позже я перешёл на ArchLinux, затем обратно на Ubuntu, и продолжал пользоваться ею до первого курса колледжа. Эти годы опыта работы с Linux заложили основу для моей серверной архитектуры. На первом курсе я начал пытаться создать собственный продукт.

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

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

Когда я начал писать веб-фронтенд, я не знал, что существуют фронтенд-фреймворки. Только закончив с Rails, я обнаружил нечто под названием Ember.js, поэтому начал переписывать всё на Ember.js. Моё первоначальное понимание всё ещё сводилось к тому, как использовать Rails для рендеринга фронтенда, но позже я осознал, что после внедрения фронтенд-фреймворка роль Rails уже стала API Server.

И вот оттуда я начал думать с новой точки зрения о том, как проектировать API Rails. Я прочитал много материалов по проектированию API — как сделать фронтенд удобным в использовании, как сократить время запросов, серверное кэширование, redis, безопасность и так далее.

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

Позже я перешёл с Ember.js на Angular.js и переписал всё на Angular. В этот период я также познакомился с фронтенд-инструментом Grunt (фронтенд меняется с головокружительной скоростью; используемые сейчас инструменты уже не этот).

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

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

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

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

Всё это произошло всего за один год.

Интересно, что много раз, когда я писал iOS-клиент, я внезапно понимал принципы реализации HTML и CSS; работая с Rails, я внезапно придумывал лучшие подходы к архитектуре iOS. Чувство проведения аналогий между разными технологиями возникало каждый день.

В дальнейшем этот опыт очень облегчил для меня общение с разными техническими людьми, потому что в прошлом году,для Miaoshiразработки фильтров, я начал изучать openGL, и после повторного знакомства сBlender, многие его места, которые я раньше понимал лишь наполовину, вдруг стали такими же простыми для реализации, как Hello World. Поэтому я просто также начал играть с Unity. После всего этого накопленного опыта изучение Unity стало очень лёгким, и оно превратилось в мой вечерний проект для отдыха. Возможно, скоро вы увидите игру, которую я сделал (возможно, это будет RPG).

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

Уважение и мир

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

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

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

Автор:Чжоу Кайвэнь

URL оригинальной статьи: http://www.ifanr.com/551905