Изначальное утверждение, с которым вы не согласились, было про хранение данных. И вы так и не прояснили, почему "в системе нет единого сервера для данных, поэтому они хранятся у всех участников цепочки " - неверно.
Просто разберитесь: есть разработка application, то что называется application/solution; есть сам блокчейн и это blockchain/core; есть RnD и это research, протоколы и криптография. У всех вышеперечисленных есть деления, но общий обзор я дал вам.
И у нас для разработки на чейне есть blockchain solution(s) engineer. И это про субстрак, солидити и прочее в зависимости от чейна. А есть blockchain engineer/ blockchain core developer.
Это так называют hr и ресечеры, которые любят большой процент отказа на высланные предложения.
А на рынке это четко делится. Особенно на вакансиях с английским описанием. Набор умений на такие позиции отличается примерно на 100% Как вы собираетесь искать при столь разном наборе умений - совершенно неясно.
Ну и статистика у вас некорректная, поскольку разное вместе объединили. Это как искать developer, объединяя frontend js и backend rust developer вместе.
И что поменяется такого страшного, если у вас конструкторы начнут возвращать объекты? Хотите - возвращайте приватные объекты. Да и обычные публичные ни инкапсуляцию, ни разделения слоёв не допустят. Или гайдлайн говорит, что так нельзя?)
Кстати, там выше у вас есть странные штуки, когда есть неиспользуемый ресивер по значению, чтобы "обозначить только для чтения). Лучше не так делать:
Нет, не топлю за функциональное. Вы интересно читаете собеседника: "Можно и в функциональный подход переписать и передавать свои функции-заглушки. Просто как вариант, чтобы показать, что указанный в статье подход не является единственным решением для тестирования, если кто-то пытается это использовать как аргумент."
Но мои вопросы вы "не заметили". Так что с теми проблемами, которые добавляют неуместные интерфейсы в вашем коде?
Как-то вы плохо приписываете мне то, чего я не писал. Попробуйте строго пройти по тексту, который выше. Там нет ничего о том, что интерфейсы не нужны. Там о том, что в го они не нужны так, как вы их используете. И обоснования почему: консирукторы с дополнительной зависимостью на интерфейс, который конструируемый тип имплементирует; большая связность кода; убийство фичи duck typing; отсутствие возможности в вашем же коде прокинуть зависимости; и то, что юниты можно не только на моках писать, часто можно обойтить передачей функции. Вы ведь понимаете, что можно DDD и в функциональном подходе иметь? И тестировать не только через тестовые имплементации интерфейса?
И да. Вы так и не ответили на вопрос о том, что у нас любой пакет, который зависит от инплементации заодно зависит и от интерфейса. Что есть прямая дорога к циклическим зависимостям. Да и то, что имплементации зависят от уровня выше не смотрится чисто.
Я пытаюсь показать, что у вас реализация не DDD, а стайлгайда на DDD, притащенного из других языков. И ваш стайлгайд DDD в го работает плохо.
"авторка ютуб-канала «Адские бабки» Александра Баязитова, которая, вроде как, выступала в качестве наемного писца"
Если "авторка", то и "писцарка"?
да ещё под 0.1%! отличное предложение!
Вы подменяете своё утверждение другим, отличным от начального.
Изначальное утверждение, с которым вы не согласились, было про хранение данных. И вы так и не прояснили, почему "в системе нет единого сервера для данных, поэтому они хранятся у всех участников цепочки " - неверно.
Просто разберитесь: есть разработка application, то что называется application/solution; есть сам блокчейн и это blockchain/core; есть RnD и это research, протоколы и криптография. У всех вышеперечисленных есть деления, но общий обзор я дал вам.
Берем крупняк с ходу https://polygon.technology/careers/
https://www.parity.io/jobs/#jobboard
И у нас для разработки на чейне есть blockchain solution(s) engineer. И это про субстрак, солидити и прочее в зависимости от чейна. А есть blockchain engineer/ blockchain core developer.
Как отличаются по навыкам вам подсказать?
Это так называют hr и ресечеры, которые любят большой процент отказа на высланные предложения.
А на рынке это четко делится. Особенно на вакансиях с английским описанием. Набор умений на такие позиции отличается примерно на 100% Как вы собираетесь искать при столь разном наборе умений - совершенно неясно.
Ну и статистика у вас некорректная, поскольку разное вместе объединили. Это как искать developer, объединяя frontend js и backend rust developer вместе.
Блокчейн разработчик или разработчик на блокчейне у вас в статье?
Было бы здорово.
Я лично property based тесты в каждом гошном проекте использую. И без них трудно.
Действительно круто!
Смущает лишь provider.T, убивающий возможность использовать многие сторонние пакеты для тестирования. Мне первым на ум пришел rapid, например.
В D всё сообщество такое, как его представляете вы? Это бы ответило на вопрос, почему язык так на рынке и не растёт.
Много лет работали на го?
Говорят, если основное время на набор кода уходит, то надо не программистов, а машинисток.
Основное время в программировании уходит на набор букв у вас? Точно?
Подождите в пределах месяца и заиспользуйте
atomic.Pointer[T]https://pkg.go.dev/sync/atomic@master#Pointer , вроде должен упростить вашу задачу.В нынешних обстоятельствах вопрос только в том с какой стороны и когда именно дернут рубильник. Но итог будет одним.
Ну нельзя же было сразу соглашаться. Надо было и поломаться цену понабивать.
Кто владеет торрентами?
И что поменяется такого страшного, если у вас конструкторы начнут возвращать объекты? Хотите - возвращайте приватные объекты. Да и обычные публичные ни инкапсуляцию, ни разделения слоёв не допустят. Или гайдлайн говорит, что так нельзя?)
Кстати, там выше у вас есть странные штуки, когда есть неиспользуемый ресивер по значению, чтобы "обозначить только для чтения). Лучше не так делать:
```
func (MoonRule) IsDepositAllowed(user User, wallet Wallet, amount Money) (bool, error) {
if IsRisingMoon() {
return true, nil
}
return false, nil
```
Про классику в виде "источники данных могут и меняться". У вас часто на проде базы меняются?) Обычно это очень больно и происходит примерно никогда.
Нет, не топлю за функциональное. Вы интересно читаете собеседника: "Можно и в функциональный подход переписать и передавать свои функции-заглушки. Просто как вариант, чтобы показать, что указанный в статье подход не является единственным решением для тестирования, если кто-то пытается это использовать как аргумент."
Но мои вопросы вы "не заметили". Так что с теми проблемами, которые добавляют неуместные интерфейсы в вашем коде?
Как-то вы плохо приписываете мне то, чего я не писал. Попробуйте строго пройти по тексту, который выше. Там нет ничего о том, что интерфейсы не нужны. Там о том, что в го они не нужны так, как вы их используете. И обоснования почему: консирукторы с дополнительной зависимостью на интерфейс, который конструируемый тип имплементирует; большая связность кода; убийство фичи duck typing; отсутствие возможности в вашем же коде прокинуть зависимости; и то, что юниты можно не только на моках писать, часто можно обойтить передачей функции. Вы ведь понимаете, что можно DDD и в функциональном подходе иметь? И тестировать не только через тестовые имплементации интерфейса?
И да. Вы так и не ответили на вопрос о том, что у нас любой пакет, который зависит от инплементации заодно зависит и от интерфейса. Что есть прямая дорога к циклическим зависимостям. Да и то, что имплементации зависят от уровня выше не смотрится чисто.
Я пытаюсь показать, что у вас реализация не DDD, а стайлгайда на DDD, притащенного из других языков. И ваш стайлгайд DDD в го работает плохо.