Так не сойдет


Гео и язык канала: Россия, Русский
Категория: Технологии


Привет!
Я Саша, руководитель отдела разработки платформы СХД в Yadro.
Буду что-то писать в этот канал, вы будете что-то читать, ставить реакции и писать комменты. Trade offer
Личка: @syberside

Связанные каналы

Гео и язык канала
Россия, Русский
Категория
Технологии
Статистика
Фильтр публикаций


Перешли сам себе письмо

Год назад я сменил место работы на YADRO.
YADRO - это большая компания, так что общения по почте у меня стало сильно больше.

Часто в письмах оседает нужная информация, но найти ее бывает сложно.
Есть хороший совет, который мне помогает:

Если видишь, что переписка важная, то перешли ее сам себе!


Тема письма: переформулируй её так, чтобы она точнее отражала суть переписки.
Тело письма: добавь краткое саммари и ключевые слова, по которым быстро сможешь найти тред в почте.
Получатели: только ты сам. ⚠️ Не забудь удалить всех остальных!

Также можно настроить в почтовом клиенте/сервере правило, чтобы такие письма сразу улетали в отдельную папку и помечались как прочитанные.

Совет хороший, а откуда взял — не помню. Если знаете источник — напишите в комментариях.


Репост из: Инженер и Менеджер
Увидел в блоге Спотифая цитату:

The fewer technologies we are world-leading in, the faster we go.

И вспомнил историю.

Очень давно жила-была команда, которая ОЧЕНЬ любила новые технологии. Это были отличные инженеры, без дураков. Я бы каждого с огромным удовольствием схантил бы сейчас.

И вот, эта команда берется за новый проект. Тащит туда новый для компании фреймворк, новые паттерны, новые библиотеки — все то, что обсуждало комьюнити. Bleeding edge technologies. Инженерная мечта! Я тогда еще активно писал код и очень хотел поработать у них в команде, потому что ИНТЕРЕСНО.

Помню, пытался поймать парней в курилке, чтобы выпытать: НУ КАК ОНО ТАМ? Как новые паттерны? А фреймворк?

Завидовал я парням белой завистью, короче.

Правда, проект не успел релизнуться ни в указанную дату, ни месяц, ни даже квартал спустя.

В курилке я начал слышать уже не восторги на тему новых инструментов, а явное непонимание: как с этим жить?

Какими бы крутыми инженерами они не были, они были ПЕРВОПРОХОДЦАМИ и часть проблем решали одними из первых в индустрии. Важно: они их решали, но решали медленно. Там, где в скучном старом фреймворке даже не надо было голову включать, в интересном новом фреймворке нужно было тратить дни и недели на выработку нового решения.

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

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

Итог: опоздавший релиз + медленные итерации = потеря потенциального рынка.

—

Но инженерный руководитель обязан развивать технологии. Я так же видел компании, которые остались на уровне 2010-ых: буквально без CI/CD. Это не фигура речи, я не шучу. И таких много.

Чтобы выдержать правильный баланс, нужно:
1. Использовать скучные технологии — это как раз то, что пишет Спотифай. Не стремитесь становиться первопроходцами.
2. Не использовать более одной новой технологии за один раз.

Если дела пойдут не по плану, одну новую технологию вы как-нибудь заборете.

А если по плану, то двинете технологический стек компании вперед.

—

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


Согласен с автором на 100%!
Дополню: взять новую технологию в проект - это всегда эксперимент. У любого эксперимента должна быть точка оценки успешности и принятия решения продолжать или нет.


Репост из: Инженер и Менеджер
Менеджмент 10 лет подряд понимает выученную беспомощность неправильно.

И делает все наоборот. Наоборот!

Чтобы нормально объяснить, давайте вспомним, что такое выученная беспомощность, которую любят упоминать с умным видом менеджеры. Если знаете, следующие два параграфа можно пропустить.

🐀 Оригинальный эксперимент: две группы крыс бьют током. Одна группа может выключить ток кнопкой. Вторая — не может, хоть обнажмись. Потом первую и вторую группу посадили в новые клетки.

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

Эффект назвали "выученная беспомощность". Типа, крысы после тщетных усилий отказывались учиться.

👨‍💻 Менеджмент концепцию нежно полюбил. Ну а как не полюбить? На выученную беспомощность много чего можно свалить. Ну вот принес ты новую инициативу в команду, а команда ее отвергла.

Ты что ли плохой?

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

🔬 А потом в 2016-ом случилось неприятное.

Те же авторы выпустили статью, где буквально сказали ПАЦАНЫ, ВСЕ НЕ ТАК! Мы неправильно все поняли! Но так как новые выводы мало кому понравились, новая трактовка не получила популярности.

В новой статье написал: беспомощность — дефолтное состояние организма.

Ей нельзя НАУЧИТЬСЯ, она и так является нашей базовой настройкой. Когда крыса нажимает на кнопку и останавливает ток, она УЧИТСЯ тому, что ее действия работают. А если результата нет и ток продолжает бить — не учится. То есть: нельзя научить беспомощности. Наоборот, живой организм можно научить контролю.

Ощущаете разницу?

Получается, нет никакой "выученной беспомощности" — есть команда, которую никто не научил контролю. Не показал, что их действия влияют на результат.

