Получи случайную криптовалюту за регистрацию!

Так не сойдет

Логотип телеграм канала @tak_ne_sojdet — Так не сойдет Т
Логотип телеграм канала @tak_ne_sojdet — Так не сойдет
Адрес канала: @tak_ne_sojdet
Категории: Технологии
Язык: Русский
Количество подписчиков: 75
Описание канала:

Привет!
Я Саша, DevHead в «Мой спорт» https://moisport.ru .
Буду что-то писать в этот канал, вы будете что-то читать, ставить реакции и писать комменты. Trade offer

Рейтинги и Отзывы

4.33

3 отзыва

Оценить канал tak_ne_sojdet и оставить отзыв — могут только зарегестрированные пользователи. Все отзывы проходят модерацию.

5 звезд

1

4 звезд

2

3 звезд

0

2 звезд

0

1 звезд

0


Последние сообщения

2023-02-04 10:04:52 О терминах не спорят, о терминах договариваются

Не знаю, кто автор этого аффоризма (гугл выдает Рене Декарта, но прямой цитаты я не нашел), но мне кажется он гений.

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

Внезапный инсайт мне подарил подкаст про микросервисы. В нем автор задал гостю вопрос абсолютно «не в тему» и выбил его из потока. Не помню суть вопроса, но помню, что подумал «интервьюер не понимает, что такое микросервисы». Я ожидал, что гость объяснит автору «где он не прав». Но его ответ меня удивил: «О терминах не спорят, о них договариваются. Давайте в рамках нашей беседы определим микросервис как …». И дальше пошла складная беседа.

Из всего подкаста я запомнил только эту мысль Меня поразило, как умело гость увернулся от холивара и установил общую почву для обсуждения.
С тех пор, в пылу обсуждения, я стараюсь задавать себе вопрос «не спорим ли мы о значении термина?». И если вижу, что понимаем какие-то термины по разному - стараюсь сделать следующее:
спросить собседника о том, как он понимает термин;
обозначить, что я понимаю термин немного по другому (не сильно вдаваясь в подробности);
предлагаю зафиксировать, что мы понимаем термин по разному, но суть обсуждения не в этом и вернуться к исходной проблеме.

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

Буду банален, но перефразирую цитату из начала поста: «не спорьте о терминах, договаривайтесь о решении исходной проблемы»
46 viewsAlexander Lozhkin, 07:04
Открыть/Комментировать
2023-01-28 19:15:21 Сначала научитесь играть по правилам, потом придумывайте свои

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

Этот принцип мне особенно запомнился, больше чем другие. Мне нравится примерять идеи из разных областей на разработку. Тимлид - это и менеджер и разработчик одновременно, поэтому взимное опыление в этих областях очень сильное. «Татуировка #1» хороший пример.

Разработчики - не глупые люди, как правило очень сильно не глупые. В то же время, изменить код гораздо проще, чем изменить какой-то объект в офлайн мире. Инженеру-физику не изменить законы физики, ему приходится учитывать их как данность. Разработчик же может менять фреймворки и подходы как перчатки.
Иногда простота изменения и наш пытливый ум играют с нами злую шутку - нам начинает казаться, что мы уже достаточно опытные и изучили все, что только можно. А дедовский метод написания кода устарел и необходимо затащить новый модный XYZ в продакшен вот прямо сегодня.
Только вот старые подходы и фреймворки, которые годами применялись в индустрии, никуда не деваются. Любая область знания накапливает best practices со временем.

- Дак что, получается надо использовать best practices и не смотреть по сторонам?
Конечно нет! Расширять кругозор обязательно нужно. Но подход, которого я стараюсь придерживаться, это «расширять best practices исключениями, а не заменять их».

Несколько примеров:
SOLID и GoF patterns. Сначала надо научиться писать понятный и структурированный ООП код, а уже потом добавлять элементы функционального программирования там, где они уместны.
DRY. Сначала надо научиться качественно обобщать код, а уже после начинать замечать ситуации где лучше этого не делать. И в них вносить дублирование, причем делать это осознанно.
Структурирование кода и распределение обязанностей. Сначала надо научиться писать качественные функции, потом классы, потом модули, научиться структрировать код на "слои". И уже тогда приступать к SOA и микросервисам.

Этот же подход хорошо ложится на условные грейды:
junior не знает best practices и только изучает их;
middle знает и «втыкает» их везде где только можно, следует им фанатично;
senior знает исключительные ситуации, когда от best practices надо отойти и почему.
Разработчик, который вдумчиво анализирует используемые подходы, скорее всего не будет переворачивать проект с ног на голову, а будет итеративно внедрять улучшения сохраняя то, что работает хорошо.

В общем, я «набил» себе эту татуировку, как универсальную и работающую почти в любой ситуации.
67 viewsAlexander Lozhkin, edited  16:15
Открыть/Комментировать
2023-01-15 13:53:46 Почему я сдаю мусор в переработку и при чем тут разработка

