Как стать автором
Обновить
22
0.4
Алексей @pankraty

Разработчик

Отправить сообщение

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

Не знаю, почему я вспомнил эту историю.

Есть также легенда, что в том же гугле (вот совпадение-то!) борются за доли процентов быстродействия поиска, т. к. на их объемах это огромные величины суммарно.

Но что-то мне подсказывает, что истина где-то посередине.

Согласен с @lair по всем пунктам. Доводилось наблюдать, как компания решила разработать гибко конфигурируемое решение, в котором программирование сведено к минимуму, а основную работу делают "аналитики". И тут есть пара подводных камней. Скилсеты хорошего программиста и хорошего аналитика довольно сильно различаются, и в плане грамотной декомпозиции и переиспользования частей кода, ой, т. е. конфигурации, аналитики показывали себя не очень хорошо, примерно на уровне джуниор программистов. Обходясь при этом сильно дороже. Квалифицированные программисты имели тенденцию надолго не задерживаться, т. к. им скучно заниматься "конфигурированием", они хотят программировать. А аналитики постепенно становились "программистами на платформе X" - а такая квалификация не сильно ценится где-то за пределами компании X. Да и на рынке программистов на своей платформе ты не найдешь (если ты не SAP или 1С, условно), а значит, новичков надо обучать с нуля.

Не утверждаю, что описанные проблемы возникают в каждом случае, но мне кажется, они довольно типичны. Есть даже устоявшийся термин Inner Platform Effect.

extremely high "time to market"

Такое себе преимущество

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

Плюс, при команде условно в 10 человек проблем будет меньше. Они начнут проявляться на уровне 30-50 человек, т.к. для большинства инструменты по автоматизации будут являться черным ящиком, который либо работает, либо нет.

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

Кроме того, есть тенденция, что с уходом основного драйвера, развивавшего расширение, его поддержка прекращается, заморозившись на какой-то версии. И все это работает до первого ломающего изменения, после чего перед организацией встает выбор: или оттягивать обновление до последнего (и продолжать работать на VS10 в 2021) или всей команде перестраивать процессы, привычно автоматизированные в расширении.

Не утверждаю, что так бывает всегда, но это то, с чем сам сталкивался.

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

Nullable типы не являются стопроцентной защитой, т.к. а) выдают ворнинги, а не ошибки компиляции, б) могут быть подавлены восклицательнвм знаком, в) компилятор иногда ошибается в определении nullability, г) бесполезны при вызове из контекста с отключенными nullable типами. Поэтому, чтобы не отхватить NRE в неожиданном месте, может потребоваться дополритеььный контроль входных параметров

У этих двух способов есть небольшое различие в том, как считается тестовое покрытие: в вашем способе надо два теста, чтобы обеспечить 100% покрытие, а в способе из статьи - достаточно одного.

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

v9s means validations

But... Why??

В случае с v8n, это хоть как-то можно обосновать созвучием - ValidEIGHTioN - лично мне такой способ именования кажется притянутым за уши, но тут уж на вкус и цвет. Но что такое Vi-nine-es и почему это means validation - загадка для меня.

Необычно, что валидатор навешивается на команды. Более аутентичный подход, как мне кажется, это валидировать входные данные, поступающие в контролеры (реквесты) тем самым не допуская конструирования невалидных команд. Получаем следующие плюсы:

  1. Не надо дополнительно конфигурировать FluentValidator - он на такой сценарий изначально рассчитан.

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

  3. Не нужно пробрасыаать исключения при валидационных ошибках.

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

По своему опыту применения медатора, могу сказать, что он помогает в написании кода под конкретные юзкейсы, что особенно полезно, если одновременно работает несколько команд, и важно не поломать чужую логику в god-service. Но при этом, когда обсуждается паттерн "сервис-локатор", в качестве главного недостатка указывается, что у сервиса, имеющего зависимость от локатора, появляются невявные зависимости от других сервисов, при которые мы не можем узнать не глядя на реализацию; однако в случае с медатором мы имеем в точности то же самое, но я почему-то не встречал обсуждений такого недостатка этого паттерна.