В экспериментах "беспомощным" крысам помогло только одно: их брали и переносили на другую сторону клетки. Раз за разом. Спустя несколько попыток, крысы все-таки начинали сами перепрыгивать на ту сторону клетки, где тока не было.

📌 Перевожу на менеджерский.

Если люди пассивные и не предлагают идей, это не "выученная беспомощность" — это менеджер не показал, что их действия на что-то влияют. Менеджер ДОЛЖЕН показывать эффект от предложений своих сотрудников. Даже больше — менеджер должен СОЗДАВАТЬ такие ситуации.

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

И пожелайте приятного осознания.


Репост из: FEDOR BORSHEV
Не писать тесты с LLM

Со всех сторон слышу, как люди генерят тесты при помощи LLM. Чуваки, так делать нельзя! Это видимость тестирования, прямо как assertion-free testing.

Когда кожаный мешок пишет тесты (не важно до кода или после), он работает не над ними, а над кодом, который тестирует. Обрабатывает edge-кейсы, которые не пришли бы в голову, если бы он не сел писать тесты. Улучшает testability — раскладывает код по коробочкам, уменьшает связность, добавляет DI если надо. В конце концов, человек создаёт фреймворк для тестов — фикстуры для бизнес-сущностей, моки, которые потом можно переиспользовать.

Всё это делает тесты не только более надёжными, но и читаемыми. AI так не умеет — он делает код, очень похожий на тесты. Даже если он будет соблюдать формальную читаемость на основе ваших примеров — думать за вас он, увы, не будет.

Кароч, не пишите тесты через LLM. Если скучно — подумайте лучше, как создать себе фреймворк, который сделает это нескучным.

---
Пятый поток «Анализа систем» стартует 6 октября. Приходите, чтобы научиться делать большие системы так, чтобы вас за них не уволили.
---
15 октября в 17:00 MSK — вебинар «
Простой код» с Толей Буровым. Приходите, чтобы научиться объяснять джунам (или научиться самому), чем понятный код отличается от непонятного.

100 0 1 13 14

Репост из: FEDOR BORSHEV
Публиковать идеи

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

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

Пока идея сидит в голове, она занимает место. Автору идея может казаться бесконечно гениальной, жрать кучу энергии на свою полировку, поддержку и восхищение. Но пока идея в голове — новая на её место не придёт. Как только идея обретает завершённость — картинкой в «мозге», постом в телегу, задачей сотрудникам — на её место приходит новая. Так работает человеческое сознание.

Конечно, процесс публикации идеи должен быть сложным — иначе все идеи осядут в заметах и тудулистах в виде сырого говна. В момент публикации идею полируют, додумывают, или вообще выкидывают. Поэтому в «мозге» есть минимальная социальная составляющая — картинки видят другие. Сырое говно туда не выложишь. Из-за этой социальной составляющей, кстати, телеграм-канал на 50 человек лучше, чем заметочник, который даже вы сами перечитывать не будете.

Кароч, не носите идеи в голове. Начинайте их описывать, думайте кому и как показать. А то рискуете всю жизнь просидеть с единственной гениальной, но никому не известной идеей.


Мой канал появился по такому же принципу. Когда я обнаруживаю, что возвращаюсь вновь и вновь к какой-то мысли, то сажусь писать пост. «Додумаваю» мысль до конца, придаю ей законченную форму, упаковываю в формат заметки. И освобождаю пространство для чего-то нового.
Это действительно работает! :)


Как оценивать сроки и трудозатраты

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

⌛️ Выделите время на оценку
Оценка - это тоже работа. Иногда, даже более сложная, чем основная задача…
Необходимость срочно дать оценку - не повод тыкать пальцем в небо.
И вы, и спрашивающий, рассчитываете: на оценку можно опираться в принятии решений, вы готовы нести ответственность за озвученное. Если это не так - лучше обозначить и взять время на проработку.

🎯 Определите желаемую точность
Точность оценки не линейно зависит от потраченного времени. Чем больше времени тратим, тем ниже ROI.
Желаемая точность обычно соотносится с размером задачи. Для квартального планирования подходит недельная точность; чтобы спланировать месяц - дни; для плана на день - часы.

📋 Декомпозируйте задачу
Чем мельче декомпозируете - тем лучше. В разумных рамках.
Составить всеобъемлющий план - задача утопическая.
Но разбивая большую задачу на маленькие мы начинаем лучше ее понимать, выявляем зависимости и ограничения.

❔ Отделяйте известное от неизвестного
Пожалуй, самый значительный фактор для точности оценки - это понимание задачи.
Оценить привычную работу мы можем достаточно легко; оценить то, с чем сталкиваемся впервые - иногда вовсе невозможно.

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

🔬Для непонятных частей проводите дополнительные исследования
При наличии времени, проведите дополнительные исследования для крупных и непонятных задач.
Если прояснить не удаётся, то обозначьте это явно в плане.

🚧 Разделяйте трудозатраты и сроки
Трудозатраты - это сколько времени займет «полезная нагрузка».
Сроки - сколько пройдет от начала до конца работы.
На сроки сильно влияют зависимости, доступность коллег, очередь в CI и пр.
Иногда даже маленькую задачу приходится ждать днями - об этом стоит помнить.
Иметь нужно обе оценки.

