Server Developer: хто це, що робить і як їм стати

Досить часто буває важко сформулювати з першого разу назва посади або позиції для фахівця в компанії на тому чи іншому проекті. Це відбувається через те, що зона відповідальності знаходиться на стику зон інших команд або відділів. Як би смішно не звучало оксюморон «спеціаліст широкого профілю», але все ж таке трапляється.

Якщо немає усталеного назви посади в «Табелі про ранги всіх чинів»? Пора придумати своє. Знайомтеся — Server Developer!

TL;DR

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

Розуміння того, що відбувається поширюється не тільки на якісь високорівневі і абстрактні поняття, але й на цілком низькорівневі: OSI model? Пфф... TCP 3-Way Handshake? Та будь ласка!

Посада Server developer в KeepSolid я займаю ось вже більше року. Мій загальний стаж в галузі при цьому становить 15 років.

У плані кар'єрних очікувань, як мені здається, все залежить конкретно від людини. Свій шлях я обрав у площині «горизонтального росту», просто тому що до мозку кісток «синій комірець». Однак серед своїх колег я бачу чимало прикладів, коли умінь і амбіцій цілком достатньо, щоб розвивати свою кар'єру «вертикально»: Tech Lead, System 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.

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

Server development це:

Кожен член команди 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 передбачає використання не тільки інноваційних технологій і підходів, але і класичних рішень галузі. «Я отримую знання не з одного лише мого досвіду, але й досвіду інших». © Людвіг Вітгенштейн

Список корисних ресурсів

Опубліковано: 13/06/18 @ 10:00
Розділ Різне

Рекомендуємо:

Пишемо багатоплатформовий код з Haxe
DevOps дайджест #20: Microsoft і GitHub, AWS зарелизил EKS, DevOps Factors
Реактивний підхід до валідації полів введення на Android
DOU Проектор: CleverStaff — сервіс для автоматизації рекрутингу
Не малюванням єдиним: навіщо дизайнеру розуміти бізнес замовника і впливати на продукт