Где-то 3-4 года назад я заметил, что стал выносить мусор почти каждый день. Когда мы с женой переехали в СПб, то стали заказывать готовые рационы. Их привозят в пластиковых контейнерах, они занимают много места в ведре => ведро быстро переполняется.

Немного математики
Бросая каждый день пакет в контейнер на улице, я стал задумываться о том, как выглядят эти пакеты на свалке. Ведь даже в специально выделенном помещении под 1 дом зона сбора мусора выглядит ужасно!
В году 365 дней, если я выбрасываю мусор в 2 из 3х дней, то за год это 241 пакет. Представьте их разложенные на автомобильной парковке в один слой - это очень много пространства
Тогда я решил поставить эксперимент - один месяц не выбрасывать контейнеры с маркировкой 5 (PP). Уже через неделю оценил масштаб: помытые и аккуратно сложенные контейнеры занимали 1 пакет (+1 пакет прочего мусора за неделю). Даже если я выброшу все это в тот же контейнер - мусор уже займет в 2 раза меньше пространства. Да, на свалке мусор утрамбовыввают, но все же разница думаю будет заметна.

От эксперимента к привычке
Сейчас я сдаю бОльшую часть мусора в переработку. У меня выстроенна целая система:
помытые контейнеры/банки/прочее я храню на кухне в больших бумажных пакетах;
раз в неделю накопленное сортирую и складываю компактно. Если скопилось много - перемещаю в багажник машины, т.к. квартира маленькая;
раз в месяц-два отвожу в Собиратор (спасибо, Сева!).
Со временем это стало для меня автоматическим и естественным процессом.

Зачем я это делаю?
Я верю, что «культура» (в широком смысле) конкретного человека во многом формируется окружением. Если вы выросли в окружении, где бросить окурок мимо урны - норма, то и вы сами будете выбрасывать окурок мимо урны, даже не замечая этого. Но вместе с тем, окружающую культуру формируют те, кто в ней живет.
Если каждый будет делать все, что может, со своей стороны - ситуация обязательно будет меняться к лучшему. И я надеюсь передать свои ценности детям, когда они у меня будут.

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

При чем же тут разработка
- Воу, это все еще канал про разработку?
Да
Мысль, которая крутится у меня в голове, следующая: культура редко стоит на месте, она постоянно меняется под воздействием акторов внутри нее. Это справедливо и для «инженерной культуры».
Новый человек часто привносит какие-то идеи в команду, с одной стороны, и сам меняется под воздействием «так здесь принято», с другой.
Это стоит иметь в виду руководителям и учитывать при решении задач, например:
если мы начнинаем забивать на покрытие тестами, то со временем для нас становится нормой тестировать все вручную;
если кто-то начинает фиксировать итоги встречи - то другие, увидев пользу такой практики, тоже могут начать фиксировать (или просить зафиксировать).

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

Мы живем в мире трейдофов и важно не бинарное решение, а какие ценности вы для себя выбираете и в каком % ситуаций поступаете так, как считаете правильным. Какие выводы вы делаете когда решение расходится с вашими ценностями - исключение это или норма?
83 viewsAlexander Lozhkin, edited  10:53
Открыть/Комментировать
2023-01-10 20:50:31 Воспользуюсь базой подписчиков из 39 человек и запощу вакансию QA к нам в команду «Мой спорт» https://spb.hh.ru/vacancy/75568312
Буду благодарен за репост!
86 viewsAlexander Lozhkin, 17:50
Открыть/Комментировать
2023-01-06 15:04:31 Камиль Фурнье: От разработчика до руководителя

Книга попала ко мне случайно - подруга жены при переезде в другую страну подарила нам почти всю свою библиотеку.
Читать книгу я не планировал, но после прочтения DDD Хорикова, захотелось чего-то про менеджмент и чего-то бумажного

Книга удачно попалась под руку


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

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

Книга разбита на главы, соответсвующие условным грейдам. Но т.к. обязанности одной и той же роли в разных компаниях могут отличаться, то и рассмотренные темы, применимы не только к грейду в котором они описаны.
Например, делегирование рассматривается в главе посвященной управлению группой команд Мне же кажется, что вопрос об эффективном делегировании возникает сильно раньше, как только у вас появляется хотя бы один формальный (или даже не формальный) подчиненный.
Как результат - читать можно смело от корки до корки. Даже разработчику будет о чем порефлексировать после прочтения главы о работе СТО и стратегии.

Кому рекомендую к прочтению
1. Инженерам, которым не интересен менеджемент, но интересно развитие в более сеньорные инженерные роли. Чем сеньорней инженер - тем важнее в его работе умение коммуницировать с другими инженерами, ставить задачи. К тому же, часто сеньоры менторят младших коллег. Поэтому я смело рекомендую книгу инженерам middle+ уровня.
2. Начинающим инженерам-руководителям: техлидам и тимлидам. Собственно, эта категория кажется мне основной ЦА книги. Вам она позволит закрепить навыки и чуть лучше понять окружение в котором работаете: о чем болит голова у выших руководителей, о чем переживают подчиненные и как ваша работа выглядит для них.
3. Тем, кто еще не определился с вектором развития и присматривается к управлению инженерами.
4. Тем, кому интересно управление командами, даже если это не команды разработки. В книге очень мало технических вопросов и почти не используется инженерный сленг (а когда используется - обязательно есть сноска с расшифровкой).

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