⚠️ Явно обозначайте риски и зависимости
Про работу с рисками я писал в этом посте. Зависимости - это всегда риск.
При необходимости, закладывайте в оценку время на решение самых вероятных проблем.

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

🪚 Точите пилу
Умение оценивать - это такой же навык, как и другие.
Пробуйте, ошибайтесь, анализируйте и пробуйте снова!

💡 И самое главное…
Никто не любит, когда пристают с вопросом «Когда уже сделаете?!».
Но ведь и приставать с распросами никто не любит тоже!
Оценка сроков это инструмент, который вы можете использовать чтобы самостоятельно управлять своим временем и создать комфортную рабочую атмосферу.


Как внедрять линтеры (2/2)

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

2. Подключите линтер к проекту
Убедитесь, что линтер подключается на машине нового разработчика автоматически.
Большинство платформ предоставляют анализаторы в виде зависимостей, а инструменты поддерживают шаринг настроек через git.
Если требуется ручная настройка, включите ее в онбординг.
Правила анализа на данном этапе лучше оставить пустыми или включить 1-2 правила для теста.

3. Встройте выполнение линтера в CI
Без CI разработчики будут забывать выполнить линтер вручную и не качественный код будет просачиваться в master.

4. Постепенно включайте правила и настраивайте их под команду
За основу лучше взять готовый пресет, поставляемый с инструментом.
Включение очередного правила лучше сливать в master через отдельную ветку без функциональных изменений.
Так вы убедитесь, что вся команда получит новую версию настроек как можно скорее.

СОВЕТЫ

⚠️ Избегайте уровня warning
Старайтесь принимать «бинарное решение»: либо считаем несоблюдение правила ошибкой (error), либо выключаем его (none).
Warning подразумевает, что человеку необходимо принять решение, а наша цель - избавиться от ручного труда.
Плюс они подобны баннерам: со временем их перестают замечать.

⚡️ Любое решение сейчас лучше, чем идеальное решение никогда
Цель не в том, чтобы выбрать самые правильные настройки.
Цель в том, чтобы договориться до единых подходов.
Если коллеги не согласны с предлагаемыми настройками, не слишком старайтесь переубедить их.
Мнения могут отличаться, но главное - чтобы коллеги согласились соблюдать принятые правила.
Disagree, but commit!

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

Пример к последним двум пунктам
В .NET запятая после последнего аргумента инициализатора является опциональной.
В одной из команд мы договорились не ставить ее, в другой - ставить обязательно. А в третьей - вовсе решили, что нас устраивает любой вариант и отключили правило.
Все варианты имеют свои плюсы и минусы
, приводят к разным последствиям.
Неважно какой был выбран, главное - IDE автоматически форматировала код исходя из настроек линтера.

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

⏳Не ждите позитивных улучшений в краткосрочной перспективе
Помните, что настройка линтеров - это инвестиция, а значит окупается в долгосрочной перспективе.
Первое время, неудобства будут обнаруживаться спонтанно. Будьте готовы реагировать оперативно.

🙏 Подготовьтесь к критике и просьбам сделать исключение
«Нам сейчас очень надо», «нет времени исправлять», «сейчас зарелизим, потом поправим» и подобные фразы вы будете слышать очень часто.
Проявите эмпатию, но не позволяйте исключениям свести на нет ваши усилия. Иначе получите exceptional debt (см. The Elegant Puzzle).

Описанным я пользовался много раз
Самый показательный пример из моей практики - внедрение SonarQube в «Мой спорт».
Встроив его в CI, я снял с себя необходимость вручную контролировать выполнение архитектурных правил.
Накопипастить код и не покрыть его тестами, сделать класс с 10ю зависимостями на 700строк кода и т.д. стало невозможно. CI не пропустит такую ветку.
Дополнительный профит: правила перестали восприниматься как «бюрократия». Если раньше мне приходилось выступать источником негативного фидбека, то теперь за меня это делает CI. А с ним спорить бесполезно.

Надеюсь, мой опыт пригодится и вам 😉


Повышаем продуктивность разработки с помощью линтеров (1/2)

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

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

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

Каждое замечание - это прямые расходы:
- написать комментарий,
- поправить комментарий.
Но они мелочь по сравнению с расходами косвенными:
- переключить контекст,
- визуально заметить проблему,
- найти это место в PR,
- …,
- прочитать коммент,
- понять его,
- найти нужное место в коде,
- закоммитить и т.д.

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

Цель ревью - проверка смыслов, а не формы
Примеры смыслов - это зона ответственности класса, уровень абстрагированности кода от фреймворка, качество моделирования бизнес-домена.
Примеры формы - длина строки/метода, размер классов, переносы/скобочки/запятые, опечатки.

Проверку смысла автоматизировать практически невозможно.
Некоторую пользу в этом могут оказать LLM, но заменить мешок с костями они пока не способны.
Автоматизировать проверку формы - легко.

