Привет!
Продолжаем публиковать текстовые версии докладов с QIWI Server Party 6.0, в этом посте — Александр Прокопьев и Developer Experience. Про инструменты, их качество и развитие инструментов разработчиков в QIWI.
У меня есть любимая притча. Мужик пилит дерево. Другой к нему подходит и спрашивает:
— Как дела? Давно пилишь?
— Три дня уже.
— Что-то долго. Может тебе стоит пилу заточить?
— Не, некогда точить, нужно дерево пилить.
И в IT такое бывает часто. Работаешь над какой-нибудь рутинной задачей и думаешь, что вот наверняка есть какой-то инструмент, который может автоматизировать эту работу. Но сроки горят, и мы говорим себе: «Не в этот раз». И оставляем на потом. А когда работа завершается, мы быстро забываем про эту боль.
Я, например, до сих пор использую старый SQL Developer для работы с базой данных, хотя все коллеги давно перешли на DataGrip. И они периодически подталкивают меня, а мне все лень. Кто-то пользуется Git-ом и никак не соберется с силами, чтобы изучить его поглубже, добавить в свой багаж более глубокие команды. А кто-то использует IDE и не изучает горячие клавиши или плагины, которые могут помочь в работе.
Давайте посмотрим на инструменты чуть глобальнее, чем индивидуальные истории использования. Вы заметили, как быстро наши инструменты вышли за рамки одного ноутбука? Еще пять-шесть лет назад мы искали логи через SSH, заходя на сервер. А сейчас каждая уважающая себя IT-компания должна иметь что-то похожее на Kibana — без этого мы уже не можем себе представить поиск логов. Появились разные системы сборки, дашборды, инструменты для совместной работы и ревью. И за этими инструментами тоже нужно ухаживать, а не просто поставить и забыть о них на веки вечные.
Например, Kibana. Представим ситуацию, что нам нужно найти логи одного конкретного приложения. Что делать? Для начала добавить фильтр по имени приложения. Но что если у нас слишком много приложений в Kibana, и она не может в одном списке показать все возможные варианты? Придется имя приложения, этот фильтр, вбивать вручную.
Затем нужно добавить фильтр по environment. Нам нужен продакшн, поэтому добавляем его. И выбираем несколько полей, которые мы хотим видеть у себя, например, level и Message. В итоге получается около пяти разных операций просто для того, чтобы посмотреть логи приложения. И это нужно делать каждый раз, когда мы смотрим логи, то есть довольно часто. Плюс сюда входит ввод имени приложения вручную, которое нужно взять откуда-то из головы.
Если кто-то решил, что можно просто взять эту ссылку, сохранить ее и использовать в будущем как пресет — это хорошо. Это как раз то, о чем я говорю. В моем понимании это и есть хоть минимальный, но все-таки уход за приложением.
Еще один наболевший пример. Мне нужно зарелизить приложение. Код уже написан, протестирован и готов к проду. Я открыл наш TeamCity, нашел приложение, нажал на кнопку Start Deploy. И тут первый сюрприз — таска упала.
Но так и было задумано. Если открыть логи этой таски, можно увидеть, что там есть ссылка на тикет в Jira, в которую нужно перейти. Но там тоже ничего особенного не увидишь. Если ты прошаренный, то знаешь, что нужно дождаться, пока специальный бот придет и выделит тебе окно для релиза.
Затем нужно поставить будильник и не забыть в это время зарелизить. Что будет, если я забуду про будильник? Да ничего страшного, конечно же. Всего лишь перенос релиза на два-три часа. А может на следующий день. Всего-то.
Но если серьезно, когда в компании катится очень много релизов одновременно, это очень и очень плохая история — забыть про релиз. В общем, неплохо бы как-то оптимизировать этот процесс.
Developer Experience — это то, что испытывает разработчик, когда работает со своими инструментами. Это почти то же самое, что и User Experience, о котором мы так часто говорим, когда разрабатываем какие-то интерфейсы для внешних пользователей, только для девелоперов. И от этого опыта зависит не только удовольствие от работы или просто какие-то абстрактные ощущения, но и производительность.
Я сам страстно болею этой темой и часто пытаюсь найти узкие места, придумать какое-то решение и показать его ребятам. И я уверен, что так стоит делать. В этом посте я бы хотел порассуждать, как именно это можно делать и что делать с возникающими по ходу дела трудностями.
А теперь давайте посмотрим на выдуманный бэклог такой команды.
Они хотят попробовать внедрить ArgoCD, развернуть Backstage, накатить какой-то патч с обновлением безопасности на Kubernetes. Может быть создать курс DevOps для разработчиков. А еще можно попробовать переехать на новый CI-tool. Видите масштаб этих задач? А теперь давайте попробуем сюда докинуть наших мелких хотелок, вроде упрощения поиска логов в Kibana или релизов в TeamCity.
Они, конечно, займутся этими задачами. Но приоритет таких мелких изменений будет всегда ниже, чем у более крупномасштабных вроде обновления безопасности Kubernetes. И мы будем ждать этих изменений очень долго. А когда DevOps-инженеры все-таки дойдут до них, то скорее всего изменят формулировку до более масштабного уровня. Типа «изменение всего пайплайна релиза в прод» или «поиск нового инструмента для просмотра логов». И это значит, что на внедрение уйдет еще больше времени.
Я думаю, что нет ничего зазорного в том, чтобы иногда брать инициативу в свои руки и пробовать самим улучшить experience и инструменты.
В одной из команд ребята устали каждый раз руками накатывать миграции на базу данных PostgresQL. И в прошлом году автоматизировали этот процесс, используя Liquibase. Об этом можно прочитать в статье.
Другая история: четыре года назад у нас началась массовая миграция в Kubernetes . Представьте, для того, чтобы перевести только одно приложение в Кубер, нужно написать как минимум докер-файл и несколько YML-ов, которые позволят запустить приложение. И таких приложений много. Чтобы не писать эти файлы каждый раз вручную, мы написали небольшой скрипт, который по шаблону позволял генерировать эти файлы с помощью ответов на вопросы. Это упрощало процесс в разы.
Со временем этот скрипт переродился в полноценный генератор приложений, который жив и сейчас. Хотя, если честно, уже немножко устарел. Но это еще один пример того, как разработчики исходили из желания улучшить свой ежедневный опыт. Все это благодаря проактивности, инициативности и творческому подходу. Это просто громкие слова, которые на самом деле очень мало чего описывают. Но я верю, что в каждой компании есть очень много таких проактивных и инициативных сотрудников.
Я бы даже сказал, что каждый разработчик в той или иной мере проактивен. Только это не бинарная шкала: ты не можешь быть либо проактивным, либо непроактивным. Это скалярная шкала с градациями. И очень часто бывает, что идея вроде есть, проактивность есть, но всего этого не хватает, чтобы пробиться через непрерывно возникающие преграды.
И постепенно желание умирает. Может вы сами сталкивались с историей, когда возникает идея что-либо изменить, но тут доступов не хватает, здесь нужно пройти семь кругов согласований, и в итоге инициатива испаряется.
Я точно так же проходил через все эти согласования и получение доступов, и могу поделиться с вами, каково это было и что я делал, чтобы получить возможность изменить Developer Experience.
Но есть небольшие лайфхаки.
Для начала будет неплохо, если вы сами пойдете и попросите доступ к инструменту, который вы хотите изменить. Это может показаться наивным, но вдруг окажется, что просто раньше никто не просил? Вдруг эти ворота открыты, и нужно только постучать?
Скорее всего, конечно, нет. Но если разговор об этом зайдет, то скорее всего вам скажут что-нибудь вроде «мы не дадим доступы, потому что ты все поломаешь». И действительно, это важный аргумент. Ведь дело касается инфраструктуры — это важная штука, повредив которую, вы подвергаете всю компанию серьезной угрозе.
Но в то же время это всего-лишь повод задуматься о том, как минимизировать риски.
Можно сказать, что вы будете проводить каждое изменение через строгое ревью ответственных людей. Это вполне полезная штука, и стоит так делать всегда, не только когда вы дорабатываете инструменты. Также можно договориться о том, что вы не будете раскатывать это изменение на всю компанию, а ограничитесь только своим продуктом, проектом, командой.
Также стоит делать упор на то, что это эксперимент. Может случиться так, что эксперимент не удастся. Поэтому нужно заранее проговорить с ответственными людьми, DevOps-ами, о том, что если что-то пойдет не так, вы просто откатите и вернете все, как было. Это также добавит прозрачности. И еще стоит проговорить критерии успешного результата, то есть definition of done, о котором писал мой коллега Никита.
Все это возможно и доступно, если в вашей компании пропагандируют DevOps. Но никакой DevOps нельзя построить, если между разработчиками Devs и Ops есть кирпичная стена, в которой просто прорублены маленькие форточки в виде инструментов. Я думаю, что стоит приводить этот аргумент: возможно, он сработает, и вам станет проще продвигать свои идеи.
Другой вопрос — где взять время на это все. Если вы не работаете в специально выделенной команде, то явно придется совмещать свои изыскания с основными задачами, поступающими от руководителя, продакт- или проджект-менеджера. Но в целом это похоже на работу с техдолгом, только вместо возврата взятого когда-то долга получается работа на опережение. Мы скорее думаем о том, как в будущем мы могли бы избежать появления техдолга.
В Qiwi для работы с техдолгом есть правило 20%. Думаю многим из вас оно знакомо, и у кого-то это 10%, у кого-то 15%, И каждый из нас знает, что это правило нифига не работает. В непрерывном потоке основных задач очень сложно выделить время для работы над какими-то техническими задачами, библиотеками или инструментами. Да и руководители обычно заинтересованы в решении сиюминутных проблем, а не чего-то эфемерного.
Еще один момент — бывало такое, что я брал техническую таску и бросался в нее с головой. Без плана, без критериев завершения задачи. Ведь она техническая, я знаю, что делаю, возьму и затащу ее. Зачем мне эти выдумки. Проходит неделя, две, и вроде бы есть результат. Но сказать, что решение внедрено, нельзя. А может я его внедрил, но оно оказалось не очень-то нужным. И от этого пыл угасает, и в следующий раз уже не хочется опять включаться в переговоры с продакт-менеджером.
Позже я понял, как важно применять к техническим задачам такие же правила, какие мы применяем к бизнесовым. Важно говорить с продакт-менеджером и любым другим менеджером на его языке. Вместо «все будет плохо» лучше сказать что-то вроде «эта проблема принесла нам убытки». И если эту проблему решить сейчас, она больше не повторится.
При этом важно самому здраво оценивать необходимость решения задачи, которую вы пытаетесь тащить. Это позволит в будущем избежать ощущения ненужности проделанной работы. И не забывать задавать критерии, по которым вы поймете, что задача сделана и цель достигнута, то самое definition of done, а также сроки. Если таска большая, стоит разделить ее на несколько этапов и определить дедлайн для каждого. То есть работать точно так же, как если бы это была бизнесовая задача от менеджера.
Все это сделает процесс работы над техническими задачами прозрачнее и для вас, и для менеджера. И даст обеим сторонам понимание, что вы делаете только то, что действительно необходимо, и что вы можете доверять друг другу.
Точно так же и с крупными инструментами. Иногда вместо глубокого погружения в инструмент можно просто написать логин к ним или небольшое приложение, которое будет использовать внешний API. Или написать бота в Telegram, который будет автоматизировать рутинные ежедневные операции.
В том же кейсе с Kibana. Там приходилось совершать много действий для того, чтобы найти логи приложения. А что если просто взять и написать расширение для браузера, которое будет совершать те же самые клики за вас и позволит искать приложения из списка? В случае с релизами в прод идеальным решением был бы пересмотр вообще всего пайплайна релизов, но это долго, и, наверное, это не по силам сделать одному разработчику. Но почему бы вместо этого не написать бота, опять же, в Telegram, который будет напоминать вам о назначенном релизе?
Пока это просто мысли, идеи того, как я сам улучшил бы эти истории. Возможно, у вас возникли какие-то свои мысли, как это можно пофиксить более правильно и более просто. Если это так — отлично. Большие инструменты могут выглядеть устрашающе, но если проявить творческий подход и посмотреть шире, можно увидеть очень много возможностей.
Весь этот рассказ не только для того, чтобы рассказать, как хорошо у нас в QIWI и что мы делаем для того, чтобы развивать инструменты. Нам еще есть к чему стремиться. Этот пост еще и для того, чтобы вы взглянули на свои процессы. Попробуйте копнуть глубже в инструменты, и, возможно, увидите, что из них можно вытянуть больше. Не только повысить удобство, но и качество работы, производительность.
Давайте работать над тем, чтобы улучшать свой experience. Попробуйте наточить пилу, и, возможно вы увидите, что ваша работа стала эффективнее и приятнее.
habr.com
Продолжаем публиковать текстовые версии докладов с QIWI Server Party 6.0, в этом посте — Александр Прокопьев и Developer Experience. Про инструменты, их качество и развитие инструментов разработчиков в QIWI.
У меня есть любимая притча. Мужик пилит дерево. Другой к нему подходит и спрашивает:
— Как дела? Давно пилишь?
— Три дня уже.
— Что-то долго. Может тебе стоит пилу заточить?
— Не, некогда точить, нужно дерево пилить.
И в IT такое бывает часто. Работаешь над какой-нибудь рутинной задачей и думаешь, что вот наверняка есть какой-то инструмент, который может автоматизировать эту работу. Но сроки горят, и мы говорим себе: «Не в этот раз». И оставляем на потом. А когда работа завершается, мы быстро забываем про эту боль.
Я, например, до сих пор использую старый SQL Developer для работы с базой данных, хотя все коллеги давно перешли на DataGrip. И они периодически подталкивают меня, а мне все лень. Кто-то пользуется Git-ом и никак не соберется с силами, чтобы изучить его поглубже, добавить в свой багаж более глубокие команды. А кто-то использует IDE и не изучает горячие клавиши или плагины, которые могут помочь в работе.
Давайте посмотрим на инструменты чуть глобальнее, чем индивидуальные истории использования. Вы заметили, как быстро наши инструменты вышли за рамки одного ноутбука? Еще пять-шесть лет назад мы искали логи через SSH, заходя на сервер. А сейчас каждая уважающая себя IT-компания должна иметь что-то похожее на Kibana — без этого мы уже не можем себе представить поиск логов. Появились разные системы сборки, дашборды, инструменты для совместной работы и ревью. И за этими инструментами тоже нужно ухаживать, а не просто поставить и забыть о них на веки вечные.
Например, Kibana. Представим ситуацию, что нам нужно найти логи одного конкретного приложения. Что делать? Для начала добавить фильтр по имени приложения. Но что если у нас слишком много приложений в Kibana, и она не может в одном списке показать все возможные варианты? Придется имя приложения, этот фильтр, вбивать вручную.
Затем нужно добавить фильтр по environment. Нам нужен продакшн, поэтому добавляем его. И выбираем несколько полей, которые мы хотим видеть у себя, например, level и Message. В итоге получается около пяти разных операций просто для того, чтобы посмотреть логи приложения. И это нужно делать каждый раз, когда мы смотрим логи, то есть довольно часто. Плюс сюда входит ввод имени приложения вручную, которое нужно взять откуда-то из головы.
Если кто-то решил, что можно просто взять эту ссылку, сохранить ее и использовать в будущем как пресет — это хорошо. Это как раз то, о чем я говорю. В моем понимании это и есть хоть минимальный, но все-таки уход за приложением.
Еще один наболевший пример. Мне нужно зарелизить приложение. Код уже написан, протестирован и готов к проду. Я открыл наш TeamCity, нашел приложение, нажал на кнопку Start Deploy. И тут первый сюрприз — таска упала.
Но так и было задумано. Если открыть логи этой таски, можно увидеть, что там есть ссылка на тикет в Jira, в которую нужно перейти. Но там тоже ничего особенного не увидишь. Если ты прошаренный, то знаешь, что нужно дождаться, пока специальный бот придет и выделит тебе окно для релиза.
Затем нужно поставить будильник и не забыть в это время зарелизить. Что будет, если я забуду про будильник? Да ничего страшного, конечно же. Всего лишь перенос релиза на два-три часа. А может на следующий день. Всего-то.
Но если серьезно, когда в компании катится очень много релизов одновременно, это очень и очень плохая история — забыть про релиз. В общем, неплохо бы как-то оптимизировать этот процесс.
Developer Experience — это то, что испытывает разработчик, когда работает со своими инструментами. Это почти то же самое, что и User Experience, о котором мы так часто говорим, когда разрабатываем какие-то интерфейсы для внешних пользователей, только для девелоперов. И от этого опыта зависит не только удовольствие от работы или просто какие-то абстрактные ощущения, но и производительность.
Я сам страстно болею этой темой и часто пытаюсь найти узкие места, придумать какое-то решение и показать его ребятам. И я уверен, что так стоит делать. В этом посте я бы хотел порассуждать, как именно это можно делать и что делать с возникающими по ходу дела трудностями.
Почему иногда проще попробовать сделать все самому
Обычно для таких задач в компании принято создавать выделенные команды DevOps-инженеров. И у нас она есть. Ребята проделывают просто невероятно огромную работу для того, чтобы двигать наши IT-процессы и инструменты вперед. Без них у нас не было бы ни TeamCity, ни Kibana, ни Kubernetes, ничего.А теперь давайте посмотрим на выдуманный бэклог такой команды.
Они хотят попробовать внедрить ArgoCD, развернуть Backstage, накатить какой-то патч с обновлением безопасности на Kubernetes. Может быть создать курс DevOps для разработчиков. А еще можно попробовать переехать на новый CI-tool. Видите масштаб этих задач? А теперь давайте попробуем сюда докинуть наших мелких хотелок, вроде упрощения поиска логов в Kibana или релизов в TeamCity.
Они, конечно, займутся этими задачами. Но приоритет таких мелких изменений будет всегда ниже, чем у более крупномасштабных вроде обновления безопасности Kubernetes. И мы будем ждать этих изменений очень долго. А когда DevOps-инженеры все-таки дойдут до них, то скорее всего изменят формулировку до более масштабного уровня. Типа «изменение всего пайплайна релиза в прод» или «поиск нового инструмента для просмотра логов». И это значит, что на внедрение уйдет еще больше времени.
Я думаю, что нет ничего зазорного в том, чтобы иногда брать инициативу в свои руки и пробовать самим улучшить experience и инструменты.
Как мы к этому шли
Так считаю не только я один. Если ретроспективно посмотреть на историю развития инструментов в Qiwi, можно заметить множество примеров того, как сами ребята на местах брали и улучшали свои инструменты.В одной из команд ребята устали каждый раз руками накатывать миграции на базу данных PostgresQL. И в прошлом году автоматизировали этот процесс, используя Liquibase. Об этом можно прочитать в статье.
Другая история: четыре года назад у нас началась массовая миграция в Kubernetes . Представьте, для того, чтобы перевести только одно приложение в Кубер, нужно написать как минимум докер-файл и несколько YML-ов, которые позволят запустить приложение. И таких приложений много. Чтобы не писать эти файлы каждый раз вручную, мы написали небольшой скрипт, который по шаблону позволял генерировать эти файлы с помощью ответов на вопросы. Это упрощало процесс в разы.
Со временем этот скрипт переродился в полноценный генератор приложений, который жив и сейчас. Хотя, если честно, уже немножко устарел. Но это еще один пример того, как разработчики исходили из желания улучшить свой ежедневный опыт. Все это благодаря проактивности, инициативности и творческому подходу. Это просто громкие слова, которые на самом деле очень мало чего описывают. Но я верю, что в каждой компании есть очень много таких проактивных и инициативных сотрудников.
Я бы даже сказал, что каждый разработчик в той или иной мере проактивен. Только это не бинарная шкала: ты не можешь быть либо проактивным, либо непроактивным. Это скалярная шкала с градациями. И очень часто бывает, что идея вроде есть, проактивность есть, но всего этого не хватает, чтобы пробиться через непрерывно возникающие преграды.
И постепенно желание умирает. Может вы сами сталкивались с историей, когда возникает идея что-либо изменить, но тут доступов не хватает, здесь нужно пройти семь кругов согласований, и в итоге инициатива испаряется.
Я точно так же проходил через все эти согласования и получение доступов, и могу поделиться с вами, каково это было и что я делал, чтобы получить возможность изменить Developer Experience.
Что делать
Чтобы внести какое-то изменение в свои инструменты, необходимо иметь саму возможность изменять, а именно получить доступы к исходникам и конфигурации. В идеале было бы хорошо, если бы не нужно было согласовывать каждое маленькое изменение с кучей менеджеров. Я понимаю, что мир не так удобен, как хотелось бы, и скорее всего, у вас не будет легкого доступа к конфигам. А также возможности избежать потока согласований.Но есть небольшие лайфхаки.
Для начала будет неплохо, если вы сами пойдете и попросите доступ к инструменту, который вы хотите изменить. Это может показаться наивным, но вдруг окажется, что просто раньше никто не просил? Вдруг эти ворота открыты, и нужно только постучать?
Скорее всего, конечно, нет. Но если разговор об этом зайдет, то скорее всего вам скажут что-нибудь вроде «мы не дадим доступы, потому что ты все поломаешь». И действительно, это важный аргумент. Ведь дело касается инфраструктуры — это важная штука, повредив которую, вы подвергаете всю компанию серьезной угрозе.
Но в то же время это всего-лишь повод задуматься о том, как минимизировать риски.
Можно сказать, что вы будете проводить каждое изменение через строгое ревью ответственных людей. Это вполне полезная штука, и стоит так делать всегда, не только когда вы дорабатываете инструменты. Также можно договориться о том, что вы не будете раскатывать это изменение на всю компанию, а ограничитесь только своим продуктом, проектом, командой.
Также стоит делать упор на то, что это эксперимент. Может случиться так, что эксперимент не удастся. Поэтому нужно заранее проговорить с ответственными людьми, DevOps-ами, о том, что если что-то пойдет не так, вы просто откатите и вернете все, как было. Это также добавит прозрачности. И еще стоит проговорить критерии успешного результата, то есть definition of done, о котором писал мой коллега Никита.
Все это возможно и доступно, если в вашей компании пропагандируют DevOps. Но никакой DevOps нельзя построить, если между разработчиками Devs и Ops есть кирпичная стена, в которой просто прорублены маленькие форточки в виде инструментов. Я думаю, что стоит приводить этот аргумент: возможно, он сработает, и вам станет проще продвигать свои идеи.
Другой вопрос — где взять время на это все. Если вы не работаете в специально выделенной команде, то явно придется совмещать свои изыскания с основными задачами, поступающими от руководителя, продакт- или проджект-менеджера. Но в целом это похоже на работу с техдолгом, только вместо возврата взятого когда-то долга получается работа на опережение. Мы скорее думаем о том, как в будущем мы могли бы избежать появления техдолга.
В Qiwi для работы с техдолгом есть правило 20%. Думаю многим из вас оно знакомо, и у кого-то это 10%, у кого-то 15%, И каждый из нас знает, что это правило нифига не работает. В непрерывном потоке основных задач очень сложно выделить время для работы над какими-то техническими задачами, библиотеками или инструментами. Да и руководители обычно заинтересованы в решении сиюминутных проблем, а не чего-то эфемерного.
Так делать-то что?
Обычно мы заходим к руководителю или продакт-менеджеру со словами о том, что надо пофиксить какой-то инструмент. Зачем? Если этого не сделать, будет плохо. Кому будет плохо? Нам плохо. Потому что в коде есть не очень хороший кусок. А дальше по этому сценарию обычно следует конфликт. Ведь менеджеру продукта сложно поставить себя на ваше место. Он, скорее всего, не понимает, в чем проблема, зачем вы к нему пришли.Еще один момент — бывало такое, что я брал техническую таску и бросался в нее с головой. Без плана, без критериев завершения задачи. Ведь она техническая, я знаю, что делаю, возьму и затащу ее. Зачем мне эти выдумки. Проходит неделя, две, и вроде бы есть результат. Но сказать, что решение внедрено, нельзя. А может я его внедрил, но оно оказалось не очень-то нужным. И от этого пыл угасает, и в следующий раз уже не хочется опять включаться в переговоры с продакт-менеджером.
Позже я понял, как важно применять к техническим задачам такие же правила, какие мы применяем к бизнесовым. Важно говорить с продакт-менеджером и любым другим менеджером на его языке. Вместо «все будет плохо» лучше сказать что-то вроде «эта проблема принесла нам убытки». И если эту проблему решить сейчас, она больше не повторится.
При этом важно самому здраво оценивать необходимость решения задачи, которую вы пытаетесь тащить. Это позволит в будущем избежать ощущения ненужности проделанной работы. И не забывать задавать критерии, по которым вы поймете, что задача сделана и цель достигнута, то самое definition of done, а также сроки. Если таска большая, стоит разделить ее на несколько этапов и определить дедлайн для каждого. То есть работать точно так же, как если бы это была бизнесовая задача от менеджера.
Все это сделает процесс работы над техническими задачами прозрачнее и для вас, и для менеджера. И даст обеим сторонам понимание, что вы делаете только то, что действительно необходимо, и что вы можете доверять друг другу.
Выводы
Я раньше смотрел на все эти большие корпоративные тулы типа GitHub, TeamCity и Kibana, и сторонился их. Казалось, что нужно обладать недюжей компетенцией, чтобы влезть и что-то в них поправить. Позже для меня открылось, что можно смотреть на эти инструменты шире и найти более простой путь для воплощения своих идей в жизнь. Вы же не изучаете Git до уровня хранения данных в файловой системе, чтобы применить какой-то алиас. Вы просто смотрите на популярные команды и сохраняете их в алиасы.Точно так же и с крупными инструментами. Иногда вместо глубокого погружения в инструмент можно просто написать логин к ним или небольшое приложение, которое будет использовать внешний API. Или написать бота в Telegram, который будет автоматизировать рутинные ежедневные операции.
В том же кейсе с Kibana. Там приходилось совершать много действий для того, чтобы найти логи приложения. А что если просто взять и написать расширение для браузера, которое будет совершать те же самые клики за вас и позволит искать приложения из списка? В случае с релизами в прод идеальным решением был бы пересмотр вообще всего пайплайна релизов, но это долго, и, наверное, это не по силам сделать одному разработчику. Но почему бы вместо этого не написать бота, опять же, в Telegram, который будет напоминать вам о назначенном релизе?
Пока это просто мысли, идеи того, как я сам улучшил бы эти истории. Возможно, у вас возникли какие-то свои мысли, как это можно пофиксить более правильно и более просто. Если это так — отлично. Большие инструменты могут выглядеть устрашающе, но если проявить творческий подход и посмотреть шире, можно увидеть очень много возможностей.
Весь этот рассказ не только для того, чтобы рассказать, как хорошо у нас в QIWI и что мы делаем для того, чтобы развивать инструменты. Нам еще есть к чему стремиться. Этот пост еще и для того, чтобы вы взглянули на свои процессы. Попробуйте копнуть глубже в инструменты, и, возможно, увидите, что из них можно вытянуть больше. Не только повысить удобство, но и качество работы, производительность.
Давайте работать над тем, чтобы улучшать свой experience. Попробуйте наточить пилу, и, возможно вы увидите, что ваша работа стала эффективнее и приятнее.
Developer Experience — как упростить себе жизнь с помощью правильных инструментов
Привет! Продолжаем публиковать текстовые версии докладов с QIWI Server Party 6.0, в этом посте — Александр Прокопьев и Developer Experience. Про инструменты, их качество и развитие инструментов...
habr.com