Month of Testing — 20 тематических вебинаров, 17 спикеров, подготовка к сертификации ISTQB!
×Закрыть

Server Developer: кто это, что делает и как им стать

Достаточно часто бывает трудно сформулировать с первого раза название должности или позиции для специалиста в компании на том или ином проекте. Это происходит ввиду того, что зона ответственности находится на стыке зон других команд или отделов. Как бы забавно не звучал оксюморон «специалист широкого профиля», но все же такое бывает.

Что если нет устоявшегося названия должности в «Табеле о рангах всех чинов»? Пора придумать свое. Знакомьтесь — Server Developer!

TL;DR

Server developer — специалист широкого профиля, который неплохо разбирается в том, как происходит взаимодействие между клиентом и сервером.

Понимание происходящего распространяется не только на какие-либо высокоуровневые и абстрактные понятия, но и на вполне низкоуровневые: OSI model? Пфф... TCP 3-Way Handshake? Да пожалуйста!

Я работаю Server developer’ом в KeepSolid вот уже больше года. Мой общий стаж в отрасли при этом составляет 15 лет.

В плане карьерных ожиданий, как мне кажется, все зависит конкретно от человека. Свой путь я выбрал в плоскости «горизонтального роста», просто потому что до мозга костей «синий воротник». Однако среди своих коллег я вижу немало примеров, когда умений и амбиций вполне достаточно, чтобы развивать свою карьеру «вертикально»: Tech Lead, Systems Architect, CTO и временами даже CEO.

Мой опыт

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

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

Эти измерительные приборы работали через популярный в то время интерфейс GPIB (IEEE-488). Каждое устройство, подключенное к шине, могло быть адресовано для выполнения операций ввода/вывода. Знание об устройстве этого интерфейса дало мне тогда первичное представление о сетях передачи данных, в том или ином виде.

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

Один из наиболее запомнившихся случаев — это когда поставили задачу получить результаты измерений из спектроколориметра «Пульсар», который был выпущен в 1987 в Узбекистане :)

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

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

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

Позже задачи и проекты стали больше ориентироваться на сеть, с акцентом на углубленное знание TCP/IP и безопасную передачи данных. Собственно говоря, это направление и стало для меня основным, особенно последние 5 лет.

Знания и обязанности Server developer

Случайно или по воле провидения мои интересы подвели меня к соответствию требованиям открытой вакансии в компании KeepSolid. После достаточно быстрого процесса найма, я получил оффер и стал Server developer’ом. Итак, кто я? Зачем я? Какова моя роль во всем этом?

Если попытаться разделить специализацию труда в Web-разработке, то можно выделить два основных направления — front-end и back-end.

  • Front-end: «клиентская сторона пользовательского интерфейса к программно-аппаратной части сервиса». © Wikipedia
  • Back-end: «программно-аппаратная часть сервиса». © Wikipedia

Эти термины по смыслу частично пересекаются с похожими понятиями client/server side, которыми можно описать все остальное, имеющее клиент-серверную архитектуру.
Server development, не побоюсь преувеличения, — это в каком-то смысле «клей», который согласовывает и координирует работу команд, занимающихся back-end, front-end (и нативными клиентскими приложениями), частично отдела техподдержки и даже немножко отдела технических писателей.

Server development это:

  • разработка собственных сетевых программных компонент;
  • интеграция готовых решений в существующую инфраструктуру;
  • расширение функциональности уже готовых решений (а также исправление имеющихся дефектов);
  • задачи, частично связанные с развертыванием и конфигурацией среды выполнения (привет DevOps’ам);
  • RnD с акцентом на Research.

Каждый член команды Server Developers чаще всего «ведет» какое-то определенное направление, однако мы стараемся делиться информацией с коллегами не только нашего, но и других департаментов.

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

Багаж знаний человека, претендующего на эту позицию, предполагает углубленные знания в области сетевых протоколов. Понимание механизмов, которые реализуют надежность протоколов TCP — от подключения и согласования (handshake) до механизма retransmission и динамического регулирования «окна передачи». Аналогично тому, что скрывается под капотом TCP, надо иметь представление о протоколе UDP и о том, что делает его не похожим на TCP.

Говоря о «смежных» доменах, стоит упомянуть, что конкретно в этом аспекте требования к знаниям такие же, как к знаниям системного администратора. Образно говоря, надо иметь представления о том, какой путь преодолевает пакет данных, начиная от сокета (через ядро системы и сетевой интерфейс, цепочку промежуточных маршрутизаторов) и заканчивая готовым устройством.

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