Кому не стоит читать
Если вы уже в «высшей лиге» то, во-первых, мне очень приятно, что у меня есть такие подписчики и вы читаете это , а во-вторых главы про работу СТО скорее всего позабавят вас
98 viewsAlexander Lozhkin, 12:04
Открыть/Комментировать
2023-01-03 15:44:35 Хороший разработчик - ленивый разработчик

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

Как же ведет себя этот зверь в естественной среде обитания?

Автоматизирует рутинные операции
Ленивому разработчику в лом повторять одни и те же операции руками раз за разом. Поэтому он автоматизирует эти операции с помощью скриптов и хоткеев. Также ему лень исправлять ошибки, которые можно допустить выполняя процедуры руками и лень помнить правила выполнения этих процедур.

Ищет наиболее эффективные способы решения задач
Ленивому разработчику лень писать сложный код, поэтому он максимально прорабатывает задачу еще до написания кода ища способы решить проблему пользователя минимальным колличеством кода.

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

Реализует концепцию deep modules
Ленивый разработчик понимает, что эффективный модуль/класс/функция должен(-а) предоставлять «узкий» интерфейс скрывая за ним «глубокую» реализацию и упрощая повторное использование.

Автоматизирует QA
Ленивый не значит безотвественный. Ленивому программисту лень доказывать, что его код работает. Лень проверять как изменилось поведение после внесения изменений. Лень проверять все 100500 корнер кейсов. Поэтому ленивый программист вместо того, чтобы проверять код руками, автоматизирует все проверки согласно тестовой пирамиде.

Использует defensive programming
Ленивому разработчику лень дебажить код пытаясь понять, почему он делает не то, что требуется. Поэтому ленивый разработчик держит только одну точку изменения внутреннего состояния; гарантирует, что связанные поля изменяются вместе; использует immutability где может и т.д. Проектируя фичи ленивый программист думает о том, как сделать так, чтобы фича требовала минимум ручного сопровождения и «восстанавливалась» самостоятельно в случае сбоя.

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

Будте ленивыми, но направляйте лень в правильное русло!
83 viewsAlexander Lozhkin, edited  12:44
Открыть/Комментировать
2022-12-25 18:03:26 Команда без дирижера

Несколько месяцев назад, я прочитал книгу Коучинг agile-команд.

Вы замечали, что апологеты agile часто похожи на наркодилеров из кино: «Чувак, просто попробуй! Тебе понравится, это не сравнится ни с чем!»? При этом, уж не знаю почему, рассказ часто приправляется странными англицизмами (КОНТРОЛЛИНГ! Контроллинг блин, я даже записал это слово, чтобы не забыть) и мега-неустойчивыми метафорами, смысл которых понятен только автору. 

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

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

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

Перенося эту идею на команду получаем, что руководитель команды - своеобразный дирижер. Дирижер нужен и важен для (большого) оркестра. К тому же, в оркестре всегда кто-то играет лучше, кто-то хуже. А дирижер слышащий общую картину способен нивелировать это. Но может ли оркестр играть без дирижера?

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

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

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

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

Перенося метафору на мир разработки - дирижер должен сесть за инструмент и начать играть с оркестром… мда, я же говорил, что не люблю agile-метафоры - они постоянно разваливаются…
80 viewsAlexander Lozhkin, edited  15:03
Открыть/Комментировать
2022-12-04 11:26:48 Learning Domain-Driven Design by Vlad Khononov Во время последнего отпуска я решил освежить знания по DDD. Мое путешествие в DDD началось с классики - голубая книга Эванса, потом книга и курс Дино Эспозито, далее красная книга Вернона. Зачем читать еще…
105 viewsAlexander Lozhkin, 08:26
Открыть/Комментировать
2022-12-01 12:05:33 Learning Domain-Driven Design by Vlad Khononov Во время последнего отпуска я решил освежить знания по DDD. Мое путешествие в DDD началось с классики - голубая книга Эванса, потом книга и курс Дино Эспозито, далее красная книга Вернона. Зачем читать еще…
103 viewsAlexander Lozhkin, edited  09:05
Открыть/Комментировать
2022-11-27 11:37:46 Learning Domain-Driven Design by Vlad Khononov Во время последнего отпуска я решил освежить знания по DDD. Мое путешествие в DDD началось с классики - голубая книга Эванса, потом книга и курс Дино Эспозито, далее красная книга Вернона. Зачем читать еще…
83 viewsAlexander Lozhkin, edited  08:37
Открыть/Комментировать