Меня никто никогда не учил. Бросили в воду и плыви как хочешь.
Но я всегда был первым/главным или максимум вторым человеком в проекте (в небольших долго живущих командах это не удивительно) и понимал свою ответственность и сам от себя требовал обоснованность решений и проводил post mortem.
Что в больших командах творится не знаю даже. Если мои компетенции так будет мерять у меня глаза на лоб полезут
Честно говоря, такие метрики вызывают большое раздражение.
Допустим, я применил тут анемичную модель, потому что это бизнес правило относится только к конкретному сценарию, а не к всему домену. И что? Какие-то оценки моих компетенций? Ты спроси почему я отошёл от типичных паттернов, я тебе объясню что другие архитектурные свойства были важнее.
Большая часть метрик это просто code style, а проверка обходится, команда пойдет оптимизировать код под них. Переименовывают DAO в Entity, добавляют папку /domain/, получают зеленый радар и думают, что работают хорошо.
Да, метрики я бы контролировал. Но не для программиста, а для проекта. Для программиста всё сильно сложнее.
Бизнесу почему-то ценен разработчик, который закрывает пять задач в день (Я слышал, что в Яндексе это даже нужно для подтверждения грейда). Даже если через полгода выясняется, что каждая новая задача требует правок в двадцати файлах, а LLM не хватает контекста, чтобы просто разобраться в архитектуре проекта
Core команде проще: разработчик знает, что если он сейчас схалявил, ему ещё несколько лет жить с этим. Но это должен быть долгий жизненный цикл и доверие команде.
А вот когда команды начинают бешено тасовать по проектам/продуктам тогда и получается продукт без хозяина. Product owner даже если и есть (а скорее, его нет или 1/10 ставки/FTE из экономии) за этим не уследит.
За 12 лет в роли тимлида и архитектора
вы так и не научились кратко объяснять. Так какую метрику вы хотите минимизировать? Эти, которые на экране? Методики расчета есть? Обоснованные оценки их влияния на бизнес результаты есть?
А те, кто получает неуд становятся очень нервными. Они вам ещё не вломили?
Для оценки компетенций это конечно же не годится.
Но неплохо иметь постоянный контроль проекта за метриками деградации. Только они для каждого проекта разные. И когда метрика превысила порог значит техдолг/архитектура уже требует ремонта
Например
Категории:
1. Контрактная гигиена (связь с каскадной системой)
Проектный офис понимает конкретную задачу хуже априори. Но лучше знает похожие задачи в соседних проектах, не заинтересован заметать проблемы под коврик, лучше знает приоритеты.
Заголовок поста гласит, что тесты sqllogictest на 100% соответствуют заявленному стандарту . Это действительно важный шаг, но, исходя из многолетнего опыта работы над соответствием стандарту SQLite, я бы осторожно возразил против того, чтобы рассматривать это как «паритет SQLite», потому что sqllogictest и собственный набор тестов TCL для SQLite имеют совершенно разные уровни сложности , и эту разницу легко недооценить.
sqllogictest почти полностью состоит из проверок корректности строк результатов для правильно сформированных запросов .
Пакет тестов TCL для SQLite проверяет документированное поведение SQLite : точный текст сообщений об ошибках
С 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. Изменчивость/частота правок
У неё не бесконечная память и весь код она не вызубрит
Отключаемый (?) GC + ownership был в ранних версиях Rust
Так ноги разъедутся
-теперь всё ломается!
-а где минусы?
Проектный офис понимает конкретную задачу хуже априори. Но лучше знает похожие задачи в соседних проектах, не заинтересован заметать проблемы под коврик, лучше знает приоритеты.
Но всем
Я успешно* перегнал на kimi k3 10.000 строк c#->rust, blazor ->axum, dapper -> sqlx без изменения бизнес логики
*Только визуальные проверки и компиляции
На фубле не пробовал. Альтернативно пробовал на arena.ai (все модели случайным образом), там видимо оптимизировано под короткие ответы и всё плохо.
Почему корутины могут переключаться быстрее чем системные потоки?
Изоляция у корутин неполная, доверительная, одно адресное пространство, те же страницы и права
У корутин кооперативная многозадачность, может зависнуть, планировщик тривиальный
Остальное это следствие
https://github.com/cursor/minisqlite
100.000 строк кода если суммировать размер трейтов
И столько же непонятно чего, видимо тестов
Я руководил тремя проектными офисами и на одной не руководящей. И так и не понял зачем проектный офис бизнесу. Мой вывод: он бизнесу не нужен.
Чем я руководил:
Стратегический проектный офис: исследования рынка, приоритеты инициатив, формирование портфеля проектов
Центр компетенций: agile, pmbok, делимся опытом,
Центр контроля: достижения, риски, финансовый учёт, продолжать или закрыть, мотивация
На руководящих в среднем по 1 году с травматичным расставанием.
Да ну нахер! Я лучше в айтишечке архитектором.
Да. Доказательство корректности решения вообще отдельная сложная тема
И там замечание прилетело
835 страниц ТЗ
Видимо, всё же 200.000 строк, судя по https://github.com/cursor/minisqlite
9000 строк это про какой-то кусок
9000 строк кода - контекст удержится целиком10.000-30.000$
Не впечатляет!
Разве что время решения, ради которого и создавался рой.
Взаимоисключающие параграфы©