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

HR-рекрутер, который ни в чем не виноват, подхватывает эту волну и начинает относиться к экспериментам или опыту как к знаниям. Аналогичная история могла бы существовать, представьте себе инженера-пищевика, работающего в Pepsi. Затем он/она решает пройти собеседование для Coca-Cola, и ему задают вопрос: «Имел ли вы какой-либо опыт в производстве Coke?». Конечно, нет. Инженер имеет опыт приготовления напитка, любого напитка. Независимо от вкуса!

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

Старший инженер-программист еще не работал со всеми существующими языками, со всеми фреймворками, использовал все инструменты и знал все названия продуктов, которые изобрели облачные провайдеры. AWS RDS — это просто база данных, GCP Compute — это просто виртуальная машина и так далее. Но сегодняшние описания вакансий спрашивали: знаете ли вы AWS? Вы уже программировали на Rust раньше? Сколько лет вы имеете опыт работы с языком Go? У вас есть опыт во Flutter? Это инструменты!

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

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

1-й — Linux (независимо от дистрибутива).

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

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

2-й — Как вещи общаются?

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

Подчеркивая все это, у вас есть приложения, серверы, протоколы, физические каналы связи и некоторые механизмы, которые мы просто называем Интернетом ;-).

Senior Software Developer должен знать, какие машины передают сигнал из одной точки земного шара в другую. Как эта коммуникация происходит по принципу «ссылка за ссылкой» и как машины передают пакет от одной к другой, пока не достигнет пункта назначения. Также следует знать, какая полезная нагрузка находится внутри пакета и какой протокол он несет. Как этот протокол передает информацию от приложений. И как разные приложения запускались на одну и ту же машину без утечки информации из одного приложения в другое приложение. Он / она должен знать об IP-адресах и протоколах передачи данных, таких как TCP и UDP, и о том, как маршрутизация выполняется с использованием этих протоколов.

Тяжелая работа, на которую мы все полагаемся, заключается в том, что протокол оператора связи, такой как TCP, и протокол маршрутизации, такой как IP, работают! И полезная нагрузка от прикладного протокола, такого как HTTP, передается из одной точки в другую.

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

3. Как приложения работали поверх этих процессов.

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

Давайте посмотрим, например, на недавний случай, когда Apple использует другую архитектуру для своих машин, но вы можете запустить Python в Windows с процессором CISC, а также тот же код Python на архитектуре ARM на машине с macOS. Эта «магия» связана с тем, что некоторые языки компилируются, а некоторые языки интерпретируются во время выполнения. И не останавливается на достигнутом. Некоторые языки предназначены для обработки данных как динамической вещи, одна и та же переменная может быть числом, а позже в программе измениться на слово. Другие языки имеют строгую парадигму типов, и переменная, которая сначала объявляется как число, всегда будет числом в программе. Все это говорит о том, что старший разработчик программного обеспечения понимает все эти различия и последствия для всех разных языков, даже если он сам никогда не программировал на этом языке.

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

4. Как существуют прикладные протоколы

Некоторые руководители или даже инженеры склонны проповедовать технологии. Быть облачным провайдером, или фреймворком, или языком, или даже инструментом. Но на самом деле прошло уже пару десятилетий с тех пор, как мы стандартизировали протоколы приложений, которые работают в Интернете. У нас есть HTTP, HTTPS, FTP, UDP, RTSP и другие. Возможно, протокольные буферы (protobuf), которые используют gRPC, являются новыми, но очень редко вы делаете свое приложение без использования некоторых из упомянутых ранее или даже просто с использованием HTTP (S Maybe).

Старший разработчик программного обеспечения знает это и знает, что независимо от технологического стека они ограничены ограничениями HTTP, у вас просто есть ГЛАГОЛЫ, и долгое время используются только GET и POST. Независимо от того, делаете ли вы «сначала приложение», «сначала мобильные», «сначала веб» или «сначала десктоп», это не имеет значения. Вы общаетесь с HTTP. Ваш базовый веб-сервер просто обрабатывает ограниченное количество одновременно подключенных клиентов. Ваше монолитное приложение Full-Stack не будет масштабироваться. Если это MVP, то все в порядке. Но вам придется измениться. И многое изменить. Чем больше плохих решений будет принято, тем больше времени вы потеряете, пытаясь создать что-то невыполнимое. И старший разработчик программного обеспечения с самого начала знает, что это невозможно, слушайте своего старшего разработчика программного обеспечения. Если он/она был один.

