На мой взгляд, лучший момент распространения знаний - это момент их приобретения.
Далее знания могут быть утеряны по множеству причин или могут не оказаться под рукой в нужный момент (эксперты тоже могут уйти в отпуск, заболеть и т.д.)
В эту же копилку. Для ипотеки мне нужно было открыть эскроу счет в Сбере. Лет 5-6 назад был их клиентом и имел карту, сейчас же нет ничего - ни карт, ни приложения, ни личного кабинета.
Раньше для открытия такого счета было достаточно зайти в офис банка с паспортом и потратить 15 минут времени.
Сейчас:
Прийти в офис
Обновить личные данные (они устарели)
Выслушать все вариации доступных карт
Оформить карту
Установить личный кабинет на свой айфон через их учетку айклауда
Зайти в личный кабинет и подписать наконец документы.
Вообще рефакторинг должен приводить к лучшему коду, чем до.
Соответственно, команда должна быть солидарна в том, какой код для них хороший, а какой - нет.
Ну и раз уж мы сравниваем код до и после, то у нас должны быть критерии сравнения и понимание, какие критерии/показатели мы улучшаем данным рефакторингом.
Я это все к тому, что рефакторинг должен быть осознанным. Если вы рефакторите просто потому, что код не нравится - не стоит надеяться на положительный исход предприятия.
А вот интересно, накрутка опыта в резюме, о которой так бурно спорят последнее время - делает пацана мутным по умолчанию или в зависимости от того, спалят ли? Вроде слово ж дал, что столько работал…
Еще часто (в моей практике было трижды) на проде девопсы/админы просто на уровне nginx закрывали все запросы, кроме GET/POST. В итоге, сделав все «красиво» выходишь в прод и ловишь проблемы во многом из-за своих стремлений к прекрасному.
У меня была практика в схеме «утки с утятами» - один синьор держит 2+ джунов и «вскармливает» опытом и задачами.
Стабильно остается половина, но эта половина работает 2+ года. В случае маленьких бюджетов и готовности синьора к такому опыту - схема рабочая, профит приходит через полгода, «окупается» за год (как сказали в статье и в комментариях выше).
При чем двух сразу вводить в команду получалось даже выгоднее, чем одного - знания по технологиям и продукту вбивались сразу в 2 головы, что экономило ресурс опытных ребят + с учетом конверсии команда практически гарантированно получала боевую единицу на долгий срок.
Не понял, как(кем) таз демобилизованного/потерявшегося чистильщика будет распределен между другими? И кто вообще и как решает, в какой таз ссыпать картошку?
Тысячи людей пишут мемуары. Миллионы их читают. Одни не находят в них ценность, другие находят. То, что вы (да и я) не подчерпнули для себя ничего нового, никак не означает, что не найдется людей, которые что-то для себя извлекут.
Может, параллельно с нами N человек прочитали и решились попробовать себя в роли лида - если вы есть, желаю вам удачи на этом нелегком поприще)
В рамках темы мне очень зашла книга Владимира Хорикова «Принципы юнит-тестирования» - зашли идеи главенства подсчета покрытия не строк кода, а ветвлений, плюс по полкам раскладывается про тестируемость кода и способы ее повышения/обеспечения.
Спасибо за статью! Решали эту же проблему в рамках перехода на json формат логов - накидали свой набор полей, подписались, сделали общее решение и подключили во все сервисы. На opentelemetry посмотрю обязательно.
В последнем вопросе - думаю, задумываться над единственностью формата нужно всегда - хоть один сервис, хоть несколько. «Плох тот солдат, что не мечтает стать генералом»
Мир не черно-белый, и таблетки не только красные и синие. Ни разу не видел ни чистого вотерфола, ни чистого аджайла (есть ли он вообще - загадка).
Если убрать терминологию, варианта как будто два - либо поставляем всю заявленную/требуемую ценность целиком и разом, либо частями. В большинстве случаев в IT можно пойти по второму пути - по нему и идут(лучше получать хоть что-то уже сейчас - есть пространство для маневра/корректировок). Как идут (скрам/канбан/etc) - часто дело вкуса менеджмента и их привычек.
У себя ввели этап дизайна фичи - отдельная сабтаска, в рамках которой разработчик описывает, каким образом фича будет реализована. Проходит дизайн-ревью, и уже после создаются сабтаски по согласованной реализации. В итоге, если есть вопрос по коду - можно посмотреть, в рамках какой фичи был добавлен код и там же посмотреть, почему именно такой.
Не покрывает всю кодовую базу, но там, где процесс работает, вопросов в духе «почему так» практически не возникает.
High available SOSAL Appilcation
HASOSALA
И сразу следом:
Несостыковочка
На мой взгляд, лучший момент распространения знаний - это момент их приобретения.
Далее знания могут быть утеряны по множеству причин или могут не оказаться под рукой в нужный момент (эксперты тоже могут уйти в отпуск, заболеть и т.д.)
Рад за ваши столь доскональные знания такого значимого труда.
В продолжение могу предложить изучить труд Хорикова «Принципы юнит тестирования» - не менее значимая книга, чем творения дядюшки Боба
Сильное заявление. Проверять я его, конечно, не буду
В эту же копилку. Для ипотеки мне нужно было открыть эскроу счет в Сбере. Лет 5-6 назад был их клиентом и имел карту, сейчас же нет ничего - ни карт, ни приложения, ни личного кабинета.
Раньше для открытия такого счета было достаточно зайти в офис банка с паспортом и потратить 15 минут времени.
Сейчас:
Прийти в офис
Обновить личные данные (они устарели)
Выслушать все вариации доступных карт
Оформить карту
Установить личный кабинет на свой айфон через их учетку айклауда
Зайти в личный кабинет и подписать наконец документы.
Спасибо за категоризацию диаграмм - почему-то ранее не задумывался, а тут все лаконично объяснено.
Для диаграммы компонентов, думаю, больше подойдет пакет C4 из стандартной библиотеки plantUML
Вообще рефакторинг должен приводить к лучшему коду, чем до.
Соответственно, команда должна быть солидарна в том, какой код для них хороший, а какой - нет.
Ну и раз уж мы сравниваем код до и после, то у нас должны быть критерии сравнения и понимание, какие критерии/показатели мы улучшаем данным рефакторингом.
Я это все к тому, что рефакторинг должен быть осознанным. Если вы рефакторите просто потому, что код не нравится - не стоит надеяться на положительный исход предприятия.
Я тимлид, и приходилось сталкиваться практически со всеми обозначенными проблемами. Часть из них до сих пор со мной(
Уйду ли я с позиции - однозначно нет. Тех, кто ушел - понимаю полностью.
Далее субъективщина.
Надо ли становиться тимлидом? Трижды подумайте. Из 20 подопечных потенциал вижу только у двоих.
Надо ли попробовать себя в роли тимлида? Обязательно. Ради трех вещей:
посмотреть на разработку с невиданной ранее стороны;
Научиться лучше понимать мотивы окружающих (проджекты/продакты/архитекторы/бизнес и кто бы там еще на команду и ее работу не влиял);
Понять, сколько всего сваливается на вашего лида и по возможности помогать ему
Спасибо за статью.
Мы у себя считаем
dev error rate (обьем проблем, вышедших от разработчиков)
Bug rate (обьем проблем, дошедших до прода)
Но вот почему то никогда не думали считать, сколько времени тратим на фиксы, хотя как будто стоить сказать «Спасибо, кэп»
Будем считать теперь, даже интересно стало)
А вот интересно, накрутка опыта в резюме, о которой так бурно спорят последнее время - делает пацана мутным по умолчанию или в зависимости от того, спалят ли? Вроде слово ж дал, что столько работал…
Еще часто (в моей практике было трижды) на проде девопсы/админы просто на уровне nginx закрывали все запросы, кроме GET/POST. В итоге, сделав все «красиво» выходишь в прод и ловишь проблемы во многом из-за своих стремлений к прекрасному.
Лучшее, действительно, часто враг хорошего.
У меня была практика в схеме «утки с утятами» - один синьор держит 2+ джунов и «вскармливает» опытом и задачами.
Стабильно остается половина, но эта половина работает 2+ года. В случае маленьких бюджетов и готовности синьора к такому опыту - схема рабочая, профит приходит через полгода, «окупается» за год (как сказали в статье и в комментариях выше).
При чем двух сразу вводить в команду получалось даже выгоднее, чем одного - знания по технологиям и продукту вбивались сразу в 2 головы, что экономило ресурс опытных ребят + с учетом конверсии команда практически гарантированно получала боевую единицу на долгий срок.
Аналогия прикольная, спасибо)
Не понял, как(кем) таз демобилизованного/потерявшегося чистильщика будет распределен между другими? И кто вообще и как решает, в какой таз ссыпать картошку?
Тысячи людей пишут мемуары. Миллионы их читают. Одни не находят в них ценность, другие находят. То, что вы (да и я) не подчерпнули для себя ничего нового, никак не означает, что не найдется людей, которые что-то для себя извлекут.
Может, параллельно с нами N человек прочитали и решились попробовать себя в роли лида - если вы есть, желаю вам удачи на этом нелегком поприще)
Спасибо за статью!
В рамках темы мне очень зашла книга Владимира Хорикова «Принципы юнит-тестирования» - зашли идеи главенства подсчета покрытия не строк кода, а ветвлений, плюс по полкам раскладывается про тестируемость кода и способы ее повышения/обеспечения.
Сам пишу код, комменты в гит, джавадок и даже этот текст. Рано или поздно вымру, но скорее поздно)
Спасибо за статью! Решали эту же проблему в рамках перехода на json формат логов - накидали свой набор полей, подписались, сделали общее решение и подключили во все сервисы. На opentelemetry посмотрю обязательно.
В последнем вопросе - думаю, задумываться над единственностью формата нужно всегда - хоть один сервис, хоть несколько. «Плох тот солдат, что не мечтает стать генералом»
Мир не черно-белый, и таблетки не только красные и синие. Ни разу не видел ни чистого вотерфола, ни чистого аджайла (есть ли он вообще - загадка).
Если убрать терминологию, варианта как будто два - либо поставляем всю заявленную/требуемую ценность целиком и разом, либо частями. В большинстве случаев в IT можно пойти по второму пути - по нему и идут(лучше получать хоть что-то уже сейчас - есть пространство для маневра/корректировок). Как идут (скрам/канбан/etc) - часто дело вкуса менеджмента и их привычек.
У себя ввели этап дизайна фичи - отдельная сабтаска, в рамках которой разработчик описывает, каким образом фича будет реализована. Проходит дизайн-ревью, и уже после создаются сабтаски по согласованной реализации. В итоге, если есть вопрос по коду - можно посмотреть, в рамках какой фичи был добавлен код и там же посмотреть, почему именно такой.
Не покрывает всю кодовую базу, но там, где процесс работает, вопросов в духе «почему так» практически не возникает.