Fortnight как "полмесяца" в принципе, возможно, но не всегда точно. See you in fortnight подразумевает "через две недели ровно", а "Через полмесяца" - весьма приблизительно. Но на практике обычно нет проблемы перевести двумя словами, действительно.
Немного из другой серии, но тоже из разряда бесполезного - это возможность иметь internal abstract член в публичном классе. Если унаследоваться из внешней сборки, переопределять этот член нельзя, т.к. он internal, но не переопределять тоже нельзя, т. к. он абстрактный. Такой вот курьез. Вроде и не баг, но и практической пользы ноль. Будет интересно, если кто-то придумает юзкейс, в котором это применимо.
Ещё одна вещь, которую вряд ли придумали бы в такой форме, если придумывали сразу, с нуля. "protected internal" является не взаимоусиливающей комбинацией "protected" и "internal", а действует как "или": чтобы получить доступ к члену надо быть наследником ИЛИ (не И) находиться в той же сборке (ср. с private static, например - на него одновременно распространяются ограничения private и static, усиливая друг друга). Зато логическое И выражается в виде модификатора "private protected", хотя от private в нём вообще ничего. Мне кажется, если бы не обратная совместимость, то "protected internal" должен был бы стать тем, что сейчас называется "private protected", а нынешний protected internal (с логическим ИЛИ) должен быть упразднен: если уж член protected, то ему обычно незачем быть публичным внутри своей сборки.
Из моей практики, на одном проекте активно использовались dynamic типы для работы с JSON -ами, приходящими из базы. С одной стороны, не надо делать массу DTO- шек, и если структура документа в базе со временем меняется, то вроде бы как код продолжает работать без необходимости поддерживать сущности v1, v2, vN+1... Но преимущества мнимые, т. к. все начинает падать в рантайме, принося в .Net все "прелести" языков без строгой типизации. Бррр, до сих передергивает, как вспоминаю.
Другой случай, где я применял dynamic, на этот раз самостоятельно, заключался в том, что внешняя библиотека (OpenXML, но это не важно) предоставляла несколько почти идентичных классов, с одинаковым набором полей, но в разных пространствах имён. Никаких общих интерфейсов или предков они не имели. Расширить внешнюю библиотеку тоже нельзя. И нужно было написать конвертацию из обоих типов в наш внутренний, по возможности, избежав копипасты. Для этого у меня было два internal метода, принимающих аргументы из разных пространств имён, и перенаправляющих вызовы в private метод, с dynamic аргументом. Чтобы это все не отвалилось при апгрейде OpenXML, код был плотненько покрыт тестами. И долгое время для меня это был единственный более-менее оправданного применения dynamic на практике, но и то потом оказалось, что это вызывало проблемы у пользователей, работающих в sandbox environment-ах (подробностей не помню, если кому будет интересно, найду соответствующий тикет на гитхабе). Так что и от такого применения пришлось отказаться.
А в защиту query syntax скажу, что тоже не понимал, для чего им вообще пользоваться, пока не столкнулся с запросом, в котором цепочка джойнов добавляла по одному новому полю к анонимному объекту. С query- синтаксисом такой запрос оказался в несколько раз короче, и читается легче.
Хехе, у этого хоррора есть еще сиквел про маленький переиспользуемый пакет, в который вынесены несколько полезных функций, используемых в нескольких проектах. И теперь мало того что изменения логики могут аукнуться в каком-то далеком месте, и тесты этого не покажут; мало того что любые изменения, ломающие API, становятся дикой головной болью... Так еще у этого пакета образовалось несколько внешних зависимостей, и все проекты его использующие обязаны выравнивать версии своих зависимостей, попутно исправляя ломающие изменения, привнесенные их обновлением.
О да, и рекомендательные системы, что в музыке, что на ютьюбе, бесконечно подсовывывающие одно и то же. Блин, у вас есть вся история просмотра, дайте мне что-нибудь новенькое, но не отстоящее на 180 градцсов от плиз интересов! Нет, тебя держат в коконе, рекомендуя одних и тех же "понравившихся исполнителей" и "видео с каналов, которые вы смотрели"
У моих детей сейчас как раз период увлечения лего, и суть в том, что получив новый набор, первый раз они собирают по инструкции именно то, что содержится в наборе. Но следом переключаются на сочетание произвольных деталей из разных наборов, и тут уж какие только Франкенштейны не получаются. Честно говоря, не припомню случая, чтобы поделка "по инструкции" собиралась больше одного раза.
У родителей в дачном кооперативе все скинулись на то, чтобы отсыпать внутренний проезд щебнем. Насыпали щебня по всей ширине проезда, разравняли, но через несколько дней один самый умный сосед, чтобы сделать себе дорожки, наскрёб щебня с середины дороги вдоль своего участка, оставив засыпанными только колеи. Т.е. вроде бы и ехать все будут по-прежнему по щебню, и он себе денежку сэкономил, и у окружающих не убыло — а его все равно почему-то м*ком считают.
Есть также легенда, что в том же гугле (вот совпадение-то!) борются за доли процентов быстродействия поиска, т. к. на их объемах это огромные величины суммарно.
Но что-то мне подсказывает, что истина где-то посередине.
Согласен с @lair по всем пунктам. Доводилось наблюдать, как компания решила разработать гибко конфигурируемое решение, в котором программирование сведено к минимуму, а основную работу делают "аналитики". И тут есть пара подводных камней. Скилсеты хорошего программиста и хорошего аналитика довольно сильно различаются, и в плане грамотной декомпозиции и переиспользования частей кода, ой, т. е. конфигурации, аналитики показывали себя не очень хорошо, примерно на уровне джуниор программистов. Обходясь при этом сильно дороже. Квалифицированные программисты имели тенденцию надолго не задерживаться, т. к. им скучно заниматься "конфигурированием", они хотят программировать. А аналитики постепенно становились "программистами на платформе X" - а такая квалификация не сильно ценится где-то за пределами компании X. Да и на рынке программистов на своей платформе ты не найдешь (если ты не SAP или 1С, условно), а значит, новичков надо обучать с нуля.
Не утверждаю, что описанные проблемы возникают в каждом случае, но мне кажется, они довольно типичны. Есть даже устоявшийся термин Inner Platform Effect.
Да-да, я согласен. Писал не с целью критики подхода, а чтобы дополнить статью соображениями о возможных подводных камнях на периоде от 5 лет и больше.
Плюс, при команде условно в 10 человек проблем будет меньше. Они начнут проявляться на уровне 30-50 человек, т.к. для большинства инструменты по автоматизации будут являться черным ящиком, который либо работает, либо нет.
У разработки кастомных расширений под проект есть пара недостатков. Во-первых, вся команда привязывается к одной IDE и даже к одной версии IDE. А значит, если кто-то предпочитает Rider, скажем, то ему придется подстраиваться под остальных. Равно как любителям попробовать новейшие превью версии придется ждать обновления расширения под новую студию. Плюс, со временем к проекту могут подключаться внешние подрядчики, у которых может не оказаться лицензии на нужную версию той же студии.
Кроме того, есть тенденция, что с уходом основного драйвера, развивавшего расширение, его поддержка прекращается, заморозившись на какой-то версии. И все это работает до первого ломающего изменения, после чего перед организацией встает выбор: или оттягивать обновление до последнего (и продолжать работать на VS10 в 2021) или всей команде перестраивать процессы, привычно автоматизированные в расширении.
Не утверждаю, что так бывает всегда, но это то, с чем сам сталкивался.
Я с вами согласен, и мне лично спокойнее, когда все ветки кода покрыты. Просто пытался придумать обоснование, когда один способ может оказаться предпочтительнее другого.
Nullable типы не являются стопроцентной защитой, т.к. а) выдают ворнинги, а не ошибки компиляции, б) могут быть подавлены восклицательнвм знаком, в) компилятор иногда ошибается в определении nullability, г) бесполезны при вызове из контекста с отключенными nullable типами. Поэтому, чтобы не отхватить NRE в неожиданном месте, может потребоваться дополритеььный контроль входных параметров
У этих двух способов есть небольшое различие в том, как считается тестовое покрытие: в вашем способе надо два теста, чтобы обеспечить 100% покрытие, а в способе из статьи - достаточно одного.
Оставим за скобками целесообразность расчёта этого показателя. На некоторых проектах требования по уровню покрытия внедрены в пайплайн сборки, и хочешь не хочешь, но вынужден соблюдать требования
В случае с v8n, это хоть как-то можно обосновать созвучием - ValidEIGHTioN - лично мне такой способ именования кажется притянутым за уши, но тут уж на вкус и цвет. Но что такое Vi-nine-es и почему это means validation - загадка для меня.
Biweekly meeting - ежеполмесячная встреча?
Fortnight как "полмесяца" в принципе, возможно, но не всегда точно. See you in fortnight подразумевает "через две недели ровно", а "Через полмесяца" - весьма приблизительно. Но на практике обычно нет проблемы перевести двумя словами, действительно.
На предложение перевести Feature как Особенность - кто такой Feature Owner?
Из айтишного навскидку Feature, Commit, Contributor, Partition/Partitioning, Shard/Sharding.
Из неайтишного - Fortnight, Biweekly. Opportunity vs Possibility.
Немного из другой серии, но тоже из разряда бесполезного - это возможность иметь internal abstract член в публичном классе. Если унаследоваться из внешней сборки, переопределять этот член нельзя, т.к. он internal, но не переопределять тоже нельзя, т. к. он абстрактный. Такой вот курьез. Вроде и не баг, но и практической пользы ноль. Будет интересно, если кто-то придумает юзкейс, в котором это применимо.
Ещё одна вещь, которую вряд ли придумали бы в такой форме, если придумывали сразу, с нуля. "protected internal" является не взаимоусиливающей комбинацией "protected" и "internal", а действует как "или": чтобы получить доступ к члену надо быть наследником ИЛИ (не И) находиться в той же сборке (ср. с private static, например - на него одновременно распространяются ограничения private и static, усиливая друг друга). Зато логическое И выражается в виде модификатора "private protected", хотя от private в нём вообще ничего. Мне кажется, если бы не обратная совместимость, то "protected internal" должен был бы стать тем, что сейчас называется "private protected", а нынешний protected internal (с логическим ИЛИ) должен быть упразднен: если уж член protected, то ему обычно незачем быть публичным внутри своей сборки.
Из моей практики, на одном проекте активно использовались dynamic типы для работы с JSON -ами, приходящими из базы. С одной стороны, не надо делать массу DTO- шек, и если структура документа в базе со временем меняется, то вроде бы как код продолжает работать без необходимости поддерживать сущности v1, v2, vN+1... Но преимущества мнимые, т. к. все начинает падать в рантайме, принося в .Net все "прелести" языков без строгой типизации. Бррр, до сих передергивает, как вспоминаю.
Другой случай, где я применял dynamic, на этот раз самостоятельно, заключался в том, что внешняя библиотека (OpenXML, но это не важно) предоставляла несколько почти идентичных классов, с одинаковым набором полей, но в разных пространствах имён. Никаких общих интерфейсов или предков они не имели. Расширить внешнюю библиотеку тоже нельзя. И нужно было написать конвертацию из обоих типов в наш внутренний, по возможности, избежав копипасты. Для этого у меня было два internal метода, принимающих аргументы из разных пространств имён, и перенаправляющих вызовы в private метод, с dynamic аргументом. Чтобы это все не отвалилось при апгрейде OpenXML, код был плотненько покрыт тестами. И долгое время для меня это был единственный более-менее оправданного применения dynamic на практике, но и то потом оказалось, что это вызывало проблемы у пользователей, работающих в sandbox environment-ах (подробностей не помню, если кому будет интересно, найду соответствующий тикет на гитхабе). Так что и от такого применения пришлось отказаться.
А в защиту query syntax скажу, что тоже не понимал, для чего им вообще пользоваться, пока не столкнулся с запросом, в котором цепочка джойнов добавляла по одному новому полю к анонимному объекту. С query- синтаксисом такой запрос оказался в несколько раз короче, и читается легче.
Хотел пройти мимо, но не смог сдержаться.
Это разве не калька? "Без предупреждения" было бы куда более по-русски.
Хехе, у этого хоррора есть еще сиквел про маленький переиспользуемый пакет, в который вынесены несколько полезных функций, используемых в нескольких проектах. И теперь мало того что изменения логики могут аукнуться в каком-то далеком месте, и тесты этого не покажут; мало того что любые изменения, ломающие API, становятся дикой головной болью... Так еще у этого пакета образовалось несколько внешних зависимостей, и все проекты его использующие обязаны выравнивать версии своих зависимостей, попутно исправляя ломающие изменения, привнесенные их обновлением.
О да, и рекомендательные системы, что в музыке, что на ютьюбе, бесконечно подсовывывающие одно и то же. Блин, у вас есть вся история просмотра, дайте мне что-нибудь новенькое, но не отстоящее на 180 градцсов от плиз интересов! Нет, тебя держат в коконе, рекомендуя одних и тех же "понравившихся исполнителей" и "видео с каналов, которые вы смотрели"
У моих детей сейчас как раз период увлечения лего, и суть в том, что получив новый набор, первый раз они собирают по инструкции именно то, что содержится в наборе. Но следом переключаются на сочетание произвольных деталей из разных наборов, и тут уж какие только Франкенштейны не получаются. Честно говоря, не припомню случая, чтобы поделка "по инструкции" собиралась больше одного раза.
У родителей в дачном кооперативе все скинулись на то, чтобы отсыпать внутренний проезд щебнем. Насыпали щебня по всей ширине проезда, разравняли, но через несколько дней один самый умный сосед, чтобы сделать себе дорожки, наскрёб щебня с середины дороги вдоль своего участка, оставив засыпанными только колеи. Т.е. вроде бы и ехать все будут по-прежнему по щебню, и он себе денежку сэкономил, и у окружающих не убыло — а его все равно почему-то м*ком считают.
Не знаю, почему я вспомнил эту историю.
Есть также легенда, что в том же гугле (вот совпадение-то!) борются за доли процентов быстродействия поиска, т. к. на их объемах это огромные величины суммарно.
Но что-то мне подсказывает, что истина где-то посередине.
Согласен с @lair по всем пунктам. Доводилось наблюдать, как компания решила разработать гибко конфигурируемое решение, в котором программирование сведено к минимуму, а основную работу делают "аналитики". И тут есть пара подводных камней. Скилсеты хорошего программиста и хорошего аналитика довольно сильно различаются, и в плане грамотной декомпозиции и переиспользования частей кода, ой, т. е. конфигурации, аналитики показывали себя не очень хорошо, примерно на уровне джуниор программистов. Обходясь при этом сильно дороже. Квалифицированные программисты имели тенденцию надолго не задерживаться, т. к. им скучно заниматься "конфигурированием", они хотят программировать. А аналитики постепенно становились "программистами на платформе X" - а такая квалификация не сильно ценится где-то за пределами компании X. Да и на рынке программистов на своей платформе ты не найдешь (если ты не SAP или 1С, условно), а значит, новичков надо обучать с нуля.
Не утверждаю, что описанные проблемы возникают в каждом случае, но мне кажется, они довольно типичны. Есть даже устоявшийся термин Inner Platform Effect.
Такое себе преимущество
Да-да, я согласен. Писал не с целью критики подхода, а чтобы дополнить статью соображениями о возможных подводных камнях на периоде от 5 лет и больше.
Плюс, при команде условно в 10 человек проблем будет меньше. Они начнут проявляться на уровне 30-50 человек, т.к. для большинства инструменты по автоматизации будут являться черным ящиком, который либо работает, либо нет.
У разработки кастомных расширений под проект есть пара недостатков. Во-первых, вся команда привязывается к одной IDE и даже к одной версии IDE. А значит, если кто-то предпочитает Rider, скажем, то ему придется подстраиваться под остальных. Равно как любителям попробовать новейшие превью версии придется ждать обновления расширения под новую студию. Плюс, со временем к проекту могут подключаться внешние подрядчики, у которых может не оказаться лицензии на нужную версию той же студии.
Кроме того, есть тенденция, что с уходом основного драйвера, развивавшего расширение, его поддержка прекращается, заморозившись на какой-то версии. И все это работает до первого ломающего изменения, после чего перед организацией встает выбор: или оттягивать обновление до последнего (и продолжать работать на VS10 в 2021) или всей команде перестраивать процессы, привычно автоматизированные в расширении.
Не утверждаю, что так бывает всегда, но это то, с чем сам сталкивался.
Я с вами согласен, и мне лично спокойнее, когда все ветки кода покрыты. Просто пытался придумать обоснование, когда один способ может оказаться предпочтительнее другого.
Nullable типы не являются стопроцентной защитой, т.к. а) выдают ворнинги, а не ошибки компиляции, б) могут быть подавлены восклицательнвм знаком, в) компилятор иногда ошибается в определении nullability, г) бесполезны при вызове из контекста с отключенными nullable типами. Поэтому, чтобы не отхватить NRE в неожиданном месте, может потребоваться дополритеььный контроль входных параметров
У этих двух способов есть небольшое различие в том, как считается тестовое покрытие: в вашем способе надо два теста, чтобы обеспечить 100% покрытие, а в способе из статьи - достаточно одного.
Оставим за скобками целесообразность расчёта этого показателя. На некоторых проектах требования по уровню покрытия внедрены в пайплайн сборки, и хочешь не хочешь, но вынужден соблюдать требования
О4ь. С5о з0а п7е.
But... Why??
В случае с v8n, это хоть как-то можно обосновать созвучием - ValidEIGHTioN - лично мне такой способ именования кажется притянутым за уши, но тут уж на вкус и цвет. Но что такое Vi-nine-es и почему это means validation - загадка для меня.