там грань довольно слабая :)

кстати я забыл уже чем в шарпе стракты от класов отличаются.

там серьезные отличия как оно на уровне CLR работает

там серьезные отличия как оно на уровне CLR работает

да. там вроде они в разных частях памяти хранятся.

вообще все от того что классы это полнейшая херня

Обман, чтобы набрать классы

вся соль dto - структура данных. И используют для этого классы в основном потому.... что языки эти не предусматривают альтернативы) в c# вон есть struct

еще есть tuple и они, со struct, являются value type

сохранить место на экране при вызове метода или конструктора, только для этого

primitive obsession

primitive obsession

можно ли говорить о primitive obsession когда ты собираешь json-ку для респонса из api?

или реквест тебе надо пробросить на обработку

можно ли говорить о primitive obsession когда ты собираешь json-ку для респонса из api?

response<T> сделать, чтоб избежать?

response<T> сделать, чтоб избежать?

ну мол в чем проблема с primitive obsession если все что ты делаешь с этими примитивами - выплевываешь их в консольку например

есть хороший показатель того есть у тебя в проекте эта болячка или нет - составить по всем кейвордам и типам облако тегов. И если превалировать будет string, float, int то явно что-то не то

это буквально будет означать что "мое крутое приложение чето делает со строками, флотамии интами"

а не "система автоматизации финансовой отчетности"

есть хороший показатель того есть у тебя в проекте эта болячка или нет - составить по всем кейвордам и типам облако тегов. И если превалировать будет string, float, int то явно что-то не то

если это бизнес логика, тогда думаю показатель, а так в IO слоях эта проблема менее остро стоит имхо

ну мол в чем проблема с primitive obsession если все что ты делаешь с этими примитивами - выплевываешь их в консольку например

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

и туда же, против классов, еще проблемы с nullability

@fes0r есть опенсорс код посмотреть, чтоб кошерный :) ?

вообще, где можно глянуть на DDD + CQRS?

если это бизнес логика, тогда думаю показатель, а так в IO слоях эта проблема менее остро стоит имхо

а IO это IO) там норм

@fes0r есть опенсорс код посмотреть, чтоб кошерный :) ?

я не встречал)

тут две проблемы: - никто не будет выкладывать большие и специализированные системы под конкретный домен в опенсурс - "посмотреть код" плохо передает суть DDD, как никак DDD это больше про то как ты узнаешь что писать и как все видоизменяется с увеличением понимания у тебя предметной области

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

тут две проблемы: - никто не будет выкладывать большие и специализированные системы под конкретный домен в опенсурс - "посмотреть код" плохо передает суть DDD, как никак DDD это больше про то как ты узнаешь что писать и как все видоизменяется с увеличением понимания у тебя предметной области

А DDD и TDD совместимы или неважно выбрать что то одно?

хоть оба)

оно о разном же)

А DDD и TDD совместимы или неважно выбрать что то одно?

нет, ваще не совместимы. И боже упаси тебя добавить туда BDD и/или FDD

ддд это в последнюю очередь о техниках)

DDD это трейдмарк Эванса. По факту это просто про моделирование предметной области, существовало задолго до этого TM.

Driven Design и Driven Development это все ж разные штуки.

например тебя никто не осудит если у тебя команда работает по Feature Driven Development, при этом юзая BDD для сбора требований и TDD для повышения качества кода, при этом за счет BDD они смогут выстроить более грамотную модель предметной области а за счет TDD эта модель будет менее связанной и более проработанной с точки зрения клиентскго кода

Driven Design и Driven Development это все ж разные штуки.

Как говорил Mark Semann с TDD легко впасть в Driven Design

Как говорил Mark Semann с TDD легко впасть в Driven Design

тут надо еще определиться что для тебя tdd. Это "тесты в начале" или "тесты как метрика качества кода". Типа удобно писать тесты - с кодом все хорошо

например тебя никто не осудит если у тебя команда работает по Feature Driven Development, при этом юзая BDD для сбора требований и TDD для повышения качества кода, при этом за счет BDD они смогут выстроить более грамотную модель предметной области а за счет TDD эта модель будет менее связанной и более проработанной с точки зрения клиентскго кода

Это прям какой-то идеальный мир

Это прям какой-то идеальный мир

нет это просто техники, ты сам выстраиваешь то как ты работаешь и какие техники тебе помогают

