Секрет хорошего дизайна, о котором знают все гиганты в IT [2/2]
Итак, Tech Design Review. Что за ним скрывается?
Процесс будет описан так, как это принято в Авито. В других компаниях он может отличаться, так как компании выстраивают внутренние процессы под себя, исходя из практического опыта. Полное описание процесса-TDR читайте в плейбуке.
Представьте, что сделали пул-реквест (или мердж-реквест) в сервис. Но вместо кода с новой фичей или багфиксом у вас документ, где описано решение какой-либо технической проблемы, которое затрагивает сразу несколько доменов и потенциально влияет на весь продукт и другие команды. Ревьюеры смотрят код, оставляют комментарии...
В TDR механика абсолютно такая же, а весь процесс состоит из следующих этапов:
0️⃣ Обозначаем проблему
TDR не возникает на пустом месте: существует проблема, которую важно решить. Формируем ее. Важно уделить данному этапу должное внимание, чтобы будущие ревьюеры документа поняли необходимость вашего решения.
1️⃣ Находим решение
Когда проблема обозначена, приступаем к решению. На этом этапе происходит основная исследовательская работа: рисуется верхнеуровневая архитектура с зависимостями, считается нагрузка на сервис, потребление ресурсов и прочее. Здесь уже все зависит от задачи, но по результату у вас должно получиться решение обязательно сопровождаемое артефактами, чтобы можно было бы наглядно погрузиться в контекст.
2️⃣ Собираем вместе
Настало время собрать все воедино. Удобно, когда есть специальный инструмент для этого, предоставляющий шаблон с основными полями. Но, если инструмента нет, то просто собираем по секциям то, что делали раньше:
проблема <=> описание решения <=> схема зависимостей <=> компромиссы <=> альтернативы <=> FAQ <=> нагрузка и расчеты <=> ресурсы <=> структура баз данных <=> метрики
Структура выше хорошо ложится на создание нового сервиса. Для прочих решений могут подойти другие шаблоны.
Фактически общая формула такая:
проблема -> решение -> обоснование
3️⃣ Отдаем в ревью
На этом этапе у нас есть оформленная версия документа (v1.0). Выбираем экспертов, в домене которых будет происходить новая разработка. Чтобы найти экспертов можно задать 2 вопроса: "Кто владелец сервиса, на которое будет оказано влияние?" и "Кому потенциально наше решение облегчит или затруднит жизнь?".
Эксперты выбраны. Отправляем на согласование и ждем.
4️⃣ Ревью
Собирается обратная связь от экспертов, автор документа отвечает на вопросы. На этом этапе эксперты должны поставить свою оценку (флаг):
🟢 - вопросов нет
🟡 - есть неблокирующие вопросы, можно начинать разработку
🔴 - такое решение нельзя запускать в прод
По результатам возможны ситуации: документ согласован, документ отправлен на доработку (фактически мы отправляемся к пункту 2 и прорабатываем возникшие вопросы, затем все повторяется) и документ отменен как невозможный к реализации с текущим решением или обоснованием.
5️⃣ Завершение
В зависимости от статуса на предыдущем шаге возможны варианты, но, если все хорошо, то можно постепенно планировать будущую разработку и приступать к реализации.
Важно отметить, что согласование TDR проводится полностью в асинхронном формате. Это быстро и удобно для всех. Конечно, при необходимости можно организовать встречу, чтобы решить спорные моменты, но это скорее исключение. С таким форматом согласен и Microsoft загляните к ним в плейбук, чтобы узнать подробнее.
Если будете углубляться в тему, то можете столкнуться с ADR (Architecture decision record) - это тоже важный документ, но представляет собой другой процесс и лучше мы рассмотрим его отдельно.
К слову, сейчас нахожусь на этапе ревью собственного TDR в компании. Уже есть интересные инсайты, которыми хочется поделиться.
Но это позже, а пока продолжаем работать.
Итак, Tech Design Review. Что за ним скрывается?
Процесс будет описан так, как это принято в Авито. В других компаниях он может отличаться, так как компании выстраивают внутренние процессы под себя, исходя из практического опыта. Полное описание процесса-TDR читайте в плейбуке.
Представьте, что сделали пул-реквест (или мердж-реквест) в сервис. Но вместо кода с новой фичей или багфиксом у вас документ, где описано решение какой-либо технической проблемы, которое затрагивает сразу несколько доменов и потенциально влияет на весь продукт и другие команды. Ревьюеры смотрят код, оставляют комментарии...
В TDR механика абсолютно такая же, а весь процесс состоит из следующих этапов:
0️⃣ Обозначаем проблему
TDR не возникает на пустом месте: существует проблема, которую важно решить. Формируем ее. Важно уделить данному этапу должное внимание, чтобы будущие ревьюеры документа поняли необходимость вашего решения.
1️⃣ Находим решение
Когда проблема обозначена, приступаем к решению. На этом этапе происходит основная исследовательская работа: рисуется верхнеуровневая архитектура с зависимостями, считается нагрузка на сервис, потребление ресурсов и прочее. Здесь уже все зависит от задачи, но по результату у вас должно получиться решение обязательно сопровождаемое артефактами, чтобы можно было бы наглядно погрузиться в контекст.
2️⃣ Собираем вместе
Настало время собрать все воедино. Удобно, когда есть специальный инструмент для этого, предоставляющий шаблон с основными полями. Но, если инструмента нет, то просто собираем по секциям то, что делали раньше:
проблема <=> описание решения <=> схема зависимостей <=> компромиссы <=> альтернативы <=> FAQ <=> нагрузка и расчеты <=> ресурсы <=> структура баз данных <=> метрики
Структура выше хорошо ложится на создание нового сервиса. Для прочих решений могут подойти другие шаблоны.
Фактически общая формула такая:
проблема -> решение -> обоснование
3️⃣ Отдаем в ревью
На этом этапе у нас есть оформленная версия документа (v1.0). Выбираем экспертов, в домене которых будет происходить новая разработка. Чтобы найти экспертов можно задать 2 вопроса: "Кто владелец сервиса, на которое будет оказано влияние?" и "Кому потенциально наше решение облегчит или затруднит жизнь?".
Эксперты выбраны. Отправляем на согласование и ждем.
4️⃣ Ревью
Собирается обратная связь от экспертов, автор документа отвечает на вопросы. На этом этапе эксперты должны поставить свою оценку (флаг):
🟢 - вопросов нет
🟡 - есть неблокирующие вопросы, можно начинать разработку
🔴 - такое решение нельзя запускать в прод
По результатам возможны ситуации: документ согласован, документ отправлен на доработку (фактически мы отправляемся к пункту 2 и прорабатываем возникшие вопросы, затем все повторяется) и документ отменен как невозможный к реализации с текущим решением или обоснованием.
5️⃣ Завершение
В зависимости от статуса на предыдущем шаге возможны варианты, но, если все хорошо, то можно постепенно планировать будущую разработку и приступать к реализации.
Важно отметить, что согласование TDR проводится полностью в асинхронном формате. Это быстро и удобно для всех. Конечно, при необходимости можно организовать встречу, чтобы решить спорные моменты, но это скорее исключение. С таким форматом согласен и Microsoft загляните к ним в плейбук, чтобы узнать подробнее.
Если будете углубляться в тему, то можете столкнуться с ADR (Architecture decision record) - это тоже важный документ, но представляет собой другой процесс и лучше мы рассмотрим его отдельно.
К слову, сейчас нахожусь на этапе ревью собственного TDR в компании. Уже есть интересные инсайты, которыми хочется поделиться.
Но это позже, а пока продолжаем работать.
👍3
Июнь 2024:
навыки
✔️ Завершил больше половины курса по анализу систем, выполнил 4/5 всех заданий курса. Улучшил экспертизу в областях: работа с требованиями и внешними ограничениями, выделение основных частей системы при помощи Event Storming, выбор архитектурного стиля в зависимости от характеристик и пр. Ход мыслей и выполнение заданий можно посмотреть здесь.
✔️ Прошел тренинг по управлению рисками. Запомнить: важно развивать вероятностное мышление, прорабатывать возможные сценарии и помнить, что наступление любого события всегда меньше единицы.
✔️ Зарефакторил старый проект. Полезная мысль: при рефакторинге и код-ревью в первую очередь обращаем внимание на то, как код влияет на остальную часть проекта, как с ним взаимодействует.
✔️ Продолжаю практиковаться в ООАП. Переосмыслил разницу между классами анализа и дизайна (отличный мог бы выйти пост в будущем, а кому интересно копнуть уже сейчас, может начать со статьи).
карьера
✔️ Перенял роль платформенного эксперта в своей вертикали (за несколько лет накопилось немало экспертизы в одном домене, которой могу делиться с коллегами и разгружать горизонтальную команду).
✔️ Написал свой первый TDR в компании. Утвержденный документ + последующая успешная реализация проекта = хорошая основа для будущего промо на следующий грейд, но, конечно, это не гарантия, а лишь один из кирпичиков.
✔️ Подготовился к перф-ревью, собрав все артефакты за полгода работы. По окончании июльского ревью подробнее поговорим о процессе и как к нему лучше готовиться, чтобы он прошел без боли.
посты
✔️ Как сделать продакшн стабильнее и что такое LSR (читать)
✔️ Моделирование угроз - инструмент для обеспечения безопасности ваших фичей (читать)
✔️ Кому нужно изучать проектирование систем и как к этому подступиться (читать)
✔️ Секрет хорошего дизайна и при чем здесь TDR и ADR (читать)
прочее
✔️ Поучаствовал в 2-х массовых забегах: на 7.195 км и 10 км. Кажется бег начинает входить в привычку. Важно к интеллектуальной активности добавлять любую физическую - они хорошо дружат, а вы сможете делать больше.
#результаты
навыки
✔️ Завершил больше половины курса по анализу систем, выполнил 4/5 всех заданий курса. Улучшил экспертизу в областях: работа с требованиями и внешними ограничениями, выделение основных частей системы при помощи Event Storming, выбор архитектурного стиля в зависимости от характеристик и пр. Ход мыслей и выполнение заданий можно посмотреть здесь.
✔️ Прошел тренинг по управлению рисками. Запомнить: важно развивать вероятностное мышление, прорабатывать возможные сценарии и помнить, что наступление любого события всегда меньше единицы.
✔️ Зарефакторил старый проект. Полезная мысль: при рефакторинге и код-ревью в первую очередь обращаем внимание на то, как код влияет на остальную часть проекта, как с ним взаимодействует.
✔️ Продолжаю практиковаться в ООАП. Переосмыслил разницу между классами анализа и дизайна (отличный мог бы выйти пост в будущем, а кому интересно копнуть уже сейчас, может начать со статьи).
карьера
✔️ Перенял роль платформенного эксперта в своей вертикали (за несколько лет накопилось немало экспертизы в одном домене, которой могу делиться с коллегами и разгружать горизонтальную команду).
✔️ Написал свой первый TDR в компании. Утвержденный документ + последующая успешная реализация проекта = хорошая основа для будущего промо на следующий грейд, но, конечно, это не гарантия, а лишь один из кирпичиков.
✔️ Подготовился к перф-ревью, собрав все артефакты за полгода работы. По окончании июльского ревью подробнее поговорим о процессе и как к нему лучше готовиться, чтобы он прошел без боли.
посты
✔️ Как сделать продакшн стабильнее и что такое LSR (читать)
✔️ Моделирование угроз - инструмент для обеспечения безопасности ваших фичей (читать)
✔️ Кому нужно изучать проектирование систем и как к этому подступиться (читать)
✔️ Секрет хорошего дизайна и при чем здесь TDR и ADR (читать)
прочее
✔️ Поучаствовал в 2-х массовых забегах: на 7.195 км и 10 км. Кажется бег начинает входить в привычку. Важно к интеллектуальной активности добавлять любую физическую - они хорошо дружат, а вы сможете делать больше.
#результаты
🔥2👍1
Google ворует имена
17 марта 2003 года вышла статья "Go! – A Logic Programming Language for
Implementing Multi-threaded Agents" (авторы: K.L. Clark и F.G. McCabe).
Был представлен новый мультипарадигменный язык "Go!", над которым велась работа на протяжении 10 лет.
Однако, большой популярности он не снискал. Язык довольно нишевый и преимущественно предназначен для академических целей и научных проектов.
Спустя 6 лет осенью 2009 Google представляет свой язык с одноименным названием за исключением пунктуации.
Авторы Go! почти сразу завели issue #9, где просили сменить название, так как такой язык уже существовал, но все тщетно.
Считаю, что про такие моменты важно знать в своей предметной области.
Вот так выглядит, например, «Hello World!» на Go!
А вот здесь можно прочитать про него краткую сводку.
Этично ли поступил Google? Или это просто бизнес и ничего личного?
17 марта 2003 года вышла статья "Go! – A Logic Programming Language for
Implementing Multi-threaded Agents" (авторы: K.L. Clark и F.G. McCabe).
Был представлен новый мультипарадигменный язык "Go!", над которым велась работа на протяжении 10 лет.
Однако, большой популярности он не снискал. Язык довольно нишевый и преимущественно предназначен для академических целей и научных проектов.
Спустя 6 лет осенью 2009 Google представляет свой язык с одноименным названием за исключением пунктуации.
Авторы Go! почти сразу завели issue #9, где просили сменить название, так как такой язык уже существовал, но все тщетно.
Считаю, что про такие моменты важно знать в своей предметной области.
Вот так выглядит, например, «Hello World!» на Go!
MODULE hello.
IMPORT standardio.
PREDICATE main.
main :-
standardio:write("Hello, World!").
А вот здесь можно прочитать про него краткую сводку.
Этично ли поступил Google? Или это просто бизнес и ничего личного?
👍3
Однажды Хемингуэй поспорил, что сможет написать самый короткий рассказ, способный напугать любого…
Он выиграл спор:Performance Review
Разберемся что это такое, почему наступает неожиданно и можно ли что-то с этим сделать?
Если кратко, то это процесс подведения итогов работы за определенный период. Подробнее можно найти здесь.
Наличие такого процесса говорит об определенном уровне зрелости компании, но он должен работать правильно, чтобы не доставлять вам хлопот(ведь вы пришли код писать, а не отчеты для менеджеров) .
Всегда стараюсь изучать как это устроено у лидеров индустрии. Но в этот раз задача оказалась непростой, MAANG-компаний не любят открыто делиться тем, что работает, но кое-что найти все-таки удалось.
Раньше, по утверждениям источников, процесс в Google выглядел в точности как и в Авито, но с небольшими изменениями.
Рассмотрим основные этапы.
Google Performance Review
В год происходит 2 ревью: превью по окончании первого семестра и полное ревью между октябрем и ноябрем. На полном ревью добавляется оценка по методу 360, на котором коллеги дают обратную связь друг другу и оценивают качество взаимодействия.
Разберем подробно полный процесс ревью.
1. Период самооценки
Это фактически отчет о своих достижениях за прошедший период. Метрики и привязки к ОКРам обязательны, иначе зачем все это, если не приносит бизнесу результат?
Самое пикантное, что все достижения нужно уложить в текстовое поле размером 512 символов :)
Здесь передаю привет своим коллегам, с которыми мы страдаем, тщетно пытаясь ужаться, но уже в более приятную цифру - 800.
2. Период оценки 360 (отсутствует на превью)
На этом этапе коллеги (которых ты пригласишь в ревью) оценят качество взаимодействия с тобой: что понравилось в работе, а что можно улучшить. Ты, в свою очередь, также даешь оценку коллегам и пишешь обратную связь.
3. Период калибровок
Когда все отчеты написаны, менеджеры выставляют драфтовые оценки своим подчиненным. Затем на общей встрече менеджеров драфтовая оценка калибруется (=выравнивается), чтобы сотрудник получил справедливый отзыв о своей работе.
4. Обсуждение результатов
На этом этапе вы обсуждаете со своим руководителем итоги процесса, составляете план развития, обмениваетесь обратной связью.
В Авито процесс устроен аналогично, только у нас нет превью, а есть 2 полноценных перформанс ревью.
Здесь можно посмотреть кратко как процесс устроен в другом Биг Техе: Meta, Apple, Amazon, Netflix.
Из этой же статьи мы узнаем, что Google в 2022 году сменил свой старый процесс на Googler Reviews and Development (GRAD). Самое главное нововведение - работа с ожиданиями и фокус на саморазвитии с построением карьеры в компании.
У Performance Review есть очень неприятное свойство: он наступает неожиданно и обычно застает тебя врасплох. Механика такая же как у лета: вот был первый день - момент - и вот мы уже перешагнули половину и движемся к завершению...
На неделе у меня заканчивается очередной период перформанс ревью. И каким бы нелюбимым для многих он не был, я вижу в нем больше преимуществ, чем недостатков.
Как с комфортом подойти к этому процессу, чтобы извлечь максимальную пользу и не тратить много времени на прохождение, напишу в продолжении.
Он выиграл спор:
Разберемся что это такое, почему наступает неожиданно и можно ли что-то с этим сделать?
Если кратко, то это процесс подведения итогов работы за определенный период. Подробнее можно найти здесь.
Наличие такого процесса говорит об определенном уровне зрелости компании, но он должен работать правильно, чтобы не доставлять вам хлопот
Всегда стараюсь изучать как это устроено у лидеров индустрии. Но в этот раз задача оказалась непростой, MAANG-компаний не любят открыто делиться тем, что работает, но кое-что найти все-таки удалось.
Раньше, по утверждениям источников, процесс в Google выглядел в точности как и в Авито, но с небольшими изменениями.
Рассмотрим основные этапы.
Google Performance Review
В год происходит 2 ревью: превью по окончании первого семестра и полное ревью между октябрем и ноябрем. На полном ревью добавляется оценка по методу 360, на котором коллеги дают обратную связь друг другу и оценивают качество взаимодействия.
Разберем подробно полный процесс ревью.
1. Период самооценки
Это фактически отчет о своих достижениях за прошедший период. Метрики и привязки к ОКРам обязательны, иначе зачем все это, если не приносит бизнесу результат?
Самое пикантное, что все достижения нужно уложить в текстовое поле размером 512 символов :)
Здесь передаю привет своим коллегам, с которыми мы страдаем, тщетно пытаясь ужаться, но уже в более приятную цифру - 800.
2. Период оценки 360 (отсутствует на превью)
На этом этапе коллеги (которых ты пригласишь в ревью) оценят качество взаимодействия с тобой: что понравилось в работе, а что можно улучшить. Ты, в свою очередь, также даешь оценку коллегам и пишешь обратную связь.
3. Период калибровок
Когда все отчеты написаны, менеджеры выставляют драфтовые оценки своим подчиненным. Затем на общей встрече менеджеров драфтовая оценка калибруется (=выравнивается), чтобы сотрудник получил справедливый отзыв о своей работе.
4. Обсуждение результатов
На этом этапе вы обсуждаете со своим руководителем итоги процесса, составляете план развития, обмениваетесь обратной связью.
В Авито процесс устроен аналогично, только у нас нет превью, а есть 2 полноценных перформанс ревью.
Здесь можно посмотреть кратко как процесс устроен в другом Биг Техе: Meta, Apple, Amazon, Netflix.
Из этой же статьи мы узнаем, что Google в 2022 году сменил свой старый процесс на Googler Reviews and Development (GRAD). Самое главное нововведение - работа с ожиданиями и фокус на саморазвитии с построением карьеры в компании.
У Performance Review есть очень неприятное свойство: он наступает неожиданно и обычно застает тебя врасплох. Механика такая же как у лета: вот был первый день - момент - и вот мы уже перешагнули половину и движемся к завершению...
На неделе у меня заканчивается очередной период перформанс ревью. И каким бы нелюбимым для многих он не был, я вижу в нем больше преимуществ, чем недостатков.
Как с комфортом подойти к этому процессу, чтобы извлечь максимальную пользу и не тратить много времени на прохождение, напишу в продолжении.
👍3🔥1
Подчиняем performance review
В текущей компании прошедшее ревью для меня стало четвертым, а самыми сложными были первые два, когда еще не до конца знаком с процессом и не понимаешь чего именно от тебя ожидают.
Что мне помогает и почему я уже начал готовиться к следующему?
Свой опыт я решил сгруппировать по периодам, которые можно рассматривать отдельно на каждом из этапов ревью.
1️⃣ Готовимся
период: окончание перф. ревью -> начало следующего перф. ревью
- ) Оставляйте цифровой след. Это могут быть любые артефакты: пост с договоренностями после встречи, тред с активным обсуждением, комментарий в Jira с результатами ресерча. Когда сядете за написание очередного ревью, обязательно скажете вчерашнему себе спасибо.
- ) Сохраняйте ссылки на артефакты. Сделайте себе единую точку входа, например, в заметках. Идеальным случаем не сваливать все в кучу, а сортировать по проектам/инициативам. Так у вас будет фактически готовый шаблон для будущего ревью, останется только обогатить контекстом и добавить цифр.
Я использую Obsidian, но подойдет что угодно. Даже простой список с перечислением и небольшими комментариями лучше, чем ничего.
Этому сложно следовать, так как думаете, что потом сможете все найти поиском по мессенджеру, но, во первых, очень легко через полгода забыть что вообще делали, а во вторых, сильно сэкономите себе время.
- ) Постоянно сверяйтесь с планом своего развития. Задавайте вопросы: Туда ли вы движетесь? Приближает ли выполнение ежедневных задач к цели? Можете ли выйти за рамки своей ответственности, делая какую-то задачу и будет ли кому-то еще это полезно?
Если понимаете, что сбились с пути и увязли в рутине, то обязательно обсудите с руководителем предмет беспокойства. Вместе вы сможете найти решение, но лучше всего - если самостоятельно предложите возможное, которое затем подкорректируете.
2️⃣ Пишем
период: начало перф. ревью -> окончание периода оценки коллег
- ) Если все время вели структурированные заметки, то все, что вам нужно: достать командные цели на прошедшие кварталы и соотнести их со своими артефактами (предполагаем, что руководитель и продакт позаботились о том, чтобы выполняемые вами задачи соотносились с роадмапом команды и приносили результат бизнесу).
Работая в продуктовой команде, нам нужны сухие цифры о выполнении ОКР'ов и, например, аналитика по окончании экспериментов. В команде инфраструктуры, очевидно, у вас будут другие метрики результата, но смысл один.
Формула следующая:
<цель/окр/инициатива/проект> + <ваш вклад: сервис/фича/документация> = <метрики результата>
- ) Используйте поиск по таск-трекинговой системе. В Jira, например, можно фильтровать свои таски за прошедший период, используя JQL.
(5 реакций и дам готовый фильтр на JQL, который использую)
- ) Если для написания ревью используете корпоративный инструмент, то лучше чаще делайте бэкап локально (в заметки). Нет ничего обиднее, чем потерять уже написанный документ.
- ) Вычитка финального ревью обязательна!
3️⃣ Анализируем
период: окончание периода оценки коллег -> окончание перф. ревью
- ) Обращаем внимание на ОС от руководителя и коллег, что было хорошо, а что можно улучшить. Делаем на это упор в следующем периоде.
- ) Самый важный вопрос: "Куда мы хотим прийти через 6 месяцев?". Ответ напрямую влияет на будущую работу. Важно понимать, что для перехода на следующий грейд требуются совершенно другие акценты, нежели чем классическая работа на "хороший" результат.
Обозначьте цель и следуйте к ней. Если это - промо, то обсудите с тимлидом заранее и уже начинайте над этим работать.
> > >
Описал, что работает для меня. Если в вашей компании есть похожая практика и у вас этот процесс связан с неприятными эмоциями, то попробуйте описанный выше алгоритм, а потом поделитесь фидбеком. Скорее всего, вы что-то оптимизируете под себя, универсального решения нет.
Какой у вас «секрет» написания ревью или вы счастливо живете без него?
P.S.: Я показал процесс со стороны инженера. У руководителя все гораздо "интереснее".
Пусть результат вашей работы превзойдет все мыслимые ожидания менеджеров!
В текущей компании прошедшее ревью для меня стало четвертым, а самыми сложными были первые два, когда еще не до конца знаком с процессом и не понимаешь чего именно от тебя ожидают.
Что мне помогает и почему я уже начал готовиться к следующему?
Свой опыт я решил сгруппировать по периодам, которые можно рассматривать отдельно на каждом из этапов ревью.
1️⃣ Готовимся
период: окончание перф. ревью -> начало следующего перф. ревью
- ) Оставляйте цифровой след. Это могут быть любые артефакты: пост с договоренностями после встречи, тред с активным обсуждением, комментарий в Jira с результатами ресерча. Когда сядете за написание очередного ревью, обязательно скажете вчерашнему себе спасибо.
- ) Сохраняйте ссылки на артефакты. Сделайте себе единую точку входа, например, в заметках. Идеальным случаем не сваливать все в кучу, а сортировать по проектам/инициативам. Так у вас будет фактически готовый шаблон для будущего ревью, останется только обогатить контекстом и добавить цифр.
Я использую Obsidian, но подойдет что угодно. Даже простой список с перечислением и небольшими комментариями лучше, чем ничего.
Этому сложно следовать, так как думаете, что потом сможете все найти поиском по мессенджеру, но, во первых, очень легко через полгода забыть что вообще делали, а во вторых, сильно сэкономите себе время.
- ) Постоянно сверяйтесь с планом своего развития. Задавайте вопросы: Туда ли вы движетесь? Приближает ли выполнение ежедневных задач к цели? Можете ли выйти за рамки своей ответственности, делая какую-то задачу и будет ли кому-то еще это полезно?
Если понимаете, что сбились с пути и увязли в рутине, то обязательно обсудите с руководителем предмет беспокойства. Вместе вы сможете найти решение, но лучше всего - если самостоятельно предложите возможное, которое затем подкорректируете.
2️⃣ Пишем
период: начало перф. ревью -> окончание периода оценки коллег
- ) Если все время вели структурированные заметки, то все, что вам нужно: достать командные цели на прошедшие кварталы и соотнести их со своими артефактами (предполагаем, что руководитель и продакт позаботились о том, чтобы выполняемые вами задачи соотносились с роадмапом команды и приносили результат бизнесу).
Работая в продуктовой команде, нам нужны сухие цифры о выполнении ОКР'ов и, например, аналитика по окончании экспериментов. В команде инфраструктуры, очевидно, у вас будут другие метрики результата, но смысл один.
Формула следующая:
<цель/окр/инициатива/проект> + <ваш вклад: сервис/фича/документация> = <метрики результата>
- ) Используйте поиск по таск-трекинговой системе. В Jira, например, можно фильтровать свои таски за прошедший период, используя JQL.
(5 реакций и дам готовый фильтр на JQL, который использую)
- ) Если для написания ревью используете корпоративный инструмент, то лучше чаще делайте бэкап локально (в заметки). Нет ничего обиднее, чем потерять уже написанный документ.
- ) Вычитка финального ревью обязательна!
3️⃣ Анализируем
период: окончание периода оценки коллег -> окончание перф. ревью
- ) Обращаем внимание на ОС от руководителя и коллег, что было хорошо, а что можно улучшить. Делаем на это упор в следующем периоде.
- ) Самый важный вопрос: "Куда мы хотим прийти через 6 месяцев?". Ответ напрямую влияет на будущую работу. Важно понимать, что для перехода на следующий грейд требуются совершенно другие акценты, нежели чем классическая работа на "хороший" результат.
Обозначьте цель и следуйте к ней. Если это - промо, то обсудите с тимлидом заранее и уже начинайте над этим работать.
> > >
Описал, что работает для меня. Если в вашей компании есть похожая практика и у вас этот процесс связан с неприятными эмоциями, то попробуйте описанный выше алгоритм, а потом поделитесь фидбеком. Скорее всего, вы что-то оптимизируете под себя, универсального решения нет.
Какой у вас «секрет» написания ревью или вы счастливо живете без него?
P.S.: Я показал процесс со стороны инженера. У руководителя все гораздо "интереснее".
Пусть результат вашей работы превзойдет все мыслимые ожидания менеджеров!
🔥9
Маленькие шаги - основа вашей эффективности
Здорово разрабатывать сложные системы, но еще очень приятно автоматизировать мелкую рутину.
Один из примеров - поиск выполненных задач за прошедший период для перформанс ревью.
Делюсь готовым JQL-запросом для получения завершенных задач связанных с вами за последние 6 месяцев в Jira, которым пользуюсь регулярно:
Можно настроить фильтр, сохранить в закладки и держать свои выполненные задачи под рукой.
Сами по себе подобные хитрости несут мало практической пользы, но когда вы их встраиваете в работающую для себя систему (подходите системно к перф. ревью, например), то достигается синергетический эффект.
Здорово разрабатывать сложные системы, но еще очень приятно автоматизировать мелкую рутину.
Один из примеров - поиск выполненных задач за прошедший период для перформанс ревью.
Делюсь готовым JQL-запросом для получения завершенных задач связанных с вами за последние 6 месяцев в Jira, которым пользуюсь регулярно:
(created >= startOfDay(-180) OR resolution changed after startOfDay(-180) OR status changed after startOfDay(-180)) AND (reporter = currentUser() OR assignee was currentUser()) ORDER BY resolved ASC, updated ASC
Можно настроить фильтр, сохранить в закладки и держать свои выполненные задачи под рукой.
Сами по себе подобные хитрости несут мало практической пользы, но когда вы их встраиваете в работающую для себя систему (подходите системно к перф. ревью, например), то достигается синергетический эффект.
🔥6
Анализ систем. Финал
Вчера получил сертификат об окончании курса по анализу систем, так как не просто его прослушал, но и выполнил все практические задания (решения выкладывал на github).
Курс мне понравился. Из основных ожиданий было получить инструмент как системно подходить к проектированию любой системы. И такой инструмент у меня теперь есть (EventStorming, стратегический DDD и другие), а также есть понимание ("big picture") всего жизненного цикла разрабатываемой системы с оглядкой на постоянно меняющиеся требования и консерны стейкхолдеров.
Формат курса
Меня поразила уникальность предлагаемого формата по обучению: никаких видеоуроков, только большой текст и работа с обратной связью. Удивительно, но могу заверить, что это лучше всего работает!
Части курса поделены по неделям, на каждой из которых дается лонгрид на 100+- страниц и ДЗ по окончанию модуля. Плюс есть возможность общаться и получать ответы через тг-канал курса у автора (очень быстрая обратная связь). Завершение очередного модуля сопровождается разбором ДЗ в формате вебинара, где обсуждаются самые распространенные ошибки.
Есть также механика проверок работ коллег (peer-to-peer). Такой подход помогает лучше закрепить материал, заставляя примерить на себя роль учителя и помогая взглянуть на решаемое задание совершенно иначе.
На курсе были разные тарифы. Я выбрал тот, который отличается подробной ОС по каждому ДЗ - и это было невероятно полезно. Когда проверял чужие работы, то видел, что автор дает краткий комментарий с пунктами, требующими внимания, но в моем случае все было детально расписано - и такой фидбек был очень ценен.
Рефлексия
В последнем ДЗ предлагалось поделиться рефлексией с оглядкой на свою самую первую систему в курсе. Прикрепляю основную выдержку ниже (полная версия):
Идеи и подходы, которые интересно внедрить в будущем:
- Думать на уровне поддоменов и ограниченных контекстов. Понравилось, что такой подход учит собирать конкретный бизнесовый контекст, вытекающий из требований к системе, в одном месте. Мыслить на уровне поддоменов - выглядит как системный подход к анализу и проектированию любой системы.
- Event Storming обязательно станет одним из постоянных инструментов в моем арсенале. Интересно его попробовать применить в своей команде для проектирования новой системы.
- Не всегда одинаковые по смыслу системы, например, в домене биллинга, должны располагаться в одном микросервисе. Иногда полезно их разделить. Тут важно смотреть на контекст, в котором они существуют. Возможно, он очень специфичный для каждой из систем.
- Характеристики системы определяют архитектурный стиль, а также помогают при распиле монолита.
- Каждое требование важно. Нужно прорабатывать каждый консерн стейкхолдеров и каждый пункт требований еще на моменте анализа.
- При наличии неопределенности в требованиях и любых сомнениях по работе будущей системы - задавайте вопросы.
- Оставляем артефакты принятых решений. В идеале - делать ADR по каждому.
Еще очень понравилась нотация C4, про которую узнал на курсе. Теперь рисую схемы только по ней (использую уровень контейнеров C2). Потихоньку готовлю пост про C4 и про использования DSL для создания схем - полезно для тех, кто устал рисовать и выравнивать стрелки 🤓
Вчера получил сертификат об окончании курса по анализу систем, так как не просто его прослушал, но и выполнил все практические задания (решения выкладывал на github).
Курс мне понравился. Из основных ожиданий было получить инструмент как системно подходить к проектированию любой системы. И такой инструмент у меня теперь есть (EventStorming, стратегический DDD и другие), а также есть понимание ("big picture") всего жизненного цикла разрабатываемой системы с оглядкой на постоянно меняющиеся требования и консерны стейкхолдеров.
Формат курса
Меня поразила уникальность предлагаемого формата по обучению: никаких видеоуроков, только большой текст и работа с обратной связью. Удивительно, но могу заверить, что это лучше всего работает!
Части курса поделены по неделям, на каждой из которых дается лонгрид на 100+- страниц и ДЗ по окончанию модуля. Плюс есть возможность общаться и получать ответы через тг-канал курса у автора (очень быстрая обратная связь). Завершение очередного модуля сопровождается разбором ДЗ в формате вебинара, где обсуждаются самые распространенные ошибки.
Есть также механика проверок работ коллег (peer-to-peer). Такой подход помогает лучше закрепить материал, заставляя примерить на себя роль учителя и помогая взглянуть на решаемое задание совершенно иначе.
На курсе были разные тарифы. Я выбрал тот, который отличается подробной ОС по каждому ДЗ - и это было невероятно полезно. Когда проверял чужие работы, то видел, что автор дает краткий комментарий с пунктами, требующими внимания, но в моем случае все было детально расписано - и такой фидбек был очень ценен.
Рефлексия
В последнем ДЗ предлагалось поделиться рефлексией с оглядкой на свою самую первую систему в курсе. Прикрепляю основную выдержку ниже (полная версия):
Идеи и подходы, которые интересно внедрить в будущем:
- Думать на уровне поддоменов и ограниченных контекстов. Понравилось, что такой подход учит собирать конкретный бизнесовый контекст, вытекающий из требований к системе, в одном месте. Мыслить на уровне поддоменов - выглядит как системный подход к анализу и проектированию любой системы.
- Event Storming обязательно станет одним из постоянных инструментов в моем арсенале. Интересно его попробовать применить в своей команде для проектирования новой системы.
- Не всегда одинаковые по смыслу системы, например, в домене биллинга, должны располагаться в одном микросервисе. Иногда полезно их разделить. Тут важно смотреть на контекст, в котором они существуют. Возможно, он очень специфичный для каждой из систем.
- Характеристики системы определяют архитектурный стиль, а также помогают при распиле монолита.
- Каждое требование важно. Нужно прорабатывать каждый консерн стейкхолдеров и каждый пункт требований еще на моменте анализа.
- При наличии неопределенности в требованиях и любых сомнениях по работе будущей системы - задавайте вопросы.
- Оставляем артефакты принятых решений. В идеале - делать ADR по каждому.
Еще очень понравилась нотация C4, про которую узнал на курсе. Теперь рисую схемы только по ней (использую уровень контейнеров C2). Потихоньку готовлю пост про C4 и про использования DSL для создания схем - полезно для тех, кто устал рисовать и выравнивать стрелки 🤓
🔥7
3 в ряд 🍒🍒🍒
В рамках экспериментального погружения в ООАП написал консольную игру.
Не все удалось реализовать согласно первоначальной задумке, многое упростил. В основном мешало, что уже несколько лет не работаю в ООП-парадигме и на смену C# пришел Go.
Однако очень помогло описание архитектуры, с которого начинал проектирование, то есть формально заставлял себя следовать тому, что я когда-то уже проанализировал и запроектировал. Из интересных открытий: во время анализа отбраковал некоторые классы, которые (как мне казалось) понадобились во время реализации. Но когда написал код, то понял, что все-таки отбраковал их правильно и они на самом деле не нужны.
Крайне важная вещь, про которую не устаю говорить: не стоит смешивать несколько фокусов (в моем случае параллельно шел Анализ систем) и, очевидно, это плохая практика.
Запомнить: время на проектирование и анализ всегда следует тратить больше, тщательнее продумывая взаимодействия между модулями. Это действительно вам поможет на этапе реализации.
В рамках экспериментального погружения в ООАП написал консольную игру.
Не все удалось реализовать согласно первоначальной задумке, многое упростил. В основном мешало, что уже несколько лет не работаю в ООП-парадигме и на смену C# пришел Go.
Однако очень помогло описание архитектуры, с которого начинал проектирование, то есть формально заставлял себя следовать тому, что я когда-то уже проанализировал и запроектировал. Из интересных открытий: во время анализа отбраковал некоторые классы, которые (как мне казалось) понадобились во время реализации. Но когда написал код, то понял, что все-таки отбраковал их правильно и они на самом деле не нужны.
Крайне важная вещь, про которую не устаю говорить: не стоит смешивать несколько фокусов (в моем случае параллельно шел Анализ систем) и, очевидно, это плохая практика.
Запомнить: время на проектирование и анализ всегда следует тратить больше, тщательнее продумывая взаимодействия между модулями. Это действительно вам поможет на этапе реализации.
👍5🔥5❤1
Июль 2024:
навыки
✔️ Завершил курс по анализу систем. Выполнил 5/5 всех заданий курса, проверил 12 работ других студентов и получил финальный сертификат.
✔️ Завершил курс по ООАП и написал консольную игру (3 в ряд). Рефлексия в прошлом посте.
✔️ Попрактиковался в приведении запутанного интерфейса в более выразительный.
карьера
✔️ Получил хороший фидбек по окончании перф-ревью. Коллеги отметили качество коммуникации и проявление инициативы по нашим стримам.
✔️ Написанный TDR по новому сервису породил активную дискуссию, особенно спорным стал выбор БД (NoSQL VS SQL) - документ ушел на второй круг. Цель на ближайший спринт - качественно обработать все комментарии и согласовать финальное решение, чтобы приступить к разработке.
посты
✔️ Как устроен TDR изнутри (Tech Design Review) (читать)
✔️ Чем отличается Go! от Go (читать)
✔️ Performance Review в Big Tech (читать)
✔️ Как готовиться и писать Performance Review (читать)
✔️ Полезный фильтр для ваших задач в Jira (читать)
✔️ Анализ систем. Что унести с собой? (читать)
прочее
✔️ Поучаствовал в двух массовых забегах: на 10 км. Лучший результат - 52:20 (5:14/км). Бег определенно вошел в привычку - помогает хорошо разгрузиться. На сентябрь запланировал полумарафон, надеюсь, хватит времени на подготовку.
#результаты
навыки
✔️ Завершил курс по анализу систем. Выполнил 5/5 всех заданий курса, проверил 12 работ других студентов и получил финальный сертификат.
✔️ Завершил курс по ООАП и написал консольную игру (3 в ряд). Рефлексия в прошлом посте.
✔️ Попрактиковался в приведении запутанного интерфейса в более выразительный.
карьера
✔️ Получил хороший фидбек по окончании перф-ревью. Коллеги отметили качество коммуникации и проявление инициативы по нашим стримам.
✔️ Написанный TDR по новому сервису породил активную дискуссию, особенно спорным стал выбор БД (NoSQL VS SQL) - документ ушел на второй круг. Цель на ближайший спринт - качественно обработать все комментарии и согласовать финальное решение, чтобы приступить к разработке.
посты
✔️ Как устроен TDR изнутри (Tech Design Review) (читать)
✔️ Чем отличается Go! от Go (читать)
✔️ Performance Review в Big Tech (читать)
✔️ Как готовиться и писать Performance Review (читать)
✔️ Полезный фильтр для ваших задач в Jira (читать)
✔️ Анализ систем. Что унести с собой? (читать)
прочее
✔️ Поучаствовал в двух массовых забегах: на 10 км. Лучший результат - 52:20 (5:14/км). Бег определенно вошел в привычку - помогает хорошо разгрузиться. На сентябрь запланировал полумарафон, надеюсь, хватит времени на подготовку.
#результаты
❤9👍1
Что может пойти не так?
Провел первую в команде сессию по моделированию угроз для перспективного сервиса.
Встреча была запланирована на час, но уже на 45-й минуте стало понятно, что на сессию нужно закладывать 1,5-2 часа, чтобы спокойно все продумать и не торопиться.
В итоге сессию разбили на две по одному часу, в ходе которых удалось взглянуть на сервис с разных сторон. Было продумано множество потенциально неприятных сценариев, которые с той или иной вероятностью могли бы случиться. Здорово, что в Биг Техе многие уязвимости закрываются инфраструктурными командами, но все равно их важно проговорить и явно зафиксировать как они будут учитываться.
Внутреннее сообщество компании продвигающее идеологию чемпионов по безопасности и рассказывающее, как проводить моделирование угроз в команде предлагает шаблон, с помощью которого рекомендуется проводить эту сессию. Это большой хост, на котором слева расположена библиотека атак (основные уязвимости для брейншторма), в центре - пространство для схемы проектируемого сервиса; а справа - цветная область, разделенная на три зоны для группировки угроз по статусам: сразу учитываем в разработке, оставляем на будущее, принимаем риски.
Такой фреймворк по моделированию угроз неплох, но есть особенности, на которые важно обращать внимание, иначе можно неэффективно потратить время:
1️⃣ Этот момент нигде явно не зафиксирован (он подразумевается): всю сессию предлагается проводить под девизом "Что может пойти не так?". Но держите постоянно в голове, что вы рассматриваете исключительно уязвимости, то есть потенциальные атаки (их вектор). Если вдруг всплывает идея про какой-либо неучтенный риск, то фиксируйте его рядом и двигайтесь дальше по фреймворку, иначе можно сильно уйти в сторону.
2️⃣ Строго следуем плану. Если используем каталог атак, то план такой: примеряем атаку из каталога на каждый узел своей функциональности -> если проблема вероятна, то располагаем рядом соответствующую карточку -> решаем что делать по каждой из проблем -> определяемся со статусом угроз (зона справа).
3️⃣ Каталог атак или методику, по которой определяем угрозы желательно продумать заранее. Все команды разные и желательно выбирать инструмент, который лучше подойдет вашей команде. У меня после использования предлагаемого каталога атак появилось сильное желание переработать его под свою, например, используя STRIDE, предлагаемый Microsoft.
Еще раз обращаю внимание на п.1. Крайне важно ограничивать рассматриваемый скоуп (область - например, угрозы безопасности).
Легко увлечься и начать обсуждать возможные риски и уязвимости, но бейте себя по рукам - сохраняйте фокус только на угрозах безопасности. Мне, к сожалению, в первый раз не удалось качественно профасилитирировать процесс, поэтому мы быстро уходили в обсуждение всевозможных рисков за пределами основного фокуса.
Оценка рисков (risk assessment) - похожий, но совершенно другой процесс. Он подразумевает более широкий подход применительно ко всем рискам, а не только угрозам безопасности. И у него есть свои инструменты для проведения сессии (матрица рисков, Risk-Based Testing и другие).
Из текущего опыта: сначала проведите оценку рисков, а затем моделируйте угрозы. Это позволить избежать обсуждений нецелевых рисков и сфокусироваться на безопасности.
#безопасность
Провел первую в команде сессию по моделированию угроз для перспективного сервиса.
Встреча была запланирована на час, но уже на 45-й минуте стало понятно, что на сессию нужно закладывать 1,5-2 часа, чтобы спокойно все продумать и не торопиться.
В итоге сессию разбили на две по одному часу, в ходе которых удалось взглянуть на сервис с разных сторон. Было продумано множество потенциально неприятных сценариев, которые с той или иной вероятностью могли бы случиться. Здорово, что в Биг Техе многие уязвимости закрываются инфраструктурными командами, но все равно их важно проговорить и явно зафиксировать как они будут учитываться.
Внутреннее сообщество компании продвигающее идеологию чемпионов по безопасности и рассказывающее, как проводить моделирование угроз в команде предлагает шаблон, с помощью которого рекомендуется проводить эту сессию. Это большой хост, на котором слева расположена библиотека атак (основные уязвимости для брейншторма), в центре - пространство для схемы проектируемого сервиса; а справа - цветная область, разделенная на три зоны для группировки угроз по статусам: сразу учитываем в разработке, оставляем на будущее, принимаем риски.
Такой фреймворк по моделированию угроз неплох, но есть особенности, на которые важно обращать внимание, иначе можно неэффективно потратить время:
1️⃣ Этот момент нигде явно не зафиксирован (он подразумевается): всю сессию предлагается проводить под девизом "Что может пойти не так?". Но держите постоянно в голове, что вы рассматриваете исключительно уязвимости, то есть потенциальные атаки (их вектор). Если вдруг всплывает идея про какой-либо неучтенный риск, то фиксируйте его рядом и двигайтесь дальше по фреймворку, иначе можно сильно уйти в сторону.
2️⃣ Строго следуем плану. Если используем каталог атак, то план такой: примеряем атаку из каталога на каждый узел своей функциональности -> если проблема вероятна, то располагаем рядом соответствующую карточку -> решаем что делать по каждой из проблем -> определяемся со статусом угроз (зона справа).
3️⃣ Каталог атак или методику, по которой определяем угрозы желательно продумать заранее. Все команды разные и желательно выбирать инструмент, который лучше подойдет вашей команде. У меня после использования предлагаемого каталога атак появилось сильное желание переработать его под свою, например, используя STRIDE, предлагаемый Microsoft.
Еще раз обращаю внимание на п.1. Крайне важно ограничивать рассматриваемый скоуп (область - например, угрозы безопасности).
Легко увлечься и начать обсуждать возможные риски и уязвимости, но бейте себя по рукам - сохраняйте фокус только на угрозах безопасности. Мне, к сожалению, в первый раз не удалось качественно профасилитирировать процесс, поэтому мы быстро уходили в обсуждение всевозможных рисков за пределами основного фокуса.
Оценка рисков (risk assessment) - похожий, но совершенно другой процесс. Он подразумевает более широкий подход применительно ко всем рискам, а не только угрозам безопасности. И у него есть свои инструменты для проведения сессии (матрица рисков, Risk-Based Testing и другие).
Из текущего опыта: сначала проведите оценку рисков, а затем моделируйте угрозы. Это позволить избежать обсуждений нецелевых рисков и сфокусироваться на безопасности.
#безопасность
👍3
Осторожно: AI. Как могут обмануть ассистенты и что с этим делать?
Еще в прошлом году хотел написать большой пост с метанием камней в AI, так как первые секунды общения с "чатом" вызывали эйфорию от потенциальных возможностей, но потом сказка рушилась, когда дело доходило до реальной практики.
Но с тех пор ассистенты серьезно набрали вес, а их качество и доступность продолжают улучшаться. Поэтому хочется поделиться в каких задачах нахожу использование AI оправданным.
ChatGPT почти мне заменил гугл в бытовых вопросах поиска информации (последний обычно использую для верификации и поиска источника), но есть также профессиональные кейсы использования: весной писал, как Llama3 помогала с вычиткой резюме.
А сегодня попробуем найти решение инженерной задачи с помощью AI и разберем на что важно обращать внимание. Использоваться будет GPT-4o, как самый сообразительный из тех, на ком я тестировал (Llama3.1, к сожалению, не смогла выдать правильное решение).
Задача
В повседневной работе, особенно когда пишешь юнит-тесты, возникает необходимость сравнивать JSON-объекты (различные конфиги, например). Зачастую это массив байт, json.RawMessage, ссылка на массив и др.
Есть объект с ожидаемой структурой, который мы написали сами, а есть другой - который получаем после результата работы программы.
Когда мы пытаемся сравнить объекты, то сталкиваемся со следующим:
1. Порядок ключей может быть произвольный во втором объекте.
2. Отступы или форматирование в 2-х json-ах могут сильно отличаться, а так как мы сравниваем массивы байт, то все влияет на результат.
Идем к AI просить помощи. Мой запрос:
Получаем подробный ответ с объяснениями и рабочим кодом!
Для решения задачи нам рекомендуют "нормализовать" 2 json'а. И это отличный совет, а вот предлагаемую реализацию разберем подробнее.
Если говорить про нормализацию в вакууме, то как будто все хорошо, но у нас же задача сравнить 2 объекта.
Поэтому меня зацепили моменты:
1. Множественный маршалинг: сначала в одну сторону, а потом и в другую (не самая дешевая операция). Почему мы не можем сравнить анмаршаленные объекты?
2. Уже на уровне придирки, но все же. Равенство объектов предлагается находить через рефлексию - для тестов подойдет, но вот для продакшн среды возможно есть более оптимальные решения.
Интересное наблюдение, если вторым запросом поинтересоваться:
То ассистент догадается, что можно обойтись без последнего маршалинга и возможно даже подскажет, что можно вместо map[string]interface{} использовать interface{}.
Вывод
Таким образом, чтобы решить одну задачу с помощью ассистента, у нас появляется 2 задачи, одна из которых - правильно сформулировать запрос или ряд запросов, чтобы получить качественное решение.
Важно помнить:
1. Ассистенты способны решать задачи, но чтобы делать это хорошо, нужен качественный запрос и контекст, формирование которых может быть трудоемким.
2. Ассистент работает поверхностно и прямолинейно с тем контекстом, который вы в него загрузили.
3. Всегда проверяйте предлагаемое решение, особенно если это код. В этом вопросе нужен опыт, поэтому для новичков не рекомендую увлекаться написанием кода с AI.
Если тема будет интересна, то постараюсь собирать подобные истории и делиться тем, как AI помогает в повседневной работе и где он наиболее эффективен.
#ai
Еще в прошлом году хотел написать большой пост с метанием камней в AI, так как первые секунды общения с "чатом" вызывали эйфорию от потенциальных возможностей, но потом сказка рушилась, когда дело доходило до реальной практики.
Но с тех пор ассистенты серьезно набрали вес, а их качество и доступность продолжают улучшаться. Поэтому хочется поделиться в каких задачах нахожу использование AI оправданным.
ChatGPT почти мне заменил гугл в бытовых вопросах поиска информации (последний обычно использую для верификации и поиска источника), но есть также профессиональные кейсы использования: весной писал, как Llama3 помогала с вычиткой резюме.
А сегодня попробуем найти решение инженерной задачи с помощью AI и разберем на что важно обращать внимание. Использоваться будет GPT-4o, как самый сообразительный из тех, на ком я тестировал (Llama3.1, к сожалению, не смогла выдать правильное решение).
Задача
В повседневной работе, особенно когда пишешь юнит-тесты, возникает необходимость сравнивать JSON-объекты (различные конфиги, например). Зачастую это массив байт, json.RawMessage, ссылка на массив и др.
Есть объект с ожидаемой структурой, который мы написали сами, а есть другой - который получаем после результата работы программы.
Когда мы пытаемся сравнить объекты, то сталкиваемся со следующим:
1. Порядок ключей может быть произвольный во втором объекте.
2. Отступы или форматирование в 2-х json-ах могут сильно отличаться, а так как мы сравниваем массивы байт, то все влияет на результат.
Идем к AI просить помощи. Мой запрос:
I need to compare two objects containing json.RawMessage in Golang. But I get a mess because of different spaces in the data. How can I solve it?
Provide the most effective and straightforward way to do it.
Получаем подробный ответ с объяснениями и рабочим кодом!
Для решения задачи нам рекомендуют "нормализовать" 2 json'а. И это отличный совет, а вот предлагаемую реализацию разберем подробнее.
// NormalizeJSON takes a json.RawMessage, unmarshals it into a generic map,
// and then marshals it back to a json.RawMessage to normalize it.
func NormalizeJSON(raw json.RawMessage) (json.RawMessage, error) {
var obj map[string]interface{}
if err := json.Unmarshal(raw, &obj); err != nil {
return nil, err
}
normalized, err := json.Marshal(obj)
if err != nil {
return nil, err
}
return normalized, nil
}
Если говорить про нормализацию в вакууме, то как будто все хорошо, но у нас же задача сравнить 2 объекта.
Поэтому меня зацепили моменты:
1. Множественный маршалинг: сначала в одну сторону, а потом и в другую (не самая дешевая операция). Почему мы не можем сравнить анмаршаленные объекты?
2. Уже на уровне придирки, но все же. Равенство объектов предлагается находить через рефлексию - для тестов подойдет, но вот для продакшн среды возможно есть более оптимальные решения.
Интересное наблюдение, если вторым запросом поинтересоваться:
Is it straightforward?
То ассистент догадается, что можно обойтись без последнего маршалинга и возможно даже подскажет, что можно вместо map[string]interface{} использовать interface{}.
Вывод
Таким образом, чтобы решить одну задачу с помощью ассистента, у нас появляется 2 задачи, одна из которых - правильно сформулировать запрос или ряд запросов, чтобы получить качественное решение.
Важно помнить:
1. Ассистенты способны решать задачи, но чтобы делать это хорошо, нужен качественный запрос и контекст, формирование которых может быть трудоемким.
2. Ассистент работает поверхностно и прямолинейно с тем контекстом, который вы в него загрузили.
3. Всегда проверяйте предлагаемое решение, особенно если это код. В этом вопросе нужен опыт, поэтому для новичков не рекомендую увлекаться написанием кода с AI.
Если тема будет интересна, то постараюсь собирать подобные истории и делиться тем, как AI помогает в повседневной работе и где он наиболее эффективен.
#ai
🔥3❤1
Мышление письмом
Мне всегда было проще записывать новый материал, рисовать схемки. И пусть они не получаются точными и красивыми, но сам процесс значительно помогает усваивать информацию.
Вот таким у меня получился конспект первой главы System Design Interview (Alex Xu).
И если раньше из этой книги я впитывал как работают Веб-системы, то сейчас интересно подойти к ней системно и спроецировать свои текущие знания на предлагаемый подход к проектированию системы во время интервью.
Как я с этим работаю?
1. Читаю главу.
2. По памяти пытаюсь воспроизвести то, что прочитал.
3. В ходе воспроизведения начинают появляться вопросы, почему именно так устроено, а не иначе - записываю их, чтобы вернуться потом.
4. Отвечаю на все возникшие вопросы.
5. Делаю финальный конспект: корректирую то, что не получилось сразу, сверяясь с источником и особо выделяя ответы на свои вопросы.
Конечно, с таким подходом не получается читать по 365 книг в год, но для меня ценнее брать качеством, а не количеством.
Мне всегда было проще записывать новый материал, рисовать схемки. И пусть они не получаются точными и красивыми, но сам процесс значительно помогает усваивать информацию.
Вот таким у меня получился конспект первой главы System Design Interview (Alex Xu).
И если раньше из этой книги я впитывал как работают Веб-системы, то сейчас интересно подойти к ней системно и спроецировать свои текущие знания на предлагаемый подход к проектированию системы во время интервью.
Как я с этим работаю?
1. Читаю главу.
2. По памяти пытаюсь воспроизвести то, что прочитал.
3. В ходе воспроизведения начинают появляться вопросы, почему именно так устроено, а не иначе - записываю их, чтобы вернуться потом.
4. Отвечаю на все возникшие вопросы.
5. Делаю финальный конспект: корректирую то, что не получилось сразу, сверяясь с источником и особо выделяя ответы на свои вопросы.
Конечно, с таким подходом не получается читать по 365 книг в год, но для меня ценнее брать качеством, а не количеством.
👍10🔥4
Улучшаем код, меняя парадигму
В августе приступил к изучению основ функционального программирования.
ФП притягивало к себе еще с тех пор, когда я писал на C# и стажировался в EPAM.
Тогда я изучал лучшие практики по обработке ошибок в .NET, а мой очень опытный наставник постоянно предупреждал во время код-ревью, что "ему это все не нравится, но так принято..." и будь его воля, то он бы использовал монады и вообще писал бы только на F#.
На мой наивный вопрос "А что такое монады и тоже хочу писать по-взрослому" - получал добрую улыбку со словами, что мне пока рано про такое думать.
Оглядываясь назад, понимаю такой ответ и полностью с ним согласен, но тогда было немного обидно.
Но зачем изучать ФП, если пишешь на нефункциональном языке и работаешь в императивной парадигме?
Основная причина - это открывает целый мир возможностей для более выразительного и чистого кода.
Вот несколько ключевых преимуществ ФП, которые зацепили меня:
1. Чистые функции и отсутствие побочных эффектов
Чистая функция всегда возвращает одинаковый результат для одинаковых входных данных и не изменяет состояние программы. Это делает код более предсказуемым и легко тестируемым.
2. Неизменяемость данных
В функциональном программировании данные неизменяемы. Вместо изменения состояния, функции создают новые значения. Это особенно полезно в многопоточных программах, где изменение состояния может привести к ошибкам.
3. Высокий уровень абстракции
ФП предоставляет мощные инструменты для работы с абстракциями, такие как маппинг, фильтрация и свертка. Эти абстракции упрощают работу с данными и позволяют писать меньше кода.
Хотя мой ежедневный инструмент не является функциональным языком, в нем можно применять некоторые принципы ФП:
В Go функции могут быть присвоены переменным, переданы в другие функции или возвращены в качестве результата. Это дает возможность писать более абстрактный и переиспользуемый код:
Go позволяет использовать чистые функции:
Есть возможность создавать замыкания, которые захватывают переменные из внешнего контекста. Это мощный инструмент для создания функций, которые могут сохранять контекст через замыкания, не используя объекты:
Также можно имитировать функциональные подходы к работе с коллекциями данных, используя стандартные библиотеки. Например, реализовать функции маппинга, фильтрации и свертки через циклы и анонимные функции:
Другая парадигма => другой взгляд на привычные вещи => больше возможностей по взаимодействию с ними.
Вижу, как ФП уже влияет на мой код и делает его лучше. На днях поймал себя на мысли, что интуитивно решил из запутанной функции сделать чистую, что за собой подтянуло другой рефакторинг. В результате получился красивый и модульный фрагмент функциональности, который легко читать и поддерживать.
Замечали ли вы, что использовали подходы функционального программирования, не осознавая этого? А встречались ли вам противники ФП?
В августе приступил к изучению основ функционального программирования.
ФП притягивало к себе еще с тех пор, когда я писал на C# и стажировался в EPAM.
Тогда я изучал лучшие практики по обработке ошибок в .NET, а мой очень опытный наставник постоянно предупреждал во время код-ревью, что "ему это все не нравится, но так принято..." и будь его воля, то он бы использовал монады и вообще писал бы только на F#.
На мой наивный вопрос "А что такое монады и тоже хочу писать по-взрослому" - получал добрую улыбку со словами, что мне пока рано про такое думать.
Оглядываясь назад, понимаю такой ответ и полностью с ним согласен, но тогда было немного обидно.
Но зачем изучать ФП, если пишешь на нефункциональном языке и работаешь в императивной парадигме?
Основная причина - это открывает целый мир возможностей для более выразительного и чистого кода.
Вот несколько ключевых преимуществ ФП, которые зацепили меня:
1. Чистые функции и отсутствие побочных эффектов
Чистая функция всегда возвращает одинаковый результат для одинаковых входных данных и не изменяет состояние программы. Это делает код более предсказуемым и легко тестируемым.
2. Неизменяемость данных
В функциональном программировании данные неизменяемы. Вместо изменения состояния, функции создают новые значения. Это особенно полезно в многопоточных программах, где изменение состояния может привести к ошибкам.
3. Высокий уровень абстракции
ФП предоставляет мощные инструменты для работы с абстракциями, такие как маппинг, фильтрация и свертка. Эти абстракции упрощают работу с данными и позволяют писать меньше кода.
Хотя мой ежедневный инструмент не является функциональным языком, в нем можно применять некоторые принципы ФП:
В Go функции могут быть присвоены переменным, переданы в другие функции или возвращены в качестве результата. Это дает возможность писать более абстрактный и переиспользуемый код:
func main() {
pow := func(x int)int{
return x*x
}
fmt.Println(pow(2)) // 4
}
Go позволяет использовать чистые функции:
func add(a, b int) int {
return a + b
}
Есть возможность создавать замыкания, которые захватывают переменные из внешнего контекста. Это мощный инструмент для создания функций, которые могут сохранять контекст через замыкания, не используя объекты:
func multiplier(factor int) func(int) int {
return func(x int) int {
return x * factor
}
}
func main() {
double := multiplier(2)
fmt.Println(double(5)) // 10
}
Также можно имитировать функциональные подходы к работе с коллекциями данных, используя стандартные библиотеки. Например, реализовать функции маппинга, фильтрации и свертки через циклы и анонимные функции:
func filter(slice []int, condition func(int) bool) []int {
var result []int
for _, v := range slice {
if condition(v) {
result = append(result, v)
}
}
return result
}
func main() {
nums := []int{1, 2, 3, 4, 5}
even := filter(nums, func(n int) bool {
return n%2 == 0
})
fmt.Println(even) // [2 4]
}
Другая парадигма => другой взгляд на привычные вещи => больше возможностей по взаимодействию с ними.
Вижу, как ФП уже влияет на мой код и делает его лучше. На днях поймал себя на мысли, что интуитивно решил из запутанной функции сделать чистую, что за собой подтянуло другой рефакторинг. В результате получился красивый и модульный фрагмент функциональности, который легко читать и поддерживать.
Замечали ли вы, что использовали подходы функционального программирования, не осознавая этого? А встречались ли вам противники ФП?
👍3🔥3
Конец спринта
Мой любимый день, когда можно столько всего успеть в промежутках между встречами:
✅ Завести и продумать задачи на следующий спринт
✅ Задеплоить в пятницу один микросервис
✅ Задеплоить в пятницу другой микросервис
✅ Провести презентацию своей команды на демо
✅ Быть ежедневным дежурным своей вертикали
Как правило, конец спринта за счет большого количества встреч связан с напряжением и стрессом, так как по разным причинам задачи не всегда закрываются вовремя (тут и проблемы с инфраструктурой, и позднее тестирование, и все что угодно).
Но бывают и приятные пятницы, когда в среду уже все проверено, задеплоено на прод, и тебе остается с приятным облегчением наблюдать за выступлением своих коллег на демо.
Катарсис же достигается где-то посередине :)
Мой любимый день, когда можно столько всего успеть в промежутках между встречами:
✅ Завести и продумать задачи на следующий спринт
✅ Задеплоить в пятницу один микросервис
✅ Задеплоить в пятницу другой микросервис
✅ Провести презентацию своей команды на демо
✅ Быть ежедневным дежурным своей вертикали
Как правило, конец спринта за счет большого количества встреч связан с напряжением и стрессом, так как по разным причинам задачи не всегда закрываются вовремя (тут и проблемы с инфраструктурой, и позднее тестирование, и все что угодно).
Но бывают и приятные пятницы, когда в среду уже все проверено, задеплоено на прод, и тебе остается с приятным облегчением наблюдать за выступлением своих коллег на демо.
Катарсис же достигается где-то посередине :)
👍2❤1
Фичалидерство: почему это нужно каждому?
В зрелых кросс-функциональных командах существует понятие фича-лида.
Эта роль предусматривает ответственность за результат конкретной фичи, и она несет большую пользу, когда в продуктовой команде появляется несколько инициатив, каждая из которых может состоять из множества фичей.
Ожидается, что такую роль регулярно примеряет на себя инженер уровня синьор и выше. Но хорошей практикой может являться, когда мидл+ также проявляет инициативу и берет на себя такие обязанности.
У нас довольно зрелая команда, поэтому практически каждый инженер становится фича-лидом по той или иной задаче. Это позволяет сильно разгрузить тимлида и повысить качество каждой отдельно взятой функциональности.
Зачем это инженеру?
Если с синьорами все понятно (это их обязанности), то для менее опытных инженеров - это в первую очередь:
- рост вширь, за пределы своей ответственности (тут и взаимодействие с горизонтальными командами, и получение экспертизы за пределами своего домена)
- такая инициатива является отличным аргументом во время перф. ревью, чтобы рекомендовать инженера для промо на следующий уровень
Есть также и неявные преимущества, но тут большая вариативность для каждого индивидуально.
Что делает фичалид?
Лучше всего, когда инженер получает фичу на самом раннем этапе и доводит ее до запуска в прод, но бывают исключения, когда лидерство может передаваться по ходу реализации (плохая практика).
Разобьем процесс по этапам:
🌎 Дискавери
- Погружается в контекст: пытается понять что и для чего мы делаем. Какие метрики при достижении результата важны.
- Коммуникация с внешними командами для уточнения контекста.
🚚 Передача в разработку
- Помощь тимлиду в составлении роадмапа на квартал
- Составление роадмапа по своей фиче и декомпозиция работ
- Обсуждение открытых вопросов на груминге, фасилитация процесса и фиксирование договоренностей
- При необходимости: организация встречи 3 Амиго
- Проработка рисков, моделирование угроз, обсуждение метрик и мониторинга фичи
🛠 Разработка
- Качественное описание задач и критериев приемки либо делегация и контроль перед взятием задач в работу
- Активное участие в планировании и взятии задач в спринт в соответствии с роадмапом
- Полное владение контекстом на время разработки, взаимодействие с внешними командами и саппорт коллег по возникающим вопросам
- Согласование изменений в контрактах и фиксация всех артефактов по результатам обсуждений
- Обнаружение проблем по ходу и предложение альтернативных путей реализации
- Обеспечение качества совместно с QA
🚀 Запуск
- Если есть АБ-эксперимент, то его заведение или контроль заведения
- Оповещение стейкхолдеров о запуске
- Запуск
- Поддержка запущенной фичи: реакция на баги, помощь коллегам по вопросам связанным с фичой
Как инженер, который активно занимается фича-лидерством, отмечу, что это отличный опыт, который нужно обязательно получать, если подворачивается возможность.
Особенно, если этот процесс вас пугает.
Меня тоже пугало еще год назад. Когда начинаешь думать, что столько ответственности, нужна серьезная экспертиза в разных областях и ты можешь не справиться и подвести команду…
Но если вас что-то действительно пугает, то рекомендую начать это делать. Сразу заметите как начнете расти, а потом вас уже будет не остановить и это войдет в привычку.
В зрелых кросс-функциональных командах существует понятие фича-лида.
Эта роль предусматривает ответственность за результат конкретной фичи, и она несет большую пользу, когда в продуктовой команде появляется несколько инициатив, каждая из которых может состоять из множества фичей.
Ожидается, что такую роль регулярно примеряет на себя инженер уровня синьор и выше. Но хорошей практикой может являться, когда мидл+ также проявляет инициативу и берет на себя такие обязанности.
У нас довольно зрелая команда, поэтому практически каждый инженер становится фича-лидом по той или иной задаче. Это позволяет сильно разгрузить тимлида и повысить качество каждой отдельно взятой функциональности.
Зачем это инженеру?
Если с синьорами все понятно (это их обязанности), то для менее опытных инженеров - это в первую очередь:
- рост вширь, за пределы своей ответственности (тут и взаимодействие с горизонтальными командами, и получение экспертизы за пределами своего домена)
- такая инициатива является отличным аргументом во время перф. ревью, чтобы рекомендовать инженера для промо на следующий уровень
Есть также и неявные преимущества, но тут большая вариативность для каждого индивидуально.
Что делает фичалид?
Лучше всего, когда инженер получает фичу на самом раннем этапе и доводит ее до запуска в прод, но бывают исключения, когда лидерство может передаваться по ходу реализации (плохая практика).
Разобьем процесс по этапам:
🌎 Дискавери
- Погружается в контекст: пытается понять что и для чего мы делаем. Какие метрики при достижении результата важны.
- Коммуникация с внешними командами для уточнения контекста.
🚚 Передача в разработку
- Помощь тимлиду в составлении роадмапа на квартал
- Составление роадмапа по своей фиче и декомпозиция работ
- Обсуждение открытых вопросов на груминге, фасилитация процесса и фиксирование договоренностей
- При необходимости: организация встречи 3 Амиго
- Проработка рисков, моделирование угроз, обсуждение метрик и мониторинга фичи
🛠 Разработка
- Качественное описание задач и критериев приемки либо делегация и контроль перед взятием задач в работу
- Активное участие в планировании и взятии задач в спринт в соответствии с роадмапом
- Полное владение контекстом на время разработки, взаимодействие с внешними командами и саппорт коллег по возникающим вопросам
- Согласование изменений в контрактах и фиксация всех артефактов по результатам обсуждений
- Обнаружение проблем по ходу и предложение альтернативных путей реализации
- Обеспечение качества совместно с QA
🚀 Запуск
- Если есть АБ-эксперимент, то его заведение или контроль заведения
- Оповещение стейкхолдеров о запуске
- Запуск
- Поддержка запущенной фичи: реакция на баги, помощь коллегам по вопросам связанным с фичой
Как инженер, который активно занимается фича-лидерством, отмечу, что это отличный опыт, который нужно обязательно получать, если подворачивается возможность.
Особенно, если этот процесс вас пугает.
Меня тоже пугало еще год назад. Когда начинаешь думать, что столько ответственности, нужна серьезная экспертиза в разных областях и ты можешь не справиться и подвести команду…
Но если вас что-то действительно пугает, то рекомендую начать это делать. Сразу заметите как начнете расти, а потом вас уже будет не остановить и это войдет в привычку.
🔥2
Что выведет программа?
Только не спрашивайте ChatGPT (он не справился).
Только не спрашивайте ChatGPT (он не справился).
package main
import (
"encoding/json"
"fmt"
)
type Data struct {
Value Arrays `json:"data"`
Name string `json:"name"`
}
type Arrays struct {
IntArray *[]int `json:"values,omitempty"`
}
func assignValues(values *[]int, name string) Data {
data := Data{
Value: Arrays{
IntArray: values,
},
Name: name,
}
return data
}
func main() {
sl := make([]int, 0)
sl = nil
data := assignValues(&sl, "nil")
value, _ := json.Marshal(data)
display(value)
}
func display(v []byte) {
fmt.Println(string(v))
}
🔥1
Что выведет программа?
Anonymous Quiz
0%
{"data":{"values":[]},"name":"nil"}
14%
{"data":{"values":null},"name":"nil"}
18%
{"data":{},"name":"nil"}
68%
Не знаю Go
Простой язык программирования - иллюзия, которая продается
Изначально я хотел написать про Go, но, заметив, что большинство с ним незнакомо, решил обобщить.
Часто можно встретить призывы изучать Go, Python или любой другой ЯП, как самый простой и популярный.
Это отлично подходит для маркетинга и позволяет быстро и дорого продавать курсы.
Я считаю подобное явление вредным для индустрии. Такие приемы формируют ложные ожидания о языке и могут деформировать мышление разработчика, который привыкает, что в выбранном ЯП все легко и просто.
Наглядные примеры из спорта:
👟 Бег
Это легко и просто. Научиться бегать может каждый, причем довольно быстро.
Но:
- Бег - это про технику, которая появляется со временем и без которой легко себе навредить.
- Хорошо бегать, чтобы показывать результат, требует больших усилий и постоянных тренировок.
♟ Шахматы
Изучить правила можно за 5 минут. Они умещаются на листке A4.
Но:
- Без стратегии и тактики сложно выигрывать и получать удовольствие от игры.
В мире технологий также.
Пример с nil-слайсами выше - простая иллюстрация того, что в Go множество нюансов. И это еще не говоря о работе с каналами, управлением памятью и указателями.
Уверен, что подобными деталями изобилует каждый язык.
Вы можете формально изучить спецификацию языка, понять, как строить примитивные конструкции и даже добиться, чтобы код работал.
Но чтобы писать хороший код, который содержит минимум багов, легко читается и поддерживается - потребуются годы. Это приходит с опытом, в этом и заключается мастерство.
Изначально я хотел написать про Go, но, заметив, что большинство с ним незнакомо, решил обобщить.
Часто можно встретить призывы изучать Go, Python или любой другой ЯП, как самый простой и популярный.
Это отлично подходит для маркетинга и позволяет быстро и дорого продавать курсы.
Я считаю подобное явление вредным для индустрии. Такие приемы формируют ложные ожидания о языке и могут деформировать мышление разработчика, который привыкает, что в выбранном ЯП все легко и просто.
Наглядные примеры из спорта:
👟 Бег
Это легко и просто. Научиться бегать может каждый, причем довольно быстро.
Но:
- Бег - это про технику, которая появляется со временем и без которой легко себе навредить.
- Хорошо бегать, чтобы показывать результат, требует больших усилий и постоянных тренировок.
♟ Шахматы
Изучить правила можно за 5 минут. Они умещаются на листке A4.
Но:
- Без стратегии и тактики сложно выигрывать и получать удовольствие от игры.
В мире технологий также.
Пример с nil-слайсами выше - простая иллюстрация того, что в Go множество нюансов. И это еще не говоря о работе с каналами, управлением памятью и указателями.
Уверен, что подобными деталями изобилует каждый язык.
Вы можете формально изучить спецификацию языка, понять, как строить примитивные конструкции и даже добиться, чтобы код работал.
Но чтобы писать хороший код, который содержит минимум багов, легко читается и поддерживается - потребуются годы. Это приходит с опытом, в этом и заключается мастерство.
👍9🫡3❤2
Август 2024:
навыки
✔️ Приступил к изучению основ функционального программирования.
✔️ Попрактиковался с имутабельными состояниями в коде вместо передачи сущностей по ссылке.
✔️ Рассмотрел различные виды багов.
✔️ Научился локально разворачивать LLM с помощью ollama и подбирать языковую модель под конкретные задачи.
✔️ Записался на внутренние занятия по "Инженерной культере" и прошел 3, на которых изучил: какие механики предусмотрены для обеспечения стабильности систем (NFR, SLI, SLO, SLA и пр.); как обеспечивать качество и тестировать производительность системы, чтобы это вошло в привычку.
✔️ Решил разбирать каждую из глав книги System Design Interview и делать краткие зарисовки. Выложил 4 первые главы.
карьера
✔️ Согласовал вторую версию документа TDR для нового сервиса. В ближайшем спринте приступаю к реализации.
✔️ Провел сессию по моделированию угроз в команде для нового сервиса.
✔️ Принял роль фичалида перспективной функциональности.
посты
✔️ Как проводить моделирование угроз (читать)
✔️ Помогите AI-ассистентам, чтобы они помогли вам (читать)
✔️ Как читать техническую литературу (читать)
✔️ Функциональное программирование как другой взгляд на привычные вещи (читать)
✔️ Возможен ли катарсис в конце спринта (читать)
✔️ Почему вам нужно фичалидерство (читать)
✔️ ChatGPT бессилен перед классическим вопросом, а вы? (читать)
прочее
✔️ 2 забега на 10 км и 1 на 5 км с препятствиями. Лучший результат - 50:03 (5:00/км). Потихоньку улучшаем показатели. Следующая цель - полумарафон.
#результаты
навыки
✔️ Приступил к изучению основ функционального программирования.
✔️ Попрактиковался с имутабельными состояниями в коде вместо передачи сущностей по ссылке.
✔️ Рассмотрел различные виды багов.
✔️ Научился локально разворачивать LLM с помощью ollama и подбирать языковую модель под конкретные задачи.
✔️ Записался на внутренние занятия по "Инженерной культере" и прошел 3, на которых изучил: какие механики предусмотрены для обеспечения стабильности систем (NFR, SLI, SLO, SLA и пр.); как обеспечивать качество и тестировать производительность системы, чтобы это вошло в привычку.
✔️ Решил разбирать каждую из глав книги System Design Interview и делать краткие зарисовки. Выложил 4 первые главы.
карьера
✔️ Согласовал вторую версию документа TDR для нового сервиса. В ближайшем спринте приступаю к реализации.
✔️ Провел сессию по моделированию угроз в команде для нового сервиса.
✔️ Принял роль фичалида перспективной функциональности.
посты
✔️ Как проводить моделирование угроз (читать)
✔️ Помогите AI-ассистентам, чтобы они помогли вам (читать)
✔️ Как читать техническую литературу (читать)
✔️ Функциональное программирование как другой взгляд на привычные вещи (читать)
✔️ Возможен ли катарсис в конце спринта (читать)
✔️ Почему вам нужно фичалидерство (читать)
✔️ ChatGPT бессилен перед классическим вопросом, а вы? (читать)
прочее
✔️ 2 забега на 10 км и 1 на 5 км с препятствиями. Лучший результат - 50:03 (5:00/км). Потихоньку улучшаем показатели. Следующая цель - полумарафон.
#результаты
👍8
Что делать, когда прямой путь не работает
Вчера ставил расширение на VS Code, которое поддерживается коллегами для внутреннего удобства разработки.
Простой плагин, который раскрашивает brief-файлы (корпоративный стандарт для описания контрактов по типу protobuf, подробнее почитать здесь), подкинул очередную задачку.
В Больших компаниях принято писать документацию. Хорошо, когда она есть, но важнее, чтобы она находилась в актуальном состоянии, иначе никто ей не будет пользоваться.
К плагину прилагалась простая инструкция:
Какое же мое разочарование было, когда я споткнулся на первом же шаге. Файл не существовал по нужному пути.
Первым же порывом было - написать в чат Платформы, чтобы уточнить, а "живой" ли вообще плагин? Но уже набирая сообщение, я осекся. Проверил историю коммитов и заметил, что есть относительно свежие, из чего я сделал вывод, что разработка не заброшена.
Далее рассудил так: если у меня есть репозиторий, куда активно контрибьютят, но нет самого vsix-файла (не важно, что я про такие файлы впервые слышу), который могу поставить как расширение, то что мне мешает собрать исходный код в такой файл?
Порадовавшись этой нехитрой мысли я переключился с проблемы "отсутствует файл", на задачу "как собрать файл". Через секунду я прочитал, что существует vsce - VS Code Extension Manager, с помощью которого я могу собрать нужный мне vsix. Ставим его:
Далее переходим в директорию с исходником расширения (где живет наш плагин) и упаковываем в нужный vsix:
Теперь нужно установить расширение в IDE. Используем следующую команду:
И, если с vsce все было просто, то следующим вызовом для меня как относительно нового пользователя VS Code стала команда code --instal-extension, так как просто в консоли она не выполнялась. Но спустя пару минут, разобравшись, что это CLI, уже устанавливал и ее.
В пределах 5-10 минут мне удалось: разобраться в проблеме, узнать как собирать vsix-файлы с помощью менеджера расширений vsce, устанавливать их через CLI и бонусом, пока все устанавливалось, подробно почитал про проект GNU Wget (небольшой тизер: Wget2 на подходе).
Вероятно, именно из-за подобных задач мне и нравится разработка - заставляет проанализировать искомую проблему и пойти не в лоб, а попытаться найти другие пути решения.
Рекомендую, когда прямолинейный подход не сработал, остановиться, записать вопрос и найти альтернативное решение, спустившись на уровень ниже. Так вы не только расширите свою экспертизу, но очередной раз потренируетесь в системном подходе решения задач.
Вчера ставил расширение на VS Code, которое поддерживается коллегами для внутреннего удобства разработки.
Простой плагин, который раскрашивает brief-файлы (корпоративный стандарт для описания контрактов по типу protobuf, подробнее почитать здесь), подкинул очередную задачку.
В Больших компаниях принято писать документацию. Хорошо, когда она есть, но важнее, чтобы она находилась в актуальном состоянии, иначе никто ей не будет пользоваться.
К плагину прилагалась простая инструкция:
1. Скачать `vsix` файл: wget http://<extension-directory>.vsix
2. Добавить его в VSCode: Extensions -> ... -> Install from VSIX -> <extension-directory>.vsix
3. Либо через терминал: code --install-extension <extension-directory>.vsix
Какое же мое разочарование было, когда я споткнулся на первом же шаге. Файл не существовал по нужному пути.
Первым же порывом было - написать в чат Платформы, чтобы уточнить, а "живой" ли вообще плагин? Но уже набирая сообщение, я осекся. Проверил историю коммитов и заметил, что есть относительно свежие, из чего я сделал вывод, что разработка не заброшена.
Далее рассудил так: если у меня есть репозиторий, куда активно контрибьютят, но нет самого vsix-файла (не важно, что я про такие файлы впервые слышу), который могу поставить как расширение, то что мне мешает собрать исходный код в такой файл?
Порадовавшись этой нехитрой мысли я переключился с проблемы "отсутствует файл", на задачу "как собрать файл". Через секунду я прочитал, что существует vsce - VS Code Extension Manager, с помощью которого я могу собрать нужный мне vsix. Ставим его:
npm install -g vsce
Далее переходим в директорию с исходником расширения (где живет наш плагин) и упаковываем в нужный vsix:
vsce package
Теперь нужно установить расширение в IDE. Используем следующую команду:
code --install-extension <extension-directory>.vsix
И, если с vsce все было просто, то следующим вызовом для меня как относительно нового пользователя VS Code стала команда code --instal-extension, так как просто в консоли она не выполнялась. Но спустя пару минут, разобравшись, что это CLI, уже устанавливал и ее.
В пределах 5-10 минут мне удалось: разобраться в проблеме, узнать как собирать vsix-файлы с помощью менеджера расширений vsce, устанавливать их через CLI и бонусом, пока все устанавливалось, подробно почитал про проект GNU Wget (небольшой тизер: Wget2 на подходе).
Вероятно, именно из-за подобных задач мне и нравится разработка - заставляет проанализировать искомую проблему и пойти не в лоб, а попытаться найти другие пути решения.
Рекомендую, когда прямолинейный подход не сработал, остановиться, записать вопрос и найти альтернативное решение, спустившись на уровень ниже. Так вы не только расширите свою экспертизу, но очередной раз потренируетесь в системном подходе решения задач.
👍4
Привычка, которая поможет расти в Big Tech
Одной из важнейших компетенций, на которую смотрят при возможном пересмотре грейда, является "инженерная культура".
В Авито на уровень E5 (синьор) ее признаки обозначаются как:
- Улучшает общие инженерные инструменты компании.
- Тестирует сложные корнер-кейсы.
- Проектирует тестопригодные системы и исправляет те, которые сложно тестировать.
- Ищет неэффективные места в коде/архитектуре/тестовых моделях. Пополняет технический бэклог команды.
- Устанавливает и тестирует нефункциональные требования или привлекает для этого экспертов.
- Знает и использует безопасные подходы к реализации функциональности.
Когда целишься в следующий грейд, то полезно время от времени сверяться с ожиданиями на нем, чтобы была возможность их продемонстрировать.
Но интереснее всего тот факт, что со временем это начинает входить в привычку. Многие из компетенций ты начинаешь закрывать не потому, что целишься на уровень выше и формально хочешь на калибровках показать соответствие следующему грейду, а потому, что приятно находить узкие места в системах, которые ты можешь улучшить.
На днях подключал к новому сервису библиотеку для работы с АБ-экспериментами. Была понятная дока с примерами, а еще были интересные нюансы:
1. Либу можно было использовать несколькими способами. Один из них - подключение как мидлвара (middleware).
Когда сделал все в соответствии с документацией, то ничего не заработало. Я долго не понимал почему, перечитывал доку и комментарии к функциями, все было правильно, но не работало.
Перечитывая очереденой раз документацию, глаз зацепился за комментарий, окруженный восклицательными знаками - он указывал на определенный порядок вызова мидлвар; я заодно перепроверил свой - все было корректно.
После нескольких часов страданий, отладки и тестирования пришла в голову странная мысль: сделать наоборот, нежели написано в документации, так как по смыслу это выглядело более логичным.
Как итог, все заработало.
В такие моменты сильно злишься на тех, кто составлял документацию, и на других - кто вероятно мог столкнуться с похожей проблемой, но никак это место не улучшил.
Но, как говорится, результат начинается с тебя, поэтому я сделал быстрый пул-реквест в библиотеку, где решил данное место задокументировать понятным образом и убрать неверный комментарий, чтобы в будущем облегчить жизнь коллегам и себе, если вдруг еще раз предстоит с этим столкнуться.
2. При использовании либы, как мидлвары, оказалось, что ее нельзя адекватно протестировать юнит-тестами.
Сложилось впечатление, что я один из первых, кто решил использовать новейшую версию этой библиотеки, а также подключал ее как мидлвару...
Если кратко, то нужно было протестировать хэндлер, в котором использовалась библиотека, но в юните было довольно сложно это поддержать, так как либа использовалась через контекст, который обогощался через мидлвару.
В юнитах - мы с мидлварой не работаем непосредственно, а прямое обогащение контекста предусмотрено не было.
Поделившись проблемой с коллегами и поворчав, я получил предложение протестировать при помощи моков (что, очевидно, я пытался сделать сразу).
Из-за использования довольно сложной структуры моки пришлось бы вкладывать друг в друга как матрешки. Поэтому я решил, что пора делать еще один пул-реквест в общую либу, чтобы можно было с этим нормально работать.
Когда удалось согласовать все правки и, наконец, завершить свою изначальную задачу, я понял, что неожиданно улучшил общий инженерный инструмент компании, а это - прямое соответствие одному из ожиданий инженера на следующем уровне.
Приятно, что такая ситуация возникла спонтанно. Я почувствовал, что подход к решению задач, когда фокусируешься не только на выполнении непосредственно своих, а также стремишься улучшить общий продукт, начинает входить в привычку.
Это дает приятно чувство удовлетворения, делает тебя немного счастливее и сильнее как инженера.
@time2code
Одной из важнейших компетенций, на которую смотрят при возможном пересмотре грейда, является "инженерная культура".
В Авито на уровень E5 (синьор) ее признаки обозначаются как:
- Улучшает общие инженерные инструменты компании.
- Тестирует сложные корнер-кейсы.
- Проектирует тестопригодные системы и исправляет те, которые сложно тестировать.
- Ищет неэффективные места в коде/архитектуре/тестовых моделях. Пополняет технический бэклог команды.
- Устанавливает и тестирует нефункциональные требования или привлекает для этого экспертов.
- Знает и использует безопасные подходы к реализации функциональности.
Когда целишься в следующий грейд, то полезно время от времени сверяться с ожиданиями на нем, чтобы была возможность их продемонстрировать.
Но интереснее всего тот факт, что со временем это начинает входить в привычку. Многие из компетенций ты начинаешь закрывать не потому, что целишься на уровень выше и формально хочешь на калибровках показать соответствие следующему грейду, а потому, что приятно находить узкие места в системах, которые ты можешь улучшить.
На днях подключал к новому сервису библиотеку для работы с АБ-экспериментами. Была понятная дока с примерами, а еще были интересные нюансы:
1. Либу можно было использовать несколькими способами. Один из них - подключение как мидлвара (middleware).
Когда сделал все в соответствии с документацией, то ничего не заработало. Я долго не понимал почему, перечитывал доку и комментарии к функциями, все было правильно, но не работало.
Перечитывая очереденой раз документацию, глаз зацепился за комментарий, окруженный восклицательными знаками - он указывал на определенный порядок вызова мидлвар; я заодно перепроверил свой - все было корректно.
После нескольких часов страданий, отладки и тестирования пришла в голову странная мысль: сделать наоборот, нежели написано в документации, так как по смыслу это выглядело более логичным.
Как итог, все заработало.
В такие моменты сильно злишься на тех, кто составлял документацию, и на других - кто вероятно мог столкнуться с похожей проблемой, но никак это место не улучшил.
Но, как говорится, результат начинается с тебя, поэтому я сделал быстрый пул-реквест в библиотеку, где решил данное место задокументировать понятным образом и убрать неверный комментарий, чтобы в будущем облегчить жизнь коллегам и себе, если вдруг еще раз предстоит с этим столкнуться.
2. При использовании либы, как мидлвары, оказалось, что ее нельзя адекватно протестировать юнит-тестами.
Сложилось впечатление, что я один из первых, кто решил использовать новейшую версию этой библиотеки, а также подключал ее как мидлвару...
Если кратко, то нужно было протестировать хэндлер, в котором использовалась библиотека, но в юните было довольно сложно это поддержать, так как либа использовалась через контекст, который обогощался через мидлвару.
В юнитах - мы с мидлварой не работаем непосредственно, а прямое обогащение контекста предусмотрено не было.
Поделившись проблемой с коллегами и поворчав, я получил предложение протестировать при помощи моков (что, очевидно, я пытался сделать сразу).
Из-за использования довольно сложной структуры моки пришлось бы вкладывать друг в друга как матрешки. Поэтому я решил, что пора делать еще один пул-реквест в общую либу, чтобы можно было с этим нормально работать.
Когда удалось согласовать все правки и, наконец, завершить свою изначальную задачу, я понял, что неожиданно улучшил общий инженерный инструмент компании, а это - прямое соответствие одному из ожиданий инженера на следующем уровне.
Приятно, что такая ситуация возникла спонтанно. Я почувствовал, что подход к решению задач, когда фокусируешься не только на выполнении непосредственно своих, а также стремишься улучшить общий продукт, начинает входить в привычку.
Это дает приятно чувство удовлетворения, делает тебя немного счастливее и сильнее как инженера.
@time2code
👍7❤2👏1