Pull to refresh
30
0
Антон Куранов @Throwable

Пользователь

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

Как я уже сказал выше, если команда, ждет, что ей объяснят на какие кнопки давить, то это незрелая команда, не способная принимать решения. Значимые детали -- это те, которые определяют архитектуру решения, и которые потом будет сложно поменять. Их и нужно обговаривать в первую очередь с продактом. А куда сдвинуть кнопку или какую надпись поставить на компонент -- это незначительные детали, которые лучше обсуждать уже имея на руках что-то рабочее, и которые прокатывают как есть в 90% случаев.

Технические же детали вообще не нужно обсуждать с продактом, потому как вероятны два варианта:

  • либо он отложит проблему в долгий ящих и скажет "подумаю потом на досуге"

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

При всем уважении, многие руководители убеждены, что причиной провала проекта является именно неверно выбранная или неправильно используемая методология. И что перейдя на X, их проект попрет как по вазелину. Хотя реальная ситуация может быть как в старом анекдоте: "У моей бабушки был бордель. И вот когда доходы падали, она меняла девочек, а не двигала кровати."

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

Там миллион причин: от низкой мотивации в команде до того, что сам менеджер просто ленивая задница.

Задача должна быть четко и конкретно сформулирована.

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

Также стоит отметить, что SMART – это не волшебная таблетка

Очень важная ремарка: мы впарили вам очередной X, но никаких гарантий не даем и никакой ответственности не несем.

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

Поэтому лучшим на мой взгляд способом для генерации кода в рантайме будет компиляция из исходного кода с использованием javax.tools.JavaCompiler в связке с каким-нибудь JavaPoet или шаблонизатором. Чаще нужно просто модифицировать уже существующий код, тогда ByteBuddy тут нет равных.

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

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

Что я понял, когда написал много тестов

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

Тесты — это документация

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

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

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

Другая вещь, которую вы не упомянули -- это мокирование. Оно как правило занимает 90% времени написания теста и его отладки. А самое смешное, что в подавляющем большинстве случаев поведение мокированного кода -- это поведение сферического коня в вакууме, которое слабо соотносится с реальными кейсами. Особенно все, что касается стейта и базы данных. Поэтому народ сейчас все более склонен поднимать в контейнере реальную базу с тестовым набором данных, чтобы тестировать все как есть. А юниты все чаще заменяются "сценарными" тестами, которые тестируют именно бизнес спецификацию, а не внутренний дизайн.

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

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

Давайте немного улучшим наш код. Перенесем логику в сервис

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

Тесты — это инвестиции в светлое будущее

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

  1. Тесты -- это тоже код, поэтому они также могут содержать баги. Кто же тестирует тесты? Основной код? Круговая порука получается.

Однозначно. Продюсер льет в topic строго последовательно, используя одно соединение. Ack подтверждения служат для гарантии доставки при выходе из строя основной partition, а не для упорядочения. Все остальное фантазии автора.

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

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

Пара моментов:

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

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

По поводу лимита файловых дескрипторов: практически во всех дистрибутивах он установлен в 1024.

В JVM процессах ещё есть такая неприятная вещь, как non-heap memory, которая выходит за рамки лимита по Xmx и собственно вообще ничем не лимитируется. Его любят использовать всякие вещи, IO подсистемы и т.д. В итоге возможна ситуация, когда процесс убивается ОС, хотя в куче полно места, и OOM с дампом не сгенерированны. Особенно актуально, когда выставлены лимиты cgroups на контейнер.

Ещё неплохая практика выставлять Xms равным Xmx, таким образом жёстко резервируя память для java процесса.

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

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

TCP гарантирует, что данные не будут повреждены, утеряны,

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

Еще скажите, что у вас монолит, и вас сразу закидают гнилыми помидорами :)

Именно по этой причине в тренд входит serverless и лямбды :)

То, что тесты отдельных частей кода зеленые отнюдь не гарантирует, что весь бизнес кейс работает корректно. Кроме того, тестирование по частям накладывает дополнительные расходы на мокирование и фейкирование зависимостей, а это не тривиальная задача. Например, как тестировать по-частям монорепозиторный фронт с зависимостями от 100 микросервисов?

В те времена для того, чтобы запустить программу, надо было принести ее в вычислительный центр. Помещение, размером с современный дата центр

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

К сожалению, опыт и грабли.

Ещё один способ - постоянное запугивание и сравнивание с конкурентами :)

Вообще любой успешный проект проходит как минимум 4 стадии легаси, при котором необходимо полное или частичное переписывание:

  • Когда наспех стряпанный прототип выстрелил, и требуется делать полноценный коммерческий продукт.

  • Когда выбранный дизайн уже не позволяет эффективно реализовать скопившиеся требования.

  • Когда одна команда уже не справляется с потоком требований и требуется распределить разработку.

  • Когда количество клиентов и нагрузка резко возросли, и требуется менять существующую архитектуру решения.

То есть в обоих случаях сначала дампим и копируем все данные с основного сервера на реплику, а затем слушаем изменения. Не совсем понятно можно ли это делать online, и что будет происходить в промежутке между копированием реплики и началом подписки, ведь данные на мастере постоянно изменяются. Или для поднятия реплики нужно мастер тоже останавливать?

P.S. вроде как были автоматические решения для HA типа PgPool.

Information

Rating
3,880-th
Location
Madrid, Испания
Registered
Activity