Давно не виделись! Надо исправлять. А поскольку у нас с вами лето, нельзя просто так взять и собраться — устраиваем митап для всех, кто связал свою жизнь с С++. Программа плотная:

18:00-19:00 Сбор гостей и welcome-кофе

19:00-19:30 Использование С++ библиотек при разработке прикладных решений в Astra Linux

19:45-20:15 C++ как производительный runtime для микросервисов: обсудим подход, при котором C++ усиливает Node.js, а Node.js ускоряет интерфейсную часть C++-систем.

20:15-20:45 Брейк на обсуждения

20:45-21:15 «Дайджест по нейросетям и их применению в IT» 

21:15-22:00 Холиварный сейшен с экспертами: С++ мертв или нет. Обсуждаем эффективные практики и методы использования С++ в задачах разработки и интеграции.

Встречаемся на Бауманская ул., 11, стр. 8 — около 10 минут от м. Бауманская или м. Красносельская.

Подробности и регистрация тут

Читаемость Си-кода: грустный ликбез, чтобы жить стало веселее

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

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

Последние два очень легко спутать, если читать код невнимательно. Вместо них иногда рекомендуют использовать

#if defined // вместо #ifdef
#if !defined // вместо #ifndef

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

Чего далеко ходить - все open source проекты пестрят именно сокращенными вариантами этих выражений и с этим уже ничего не поделаешь.

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

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

• условную компиляцию;

• выравнивание структур;

• предотвращать повторные включения файла;

• работать со строками;

• грамотно оборачивать повторяющийся код и т.д. и т.п.

Но бывают случаи, когда упрощение кода с точки зрения алгоритма делает его слабо читаемым для того самого бедного программиста, пытающегося прочесть этот шедевр машинописного текста:

struct {
  const char *name;
  const char *value;
#define _SPECIAL(x) { .name = #x, .value = b->x, }
} specials[] = {
  { .name = "object", .value = b->object_string, },
  _SPECIAL(host),
  _SPECIAL(endpoint),
#undef _SPECIAL
};

*ну все, можно начинать грустить*

Чтобы разобраться, давайте очистим код от макросов, но сохраним суть:

struct {
  const char *name;
  const char *value;
} specials[] = {
  { .name = "object", .value = b->object_string, },
  { .name = "host", .value = host, },
  { .name = "endpoint", .value = endpoint, },
};

Что понятно из очищенного варианта:

• инициализируется массив specials[];

• типом данных этого массива является структура с полями *name и *value;

• поля элементов массива задаются вручную.

Но как можно этот процесс немного автоматизировать и не прописывать вручную одинаковые строки?

Правильно, с помощью макроса:

#define _SPECIAL(x) { .name = #x, .value = b->x, }

который определяется после объявления полей структуры.

Как обрабатывается аргумент x:

• имя аргумента преобразуется в строку с помощью макроса "#x" и присваивается полю *name;

• полю *value присваивается значение поля структуры b с названием аргумента x (тут нужно убедиться, что поле с именем x действительно существует в структуре b).

То есть чтобы при заполнении массива не писать каждый раз одинаковые строчки:

{ .name = "host", .value = host, },
{ .name = "endpoint", .value = endpoint, }

можно вызвать выражение _SPECIALS:

_SPECIAL(host),
_SPECIAL(endpoint),

Ну и в самом конце вызываем удаление созданного макроса, чтобы оно не было использовано в коде в дальнейшем:

#undef _SPECIAL

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

А какие выражения и макросы в Си видели вы?

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

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

Итак, навыки, правила, они же житейские мудрости, они же грабли, на которые наступал.

1. Сначала править конфиги и только потом - код. Это база

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

Сначала проверь конфигурацию и все её возможные варианты! Если все эти варианты исчерпаны, то только тогда, в последнюю очередь смотри в код!

Я очень долго привыкал к этой мысли, тратя тонны времени на чтение кода, так и не найдя там ошибки. А после приходил коллега-сисадмин, который пошарил конфигурацию, почитал документацию, поиграл с настройками и всё решил.

2. Владеть инструментами командной строки

Логично, но не очевидно на первый взгляд. В отличие от обычного программиста (в сферическом вакууме), когда ты можешь ограничиться пошаговой отладкой или логами, Unix-программист должен уметь работать с командной строкой. Хоть и не обязательно знать все команды и их опции "на зубок", но нужно понимать, для каких случаев какие утилиты полезны.

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

Например:

- при невозможности пошаговой отладки использовать perf, чтобы проанализировать стек вызовов

- уметь пользоваться grep'ом для поиска и выделения нужной информации из конкретных файлов

- использовать sed для формирования файлов без лишней информации (например в логах убирать строки с наличием отметок времени)

3. Уметь работать с виртуальными машинами, докером, анализаторами трафика

Например, не плодить виртуалки, а делать снэпшоты (вы скажете: "Спасибо, капитан-очевидность!", но я видел на своей практике тех, кто, не зная про снэпшоты, плодил виртуалки). Держать мастер-копии виртуалок с предварительно настроенной конфигурацией для быстрого развертывания новых машин. Понимать, для каких целей проще использовать докер-контейнер и т.д.

4. Работать с огромным количеством открытых одновременно утилит

Как ни странно, я встречал разработчиков, которые задавали вопрос: "Зачем так много всего?"

Ответ прост: когда непонятно поведение программы, нужно принимать во внимание всё.

Резюме: с таким набором навыков в какой-то момент начинаешь себя чувствовать, как оператор из Матрицы.

А какие особенности в Unix-разработке (и не только) подметили вы?