Линтеры и форматеры - cамый популярный инструмент проверки формы.
Помню, как 8 лет назад техлид моей команды писал собственную утилиту для проверки форматирования кода.
Сегодня, к счастью, этим заниматься не нужно.
У любого популярного языка программирования уже есть богатый набор линтеров и инструментов для автоматизации проверки стайлгайда.
Pylint, Prettier, go fmt, dotnet format, you name it!
Возможностей стандартных инструментов должно быть достаточно для 90% случаев.
Для оставшихся 10% можно написать свои проверки (как пример - roslyn analyzers).
Для более сложных проверок (архитектурных правил, тестового покрытия, дублирования и т.д.) помогут архитектурные тесты, фитнес функции и quality gates на основе них.
Например, в «Мой спорт» мы отказались от устаревшего способа аутентификации, который был реализован на балансере и требовал начинать url сервисов с определенного префикса. Чтобы избежать добавления новых некорректных АПИ методов - добавили TypeScript тест, который проверяет JSON schema всех сервисов на использование этого префикса.

Инструментов вагон и маленькая тележка, внедряй - не хочу!
Как? Об этом дальше 👇


🌚 Инструменты для команды: как «пасхалки» экономят десятки часов

В классической трилогии Grand Theft Auto (GTA 3, GTA Vice City, GTA San Andreas) есть интересная пасхалка.
Если выстрелить из снайперской винтовки в луну, то она поменяет размер.

Пасхалка - на самом деле встроенная «фича» для дизайнеров.
Дизайнеры попросили разработчика поменять размер луны… и не пришли к консенсусу, какой размер оставить.
Тогда разработчик добавил возможность менять размер луны без изменения кода.
Так дизайнеры могли сами пробовать разные размеры луны в разных локациях.
В итоге, «фича» дожила до релиза игры и пришлась по душе фанатам серии.
Почитать подробнее можно, например, на DFT.

Это отличное решение!
👍 Эффективно: добавив такой инструмент, разработчик смог не ждать решения от дизайнеров и не тратить время «играясь» с размером луны.
Трудозатраты явно окупились слихвой.
👍 Удобно: проверить разные варианты можно прямо в игре. Не нужно заморачиваться с параметрами конфигурации, что-то пересобирать или перезапускать.
Добрался в игре до нужно локации, настроил луну и тут же оценил результат. А удобство ведет к более качественным решениям, т.к. можно проверить больше комбинаций меньшими усилиями.
👍 Отношение к внутренним потребностям разработчика (в широком смысле, всей компании) как к пользовательским требованиям.
Раз у коллег есть необходимость менять этот параметр - значит он должен быть частью продукта, по крайней мере на этапе разработки.

Инженеры - тоже пользователи продукта
Более релевантный для большинства пример - это инструменты для тестирования.
Например, мы встраивали в мобильные приложения возможность менять окружение (экземпляр бэкенда) в скрытом интерфейсе внутри приложения.
До этой фичи, тестировщикам приходилось ждать пока CI соберет версию с нужным бэкендом.
Экономия - колоссальная: часы или десятки часов в неделю.
Естественно, такая фича не была запросом менеджера продукта. Для него важно только чтобы задачи делались качественно и в срок.
Это была инициатива команды, которая помогла ей стать эффективней.

Не обязательно подобные инструменты должны представлять собой «пасхалку».
В SaaS можно реализовать их как АПИ методы закрытые авторизацией, чтобы только определенная группа пользователей могла воспользоваться ими.
Например, мы делали внутреннее АПИ для принудительного запуска статистических расчетов и выгрузок.
При штатной работе они формируются по расписанию, но если что-то пошло не так - их можно запустить принудительно.
СТП получили возможность перезапустить расчеты не дожидаясь исправления от разработки.

Это всего пара примеров, но по ним видна рекомендация: инвестируйте время в создание внутренних инструментов.
Похожие рекомендации можно встретить и в книге по QA, из прошлого поста.
Я с ними полностью согласен, это хороший пример синергии в команде.

⚠️ Добавлять такие возможности нужно осторожно
Инструменты должны гармонично расширять фичи системы, а не приводить к их некорректной работе.
Не должно возникать нарушений информационной безопасности, консистентности данных и прочих проблем.

❔ Добавление подобных инструментов - лишние расходы?
Поначалу, я думал именно так.
Однако, эффективность расскрывается в масштабе.
В любом продукте найдутся десятки, если не сотни подобных улучшений, способных сэкономить массу времени.
Такие вещи часто незаметны в силу выработанных привычек. Мы привыкаем к неудобствам и воспринимаем их как должное.

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


Тестирование программного обеспечения: контекстно ориентированный подход

Тестирование и обеспечение качества, пожалуй, одна из самых близких к разработке областей.

Чем больше я рос как инженерный менеджер, тем больше нужно было понимать работу коллег из цеха тестирования.
Для общего понимания, я прочел QA Bible.
Нового узнал немного, но структурировал уже известные темы.
Тем не менее, мой запрос оставался открытым.
Главным образом, хотелось разобраться с верхнеуровневыми стратегическими вопросами, например «стратегией тестирования».

В одной из рассылок издательства «Питер» была аннотация на книгу «Тестирование программного обеспечения: контекстно ориентированный подход».
Аннотация понравилась, сложилось впечатление, что в книге изложен реальный опыт «выстраданный» годами.
Мне интересна была именно практика, а не теория. Поэтому я остановил свой выбор на данной книге.

