• Не надо портить инженерам десктопы своими мобильными решениями, одумайтесь
    0

    Да, поэтому когда надо перелезать участок забора рефакторят.

  • Не надо портить инженерам десктопы своими мобильными решениями, одумайтесь
    0

    Они этим одновременно плохи и хороши.

  • Не надо портить инженерам десктопы своими мобильными решениями, одумайтесь
    0

    Обычно наоборот, конечно. Интерфейсы плохи тем, что их расширение это breaking change. Или кто-то соверинжинирил и сейчас ещё не нужен класс и интерфейс модно убрать лишнюю сущность, оставив только класс.

  • Не надо портить инженерам десктопы своими мобильными решениями, одумайтесь
    +9

    А меня наоборот. Теоретически это мешает переделывать интерфейс в класс и обратно (главное роль типа в программе, а интерфейс это или класс — вторична). Практически, правда, я соблюдаю нейминг конвеншнс того места, где я оказался.

  • ООП: Кто взял Измаил? Вопрос принадлежности методов объекту
    +2

    Кстати в мире Гарри Поттера есть машина времени временные петли. Например, там было два Гарри Поттера — один наблюдал за другим.


    Я не помню наблюдалось ли там две Совы но не помню также фундаментального ограничения на этот счёт.


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

  • ООП: Кто взял Измаил? Вопрос принадлежности методов объекту
    0

    Тогда оба варианта наилучшие. Так как оба меньше слона. Но вы, наверное, имели ввиду "быть как можно меньше".


    Для основной мысли моего высказывания, впрочем, это не особенно важно — я просил т хотел показать что Ви зависимости от постановки меняется дизайн и без понимания того что мы дизайном и с какой целью трудно нельзя сказать что само собой разумеется, что метод X должен быть в классе Y

  • ООП: Кто взял Измаил? Вопрос принадлежности методов объекту
    0

    То что вы написали после "нет" никак не отрицает ни основной мысли комментария ни процитированного текста :D.


    " — собака куда меньше слона.


    • Нет, муравей куда меньше слона"
  • Slack подала антимонопольную жалобу в Еврокомиссию на Microsoft из-за политики распространения Teams
    0

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

  • ООП: Кто взял Измаил? Вопрос принадлежности методов объекту
    0

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


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


    Куда проще завести разные классы кошек с методом "прокормить" и описывать процесс кормления там а человека и кормушку вынести за скобки. Например человека вообще не включать в модель а кормушку использовать только для хранения ёмкости.

  • ООП: Кто взял Измаил? Вопрос принадлежности методов объекту
    0

    Или сделать таблицу смещений (подобно тому как при загрузке exe в досе было)

  • Медленный код — вообще не проблема, если ты знаешь как его ускорить. Главное красиво
    0

    А как вы пишете тесты на перформанс и как избегание регрессий в перформансе?

  • ООП: Кто взял Измаил? Вопрос принадлежности методов объекту
    +1

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


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

  • ООП: Кто взял Измаил? Вопрос принадлежности методов объекту
    0
    Это не программирование, это схоластика, которая присуща только ООП. Причём это буквально так. В реальном мире не существует никакого наследования.

    Это все про то, как человеку удобно думать про окружающий мир. Наследование это отражение того факта, что человеку удобно делить предметы на категории и подкатегории обладают по умолчанию свойствами надкатегорий (если все собаки хвостаты, а пудели — собаки, то пудели хвостаты).

  • ООП: Кто взял Измаил? Вопрос принадлежности методов объекту
    +2

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


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


    Для меня из этого следует, что к какому классу принадлежит метод зависит от того, что мы моделируем а что отбрасываем. Например, если мы хотим смоделировать то, как Суворов берет крепости, вполне допустим и Измаил.Взять() (так как никаких других полководцев мы не рассматриваем и алгоритм взятия крепости зависит только от нее самой).


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


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

  • «Обратные интервью» или Как вовремя перевернуть доску
    –1

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


    Мы можем, например, дать простой "hello world", дать денег за hello world чтобы снизить влияние нежелания писать задания. Ну или не хотящих писать задания по какой-то другой причине отвергать.

  • ООП: Кто взял Измаил? Вопрос принадлежности методов объекту
    0

    Я про это:


    Это вообще-то не прямоугольник, а некоторая другая сущность, с прямоугольником связанная только формой.


    • Это ничего особо не изменит в дискуссии *

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


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


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


    Если у вас в рисовалке есть
    изменяемые прямоугольники и квадраты, то либо класс фигуры должен меняться от изменения параметров; либо не надо требовать чтобы квадраты были прямоугольниками; либо надо обозначить что при изменении одной стороны прямоугольника не было бы ожидания, что у прямоугольника размеры сторон независимы. (Выделить Изменяемый прямоугольник отдельно и Изменяемый прямоугольник с независимыми сторонами отдельно)


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

  • ООП: Кто взял Измаил? Вопрос принадлежности методов объекту
    –1

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


    • Здесь слово "всегда" означает что он не может перестать быт квадратом (в некоторых смолтоках можно поменять класс объекта, насколько я знаю, а в языке cecil есть предикатные подклассы)
  • «Обратные интервью» или Как вовремя перевернуть доску
    0

    Правильно я понимаю, что тот кто не способен написать "привет мир" способен написать хайлоад систему?

  • Надо помолчать
    +3

    Это вы в чате делаете или в устном общении но с отвращением?

  • Созвоны не решают никаких проблем. Они нужны только людям, которые не умеют писать код
    0

    Пригнали

  • Созвоны не решают никаких проблем. Они нужны только людям, которые не умеют писать код
    0

    Когда говорят "дискриминация" часто имеют ввиду "негативную дискриминацию" а есть еще "позитивная"

  • Созвоны не решают никаких проблем. Они нужны только людям, которые не умеют писать код
    0

    Представьте себе, что вас пригнали на несколько докладов на типичную конференцию типа WWDC по структуре: Презентации по полчаса, несколько выступающих о том как повысились надои в бекенде с подробным разжевыванием того, что сделано и Q&A в конце, часть тем вам интересна, а часть нет.

  • Созвоны не решают никаких проблем. Они нужны только людям, которые не умеют писать код
    0

    Вы сначала определите, что именно вы хотите отсчитывать? Рабство, расизм или что-то еще? Если расизм то официальный или неофициальный?

  • Созвоны не решают никаких проблем. Они нужны только людям, которые не умеют писать код
    +1
    От чего они там митингуют, если роли поменялись аж 155 лет назад?

    Вы лет на 100 где-то промахнулись

  • Созвоны не решают никаких проблем. Они нужны только людям, которые не умеют писать код
    +3

    Текст хорош тем, что по нему легко искать, легко общаться асинхронно, он может быть визуален (отступы, буллиты, жирнота и прочее).


    Голос хорош тем, что он не занимает руки (можно одновременно показывать что-то и говорить, например) он принудительно синхронен (обычно не принято просто так класть трубку и куда-то уходить — в чате это делается достаточно легко), многим проще говорить чем печатать.


    Голос хорош если нужен быстрый обмен короткими сообщениями и желательно побыстрее получить результат.


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


    Хреновые созвоны не учитывают эти особенности:


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

    В хорошем созвоне участвют только те, кому это надо и интересно. Результат может быть зафиксирован текстом (именно результат, все промежуточные переговоры не интересны).

  • Вероятно, хватит рекомендовать «Чистый код»
    0

    А вот интересно как в ФП стиле решить эту задачу. Только чтобы перечень героев игры был расширяем. Мы делаем движок с человеком, а кошки и разные модели кормушек в аддонах.

  • Вероятно, хватит рекомендовать «Чистый код»
    0
    Оптимизировать просто нечего, так как всё уже предельно просто.

    Оптимизация, это не всегда упрощение (кеш, предсказание переходов, JIT это усложенение, а не упрощение)


    В большинстве паттернов использования данные читались только 1 раз, и кэш прикручивать было бессмысленно.

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


    Я правильно понимаю, что исследование произваодительности показало, что узкое место — доступ к БД (т.е. задача IO/Network bound)?


    А что именно в этом доступе к БД тормозило? Генерация запросов, latency в сети, составление планов? Исполнение запросов?

  • Вероятно, хватит рекомендовать «Чистый код»
    +1

    https://martinfowler.com/bliki/FunctionLength.html


    Smalltalk's graphics class had a method for this called 'highlight', whose implementation was just a call to the method 'reverse' [4]. The name of the method was longer than its implementation — but that didn't matter because there was a big distance between the intention of the code and its implementation.
  • Вероятно, хватит рекомендовать «Чистый код»
    0

    А как это связано с разбиением на функции?

  • Представляем .NET 5.0 Preview 6
    0

    Есть еще проект MAUI планируется на .NET 6, судя по странице, как-то Linux может поддерживаться (там написано community, как у Xamarin Forms, вероятно, это будет делать не MS, а классический opensource)

  • Вероятно, хватит рекомендовать «Чистый код»
    0

    undel.


    но, к слову, почему-то заметно тормозит в некоторых случаях

    Может зависеть от платформы, напримерп, поддерживает ли компилятор инлайнинг. А может было что-то еще. Надо профилировать.

  • Анатомия юнит тестирования
    0

    Тут вопрос, что вы называете моками и что юнит тестами.


    Вот терминология у Фаулера моки


    Моки
    • Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.
    • Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example).
    • Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test.
    • Spies are stubs that also record some information based on how they were called. One form of this might be an email service that records how many messages it was sent.
    • Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.

    Юнит тесты


    Если для вас приемлемы sociable юнит тесты с фейками, то: создаем единственный фейк на кеш. При его изменении его меняем. Надо поменять только тесты на кеш и фейк. Тесты тех, кто использует кеш остаются, примерно такими же, кроме новых требований (т.е. ситууации когда возвращаются ItemState отличный от того который раньше кодировался булеаном и это важно в конкретном требовании).


    Так же см разные паттерны у Шора. Например, использование signature shielding.


    Еще можно сохранить совместимость с boolean либо просто добавив новый метод вместо переделки существующего, либо сделав imlicit cast к булеан. Последним, правда, я не пользовался, если у кого-то есть какой-то опыт, было бы интересно узнать.

  • Что я узнал после более чем 1000 code review
    0
    Вы пытаетесь использовать ветки для документации истории изменений. Но они для этого не предназначены. Они нужны для изоляции кода.

    Как раз для изоляции — фич друг от друга.


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

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


    Все это нужно до того момента, когда надо интегрировать фичу, после того как фича готова, это можно засквешить.


    Мердж коммит находится «вдалеке» от основного коммита и надо искать где находится тот, про который написано в мердже.

    Делается squash merge и я вижу только один коммит. Если не хочется сквешить, то можно проребейзить перед мерджем и они будут рядом.


    А в мастер не обязательно мержить, когда вся фича готова. Можно замерджить и 10 фич и полфичи.

    Чем больше объем мерджа тем больше разбираться что сломало CI, меньше гранулярность при черрипике, если надо будет, больше объем ревью и так далее.


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


    Необязательно: она может быть сделана, но непроревьювена.

    Зачем ее тогда брать, после ревью может быть сильно изменена?


    Я бы сказал, что это нетипичный случай.

  • Что я узнал после более чем 1000 code review
    0
    Почему нельзя взглянуть сразу в коммит сообщения, где так же будет ссылка на таску в джире (если коммит связан с таской). Зачем мне идти в мердж коммит, который фиг знает где, открывать пул реквест и только там смотреть конкретные таски?

    Что значит фиг знает где? Он составляет историю мастера.


    Я совершенно не против, чтобы там были и идентификаторы фич. Просто если их много удобнее видеть ссылку PR в целом и текстовый осмысленный коммент, если нужны детали можно открыть PR и ходить по ссылкам на фичи если их несколько.


    Если она одна, наверное, иметь ссылку на PR чуть менее удобно, чем на фичу в джире на один дополнительный клик. Зато имея ссылку на PR можно посмотреть и дополнительные вещи (типа кто ревьюил и какие были замечания.)


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


    Зачем что-то мержить в мастер пофично?

    Потому, что вы можете работать, как вы сами говорили, над несколькими фичами, одна может быть готова отправке в мастер, другая не готова — тесты не дописаны, не компилируется, нет документации или какие там у вас характеристики проверяет билд еще.


    какую версию кода брать для дальнейшей работы над другими задачами: с фичей или без неё.

    Если она не вмерджена в мастер, значит не готова. Берите всегда из мастера. (Кроме того случая, когда вы работаете над долгоиграющей фичей — тогда берите из фичи, над которой работаете)

  • Что я узнал после более чем 1000 code review
    0
    Совершенно верно. Собственно так это и задумывалось

    Приведите цитату плиз, я там услышал что им удобно репо на команду, а не ветку на разраба


    Merge commit будет содержать название ветки, но что мне это даст?

    Обычно он содержит ссылку на PR которую можно открыть и посмотреть все детали


    Как фича бренчи улучшают понимание, если разработчики синхронизируются только с мастер веткой?

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


    Но зачем засорять гит тысячами мелких бренчей мне непонятно.

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

  • Что я узнал после более чем 1000 code review
    0
    Что значит зачем? Программирование — это творческий процесс. Разработчики работают, как им удобнее. Если у меня есть 2 задачи по фронту и бакенду для фичи A и фронт+бакэнд для фичи B.
    То мне может показаться удобнее написать сначала бакэнд для обеих фич а затем фронт для обеиз фич.

    Ок тут согласен — вполне допустимо в каких-то случаях создавать ветку на несколько связанных задач, если их удобнее сделать как одну.


    Но вы-то предлагает ветку на разработчика — т.е. там должны быть вообще все зачачи разработчика даже логически не связанные или как?


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

    Наверное тут какое-то недопонимание. Я подразумеваю, что ветки сливаются в какой-то момент в основную. Соответсвтенно, merge commit будет содержать описание и ссылку на задачу и можно будет посмотреть в истории по master.


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


    Я например постоянно переписываю документацию. И что мне для каждой опечатки таску и отдельную ветку создавать?

    Ага, с моей точки зрения это не должно занимать сильно больше времени, чем написание данного коммента.

  • Что я узнал после более чем 1000 code review
    0
    Во первых возникает туева хуча веток. Часто работу нельзя правильно разбить по этим веткам, да и не нужно.

    Что такое "правильно разбивать" и почему их невозможно разбить?


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

    Что их заставляет так делать? Как они поступают когда одна задача готова, а другая — еще нет? Как потом в истории разобраться зачем именно было сделано конкретное изменение?


    Непонятно куда девать коммиты которые не связаны непосредственно с тасками, либо таски не созданы, либо уже закрыты.

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


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

  • Что я узнал после более чем 1000 code review
    0

    Вы имеете ввиду что на одного разработчика ровно одна ветка? Или что ветка на фичу И разработчика?


    Ссылка на forking workflow она про создание форков репы а не про ветки.


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


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

  • Анатомия юнит тестирования
    0

    Возможно, вам помогут идеи Джеймса Шора

  • Что я узнал после более чем 1000 code review
    0

    Какое у вас тестовое покрытие? Как оно измерено?