В некоторых случаях использование какого-либо интерпретируемого языка (к примеру Python) дает такое же эффективное решение и даже выигрыш в плане сроков реализации. А когда речь идет о прототипировании (имплементации proof-of-concept), то использование такого рода инструментария трудно переоценить. Поэтому знание некоторых популярных интерпретируемых языков программирования совершенно точно не будет лишним.

Исторически сложилось так, что UNIX-подобные операционные системы прочно заняли нишу серверов и ассоциируются именно с этой ролью. Однако мир UNIX-подобных операционных систем гораздо разнообразнее и охватывает не только серверные системы, но и рынок настольных рабочих станций и даже мобильный сегмент. Умение ориентироваться во всем этом многообразии — достаточно важный навык. Знание набора стандартов POSIX сильно поможет в этом (даже Windows частично совместим, благодаря FIPS-151).

Советы для начинающих специалистов

Как правило, на первом месте в списках такого рода — совет изучать алгоритмы и структуры, а не новые модные языки программирования или библиотеки (но Python и C лучше, конечно же, знать хотя бы на базовом уровне).

Пишите, пишите и еще раз пишите! Опыт — неплохой способ впитать умения. Со временем у вас выработается собственный, как правило, хороший стиль кодирования.

Вместе с тем старайтесь изучать уже существующие решения — эталоны в отрасли. К примеру, если вы разрабатываете свое решение хранения данных, то неплохо бы знать, хотя бы в теории, что находится под капотом таких титанов, как MongoDB, Redis, MySQL и т. д. Чужой опыт и удачные архитектурные приемы помогут принять правильное решение и выбрать путь.

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

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

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

Выводы

Server developer — это просто квинтэссенция понятия «горизонтальный рост». Предметная область охватывает настолько широкий фронт задач, что кажется, работа есть всегда и много. Эта одна из тех специализаций, где постоянно открываешь что-то новенькое. Выражение «век живи — век учись» — на самом деле вовсе никакое не избитое клише. Вместе с тем Server development подразумевает использование не только инновационных технологий и подходов, но и классических решений отрасли. «Я получаю знание не из одного лишь моего опыта, но и из опыта других». © Людвиг Витгенштейн

Список полезных ресурсов

LinkedIn

38 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.
Server developer — специалист широкого профиля, который неплохо разбирается в том, как происходит взаимодействие между клиентом
и сервером

Так вот, уважаемые. Разработчик, б...ь, сервера, это либо специалист, создающий серверное ПО, либо специалист по архитектуре hardware, на котором это ПО будет работать. Все остальное — галиматья и куча умных слов.

Не деда ты не прав между ПО и железом же ж ещё куча всего... ))

ЗЫ: как и между клиентом и сервером кстати ))

Товарищ Фогол, между серверным ПО и железом — только ОС да bios. Все.:-)

только ОС да bios. Все

Гы гы гы )) там в этом «только» сегодня много в слове )) настолько что для него даже придумали новое слово devops и Site Reliability Engineering.

Это прокладка между стулом и биосом %)

Все-то вы знаете, товарищ Фогол! :-D :-) :-D

«Во многой мудрости много печали; и кто умножает познания, умножает скорбь.» (к)

Андрей, спасибо за комментарий! Я рад что получилось вызвать живой отклик. Уверен что в дискуссии рождается истина, при условии что есть что обсуждать =)

А может он сам спаял теплый ламповый сервер и написал весь софт для него, только постеснялся рассказывать об этом?

Смотрю, дедушко понравилось :).

теплый ламповый сервер

Облачный же ж ))

То же ж солнышко!!!

Простите, но статья чуть более, чем полностью состоит из ненужного пафоса, самолюбования и воды.
Чего только стоит:

Пора придумать свое. Знакомьтесь — Server Developer!

Было бы справедливо объяснить, с использованием реальных рабочих примеров, почему вообще возникла необходимость придумывать что-то свое и не является ли эта необходимость банальным непониманием процессов разработки.
Или можно хотя бы предоставить конкретный пример задачи, которую ставят перед «Server developer» и сходу же аргументацию: почему эту задачу должен выполнять именно «Server developer», а не backend или dev-ops, к примеру?
Заранее спасибо.

Можете думать об этом так, будто бы Server developer создает платформу-инструмент в терминах которой при помощи других средств (и другими людьми, как правило) реализуется бизнес-логика.
К примеру реализовать пользовательский модуль для Apache или специализированный secure-proxy вполне типовая задача для Server developer.
Реализация web-сервисов, с какими либо API, это уже ипостась коллег занимающихся back-end разработкой(бизнес логика).