🥵 Книга далась мне нелегко
По сути, вся книга - это набор советов, разделенных на тематические блоки.
Сами по себе советы написаны хорошо: краткие, понятные, привязанные к контексту, часто сопровождаются опытом авторов и (ого!) мнением рецензентов книги.
Но читать их подряд сложновато. Между ними не всегда присутствует связь из-за чего тексту не хватает «плавности».
Тем не менее, я рад, что прочитал книгу.

Что мне понравилось в книге
➕ «It depends» идет красной линией через всю книгу. Теперь я лучше понимаю, какие компромиссы нужно принимать, когда дело касается качества.
➕ Акцент на «служении» - задача QA предоставлять сервис. Какой? Дать ответ на этот вопрос - тоже задача тестировщика. И это не такой простой вопрос, как может показаться!
➕ Книга неплохо расширяет кругозор. Со временем глаз замыливается, а советы в книге даются для разных областей и ситуаций. Можно подчерпнуть что-то новое.
➕ Больше всего в книге мне понравился раздел про карьеру. Советы в этом разделе универсальные.
➕ Раздел про стратегию тестирования полностью закрыл мой запрос 👍

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

Стоит ли ее читать вам?
Думаю книгу стоит читать, только если есть достаточно большой прямой или косвенный опыт в тестировании.
Без «насмотренности» советы просто не будут работать.
Если же хотите найти «учебник» позволяющий погрузиться с тему с нуля - то книга точно не подойдет.

P.S.: Посоветуйте ваши любимые книги по тестированию в комментариях 🫰

#книги


caffeinate

Открыл для себя небольшую полезняшку, встроенную в macOS: caffeinate.
Это консольная утилита, которая позволяет временно отключить спящий режим и блокировку экрана.
Пока команда выполняется - экран не заблокируется.

Иногда мне необходимо выполнять какие-то длительные скрипты.
Переход в спящий режим разрывает соединение с удаленным сервером и приходится делать все по новой.
Утилита это решает: запустил ее в отдельной табине консоли и можно смело идти заваривать кофе.

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

С консольной утилитой как-то удобнее.
Плюс ее можно встраивать в скрипты и накручивать поверх автоматизацию.

Подробнее про утилиту можно почитать, например, тут.

P.S.: Подскажите такую же утилиту, только на монитор LG, который все равно выключается 😆


Техдолга не существует 🤯

🔙 В предыдущем посте я рассказывал про стратегии борьбы с техдолгом и отметил, что стоило начать с определения.
Мы часто используем понятия на автомате, не вникая в их суть.
А при детальном разборе оказывается, что всё не так однозначно 🤓

Так что же такое техдолг?
Чтобы сильно не мудрить, возьмем за отправную точку определение из Википедии:

Технический долг […] — это метафора […], обозначающая накопленные в программном коде или архитектуре проблемы, связанные с пренебрежением качеством […] и вызывающие дополнительные затраты труда в будущем.


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

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

Приведу более зацепившую меня формулировку: «задача продуктовой команды - уменьшать беклог, а не увеличивать его»
(с) Олег Семыкин, по крайней мере от него я услышал эту фразу.

Если команда выполнила «продуктовую» задачу и положила в беклог две «технические», то бэклог увеличился, а не уменьшился.
То есть команда поработала в минус! 👎
Это просто-напросто плохо сделанная работа, как ни завуалируй ее под необходимость в моменте, сложности и прочие обстоятельства.
Поэтому, с точки зрения конечного результата, техдолг это лишнее понятие.

Зачем же тогда появился отдельный термин?
Мне кажется, что причина банальная: человеческая лень 🦥
🤔 Объяснять комплексные технические вещи - сложно.
🤔 Думать, как «рефакторинг вот этого класса принесет ценность бизнесу» - сложно.
🤔 Отстаивать свое мнение - сложно.
🤔 Вникать во все эти нюансы и задавать инженерам «глупые» вопросы - сложно.
🤩 А вот сказать «это техдолг» и молча кивнуть в ответ - просто.
Но ведет это к тому, что формируется два отдельных бэклога, а люди разобщаются.
Ведь у каждого теперь свои цели и приоритеты.

Суть команды в достижении синергии ✨
Когда, на уровне вложенных усилий, 1+1=3 🤝, тогда команда и оправдывает свое существование.
Синергия отличает команду от, например, рабочей группы.
И чтобы команда стала командой, нужны взаимные усилия всех участников.
Инженерам и менеджерам надо преодолевать упомянутые «сложности», двигаться навстечу друг другу и не выбиваться из канвы общих целей.

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


Стратегии работы с техническим долгом

С тех.долгом рано или поздно сталкиваются все команды.
Бороться с ним можно по разному.
От самых простых к сложным, можно выделить следующие стратегии.

0️⃣ Игнорировать техдолг
Техдолг никак не контролируем и не исправляем.
В долгосрочной перспективе это замедлит скорость разработки, а то и вовсе сведет ее до нуля.
Но в краткосрочной перспективе такая модель даст ускорение.
Применять нужно аккуратно, в краткосрочных проектах, сопровождать которые не придется.

1️⃣ Заводить задачи на техдолг, но не делать их
Зачем заводить задачи, которые никогда не будут сделаны?
В лучшем случае, вы привлечете внимание коллег к проблеме и сможете что-то поменять.
В худшем - через время вернетесь к списку техдолга и оцените как он повлиял на проект.