но знать список ты должен

и для чего они

иначе велосипеды опять будут изобретать

кстати я забыл уже чем в шарпе стракты от класов отличаются.

Тем что классы передаются по ссылке, а структуры - по значению.

Тем что классы передаются по ссылке, а структуры - по значению.

"инстансы классов"...

и именно это как по мне делает структуры идеальными dto)

и именно это как по мне делает структуры идеальными dto)

Ну при жедлании можно и в managed-режиме работать со структурами по ссылке)

Есть там у нас ключевое слово ref..) И если почитать ченжлоги с 6 версии языка по 7.3, то там постоянно что-то добавляли на этот счёт)

Комрады, а есть кто-нибудь кто со сваггером хорошо дружит? Забуксовал что-то

и именно это как по мне делает структуры идеальными dto)

Кроче вот https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/ref

Комрады, а есть кто-нибудь кто со сваггером хорошо дружит? Забуксовал что-то

Смотря в чем вопрос, озвучьте его)

Смотря в чем вопрос, озвучьте его)

Не получается описать свагером WSSE авторизацию

Не было такого таска у меня, а в чем загвоздка?

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

Не получается описать свагером WSSE авторизацию

https://github.com/swagger-api/swagger-codegen/issues/4127

https://github.com/swagger-api/swagger-codegen/issues/4127

? похоже птичка обломинго... спасибо!

Ну, как сказать - это opensource. Если очень надо, можно предложить PR в нужный проект)

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

а уже RAML компилить в сваггер при желании)

@fes0r, всё-таки уговорили выступить на fwdays?)

@fes0r, всё-таки уговорили выступить на fwdays?)

может быть

А, в процессе, хорошо)

Ребята, как считаете: от код ревью больше вреда или пользы?

странный вопрос)

Это точно. Не зря его придумали же?

Ребята, как считаете: от код ревью больше вреда или пользы?

зависит от целей этого ревью

но если у тебя проект однодневка, то вообще мало что для него нужно

зависит от целей этого ревью

а какие там цели могут быть?) чсв потешить?

если есть возможность заменить ревью кода парным программированием (или mob development) то в целом код ревью не нужен)

а какие там цели могут быть?) чсв потешить?

ну мне не нравится подход в апрувом PR, мне нравится подход с ревью вмердженного кода.

mob?

если есть возможность заменить ревью кода парным программированием (или mob development) то в целом код ревью не нужен)

это если не оба джуны

mob?

https://www.youtube.com/watch?v=8cy64qkgTyI

это если не оба джуны

ну а так они оба будут ревьювить друг друга, много наревьювят да

ну мне не нравится подход в апрувом PR, мне нравится подход с ревью вмердженного кода.

а что не нравится-то?

а что не нравится-то?

не эффективно, но может быть эффективнее других вариантов при определенных обстоятельствах

ну а так они оба будут ревьювить друг друга, много наревьювят да

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

не эффективно, но может быть эффективнее других вариантов при определенных обстоятельствах

а почему эффективность второго варианта должна быть выше?

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

а почему эффективность второго варианта должна быть выше?

"второго" это какого?) идея в том что бы уменьшить длину фидбэк лупа

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

если тебе надо ждать ревью день - это не эффективно. Если минут 10 - более-менее эффективно. Не надо ждать -> парное программирование

"второго" это какого?) идея в том что бы уменьшить длину фидбэк лупа

я про "ну мне не нравится подход в апрувом PR, мне нравится подход с ревью вмердженного кода"

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

Поиск поверхностных ошибок - это не ревью

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

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

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

поиск ошибок в принципе - это не ревью, а тестирование)

если тебе надо ждать ревью день - это не эффективно. Если минут 10 - более-менее эффективно. Не надо ждать -> парное программирование

Что за ревью можно сделать за 10 минут?

Или совсем мелкие изменения?

Что за ревью можно сделать за 10 минут?

а сколько кода ты можешь написать за 30 минут?)

Одну строку, если повезет, иногда

Ну, бывает по разному, если серьёзно

поиск ошибок в принципе - это не ревью, а тестирование)

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

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

ну это не ошибка ведь)

к чему эта подмена понятий)

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

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

ну это не ошибка, это и есть передача знаний.

и с формулировкой "учитель -> ученик" согласиться не выходит