Все вище описане Вами входить в обов’язки програміста, який спеціалізується на Network Programming. Тайтл я б залишив Developer — просто при потребі уточнив би спеціалізацію.

Назарий, я с Вами согласен но лишь частично =)
Можно еще более генерализировать, и назваться Software engineer (вполне себе распространенный тайтл).
Имею альтернативное мнение в том месте, где Вы указываете что это просто разработчик специализирующийся на Network Programming.
Server development это и security/cryptography, знание архитектуры целевой ОС и много чего еще.
Ввиду «размазанной» и неоднозначной зоны ответственности, и используется этот тайтл (в других компаниях тоже).

Підтримую, але security в Network Programming це маст хев.

«Не следует множить сущности без необходимости» ©.
Є термін «network developer», який на 90% описує, чим ви займаєтесь.
А те, що «я иногда еще примусы починяю devops» — то таке...

Виталий, а что если тайтл Server Developer всего лишь на 63% пересекается с «network developer» а не на 90% ? Вдруг Вы ошиблись в подсчетах ?
Следуя Вашей логике можно генерализировать и называть всех айтишниками ) Причина существования такого тайтла описана в самом начале статьи.

А виходячи з вашої логіки, те, чим займається Сергій Жуков, настільки неповторне, що для нього потрібно придумати нове визначення. ;)

Ну справедливости ради я не один такой, но в целом Вы правы =)

Виталий, а что если тайтл Server Developer всего лишь на 63% пересекается с «network developer» а не на 90% ? Вдруг Вы ошиблись в подсчетах ?

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

Богдан, ну я примерно и выдал значение 60% основываясь на внутренних ощущениях. Остальные виды активности могут меняться в разных пропорциях не только в зависимости от проекта, но и в зависимости от стадии проекта.
Примерно похожая ситуация и с позицией DevOps (в целом, без привязки к компании).
Если DevOps в контексте задачи значимую часть времени занимается развертыванием среды — почему мы его не называем тогда системным администратором ? Ответ прост — DevOps аналогично находится на стыке нескольких зон ответственности. Поэтому придумали даже такой тайтл.

ну я примерно и выдал значение 60% основываясь на внутренних ощущениях.

Я не про ваши внутренние ощущения спрашивал, а про список.

Если DevOps в контексте задачи значимую часть времени занимается развертыванием среды — почему мы его не называем тогда системным администратором ?

По разным причинам. 2 наиболее частые:
1) Некоторым ЧСВ и букет комплексов не позволяет называть себя админами. (Потому что админ — это чувак которых принтер подключает в бухгалтерии, по их мнению)
2) Аутсорсерам так проще продать тушку.
Вы, кстати, в аутсорсинговой компании работаете?

Богдан, Вы подводите тему в то русло, где любой мой ответ как бы будет означать мою неправоту (а стало быть Вашу правоту).
Я Вам ответил честно что если бы было можно было создать список, то безусловно «network programming» был бы на первом месте. Другие виды активности это что-то не имеющее регулярную структуру (сложно выделить очередность по важности и т.д.) .
Компания с которой я себя ассоциирую (KeepSolid Inc.) является продуктовой компанией что мне лично подходит. Также мне лично знакомо как дела состоят в аутсорсинговых компаниях — максимум что я там видел это «махинации» с рангом специалиста для продажи. Придумыванием «переворачивателей пингвинов» никто не занимался )
Если Вы готовы принять существование тайтла DevOps, не ясно ваше очевидное несогласие с существование других тайтлов ?!
«ЧСВ и комплексы» никак не связаны с фактом существования неких тайтлов которые Вас смущают. Это всё личностные особенности которые могут проявляться у кого угодно, даже у канонических Software Engineer.

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

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

Я Вам ответил честно что если бы было можно было создать список, то безусловно «network programming» был бы на первом месте.

Не правда. На момент написания вашего комментария, вы еще не ответили честно.

Если Вы готовы принять существование тайтла DevOps, не ясно ваше очевидное несогласие с существование других тайтлов ?!

Нет не готов я принять существование тайтла DevOps. Я лишь объяснил почему это тайтл существует (появился он по немного другим причинам, пересекающимися с теми что я озвучил)

«Нет не готов я принять существование тайтла DevOps» — Богдан, думаю этого вполне достаточно =)

думаю этого вполне достаточно =)

Обычно, чтобы подчеркнуть полное остутсвие аргументов со своей стороны люди еще добавляют слово «Точка» в конце :)

Не могу понять чего в статье больше, воды или самолюбования.

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

Туфта, а не статья с кучей воды ни о чем.

Программист который выучил сеть — больше не программист. А разработчик серверов!

Подписаться на комментарии