2️⃣ Исправлять техдолг эпизодически
Устранять техдолг не системно - лучше, чем не исправлять вовсе.
Стретегия применима, когда в проекте не налажен конвеер по поставке продуктовых задач и нагрузка на команду идет “волнами”, с непредсказуемыми задержками.
Однако, контролировать состояние продукта и размерено работать в таком подходе проблематично.

3️⃣ Использовать фиксированное capacity для устранения техдолга
Например, можно выделять 20% в каждом спринте или тратить 1 неделю раз в квартал.
В данном подходе возврат долгов уже становится частью повседневной работы.
А значит и отношение к нему формируется соотвествующее.

Но есть и подводные камни:
- соблазн использовать слоты под техдолг не по назначению, снижая качество фичей;
- со стороны может казаться, что команда тратит % времени на бесполезную работу;
- соблазн выделить под это капасити отдельных людей или целую команду и разорвать цикл обратной связи.
Поэтому такой подход требует аккуратной коммуникации и контроля.

4️⃣ Контролировать размер техдолга
«Почему именно 20% или 1 неделя?»
Если при прочтении предыдущей стратегии у вас возник такой вопрос, то я вас поздравляю, вы на правильном пути! 🤝
20% может быть как много, так и мало, в зависимости от текущего состояния проекта и целей.
Чтобы понять, какой % времени выделять, нужно ввести метрику и контролировать ее динамику.
Не суть в чем измерять, главное чтобы было отслеживаемое число.

Плюс подхода - появляется обратная связь в виде метрики, контролируем ситуацию.
Минус - трудозатраты на обслуживание тех.беклога.

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

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

Этот подход устраняет проблему прозрачности технических работ, но требует стойкости в отстаивании технических работ.

6️⃣ Не добавлять техдолг 🙅‍♂️
Не считать «выполненной» задачу с явными проблемами в реализации.
Это звучит идеалистично, но я верю в возможность такого подхода.
Не во всех ситуациях, но чем чаще он применяется - тем более реалистичным становится.

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

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

🤔 Какая стратегия лучшая?
Конечно последняя!!!1
Хорошая стратегия соответствует целям проекта, его состоянию и коллективу.
«Не плодить техдолг» - это (недостижимый) идеал, к которому (тем не менее) стоит стремиться.

Пост подразумевает: объяснять, что такое техдолг не нужно.
Понятие однозначное… или нет? Об этом следующий раз 😉


Создавать системы, которые работают без твоего участия

Внезапно осознал, что это универсальный навык/образ мышления.

🌱 Когда ты разработчик

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

Пример 1: разработчик пишет ошибку в лог и возвращает код ответа 200 OK.
- Хорошо, а как мы узнаем, что у нас что-то работает некорректно?
- Посмотрим в логи!


Такой ответ - «звоночек». Просмотр логов подразумевает, что это кто-то должен делать.
Сразу возникают дополнительные вопросы: кто будет смотреть в логи, как часто, как убедиться, что он не забыл и т.д.
То есть вокруг созданного кода возникает необходимость выстраивать какие-то процессы сопровождения.
Да, они всё равно нужны. Но их объёмом и требуемой квалификацией сопровождающих можно управлять.
Иначе получается, что бизнес, заказывая фичу, вместо экономии денег получает дополнительные расходы.

Пример 2: разработчик делает фичу, которая зависит от конфигурационных данных в БД. Способ внесения этих данных не делает.
Если на проекте всё в порядке с информационной безопасностью и регулированием доступа к средам, то такая фича просто не заработает в проде. Нужным данным-то взяться неоткуда.
Но в маленьких компаниях могут быть незрелые политики ИБ, допускающие подобное.
Как следствие, и без того ограниченный ресурс разработки тратится на какие-то ручные манипуляции с БД.
И этот эффект копится с каждой подобной фичей.

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

🪴 Когда ты тимлид

На уровне тимлида к описанному добавляется команда.
Когда встречаю в резюме пункты вроде «управляю командой из X человек: распределяю задачи...», то для меня это красный флаг.
Хочется включить токсика (спалился, гы 😬) и спросить: разработчики в команде – это пятилетки, которые без вас не разберутся, как вместе сделать общее дело? Или вам нужно как-то оправдать свою необходимость перед бизнесом?
Спасибо Стратоплану, в котором Слава Панкратов рассказывал нам про «мясных роутеров»!
А если серьёзно, то для меня это просто показатель незрелости команды и её лидера.

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

Поэтому задача тимлида, на мой взгляд, это построить такую команду, которой тимлид не нужен в краткосрочной перспективе.
Операционка должна быть так налажена, чтобы всё работало как часы – само по себе и чётко.
И тогда появляется время на другие активности: стратегическое развитие команды и подходов, помощь тиммейтам в развитии, возможность самому поработать руками. Да и человеческую эмпатию и эмоциональный интеллект проще проявлять, когда от тебя не ждут 10 ответов сегодня, иначе фичу не сделают, релиз не выкатят и всех уволят.

🌳 Когда ты руководитель разработки

На уровне выше индивидуальные исполнители превращаются в команды.
Процессы взаимодействия и связи становятся сложнее, ответственность и сложность решений – выше.
Появляется над-команда тимлидов. Становится больше взаимодействия с другими отделами.
В общем, всего больше и всё сложнее…
Но, как мне кажется, ключевая задача остаётся прежней: создать такую систему, чтобы команды выполняли цели бизнеса без твоего микроменеджмента.

