GitHub Copilot исправит баги в твоём API

Продолжаю исследовать возможности AI-ассистентов написания кода. Ранее на эту тему были
— пост про ожидания и реальность от использования Codeium в реальной кодовой базе
— видео с добавлением новой фичи с помощью GitHub Copilot в большую кодовую базу (😉 YouTube, 😄 ВКонтакте)

А на прошлой неделе GitHub Copilot удивил меня тем, что обнаружил баг в API класса, который я написал. Сегодня хочу об этом рассказать.

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

class RingBufferAllocator {
public:
  explicit RingBufferAllocator(std::span<char> arena);

  struct Iterator { ... }; // Абстрагирует переход через край буфера

  std::optional<Range<Iterator>> Allocate(size_t bytes);
  void Deallocate(Range<Iterator> range);
};

Метод Allocate возвращает пару итераторов либо std::nullopt, если в буфере недостаточно места. И мне показалось логичным в Deallocate передавать тот Range, который вернулся из Allocate.

После этого я стал писать тесты на RingBufferAllocator и попросил Copilot сделать это за меня. Первый же его тест выявил ошибку в моём API:

TEST(RingBufferAllocatorTest, AllocateAndDeallocate) {
  std::array<char, 16> arena;  // Example arena with 16 bytes
  RingBufferAllocator allocator(arena);

  // Allocate 8 bytes
  auto range1 = allocator.Allocate(8);
  ASSERT_TRUE(range1.has_value());
  EXPECT_EQ(range1.value().size(), 8);

  // Allocate 4 bytes, total 12 bytes allocated
  auto range2 = allocator.Allocate(4);
  ASSERT_TRUE(range2.has_value());
  EXPECT_EQ(range2.value().size(), 4);
  
  allocator.Deallocate(*range2); // <--- OOPS. THE BUG IS HERE

  auto range3 = allocator.Allocate(8);
  ASSERT_TRUE(range3.has_value());
  EXPECT_EQ(range3.value().size(), 8);
}

Ошибка в том, что мой API позволял освобождать память не только с "начала" буфера, но и внутри. А это противоречит идее кольцевого буфера. Заметив это, я поменял API вот так:

class RingBufferAllocator {
public:
  explicit RingBufferAllocator(std::span<char> arena);

  struct Iterator { ... };

  // Tries to allocate from the end of the ring buffer
  std::optional<Range<Iterator>> Allocate(size_t bytes);
  // Deallocates the first `bytes` bytes from the beginning of the ring buffer
  void Deallocate(size_t bytes);
};

Теперь Deallocate тоже принимает количество байт и освобождает их только с "начала" буфера.

Прелесть этой истории в том, что Copilot помог мне найти ошибку почти сразу после её допущения и не дать плохому API расползтись по коду 💪

В следующем посте расскажу ещё одну историю, как мне неожиданно помог Copilot. А сейчас поделитесь, какую пользу от AI-ассистентов написания кода извлекаете вы.

А как это на самом деле?

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

Вокруг нас, с одной стороны, много маркетинга, который рассказывает о безоблачной жизни сотрудников бигтехов 😎, а с другой стороны — много слухов и разговоров, в какую соковыжималку превратились IT-компании 🤕. Я же стараюсь рассказывать реальные истории со всеми их яркими и грязными сторонами.

Следуя этой миссии, сегодня делюсь, как мой хороший друг, не меняя работу, вырастил доход на 30%, имея уже высокую зарплату.

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

Посмотрите наше интервью и пишите в комментариях, что ценного для себя вынесли
— 😉 YouTube
— 😄 ВКонтакте

Думал, C++ — всё, что нужно. Ошибался!

В последний год я очень много сил вкладываю в проект «Выше вилки». Это тренинг по переговорам о зарплате для айтишников.

Расскажу, почему я, разработчик, занялся soft skill'ами и ради чего развиваю этот проект.

Какие переговоры за деньги, Илья? Просто качай hard'ы

Многие годы я думал именно так 👆 Я был уверен, что достаточно расти как разработчику: изучать технологии, глубже постигать C++ и т.д. А об остальном позаботится компания: вовремя даст мне проект на вырост, повысит зарплату, чтобы я не нуждался в деньгах, укажет, что мне надо изучить для следующего шага вперёд. И знаете... Лет 5 у меня так и работало 😉 Но потом это розовое представление о карьере перестало совпадать с реальностью.

