Давно не виделись! Надо исправлять. А поскольку у нас с вами лето, нельзя просто так взять и собраться — устраиваем митап для всех, кто связал свою жизнь с С++. Программа плотная:
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 Холиварный сейшен с экспертами: С++ мертв или нет. Обсуждаем эффективные практики и методы использования С++ в задачах разработки и интеграции.
Читаемость Си-кода: грустный ликбез, чтобы жить стало веселее
Многие коллеги по цеху подтвердят, что читаемость кода на языке Си иногда оставляет желать лучшего. Как подтвердят и те, кто им плохо владеет, но так или иначе сталкивается в связи с рабочими задачами.
И всему виной (ожидаемо) выражения препроцессора и, как следствие, макросы. Да, вы правильно подумали. Именно те части кода, в которых вызываются такие легенды как:
Последние два очень легко спутать, если читать код невнимательно. Вместо них иногда рекомендуют использовать
#if defined // вместо #ifdef
#if !defined // вместо #ifndef
Но если же в компании/проекте/отделе нет определенного код-стайла, или он не предполагает написание длинного варианта, то, естественно, разрабы пишут короткую форму (я, честно признаться, тоже).
Чего далеко ходить - все open source проекты пестрят именно сокращенными вариантами этих выражений и с этим уже ничего не поделаешь.
А вот первое выражение из первой тройки игроков иногда вообще открывает врата ада, когда используется многострочный макрос с бэкслэш-символами (\) на концах строк.
Конечно же выражения препроцессора - это очень гибкий и полезный инструмент, позволяющий делать всё:
условную компиляцию;
выравнивание структур;
предотвращать повторные включения файла;
работать со строками;
грамотно оборачивать повторяющийся код и т.д. и т.п.
Но бывают случаи, когда упрощение кода с точки зрения алгоритма делает его слабо читаемым для того самого бедного программиста, пытающегося прочесть этот шедевр машинописного текста:
который определяется после объявления полей структуры.
Как обрабатывается аргумент x:
имя аргумента преобразуется в строку с помощью макроса "#x" и присваивается полю *name;
полю *value присваивается значение поля структуры b с названием аргумента x (тут нужно убедиться, что поле с именем x действительно существует в структуре b).
То есть чтобы при заполнении массива не писать каждый раз одинаковые строчки:
Ну и в самом конце вызываем удаление созданного макроса, чтобы оно не было использовано в коде в дальнейшем:
#undef _SPECIAL
Теперь после прочтения этого небольшого ликбеза вы можете смело пользоваться макросами и создавать более сложные и нечитаемые шедевры наконец-то разобрались в том, насколько гибкими могут оказаться выражения препроцессора ( вообще не понимаю, как вы жили без них раньше...)
Что такое быть Unix-программистом? Быть наполовину сисадмином (и вот почему)
Как вы поняли, этот пост на Хабре начался со смелого заявления. Конкретно в данном случае я не хотел бы раскладывать по полкам абсолютно все навыки, которые нужны Unix-программисту для успешной работы. Их можно получить простым запросом в поисковике или к любому чат-боту типа ChatGPT, DeepSeek и т.д. (на ваш вкус и цвет)
Я же отметил именно те, приобрести которые стоило мне многих набитых шишек. Они связаны с работой в проектах, состоящих из утилит, содержащих по несколько тысяч строк кода каждая.
Итак, навыки, правила, они же житейские мудрости, они же грабли, на которые наступал.
1. Сначала править конфиги и только потом - код. Это база
В течение практически двух лет такой работы, я часто сталкивался с ситуацией: когда возникает проблема, она находится (неожиданно) не в коде, а в конфигурации программы. Спустя десятки выполненных задач на стыке программирования и системного администрирования, я осознал одну очень важную вещь:
Сначала проверь конфигурацию и все её возможные варианты! Если все эти варианты исчерпаны, то только тогда, в последнюю очередь смотри в код!
Я очень долго привыкал к этой мысли, тратя тонны времени на чтение кода, так и не найдя там ошибки. А после приходил коллега-сисадмин, который пошарил конфигурацию, почитал документацию, поиграл с настройками и всё решил.
2. Владеть инструментами командной строки
Логично, но не очевидно на первый взгляд. В отличие от обычного программиста (в сферическом вакууме), когда ты можешь ограничиться пошаговой отладкой или логами, Unix-программист должен уметь работать с командной строкой. Хоть и не обязательно знать все команды и их опции "на зубок", но нужно понимать, для каких случаев какие утилиты полезны.
Сколько было случаев, когда работа над какой-то задачей ускорялась при использовании какой-нибудь утилиты, дающей больше информации об используемых ресурсах.
Например:
- при невозможности пошаговой отладки использовать perf, чтобы проанализировать стек вызовов
- уметь пользоваться grep'ом для поиска и выделения нужной информации из конкретных файлов
- использовать sed для формирования файлов без лишней информации (например в логах убирать строки с наличием отметок времени)
3. Уметь работать с виртуальными машинами, докером, анализаторами трафика
Например, не плодить виртуалки, а делать снэпшоты (вы скажете: "Спасибо, капитан-очевидность!", но я видел на своей практике тех, кто, не зная про снэпшоты, плодил виртуалки). Держать мастер-копии виртуалок с предварительно настроенной конфигурацией для быстрого развертывания новых машин. Понимать, для каких целей проще использовать докер-контейнер и т.д.
4. Работать с огромным количеством открытых одновременно утилит
Как ни странно, я встречал разработчиков, которые задавали вопрос: "Зачем так много всего?"
Ответ прост: когда непонятно поведение программы, нужно принимать во внимание всё.
Резюме: с таким набором навыков в какой-то момент начинаешь себя чувствовать, как оператор из Матрицы.
А какие особенности в Unix-разработке (и не только) подметили вы?
Системный аналитик — проблемная должность на рынке.
Руководители и команды зачастую не знают, какие именно функции такой специалист должен выполнять, а сами аналитики не понимают, какие компетенции развивать. В разных компаниях к системным аналитикам порой предъявляются диаметрально противоположные требования.
За 8+ лет работы системным аналитиком, участия во множестве собеседований и общения с коллегами я пришла к выводу, что путаница возникает из-за того, что за условным названием "системный аналитик" сегодня скрываются как минимум пять специализаций. Давайте поделюсь, как я их вижу, и буду рада, если вы расскажете, как это выглядит у вас.
1. Инженер по требованиям
Функции: систематизирует и описывает требования в информационной системе, пишет документацию, помогает разработчикам понять, что именно нужно реализовать. Отвечает за полноту и согласованность требований. Управляет изменениями требований.
Инструменты: вики-системы, таск-трекеры, BPMN, UML, системы разработки интерфейсов
2. Фича-овнер (фича-лид)
Функции: управляет жизненным циклом фичи или подсистемы. Определяет цели и дорожную карту развития подсистемы. Координирует работу фича-team, создающих и поддерживающих подсистему. Это продукт-овнер "на минималках". Отвечает за функционал на всех стадиях: от проработки идеи до внедрения и поддержки.
Функции: роль близка к архитектору, но, как правило, с узким фокусом на конкретный набор подсистем. Создаёт архитектуру системы, продумывает её компоненты и взаимодействия, моделирует процессы. Отвечает за документирование и актуальность схем архитектуры.
Инструменты: C4 Model, PlantUML, вики-системы, системы для моделирования процессов
4. Проектировщик баз данных
Функции: собирает и документирует требования к обработке и хранению данных. Строит модели данных, проектирует структуры БД с учётом, в том числе, и нефункциональных требований. Заботится о связях и нормализации.
Инструменты: SQL, инструменты для проектирования баз данных, вики-системы
5. Проектировщик интеграций
Функции: работает там, где есть потребность в интеграциях. Разрабатывает схемы и спецификации взаимодействия между системами, продумывает форматы данных и их трансформации. Документирует API. Помогает команде настраивать интеграционные тесты и валидирует их результаты.
Инструменты: OpenAPI, средства управления запросами к API, стек для управления логами и анализа данных
Это не устоявшаяся терминология и тем более не жёсткое разделение. Однако, судя по вопросам на собеседованиях и картам развития СА (раз, и два), такие границы довольно очевидны.
Что даёт понимание разделения ролей системного аналитика?
Для аналитиков:
Задайте себе вопрос: в какой роли вы чувствуете себя наиболее уверенно? Понимание своей специализации и зон роста поможет вам:
выбирать компании и проекты с подходящими задачами;
чётко выстраивать своё профессиональное развитие.
Например, я знаю, что как проектировщик баз данных я пока скорее джун, но в интеграциях и работе с требованиями могу уверенно брать задачи для уровня сеньора. И для моих текущих обязанностей это идеальный набор.
Для команд:
Вы лучше понимаете, как взаимодействовать с аналитиком, учитывая его специализацию. Да и в целом становится яснее, кто именно появился или уже работает в вашей команде.
Для руководителей:
Это помогает чётче формулировать задачи и искать специалиста под конкретные потребности, а не пытаться закрыть всё одним человеком.
Я считаю, что разделение ролей системного аналитика — это ключ к более ясному и эффективному взаимодействию всей команды. А вы?
Не иди в стартап, не совершай ошибки… или совершай?
Всем привет!
Меня зовут Данил, и я работаю старшим специалистом веб-разработки в компании ООО «Увеон» (Группа компаний Астра). Сегодня я бы хотел поговорить о своем опыте вхождения в айти через стартапы.
В моем окружении разработчики делятся на два типа: те, кто работают в стартапах, и те, кто трудятся в корпорациях. Каждый может привести весомые аргументы за свою позицию. Я успел побывать в обоих легионах и готов поделиться своей историей работы в стартапе. Буду рад вашим мнениям и комментариям.
Спустя год после окончания университета и работы на Ижевском Радиозаводе python-программистом, я понял, что уперся в потолок как технический, так и зарплатный, хотелось изменений. Плюс впереди планировался переезд в Питер, нужно было искать удаленный формат, что завод никак не мог предложить.
После пары недель поиска основатель стартапа, о котором пойдет речь, нашел меня сам, провел техническое собеседование, которое тогда показалось мне довольно легким. Сам проект представлял собой соцсеть для финансистов: пользователи могли доверять свои средства опытным игрокам валютного рынка, чьи операции затем автоматически копировались. Идея заключалась в том, чтобы все участники оказывались "в плюсе". Моей задачей была разработка модуля копирования операций MT5.
У проекта был заказчик, который оплатил бюджет целиком, а не по спринтам, что вскоре создало проблемы. Через некоторое время начались сложности. Руководство заявило, что моя зарплата завышена и её нужно сократить на 30%. Не обошлось без сравнений с другими сотрудниками, которые якобы "работают лучше". Атмосфера в команде стала напряжённой.
Далее выяснилось, что все работники подписали краткосрочные партнерские договоры на три месяца (испытательный срок) и получали деньги через самозанятость. Контракты не продлевались, а трудовые договоры считались "невыгодными". Через несколько месяцев поступило предупреждение: денег не хватает, возможны задержки оплаты. Однако уверяли, что ситуация наладится. Увы, я был слишком наивен и начал искать новое место лишь спустя два месяца после первых признаков кризиса.
Хочу отметить, что не все стартапы такие. Многие работают честно, создают интересные проекты и открыты перед сотрудниками. Однако мой опыт заставляет быть осторожным.
Опираясь на свой опыт и наблюдения моих коллег, я бы хотел выделить следующие плюсы работы в стартапе:
Подработка. Стартап может быть отличным вариантом, если вы ищете дополнительный доход, особенно при формате 0.5 ставки или работы через ИП.
Рост. Участие в стартапе ускоряет профессиональное развитие. Из-за ограниченных ресурсов вы осваиваете новые навыки и роли.
Значимость. В стартапе каждый сотрудник играет ключевую роль, чего не всегда можно сказать о корпорациях.
Доля в компании. Возможность получить опцион или бонусы за вклад в развитие продукта.
Свобода. Меньше корпоративных ограничений, например, связанных с географией работы.
НО есть и минусы:
Отсутствие корпоративных бонусов. Обычно нет ДМС, оплачиваемого оборудования или других стандартных "плюшек".
Риски с оплатой труда. Возможны задержки, сокращения или даже отсутствие зарплаты.
Риск банкротства. Стартап может закрыться в любой момент, а сотрудники останутся без компенсаций.
Сложности с менеджментом. Часто в стартапах не хватает структурированного управления, что приводит к хаосу.
Большая нагрузка. Вам придётся совмещать несколько ролей, что ведёт к выгоранию.
Как вам мои выводы? Пишите свое мнение и делитесь своим опытом в комментариях.