Другими словами, цель – создать самодостаточную систему, а не систему, которой нужно «управлять».
Что это за система – техническая или социальная – уже деталь реализации…
Хотя, возможно, я слишком упрощаю и неуместно притягиваю всё к одной простой абстракции 😁
А вы как думаете, есть в этом здравое зерно?

#софты


Пятничное 🤡


Курс «Без ерунды» (dev ex) от школы сильных программистов

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

Термин developer experience я впервые услышал года 4 назад.
Для меня он стал недостающим кусочком пазла, одной из тех вещей, что интуитивно понимаешь, но не знаешь как назвать.
Вроде мысль, что надо налаживать продуктивный контекст для команды, очевидная:
* помехи на пути команды нужно устранять;
* инструменты должны быть удобными;
* с входящими и встречами нужно работать осознанно;
* о мотивации команды надо заботиться;
* с бизнесом надо разговаривать на языке бизнеса, налаживать диалог;
* ко всему, что делаете, нужно применять продуктовый подход.
Но одно дело знать теоретически. Другое дело - видеть применение всех этих пунктов в контексте конкретной ситуации.
Курс для меня стал эдаким клеем между разрозненными темами - от CI/CD до построения мостиков с бизнес-заказчиками.

Что отдельно порадовало - дак это то, что курс избегает частой ошибки, связанной с термином dev ex.
Многие компании воспринимают его так: «надо сделать набор инструментов на все случаи жизни, чтобы ускорить разрботку».
В итоге у компании рождается набор велосипедов, на которых можно ездить только в рамках компании.
Онбординг вместо ускорения удлиняется, ведь инструменты приходится изучать заново.
Разработчики понимают, что ценность изученного на рынке около нулевая.
В общем, эффект прямо противоположный задуманному.
В курсе же выбран другой вектор - вместо изобретения велосипедов, рекомендуют использовать стардартные для индустрии решения.

🙂 Еще несколько моментов, которыми курс понравился:
➕ Тема dev ex отлично раскрыта.
Считаю, что авторам отлично удалось показать 1) как кривой опыт разработчика сводит на нет продуктивность и 2) как можно подойти к решению этой проблемы.
➕ Простой и приятный сторителлинг. Лонгриды - это описание диалогов героев, которые в течении 4х недель фиксят продуктивность в соседней команде. Герои и ситуации получились живые, легко представить себя на их месте. Местами герои ломают четвертую стену - это забавно и в тренде сейчас.
➕ Много ссылок на дополнительные материалы и книги по темам. Курс получился не подвешанным в воздухе и, как бы, саммари по теме. После прочтения, понятно что еще почитать и куда покопать.
➕ Чувствуется опыт авторов в решении тех проблем, которые описаны. Много практичных идей - бери и пробуй!
➕ История происходит в компании, которая не является ИТ-компанией. Основной ее бизнес - это медиа. Выбор такой компании создает хорошие условия для донесения простой мысли, которая мне близка: разработка, для большинства компаний, это утилитарная функция. Это инструмент достижения целей «бизнеса», а не самоцель, как, например, для аутсорсов.

👎 Чем курс не понравился:
➖ Из последнего плюса вытекает и минус. Несмотря на то, что хороших идей в курсе много, применимость за пределами обозначенного контекста приходится докручивать самостоятельно. Если вы работали в разных компаниях - то сможете это сделать. Если нет - могут быть сложности.
Мой вывод по материалу: в продуктовых компаниях применить описанное можно, в проектных - сильно затруднительно.
➖ Откровенное хваставство за ваши деньги. Хз как это еще назвать, но местами в курсе начинается какой-то неуместный самопиар. Отсылки к другим курсам, в контексте происходящего, обычно уместны. Но вот когда, внезапно, герои начинают рассказывать друг другу, что «Марьяна (соавтор курса) задала вопрос Барбаре Оакли и даже сфоткалась с ней (и показывают это фото)», невольно задаешься вопросом «а какое это отношение имеет к моему обучению?!». Особенно иронично, что курс называется «без ерунды» и учит строить продуктивный контекст. А вам этот самый продуктивный (для обучения) контекст ломают, чтобы похвастаться.

В общем, минусов не много, а плюсов много.
Рекомендую к ознакомлению всем руководителям в ИТ!
Разработчикам тоже будет полезно, чтобы взглянуть на свою работу под новым углом.


Чеклист описания задач для разработчиков
https://cdn.tough-dev.school/materials/8-task-rules.pdf

Нравятся все пункты.
Но добавлю пару комментариев:
1️⃣ Пункт 4 «указана методика тестирования», я бы заменил на «how to demo», т.к. тестирование все таки более глубокий процесс.
2️⃣ Под задачей в данном чеклисте подразумевается целая фича - epic, а не отдельная user story.
И немного замечаний к примерам далее.

Первый пример - Делаем промо-коды для дня рождения
Заголовок содержит избыточное «делаем».
Представьте беклог, в котором все задачи начинаются с «делаем».
Зачем каждый раз писать это слов и тратить на него экранное место?…
Подобные слова лучше не использовать в заголовках.
К тому же, авторы сами говорят о том, что задача должна описывать результат, а не процесс.
Как улучшить: озаглавить задачу «Промо-коды для дня рождения» - этого достаточно.