И что у тебя пошло не так?

Всё чаще я стал слышать, что «надо больше перформить». Я пытался выяснить, а что это значит? Как понять, сколько я перформлю сейчас и «больше» — это сколько? Ответы на эти вопросы я не получал.

Как-то раз на объявлении результатов performance review руководитель сказал мне: «Илья, в этом полугодии ты прям много наперформил, поэтому у тебя повышенная оценка». А я оборачиваюсь назад и понимаю, что работал так же как и в предыдущем полугодии, и не понимаю, почему сейчас больше, а тогда было меньше. И руководитель, конечно, не может внятно объяснить разницу.

Илья, ты разобрался, в чём дело?

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

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

И что дальше?

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

Следуя советам для начинающих предпринимателей, я начал с очень узкой темы — переговоров о зарплате. Я на своём опыте знаю, как тяжело многим айтишникам обсуждать деньги. Сразу всплывает много стыда, вины, тревоги 😱 В комнату врывается самозванец со своим «Ты ещё не знаешь досконально C++23! За что тебе больше платить-то?»

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

И что у вас есть сейчас?

Проекту «Выше вилки» уже больше года. За это время мы провели 14 тренингов. Мы начинали с однодневного 4-часового тренинга. Сейчас — это 10 дней, на протяжении которых мы проводим 4 зум-созвона: 2 посвящены переговорам за оффер, 2 — переговорам с руководством о повышении зарплаты без смены работы. Между созвонами даём домашние задания, а также время на отдых.

За год через тренинг прошло более 40 человек: разработчики, аналитики, лиды, дизайнеры, data scientists и т.д. Многие по итогам получили желаемые повышения.

Что ещё планируешь делать?

Моя цель — набор продуктов, которые учат эффективно справляться с самыми частыми ситуациям в IT. Наряду с флагманским продуктом «Выше вилки» есть ещё два:
— тренинг «Нет» — по эффективным и экологичным отказам
— онлайн-курс «Зарплатная эволюция» — если вы не хотите тренировать переговоры, но желаете изучить теорию

А как узнать побольше?

Всё про тренинг «Выше вилки» можно узнать на его сайте. Ещё в среду в специальном телеграм канале я проведу эфир «Как зарабатывать больше без переработок». Буду рассказывать в том числе и про тренинг. Приходите ✌️

Подводя итог, хочу сказать, что с определённого этапа карьеры коммуникация с другими людьми начинает играть определяющую роль в вашем успехе. Это навыки, которые вы осваиваете 1 раз, а используете потом всю жизнь. Я вношу в это вклад.

Почему ты хочешь быть тимлидом?

На эфире проекта «Выше вилки», о котором я рассказывал в предыдущем посте, участник попросил помочь ему выстроить тактику переговоров с руководством, чтобы перейти из разработчика в тимлиды.

Естественно, нашим первым вопросом было — «А почему ты хочешь стать тимлидом?» 🧐 Участник выдал только одну причину — больше денег 💰 Дальше мы с ним ушли в разговор о том, что помимо «из сильного разработчика превратиться в так себе менеджера» есть другие способы получить больше денег, при этом оставаясь в зоне своих компетенций.

Это напомнило мне мой доклад 2022 года «Зачем мне быть CTO?» на конференции SouthHub. В IT и правда бытует мнение, что с определённого момента быть «просто сеньором» уже как-то некруто, и надо обязательно идти в тимлиды и дальше по менеджерской ветке.

Всё же, когда вы идёте в тимлиды, важно, чтобы на вопрос «зачем?» звучали слова «больше ответственности», «вносить больший вклад», «реализовать больше своих идей», «помочь развиваться другим» и т.д. Тогда в этом есть смысл. Состояние «больше денег» 🤑 или «стать круче» 💪 точно можно достичь, оставаясь не простым, а крутым сеньором. Об этом я и рассказывал на SouthHub, и за 2 года доклад не потерял актуальности.

Приглашаю вас к просмотру 😉