Миф, Реальность, Абсурд

Вступление:

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

Я не могу точно сказать, когда термин «полный стек» стал широко использоваться для описания должности программиста. Это похоже на многие другие термины, которые со временем исчезают и исчезают. Например, термин «DevOps», который стал чрезвычайно популярным, представляет в своем самом основном формате вечный цикл разработки, постановки, производства. При осторожном применении предполагается сократить время от программирования до реализации. Недавно вы также заметили термин «CI / CD». Когда я впервые увидел это, я почувствовал себя дураком, сказал себе: «Что, черт возьми, это значит?», И пошел посмотреть. Я буквально разразился смехом, когда понял, что это означает «Непрерывная интеграция / Непрерывное развитие». YAT (еще один термин) для DevOps (на основе некоторой методологии, такой как Agile, Scrum или Kanban и т. Д. И т. Д.)! Поэтому никого в области технологий не должно удивлять то, что «Fullstack» стал популярным и упоминаемым. Вдруг половина программистов, с которыми я беседую или разговариваю, смотрят мне прямо в глаза со всей серьезностью и говорят: «Я программист полного стека».

И затем я спрашиваю, как и в случае с CI / CD: «Что, черт возьми, это значит?». Как только я слышу, как кто-то хвастается своими возможностями полного стека, вопросы приходят быстро и яростно (и да, я также признаю, с небольшим сарказмом).

1. О каком стеке вы говорите? Какой стек технологий использует или собирается использовать ваша компания?

2. Вы утверждаете, что знаете Angular, Vue, HTML и React? И знаете их все в совершенстве?

3. Вы можете программировать серверные части на NodeJS, Java / Scala, C ++, PHP, Python, Golang? Вы знаете все эти языки и хорошо их знаете?

4. Вы разбираетесь в JSON и как его реально использовать, когда он глубоко вложен?

5. Вы знаете AWS, Azure и т. Д. И все компоненты? От шлюзов EC2 до NAT и всех более 1001 модулей, которые предлагает вам только AWS?

6. Вы являетесь экспертом в Redis и Memcached и знаете, как настроить и правильно использовать систему Redis и для чего ее использовать?

7. Вы знаете как IOS, так и Android, а также не используете собственный код с помощью React?

8. Вы знаете SQL и NoSQL? Различия между ними и как ими пользоваться? Вы понимаете MySQL, Postgre / Postgres SQL, MongoDB, Hadoop, Cassandra, Apache Spark?

9. И, наверное, самое главное, знаете ли вы, как защитить все свои данные, как данные в состоянии покоя, так и данные в пути?

Я просто позволяю вопросам летать, не дожидаясь ответов. Потому что этих вопросов можно легко превратить в 25 и более. Любой, кто осмелится сказать мне, что знает все вышеперечисленное и хорошо их знает, - либо дурак, либо шарлатан. Итак, о каком «полном стеке» мы говорим? Прежде всего, определите свой полный стек. Я понятия не имею, что вы подразумеваете под «полным стеком»!

Чтобы понять, что такое настоящий стек, давайте возьмем в качестве примера два самых простых стека в стране лексиконов и сокращений, столь распространенных в технологиях. Технологи знают о стеке «LAMP» и о новом стеке «MEAN». LAMP означает «Linux, Apache, MySQL и PHP». MEAN означает «MongoDB, Express, Angular, NodeJS». Стек MEAN включает в себя интерфейсную часть - Angular. Стек LAMP нет.

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

Миф

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

1. Ограниченные средства. На самом деле бюджет ограничен. Это само собой разумеющееся, будь то стартап или крупная компания. Бюджеты создаются, чтобы гарантировать, что скорость сжигания не приведет к безудержному поезду, и компания сможет покрыть расходы. Это экономика 101, и те, кто решил проигнорировать сумму денег, собранных или заработанных в результате продаж, гарантируют катастрофу. Следовательно, казалось, что это имело большой смысл, а не иметь команду программистов, в которой каждый человек (или команды) был экспертом в одной или двух вещах, почему бы не иметь людей, способных делать все это? «Fullstack» нашел свое применение. В конце концов, многие компании требуют, чтобы их технический директор был «практическим» (HO), чтобы они могли выполнять две работы - одну в программировании, а другую - в управлении другими программистами. Так почему бы не объединить различные «экспертизы» в одной должности? Это позволяет сэкономить деньги и дает дополнительное преимущество в виде небольших и плотных команд.

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

3. Незнание того, сколько знаний требуется - в недавнем очень открытом разговоре с недавно назначенным вице-президентом по исследованиям и разработкам он спросил меня, что я думаю о команде программистов полного цикла. Я ответил вопросом. "Что такое стек?" По его словам, это MongoDB, React, стек NodeJS, включая микросервисы, лямбда-выражения и другие виды использования технологий AWS. Я подумал на секунду, прекрасно зная, что, если я буду жестоко честен, мне придется подумать о работе, на которую я собирался пройти собеседование. У меня всегда побеждает «жестокая честность». Я спросил вице-президента, понимает ли он то, о чем просит своих программистов.

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

б. MongoDB - это хранилище данных NoSQL. Многие не понимают, что только он содержит язык, содержащий более 200 возможных вызовов. Это также требует глубокого понимания данных, поскольку это не ваши реляционные линейные таблицы. (И даже в системах SQL должен быть серьезный специалист по данным (DBA)). MongoDB и все системы NoSQL также требуют знания данных без схемы. (См. Мою статью в Medium: Серьезная ошибка использования Mongoose для обработки больших данных.) Это наука сама по себе. А как насчет репликации и шардинга? Индекс использовать? Понимание, когда использовать уменьшение карты и все остальные точки.