Системный аналитик — проблемная должность на рынке.

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

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

1. Инженер по требованиям

Функции: систематизирует и описывает требования в информационной системе, пишет документацию, помогает разработчикам понять, что именно нужно реализовать. Отвечает за полноту и согласованность требований. Управляет изменениями требований.

Инструменты: вики-системы, таск-трекеры, BPMN, UML, системы разработки интерфейсов

2. Фича-овнер (фича-лид)

Функции: управляет жизненным циклом фичи или подсистемы. Определяет цели и дорожную карту развития подсистемы. Координирует работу фича-team, создающих и поддерживающих подсистему. Это продукт-овнер "на минималках". Отвечает за функционал на всех стадиях: от проработки идеи до внедрения и поддержки.

Инструменты: таск-трекеры, корпоративные мессенджеры, онлайн-доски

3. Проектировщик информационных систем (ИС)

Функции: роль близка к архитектору, но, как правило, с узким фокусом на конкретный набор подсистем. Создаёт архитектуру системы, продумывает её компоненты и взаимодействия, моделирует процессы. Отвечает за документирование и актуальность схем архитектуры.

Инструменты: C4 Model, PlantUML, вики-системы, системы для моделирования процессов

4. Проектировщик баз данных

Функции: собирает и документирует требования к обработке и хранению данных. Строит модели данных, проектирует структуры БД с учётом, в том числе, и нефункциональных требований. Заботится о связях и нормализации.

Инструменты: SQL, инструменты для проектирования баз данных, вики-системы

5. Проектировщик интеграций

Функции: работает там, где есть потребность в интеграциях. Разрабатывает схемы и спецификации взаимодействия между системами, продумывает форматы данных и их трансформации. Документирует API. Помогает команде настраивать интеграционные тесты и валидирует их результаты.

Инструменты: OpenAPI, средства управления запросами к API, стек для управления логами и анализа данных

Это не устоявшаяся терминология и тем более не жёсткое разделение. Однако, судя по вопросам на собеседованиях и картам развития СА (раз, и два), такие границы довольно очевидны.

Что даёт понимание разделения ролей системного аналитика?

Для аналитиков:

Задайте себе вопрос: в какой роли вы чувствуете себя наиболее уверенно? Понимание своей специализации и зон роста поможет вам:

• выбирать компании и проекты с подходящими задачами;

• чётко выстраивать своё профессиональное развитие.

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

Для команд:

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

Для руководителей:

Это помогает чётче формулировать задачи и искать специалиста под конкретные потребности, а не пытаться закрыть всё одним человеком.

Я считаю, что разделение ролей системного аналитика — это ключ к более ясному и эффективному взаимодействию всей команды. А вы? 

Не иди в стартап, не совершай ошибки… или совершай?

Всем привет!

Меня зовут Данил, и я работаю старшим специалистом веб-разработки в компании ООО «Увеон» (Группа компаний Астра). Сегодня я бы хотел поговорить о своем опыте вхождения в айти через стартапы.

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

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

После пары недель поиска основатель стартапа, о котором пойдет речь, нашел меня сам, провел техническое собеседование, которое тогда показалось мне довольно легким. Сам проект представлял собой соцсеть для финансистов: пользователи могли доверять свои средства опытным игрокам валютного рынка, чьи операции затем автоматически копировались. Идея заключалась в том, чтобы все участники оказывались "в плюсе". Моей задачей была разработка модуля копирования операций MT5.

У проекта был заказчик, который оплатил бюджет целиком, а не по спринтам, что вскоре создало проблемы. Через некоторое время начались сложности. Руководство заявило, что моя зарплата завышена и её нужно сократить на 30%. Не обошлось без сравнений с другими сотрудниками, которые якобы "работают лучше". Атмосфера в команде стала напряжённой.

Далее выяснилось, что все работники подписали краткосрочные партнерские договоры на три месяца (испытательный срок) и получали деньги через самозанятость. Контракты не продлевались, а трудовые договоры считались "невыгодными". Через несколько месяцев поступило предупреждение: денег не хватает, возможны задержки оплаты. Однако уверяли, что ситуация наладится. Увы, я был слишком наивен и начал искать новое место лишь спустя два месяца после первых признаков кризиса.

Хочу отметить, что не все стартапы такие. Многие работают честно, создают интересные проекты и открыты перед сотрудниками. Однако мой опыт заставляет быть осторожным.

Опираясь на свой опыт и наблюдения моих коллег, я бы хотел выделить следующие плюсы работы в стартапе:

1. Подработка. Стартап может быть отличным вариантом, если вы ищете дополнительный доход, особенно при формате 0.5 ставки или работы через ИП.

2. Рост. Участие в стартапе ускоряет профессиональное развитие. Из-за ограниченных ресурсов вы осваиваете новые навыки и роли.

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

4. Доля в компании. Возможность получить опцион или бонусы за вклад в развитие продукта.

5. Свобода. Меньше корпоративных ограничений, например, связанных с географией работы.

НО есть и минусы:

1. Отсутствие корпоративных бонусов. Обычно нет ДМС, оплачиваемого оборудования или других стандартных "плюшек".

2. Риски с оплатой труда. Возможны задержки, сокращения или даже отсутствие зарплаты.

3. Риск банкротства. Стартап может закрыться в любой момент, а сотрудники останутся без компенсаций.

4. Сложности с менеджментом. Часто в стартапах не хватает структурированного управления, что приводит к хаосу.

5. Большая нагрузка. Вам придётся совмещать несколько ролей, что ведёт к выгоранию.

Как вам мои выводы? Пишите свое мнение и делитесь своим опытом в комментариях.