Достаточно часто бывает трудно сформулировать с первого раза название должности или позиции для специалиста в компании на том или ином проекте. Это происходит ввиду того, что зона ответственности находится на стыке зон других команд или отделов. Как бы забавно не звучал оксюморон «специалист широкого профиля», но все же такое бывает.
Что если нет устоявшегося названия должности в «Табеле о рангах всех чинов»? Пора придумать свое. Знакомьтесь — Server Developer!
TL;DR
Server developer — специалист широкого профиля, который неплохо разбирается в том, как происходит взаимодействие между клиентом и сервером.
Понимание происходящего распространяется не только на какие-либо высокоуровневые и абстрактные понятия, но и на вполне низкоуровневые: OSI model? Пфф... TCP
Я работаю 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 подразумевает использование не только инновационных технологий и подходов, но и классических решений отрасли. «Я получаю знание не из одного лишь моего опыта, но и из опыта других». © Людвиг Витгенштейн
Список полезных ресурсов
- «UNIX Network Programming», by W. Richard Stevens, Bill Fenner, Andrew M. Rudoff;
- «The Linux Programming Interface: A Linux and UNIX System Programming Handbook», by Michael Kerrisk;
- «Dive Into Python 3», by Mark Pilgrim;
- «C Programming Language», by Brian W. Kernighan, Dennis M. Ritchie;
- «C++ Concurrency in Action: Practical Multithreading», by Anthony Williams;
- «The No Asshole Rule: Building a Civilised Workplace and Surviving One That Isn’t», by Robert I. Sutton;
- GNU Software.