c. Тогда есть AWS. AWS изобилует технологиями. Лямбда - одна из них. Он стал невероятно популярным, но при неправильном применении может превратиться в кошмар (особенно с точки зрения затрат компании). А как насчет всех остальных требований к AWS? Простой стек AWS, включающий экземпляры, шлюз NAT, использование S3 и множество технологий, которые предлагает AWS. Уже одно это - огромная задача, и она может легко выйти из-под контроля.

d. В свой ответ я добавил еще несколько интересных моментов. Redis - когда и где использовать? Как это использовать? Как умело манипулировать им и данными.

е. А кто позаботится о безопасности данных? Само по себе это работа на полную ставку, и она так часто игнорируется в цикле разработки, что пугает. (Не вдаваясь глубоко в эту тему, прочтите мою статью в Medium: 10 начальных шагов к созданию системы кибербезопасных технологий).

f. Если этого было недостаточно, чтобы показать, просто описав безумие ожидать, что один программист сможет сделать все вышеперечисленное и сделать это превосходно, я тогда перешел к интерфейсу. Вы говорите мне, что один человек будет знать все, что указано в приведенном выше списке, а также сможет подготовить достойный интерфейс с нормативным UI и UX? Даже если бы это был не React (возможно, самый сложный из всех), а Angular или Vue, это все равно огромная фантазия. Меня не волнует, насколько этот программист «ниндзя».

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

4. Plain & Simple Hubris - Да, есть несколько стеков (например, WordPress, Wix и т. Д.), Которыми может управлять один человек. Тем не менее, любой программист или технический директор, заявляющий о полном объеме знаний, а иногда я слышал, что такое утверждение относится ко многим языкам программирования, интерфейсам и структурам баз данных (со смесью SQL и NoSQL), - это просто высокомерие в худшем случае.

Реальность

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

На самом деле вы сначала должны определить, что содержится в вашем стеке. Если мы будем придерживаться приведенного выше примера, ваши программисты на NodeJS могут также справиться с настройкой MongoDB. Но поймут ли они необходимость обеспечения безопасности? Я не могу сосчитать, сколько раз я видел установку MongoDB, локально или в Атласе, которая была совершенно небезопасной и требовала затвора. Будут ли эти программисты знать, что пока данные находятся в пути, они должны применять к ним меры безопасности? Поймут ли они разницу между bCrypt и криптовалютой? Я мог бы продолжать и продолжать, но давайте предположим, что все вышеперечисленное можно найти в одном человеке. А как насчет интерфейса? Они также собираются разрабатывать весь интерфейс (для мобильных и веб-сайтов), делая при этом вышеупомянутое и делая это хорошо?

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

1. Фронтенд

2. Серверная часть

3. Базы данных

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

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

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

Реальность такова - сразитесь с реальностью и ограничениями разумным образом.

Абсурд

Вы бы наняли программиста, который знает Python, в качестве специалиста по данным? Я чертовски уверен, что ответ на этот вопрос - «нет». Почему? Потому что специалистам по данным требуется набор навыков, из которых Python или Java / Scala являются лишь частью пула. Зачем тогда вам приходить в голову нанять программиста на Python, который немного разбирается в NodeJS, для создания всей системы фронтенда, бэкенда и базы данных? Это явный абсурд.

Но .. но .. но .. вы их проверяли! Да вы сделали. Они прошли тест Python, тест NodeJS, тест БД и даже небольшую интерфейсную систему. Форма здесь, вопрос там, отзывчивый сайт - конечно, вы нашли отличного программиста полного стека. Они настолько хороши, что даже если вы перейдете на Golang или добавите JAVA в микс, они легко выполнят переход.

Это родной программатор iOS? Что ж, если они могут делать IOS, они могут делать Android, верно? Конечно! Они смогут обрабатывать все нюансы в обеих системах, включая данные, которые будут передаваться туда и обратно из серверной части. Почему нет?

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

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

Это все равно, что ожидать, что технический директор станет генеральным директором, операционным директором и финансовым директором в одном лице. Никто в здравом уме не посоветовал бы сделать такое. Почему вы могли ожидать, что программист сделает это? Когда все сказано и сделано, вы никогда не должны ожидать, что программист «полного стека» будет просто знать все и быть экспертом во всем. Это просто смехотворно.

Прелюдия к неудаче

Для всех «программистов полного стека»:

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

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

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

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

Итак, отвечу жестоко честно. Полностековое программирование - это афера. Вы будете мастером на все руки и ни в чем не мастером. И когда ваша БД не отвечает, или ваша серверная часть не выполняет правильные вычисления, или ваш внешний интерфейс не представляет данные правильно, или когда ваша система взломана и взломана - угадайте, кто будет виноват? В конце концов, вы же программист fullstack!

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

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

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

Держитесь подальше от соблазна «fullstack». Держись подальше. Знайте, что вы действительно знаете, и признавайте то, чего не знаете. Это мои любимые слова в английском языке. "Я не знаю". Прекратите пытаться обмануть систему. В конечном итоге виноваты будете вы, программист.

_________________________________________________________________

С Тедом можно связаться по электронной почте: [email protected]; Твиттер (@tedwgross); LinkedIn; "Середина"