Для сравнения - вероятность того, что на голову человеку упадет метеорит, равняется 0,000001% [14].

Вызывает сомнение эта цифра. При такой вероятности за время жизни среднестатистического человека, нескольким десятками людей по миру должны падать метеориты на головы. Примерно по одному в год. Как-то не верится. И в статье за номером 14 про это тоже ничего нет (что, впрочем, логично - в научных статьях обычно не прибегают к обывательским сравненияи).

Грабли №5. Слушать команду

Она реально лучше знает, как надо.

Пример: команда должна проводить рефайнмент сессии и оценивать скоуп своих задач. Классно звучит, но мы некоторые задачи не можем оценить и не делаем этого. Вот как можно оценить саппорт скрам-команды, когда она переходит....ну пусть на java 14? Или как можно оценить РоС? А совместный рефакторинг архитектора и команды?

Как быть: методички - класс, их писали не идиоты. Но всегда задавайте вопрос "а что для нас важно: следовать процессу или делать качество?"

Не пытайтесь повторить.

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

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

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

  • D'gs, d'gs, d'you like d'gs (произносит как dugs)

  • Oh, you mean dogs? Yes, I like dogs!

Браво Пучкову за адекватный перевод (по памяти, что-то вроде) :

  • П'ськи, п'ськи, любишь п'ськи?

  • А, пëсики! Да, обожаю собачек!

Еще "четыре" выбивается по количеству слогов - само по себе редко мешает, но "четыредесят" - уже явно слишком громоздко. Раз уж рефакторим, ломая обратную совместимость, можно и сократить. В идеале - все простые числительные сделать односложными (примерно как в английском, только без zero и seven. Сравните, насколько быстрее произносить nine-one-one, чем девять-один-один).

И заодно избавиться от созвучности некоторых числительных, которая мешает при восприятии на слух, особенно, когда качество связи не очень: семь-восемь (особенно, если о безударное, как в "восемнадцать"), девять-десять...

Т.е. могло бы получиться что-то вроде ноль-ван-два-три-фо-пять-шесть-семь-эйт-найн

Можно не вешать, а говорить: "ой сейчас, подождите минуточку" - и ставить звонок на удержание. Кто-то минуту висит, а кто-то и пять. Мелочь, конечно, но время у мошенников вы отняли, на один-два звонка меньше сделает.

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

По вашей же ссылке я читаю


A class or a record is a reference type. When an object of the type is created, the variable to which the object is assigned holds only a reference to that memory. When the object reference is assigned to a new variable, the new variable refers to the original object. Changes made through one variable are reflected in the other variable because they both refer to the same data.

A struct is a value type. When a struct is created, the variable to which the struct is assigned holds the struct's actual data. When the struct is assigned to a new variable, it's copied. The new variable and the original variable therefore contain two separate copies of the same data. Changes made to one copy don't affect the other copy.

И только потом идет про кучу.


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

Кстати, по моей практике, нет. Про boxing/unboxing большинство что-то слышали и с разной степенью уверенности могут ответить, что в случае боксинга значение попадет в кучу.


Всё-таки, на мой взгляд, то, как присваиваются значения — это важное, но всё-таки следствие того, где значения располагаются. Также, например, важным следствием является то, как идёт очистка памяти от значений.

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


Хотя постойте… Зачем представлять? Уже есть Large Object Heap, и рантайм решает за нас, аллоцировать память в SOH или в LOH. И да, разработчику иногда важно представлять, где произойдет аллокация, чтобы оптимизировать производительность, но с точки зрения языка C# разницы между "small" reference type и "large" reference type нет.

Все верно, разрыв устраняется, но разработчику нужно понимать разницу между категориями, чтобы представлять, что будет сохранено в x после var x = new Point(); в зависимости от того, объявлен тип Point как структура или как класс. И соответственно, что будет скопировано в y - ссылка (значение ссылки) или значение целиком.

Информация

В рейтинге
1 991-й
Откуда
Саратов, Саратовская обл., Россия
Дата рождения
Зарегистрирован
Активность