Было пара таких случаев, когда клиент приходит с болью и потенциальными деньгами. А тебе нечего предложить. Совсем тупик. А потом проходит несколько лет и решение находится почти само. Ну и побежали: поднимать старые контакты, детализировать требования, писать демо...
Меня никто никогда не учил. Бросили в воду и плыви как хочешь.
Но я всегда был первым/главным или максимум вторым человеком в проекте (в небольших долго живущих командах это не удивительно) и понимал свою ответственность и сам от себя требовал обоснованность решений и проводил post mortem.
Что в больших командах творится не знаю даже. Если мои компетенции так будет мерять у меня глаза на лоб полезут
Честно говоря, такие метрики вызывают большое раздражение.
Допустим, я применил тут анемичную модель, потому что это бизнес правило относится только к конкретному сценарию, а не к всему домену. И что? Какие-то оценки моих компетенций? Ты спроси почему я отошёл от типичных паттернов, я тебе объясню что другие архитектурные свойства были важнее.
Большая часть метрик это просто code style, а проверка обходится, команда пойдет оптимизировать код под них. Переименовывают DAO в Entity, добавляют папку /domain/, получают зеленый радар и думают, что работают хорошо.
Да, метрики я бы контролировал. Но не для программиста, а для проекта. Для программиста всё сильно сложнее.
Бизнесу почему-то ценен разработчик, который закрывает пять задач в день (Я слышал, что в Яндексе это даже нужно для подтверждения грейда). Даже если через полгода выясняется, что каждая новая задача требует правок в двадцати файлах, а LLM не хватает контекста, чтобы просто разобраться в архитектуре проекта
Core команде проще: разработчик знает, что если он сейчас схалявил, ему ещё несколько лет жить с этим. Но это должен быть долгий жизненный цикл и доверие команде.
А вот когда команды начинают бешено тасовать по проектам/продуктам тогда и получается продукт без хозяина. Product owner даже если и есть (а скорее, его нет или 1/10 ставки/FTE из экономии) за этим не уследит.
За 12 лет в роли тимлида и архитектора
вы так и не научились кратко объяснять. Так какую метрику вы хотите минимизировать? Эти, которые на экране? Методики расчета есть? Обоснованные оценки их влияния на бизнес результаты есть?
А те, кто получает неуд становятся очень нервными. Они вам ещё не вломили?
Для оценки компетенций это конечно же не годится.
Но неплохо иметь постоянный контроль проекта за метриками деградации. Только они для каждого проекта разные. И когда метрика превысила порог значит техдолг/архитектура уже требует ремонта
Например
Категории:
1. Контрактная гигиена (связь с каскадной системой)
Заголовок звучит как взлом систем безопасности
https://en.wikipedia.org/wiki/Expression_problem
Это признание мастерства
Хабр не выкупил сарказм
Буду ставить /s
Тест кривой. Ясно, понятно
Не настолько семья, это очевидно.
Максимум это приоритет своим сотрудникам на замещение открытых вакансий.
Ну всё, теперь узкоглазым санкций накидают полную панамку.
Эта дурная контора имеет какое-то отношение к государству?
Ясно же откуда берутся 700.000 отзывов про подставку для телефона.
ЗЫ это озон
Обо всем и ни о чём
Было пара таких случаев, когда клиент приходит с болью и потенциальными деньгами. А тебе нечего предложить. Совсем тупик. А потом проходит несколько лет и решение находится почти само. Ну и побежали: поднимать старые контакты, детализировать требования, писать демо...
С LLM мы всё больше теряем контроль и уверенность
Будет быстрый WSL NTFS?
Active record это не только
ценный мехN+1 problemОднако, уже две статьи только про неё
Их проблемы
За лицензию на совместимость по автофокусу с тушкой нада многа деняк.
А с ручной фокусировкой я так и не смог
Меня никто никогда не учил. Бросили в воду и плыви как хочешь.
Но я всегда был первым/главным или максимум вторым человеком в проекте (в небольших долго живущих командах это не удивительно) и понимал свою ответственность и сам от себя требовал обоснованность решений и проводил post mortem.
Что в больших командах творится не знаю даже. Если мои компетенции так будет мерять у меня глаза на лоб полезут
Честно говоря, такие метрики вызывают большое раздражение.
Допустим, я применил тут анемичную модель, потому что это бизнес правило относится только к конкретному сценарию, а не к всему домену. И что? Какие-то оценки моих компетенций? Ты спроси почему я отошёл от типичных паттернов, я тебе объясню что другие архитектурные свойства были важнее.
Большая часть метрик это просто code style, а проверка обходится, команда пойдет оптимизировать код под них. Переименовывают DAO в Entity, добавляют папку /domain/, получают зеленый радар и думают, что работают хорошо.
Да, метрики я бы контролировал. Но не для программиста, а для проекта. Для программиста всё сильно сложнее.
Запомни студент: сейчас к людям надо помягше а на вопросы смотреть ширше©
Core команде проще: разработчик знает, что если он сейчас схалявил, ему ещё несколько лет жить с этим. Но это должен быть долгий жизненный цикл и доверие команде.
А вот когда команды начинают бешено тасовать по проектам/продуктам тогда и получается продукт без хозяина. Product owner даже если и есть (а скорее, его нет или 1/10 ставки/FTE из экономии) за этим не уследит.
вы так и не научились кратко объяснять. Так какую метрику вы хотите минимизировать? Эти, которые на экране? Методики расчета есть? Обоснованные оценки их влияния на бизнес результаты есть?
А те, кто получает неуд становятся очень нервными. Они вам ещё не вломили?
Для оценки компетенций это конечно же не годится.
Но неплохо иметь постоянный контроль проекта за метриками деградации. Только они для каждого проекта разные. И когда метрика превысила порог значит техдолг/архитектура уже требует ремонта
Например
Категории:
1. Контрактная гигиена (связь с каскадной системой)
2. Доменная целостность (illegal states)
3. Слоистость/зависимости
4. Тестовое покрытие/ археология
5. Изменчивость/частота правок
У неё не бесконечная память и весь код она не вызубрит