Второй пример - «тип сотрудника» в отчетах для бухгалтерии
Тут у меня вопросов нет, пример отличный.

Третий пример - отрефакторить подсистему логистики
С первого взгяляда пример показался хорошим.
Но взглянув на него глазами разработчика, всплыли проблемы:
Во-первых, заголовок «отрефакторить» никак не специализирует решаемую проблему.
Во-вторых, по сути, в этом примере бизнесовая задача спрятана за технический термин. По определению, рефакторинг - это процесс изменения структуры кода без изменения его функциональных свойств.
Тут же в систему добавляются новые фичи - поддержка нескольких партнеров, алгоритмы выбора между ними. Это явно новое бизнес-требование, а не «рефакторинг».
В-третих, сама задача очень туманная. Про будущее много предположений, а про настоящее - требований мало. Так разработку может унести в проработку решения сильно наперед.
Как улучшить:
Заголовок: «Поддержка нескольких партнеров для доставки»
Текст:
И не дискредитировать слово «рефакторинг», пряча за него бинесовые задачи! =)

И напоследок, замечу, что чем раньше обнаруженна ошибка - тем дешевле ее исправить.
Поэтому ошибки в понимании задачи - самые дорогие.
Следовательно, самый главный пункт чеклиста - это пункт 4 how to demo.
Ведь этот пункт призван заранее дать команде понимание, как заказчик будет проверять, удовлетворяет ли результат его ожидания.


Правила команды

В одном из курсов напомнили хорошую практику - фиксировать свод правил команды.
Он не должен быть подробным и включать штрафные санкции, напоминать УК РФ или contribution policy к open source проекту.
Напротив - достаточно небольшого переченя неформальный правил, которые должен принять каждый, кто хочет стать полноценной частью команды.

Чем полезен такой свод правил:
🐥 для новичков - позволяет быстрее притереться к коллегам, понять, что ожидает команда и какая модель поведения поощряется;
🚀 для новых команд - договориться о том, как будете «вместе жить в общем скворешнике»;
🤝 для устоявшихся команд - неплохой тимбилдинг и способ вспомнить, почему цените друг друга и выбираете эту команду/компанию.

Пример из курса (мои комментарии - курсивом).

1️⃣«Если застрял - спроси»
Если ты несколько дней мучаешься со своей задачей и чувствуешь тупик — лучше попроси коллег о помощи, а не продолжай биться головой об стену.
-
На мой взгляд, время через которое пора идти с вопросом к другим, зависит от размера и сложности задачи.
Если вы стараетесь делать задачи маленькими и понятными (что очень рекомендую), то и время, через которое пора обратиться за помощью, будет минимальным.
Но чтобы это работало, в команде должна быть атмосфера доверия и поддержки.
Чтобы «задать вопрос» было естественной практикой, а не воспринималось как проявление не самостоятельности.

2️⃣«Не приходи на встречу без подготовки»
У нас не принято отсиживаться на встречах и ничего не отвечать.
Если идёшь на встречу — проверь, что у тебя есть всё, что необходимо, чтобы она прошла успешно.
-
Чуть уточню, что речь не только про изучение агенды и подготовку необходимой информации.
Подготовка включает в себя, в том числе, подходящие условия для встречи:
✅ в офисе - прийти вовремя со свежей головой. Не знаешь где переговорка - уточни заранее
; нужно выдохнуть после предыдущей встречи - спланируй время так, чтобы взять паузу.
✅ на удаленке - хороший интернет, отстутсвие шума на фоне и отвлечений на курьеров и прочее.
В целом, для меня этот пункт про уважение к времени других. Хорошая подготовка, иногда, заменяет встречу целиком.

3️⃣«Делать не равно сделать»
Нам не важно, почему ты не успел доделать, если ты делал-делал, но не сделал - это плохо.
-
Если у вас есть дейли, то советую прислушаться к тому, что на нем обсуждается: кто-что делал/будет делать или Сделал/Сделает.
В эту же копилку: данные обещания надо выполнять.
Да, бываю разные ситуации и никто не умеет идеально предсказывать сроки.
Но если потребовались сверхусилия для выполнения обещания, то всегда можно дать об этом знать руководителю и попросить дать время на передышку.
Да и предупредить об ошибке в оценке всегда лучше заранее.
Уверен, что любому руководителю, предсказуемость в подчиненных важнее других качеств.


4️⃣«Чья задача, тот и носится»
Если по задаче нужна помощь сисадминов или безопасников — это твоя проблема, а не проблема сисадминов и безопасников.
Не жди, что они сами себе за тебя напомнят.
-
Могу посоветовать следующее: если вы ждете, что кто-то сделает что-то для вас, то спросите, когда вы можете вернуться за результатом/напомнить о себе.
Никто не любит, когда к нему бегают каждый час с вопросами «ну чо там?!». Вопрос про сроки, хоть и может вызывать неприязнь, но позволяет вашему собеседнику ощутить контроль над ситуацией.
А это в свою очередь повышает ответственность.

Если у вас в команде еще нет подобного свода - можно начать с правил выше.
Они универсальные и надеюсь, понравились вам также, как и мне 🙂

Показано 20 последних публикаций.