Не принимайте корпоративную культуру, согласно которой технический директор всегда подходит директору, директор всегда подходит менеджеру, менеджер всегда подходит техническому руководителю, технический руководитель всегда подходит инженеру, а инженер не У меня нет голоса. Он/она уйдет.

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

5-й — Алгоритмы и структуры данных

Хотите верьте, хотите нет, но существует ограниченное количество способов обработки данных. Данные можно хранить, искать, сортировать, обновлять и уничтожать. И есть только один способ представить эти данные. С 0 и 1.

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

Старший инженер-программист знает эти алгоритмы, более сложные, более эффективные, те, которые используют больше памяти, те, которые используют меньше памяти, и так далее. Ему или ей не нужно уже знать язык программирования, эти концепции преподаются еще до того, как вы начнете программировать. Кодирование является проявлением этого знания. Если Senior Software Developer знает Swift и Python, но не знает Rust, это НИЧЕГО не значит. Это означает лишь то, что он выучит его за пару недель. Потому что программирование — это проявление более глубоких знаний, то есть вычислительного мышления и мышления, направленного на решение проблем. А если он/она старший разработчик программного обеспечения, то он/она уже использовал несколько языков. Любой язык, который вам нужен, он более чем способен выучить и использовать, каким бы странным он ни был, или, казалось бы, сложным.

Если Senior Software Developer уже знает какие-то языки (да, во множественном числе), то он Senior и новый язык для него не будет проблемой.

6. Как сохраняются данные

Как и в случае с алгоритмами, существует всего несколько решений для хранения данных. Каждый из них для конкретной вещи. Существуют десятилетия исследований того, как хранить транзакционные данные. Другими словами, вы можете гарантировать, что если результат команды INSERT вернет true, вы можете быть уверены, что эти данные будут там, независимо от того, сколько миллисекунд прошло после того, как я запросил эти данные, или если после этого весь центр обработки данных был закрыт. Мы называем это АТОМНЫМ. Это реляционные базы данных. На сегодняшний день это самый эффективный способ хранения и сохранения данных.

Также есть альтернативы, и я расскажу еще о двух, блочном хранилище и хранилище документов. В настоящее время существует ажиотаж вокруг хранения документов, кажется, что все хотят использовать базу данных NoSQL, но база данных NoSQL — это именно то, что следует из названия, база данных, которая не основана на транзакциях, которые «видят», когда вы ВСТАВЛЯЕТЕ в нее что-то, нет гарантии, что данные были сохранены. В конце концов, данные сохранятся, но вы не знаете, сколько времени после этого. Может случиться так, что если вам нужен фрагмент данных сразу после вставки или обновления этих данных, вы получите старый ответ.

Старший разработчик программного обеспечения знает об этом и использует это в сценариях, когда вам не нужны транзакции ATOMIC с немедленным чтением, а документы можно хранить и показывать только тогда, когда они готовы, например, ленту в социальной сети. Но не в случае, когда вы выполняете финансовую транзакцию для электронного платежа и должны убедиться, что платеж был совершен в это время. Затем вы должны сделать это в реляционной базе данных. Опять же, независимо от названия продукта для этого в облаке Google, AWS или Azure. Он/она знает технологию, независимо от названия продукта.

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

7. Как разрабатывается программное обеспечение

И последнее, но не менее важное: старший инженер-программист знает, как создается программное обеспечение, шаг за шагом, он/она знает, что является приоритетным, а что нет. Он/она понимает основы того, что создается, и поможет команде понять, что некоторые части программного обеспечения можно было бы сделать позже. Ему или ей нужно всего пару минут с владельцем продукта, чтобы понять, что такое программное обеспечение и как его можно развивать. Конечно, развитие означает изменение, но это совершенно нормально. Что не нормально, так это то, что в середине проекта какой-то генеральный директор очищает весь код и хочет начать все сначала. Это как раз случай огромного разворота в самой компании. Но строить тот же продукт, но с другим стеком технологий просто так, недопустимо.

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

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

То же самое для ITIL, выбросьте его.

То же самое для моделей возможностей, выбросьте их.

Старший инженер-программист знает принципы манифеста экстремального программирования и использует его.

Старший инженер-программист знает принципы Scrum и использует их.

Не Jira, не Канбан, не инструмент… принципы. Хороший старший инженер-программист знает, когда Scrum-церемония не нужна. И когда это произойдет.

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

Прежде чем закончить…

Я не владею правдой, если у вас есть какие-либо комментарии, предложения или исправления по этому тексту, пожалуйста, поделитесь ими в моем аккаунте в Твиттере здесь.