Re[28]: GoF и ФП
От: Sharov Россия  
Дата: 05.12.20 15:55
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Sharov, Вы писали:


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

S>Не совсем. Ещё нужна возможность конструировать функции на лету.
S>В приведённом примере нам повезло — функция + уже была в стандартной библиотеке, и мы ей воспользовались.
S>В более интересных случаях могут потребоваться одноразовые функции, которые никто в библиотеку складывать не будет. Например, функция "отрезать и выкинуть последние 4 символа строки" — чтобы избавиться от единиц измерения.
S>Или наоборот, "добавить ко всем строчкам указанный суффикс".
S>Вот такую простейшую вещь вы на языке C вспотеете записывать — потому, что в нём нету ни замыканий, ни анонимных функций. А указатели на функцию в нём, конечно же, есть.

Если in-place, то да, нужны лямбды. Ну в С понадобится отдельно написать ф-ию, но на паттерне Стратегия это не скажется...
Кодом людям нужно помогать!
Re[29]: GoF и ФП
От: samius Япония http://sams-tricks.blogspot.com
Дата: 05.12.20 16:10
Оценка:
Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, Sinclair, Вы писали:


S>>Вот такую простейшую вещь вы на языке C вспотеете записывать — потому, что в нём нету ни замыканий, ни анонимных функций. А указатели на функцию в нём, конечно же, есть.


S>Если in-place, то да, нужны лямбды. Ну в С понадобится отдельно написать ф-ию, но на паттерне Стратегия это не скажется...


А на прокси скажется.
Re[30]: GoF и ФП
От: Sharov Россия  
Дата: 05.12.20 18:11
Оценка:
Здравствуйте, samius, Вы писали:

S>>Если in-place, то да, нужны лямбды. Ну в С понадобится отдельно написать ф-ию, но на паттерне Стратегия это не скажется...

S>А на прокси скажется.

Не понял почему? Прокси это же вообще отдельная сущность/ф-ия.
Кодом людям нужно помогать!
Re[29]: GoF и ФП
От: Sinclair Россия https://github.com/evilguest/
Дата: 06.12.20 06:18
Оценка:
Здравствуйте, Sharov, Вы писали:

S>Если in-place, то да, нужны лямбды. Ну в С понадобится отдельно написать ф-ию, но на паттерне Стратегия это не скажется...

В С понадобится не только написать функцию; потребуется протаскивать в неё контекст.
Но вы совершенно правы — сам паттерн будет иметь место и в C. Точнее, определённый вариант паттерна.
Надо просто понимать, что паттерны — это обобщённые описания решений типичных задач в рамках определённой технологии.
Если у нас какое-то решение сразу встроено в язык, то паттерн "исчезает" — то есть его можно заметить только опытным взглядом.
Поэтому в ФП никто не говорит о паттернах "стратегия" и "декоратор" — их реализация встроена в язык.
Точно так же нет паттерна subscriber/publisher в дотнете — там есть ивенты, которые реализуют его из коробки.
В дельфи нет фабрик — есть виртуальные конструкторы.
В С++ нет паттерна "VMT", которым можно реализовать наследование реализаций в C — потому что порождение VMT и обращение к нему встроены в язык.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[31]: GoF и ФП
От: samius Япония http://sams-tricks.blogspot.com
Дата: 06.12.20 18:38
Оценка:
Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, samius, Вы писали:


S>>>Если in-place, то да, нужны лямбды. Ну в С понадобится отдельно написать ф-ию, но на паттерне Стратегия это не скажется...

S>>А на прокси скажется.

S>Не понял почему? Прокси это же вообще отдельная сущность/ф-ия.

Паттерн указывает на то, что прокси хранит ссылку на то, что заменяет. С лямбдой — нет проблем. Когда лямбд нет и за них указатели на функции, то хранить там что-то кроме указателя не получается.
Re[24]: DDD протаскивание других слоев через параметры методов Domain
От: Sinclair Россия https://github.com/evilguest/
Дата: 09.12.20 08:09
Оценка:
Здравствуйте, Sharov, Вы писали:
S>Речь о том, где эти связи находятся\локализованы -- по всему коду, от DAO к сервисам, или только в AggregateRoot?
В сервисах, естественно. AggregateRoot у вас чреват неявными зависимостями через справочные entity — когда кажется, что всё разделено, однако при изменении в одном месте разъезжается ещё в семи.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[24]: DDD протаскивание других слоев через параметры метод
От: AndrewJD США  
Дата: 09.12.20 18:40
Оценка: 8 (1) +1
Здравствуйте, Sharov, Вы писали:

S>Еще раз: да, в каких-то случаях все будет 1 в 1. В самых, вероятно, простейших.

Я например утверждаю, что она такая же и для сложных случаев.

S>Там вся соль на картинке именно в связях,

S>т.е. ребрах между сущностями в соотв. уровне. Вот эти связи и есть сложность, которую надо контролировать.
Количество связей плюс/минус одинаково ибо оно дикуется бизнес логикой, вопрос в том где эти связи располагаются.

S>DDD предлагает подход, где эти связи отсутствуют, т.е. сложность проще контролировать. Т.е. изоляция на уровне дизайна\архитектуры. А не только в коде.

Сливание всего в кучу не означает что связи исчезли. ИМХО, в этом и проблема, что в DDD постулируется что это приводит к лучшему дизайну без доказательств. Даже в этой статье приводится "Aggregates allow us to encapsulate parts of our domain so our API becomes simpler and changes inside aggregates are easier to implement (we don’t need to analyse our changes impact on some other parts of the domain because it doesn’t exist)" без аргументов откуда это следует. Из моей практики я вижу строго наоборот, что разделние логики и данных уменьщает связанность и делает дизайн гибче, а код быстрее.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Отредактировано 09.12.2020 19:02 AndrewJD . Предыдущая версия .
Re[25]: DDD протаскивание других слоев через параметры метод
От: Sharov Россия  
Дата: 10.12.20 12:34
Оценка:
Здравствуйте, AndrewJD, Вы писали:

S>>Еще раз: да, в каких-то случаях все будет 1 в 1. В самых, вероятно, простейших.

AJD>Я например утверждаю, что она такая же и для сложных случаев.

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

S>>Там вся соль на картинке именно в связях,

S>>т.е. ребрах между сущностями в соотв. уровне. Вот эти связи и есть сложность, которую надо контролировать.
AJD>Количество связей плюс/минус одинаково ибо оно дикуется бизнес логикой, вопрос в том где эти связи располагаются.

Как я понял, в DDD эти связи стараются локализовать, изолировать.

S>>DDD предлагает подход, где эти связи отсутствуют, т.е. сложность проще контролировать. Т.е. изоляция на уровне дизайна\архитектуры. А не только в коде.

AJD>Сливание всего в кучу не означает что связи исчезли. ИМХО, в этом и проблема, что в DDD постулируется что это приводит к лучшему дизайну без доказательств. Даже в этой статье приводится "Aggregates allow us to encapsulate parts of our domain so our API becomes simpler and changes inside aggregates are easier to implement (we don’t need to analyse our changes impact on some other parts of the domain because it doesn’t exist)" без аргументов откуда это следует. Из моей практики я вижу строго наоборот, что разделние логики и данных уменьщает связанность и делает дизайн гибче, а код быстрее.

А что и как тут можно доказать? Задачи DDD -- уменьшение связанности за счет выделения AR, т.е.
чем меньше ребер (на любом уровне), тем лучше. В DDD утверждается, что если делать все по науке,
то ребра будут только в BL(domain service), внутри AR, край -- между AR.
Кодом людям нужно помогать!
Re[11]: DDD протаскивание других слоев через параметры методов Domain
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 13.01.21 09:22
Оценка: 76 (1)
Здравствуйте, #John, Вы писали:

J>Допустим у нас есть пользователь у него есть контактная информация и нам нужно добавить

J>бизнес логику, когда пользователь нажимает кнопку "Save", нам приходят данные: `Info` и `email` и мы их обрабатываем.

J>В DDD это выглядело бы вот так:


  Domain Layer
J>
J>    public class User
J>    {
J>        public Guid Id { get; private set; }

J>        public string UserName { get; private set; }

J>        public string Info { get; private set; }

J>        public ContactInformation ContactInformation { get; private set; }

J>        protected internal User() { }

J>        /// <summary>
J>        /// Used for loading for ex. from the DB
J>        /// </summary>
J>        public static User Create(Guid id, string userName, string info, ContactInformation contactInformation)
J>        {
J>            return new User
J>            {
J>                Id = id,
J>                Info = info,
J>                UserName = userName,
J>                ContactInformation = contactInformation,
J>            };
J>        }

J>        /// <summary>
J>        /// Used for creation 
J>        /// </summary>
J>        public static User Create(string userName, string info, ContactInformation contactInformation)
J>        {
J>            if (string.IsNullOrWhiteSpace(userName))
J>            {
J>                throw new ArgumentException();
J>            }
J>            // other validation ...

J>            var id = Guid.NewGuid();

J>            return Create(id, info, userName, contactInformation);
J>        }

J>        public virtual ContactInformation GetContactInformation() => ContactInformation;

J>        public virtual void UpdateInformation(string info, string email)
J>        {
J>            // validation ..

J>            this.Info = info;
J>            GetContactInformation().UpdateEmail(email);
J>        }
J>    }
J>    public class ContactInformation
J>    {
J>        public Guid Id { get; private set; }

J>        public string Phone { get; private set; }

J>        public string Email { get; private set; }

J>        protected internal ContactInformation() { }

J>        public static ContactInformation Create(Guid id, string phone, string email) => new ContactInformation
J>        {
J>            Id = id,
J>            Phone = phone,
J>            Email = email
J>        };

J>        public static ContactInformation Create(string phone, string email)
J>        {
J>            var id = Guid.NewGuid();
J>            return Create(phone, email);
J>        }

J>        public static ContactInformation Create(string email) => Create(null, email);

J>        internal virtual void UpdateEmail(string newEmail)
J>        {
J>            if (newEmail.Contains("admin"))
J>            {
J>                throw new ArgumentException();
J>            }

J>            this.Email = newEmail;
J>        }
J>    }

J>


  Infrastructure Layer
J>
J>    public class UserRepository
J>    {

J>        public User Load(Guid id)
J>        {
J>            // Loading from the DB ...
J>            var contactInformation = ContactInformation.Create(Guid.NewGuid(), "bob@example.com", "+123456");
J>            var user = User.Create(id, "Bob", "Smth", contactInformation);
J>            return user;
J>        }
J>        public void Save(User user)
J>        {

J>        }
J>    }
J>


  Application Layer
J>
J>   public class UserInformationDto
J>    {
J>        public string Email { get; set; }
J>        public string Info { get; set; }
J>    }

J>    public class UserService
J>    {

J>        // IUserRepository
J>        private UserRepository userRepository;

J>        public UserService(UserRepository userRepository)
J>        {
J>            this.userRepository = userRepository;
J>        }

J>        public void UpdateUserInformation(Guid userId, UserInformationDto userInformation)
J>        {

J>            // validation ..

J>            var user = userRepository.Load(userId);

J>            user.UpdateInformation(userInformation.Info, userInformation.Email);

J>            userRepository.Save(user);
J>        }
J>    }
J>


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

Вот как должен выглядеть такой код (в плохом случае):
public class User
{
    public Guid Id { get; set; }
    public string UserName { get; set; }
    public string Info { get; set; }
    public ContactInformation ContactInformation { get; set; }
}

public class ContactInformation
{
    public Guid Id { get; set; }
    public string Phone { get; set; }
    public string Email { get; set; }
}

public class UserInformationDto
{
    public string Email { get; set; }
    public string Info { get; set; }
}


public class UserService
{
    public async Task UpdateUserInformation(Guid userId, UserInformationDto userInformation)
    {
        // validation ..
        var user = await dbContext.Users.Include(u => u.ContactInformation).FindAsync(userId);
        user.Info = userInformation.Info;
        user.ContactInformation.Email = userInformation.Email;
        dbContext.Save(user);
        dbContext.Save(user.ContactInformation);
        await dbContext.SaveChangesAsync();
    }
}


А в идеале еще и два класса данных объединить в один и испольовать modelbinding или мапперы, а не ручное присваивание DTO. И избавится от UserService, а код написать непосредственно в контроллере.
И мне все равно что там более или менее ООП, что там думает фаулер, эванс или буч. Мне важно что я плачу фактически за каждую строку кода и чем меньше программисты созают строк кода для решения задачи, чем больше я могу заработать.



J>В трехслойной/четырехслойной архитектуре с анемичными моделями, нам точно так уже пришлось бы мокать `IChangeContactInformationService`

J>и метод "GetContactInformation". Потому разницы в сложности поддержания/написания тестов — нет.
Этих методов просто не будет. Можно конечно каждое присваивание вынести в отдельный метод, чтобы его протестировать, но лучше мапперы использовать, а не труд программистов.

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

Ты серьезно считашь что 4 класса и 6 методов легче поддерживаются чем один класс и один метод?
У меня для тебя плохие новости.

J>Из дополнительных плюсов с DDD мы легко можем применить CQRS подход.

Лучше раскажи как ты в своем коде сделаешь такое:
dbContext.Users.Select(u => new UserInformationDto { Info = u.Info, Email = u.ContactInformationюEmail }).ToListAsync()

Это тебе понадобится 100%, а CQRS не понадобится совсем.
Re[12]: DDD протаскивание других слоев через параметры методов Domain
От: Буравчик Россия  
Дата: 13.01.21 10:19
Оценка: 5 (1) +1
Здравствуйте, gandjustas, Вы писали:

G>Вот как должен выглядеть такой код (в плохом случае):


Код ты не сильно и изменил. Уменьшил количество строк в data-классах — норм.

И объединил репозиторий с сервисом, прибив сервис к БД. Но в твоем сервисе содержится код для двух задача:
— код для обработки бизнес-логики
— код для обработки хранения данных

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

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

G>Лучше раскажи как ты в своем коде сделаешь такое:


Просто добавить этот код в репозиторий
Best regards, Буравчик
Re[13]: DDD протаскивание других слоев через параметры методов Domain
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 13.01.21 11:17
Оценка: +2
Здравствуйте, Буравчик, Вы писали:

Б>Здравствуйте, gandjustas, Вы писали:


G>>Вот как должен выглядеть такой код (в плохом случае):


Б>Код ты не сильно и изменил. Уменьшил количество строк в data-классах — норм.

Именно. Он делает то же самое и приерно в 3 раза короче, имеет меньше классов, меньше покозатель связности.

Б>И объединил репозиторий с сервисом, прибив сервис к БД. Но в твоем сервисе содержится код для двух задача:

Б>- код для обработки бизнес-логики
Б>- код для обработки хранения данных
О ужас, как с этим жить...

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

Когда требования изменятся, тогда и код изменится, независимо от того что было написано ранее. Причем чем меньше было написано, тем проще менять.


Б>Плюс, когда репозитория отделен, для него очень удобно писать интеграционный тест.

А когда не отделен, то этот тест вообще не нужен. Нуюен тст — делай тестовую inmemory базу, EF позволяет.

G>>Лучше раскажи как ты в своем коде сделаешь такое:


Б>Просто добавить этот код в репозиторий

А потом вызывать его из сервиса. Вот и кончился DDD с его Entity и Aggregate Root.
Re[12]: DDD протаскивание других слоев через параметры методов Domain
От: Sharov Россия  
Дата: 13.01.21 16:33
Оценка:
Здравствуйте, gandjustas, Вы писали:


G>Если у меня программист напишет такое больше одного раза, то он будет уволен, потому что тратит мои деньги.


Вы бы потрудились объяснить, что с кодом выше не так? Кроме статических методов Create
(должна быть по идее фабрика какая-нибудь), особых проблем не видно.


G>А в идеале еще и два класса данных объединить в один и испольовать modelbinding или мапперы, а не ручное присваивание DTO. И избавится от UserService, а код написать непосредственно в контроллере.

G>И мне все равно что там более или менее ООП, что там думает фаулер, эванс или буч. Мне важно что я плачу фактически за каждую строку кода и чем меньше программисты созают строк кода для решения задачи, чем больше я могу заработать.

Это конечно, оффтоп, но фраза крайне странная: если Вы не платите своей кровью (мало ли, заказчик за баг отмудохает),
то тогда да, меньше строчек, меньше багов. Но Вы платите за время, а не за строчки. Т.е., получается,
за удаление строк кода (рефакторинг, например), программист Вам еще и доплатит?

J>>Из дополнительных плюсов с DDD мы легко можем применить CQRS подход.

G>Лучше раскажи как ты в своем коде сделаешь такое:
G>
G>dbContext.Users.Select(u => new UserInformationDto { Info = u.Info, Email = u.ContactInformationюEmail }).ToListAsync()
G>

G>Это тебе понадобится 100%, а CQRS не понадобится совсем.

А в чем тут затык?
Кодом людям нужно помогать!
Re[14]: DDD протаскивание других слоев через параметры методов Domain
От: Sharov Россия  
Дата: 13.01.21 16:37
Оценка:
Здравствуйте, gandjustas, Вы писали:

Б>>Просто добавить этот код в репозиторий

G>А потом вызывать его из сервиса. Вот и кончился DDD с его Entity и Aggregate Root.

А в чем проблема, если код будет вызываться из доменного сервиса? Репозитории как раз для этого и нужны.
Кодом людям нужно помогать!
Re[13]: DDD протаскивание других слоев через параметры методов Domain
От: Sharov Россия  
Дата: 13.01.21 16:39
Оценка:
Здравствуйте, Буравчик, Вы писали:


Б>И объединил репозиторий с сервисом, прибив сервис к БД. Но в твоем сервисе содержится код для двух задача:

Б>- код для обработки бизнес-логики
Б>- код для обработки хранения данных

Читал мнения, что dbContext можно рассматривать как репозиторий. Т.е. отдельно создавать репо
иногда бывает излишне. Но это скорее для совсем крошечных приложений, для которых DDD и смысла-то не имеет.
Кодом людям нужно помогать!
Re[13]: DDD протаскивание других слоев через параметры методов Domain
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 14.01.21 08:24
Оценка:
Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:



G>>Если у меня программист напишет такое больше одного раза, то он будет уволен, потому что тратит мои деньги.


S>Вы бы потрудились объяснить, что с кодом выше не так? Кроме статических методов Create

S>(должна быть по идее фабрика какая-нибудь), особых проблем не видно.
Проблема в том, что кода сильно больше, чем необходимо для реения задачи. Это означает увеличенное количество ошибок и увеличенные затраты н поддержку.


G>>А в идеале еще и два класса данных объединить в один и испольовать modelbinding или мапперы, а не ручное присваивание DTO. И избавится от UserService, а код написать непосредственно в контроллере.

G>>И мне все равно что там более или менее ООП, что там думает фаулер, эванс или буч. Мне важно что я плачу фактически за каждую строку кода и чем меньше программисты созают строк кода для решения задачи, чем больше я могу заработать.

S>Это конечно, оффтоп, но фраза крайне странная: если Вы не платите своей кровью (мало ли, заказчик за баг отмудохает),

S>то тогда да, меньше строчек, меньше багов. Но Вы платите за время, а не за строчки. Т.е., получается,
S>за удаление строк кода (рефакторинг, например), программист Вам еще и доплатит?
Я плачу своими деньгами, это почти то же самое.
Если строчек сильно больше чем надо это значит программист уже потратил время (и деньги) на создание этого.

J>>>Из дополнительных плюсов с DDD мы легко можем применить CQRS подход.

G>>Лучше раскажи как ты в своем коде сделаешь такое:
G>>
G>>dbContext.Users.Select(u => new UserInformationDto { Info = u.Info, Email = u.ContactInformationюEmail }).ToListAsync()
G>>

G>>Это тебе понадобится 100%, а CQRS не понадобится совсем.

S>А в чем тут затык?

Затыка никакого нет. Только тако код обычно убивает весь DDD. Любая попытка прикрутить DDD-патерны к этому коду сделает его однозначно хуже.
Re[15]: DDD протаскивание других слоев через параметры методов Domain
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 14.01.21 08:25
Оценка:
Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:


Б>>>Просто добавить этот код в репозиторий

G>>А потом вызывать его из сервиса. Вот и кончился DDD с его Entity и Aggregate Root.

S>А в чем проблема, если код будет вызываться из доменного сервиса? Репозитории как раз для этого и нужны.

Для чего в этом примере нужен репозиторий?
Re[16]: DDD протаскивание других слоев через параметры методов Domain
От: Sharov Россия  
Дата: 14.01.21 15:36
Оценка: :)
Здравствуйте, gandjustas, Вы писали:

S>>А в чем проблема, если код будет вызываться из доменного сервиса? Репозитории как раз для этого и нужны.

G>Для чего в этом примере нужен репозиторий?

Четко обозначить ключевые сущности DDD. Так если подумать, для в примеров из всяких книжек по DDD
репозитории и много чего еще также излишне.
Кодом людям нужно помогать!
Re[14]: DDD протаскивание других слоев через параметры методов Domain
От: Sharov Россия  
Дата: 14.01.21 15:39
Оценка:
Здравствуйте, gandjustas, Вы писали:

S>>Вы бы потрудились объяснить, что с кодом выше не так? Кроме статических методов Create

S>>(должна быть по идее фабрика какая-нибудь), особых проблем не видно.
G>Проблема в том, что кода сильно больше, чем необходимо для реения задачи. Это означает увеличенное количество ошибок и увеличенные затраты н поддержку.

Это игрушечный пример, не более.

S>>Это конечно, оффтоп, но фраза крайне странная: если Вы не платите своей кровью (мало ли, заказчик за баг отмудохает),

S>>то тогда да, меньше строчек, меньше багов. Но Вы платите за время, а не за строчки. Т.е., получается,
S>>за удаление строк кода (рефакторинг, например), программист Вам еще и доплатит?
G>Я плачу своими деньгами, это почти то же самое.

Таки платите за время, а не за строчки.

G>Если строчек сильно больше чем надо это значит программист уже потратил время (и деньги) на создание этого.


При таком подходе имеет смысл работать только одному -- колоссальная экономия.
Кодом людям нужно помогать!
Re[15]: DDD протаскивание других слоев через параметры методов Domain
От: Sinclair Россия https://github.com/evilguest/
Дата: 19.01.21 06:15
Оценка:
Здравствуйте, Sharov, Вы писали:

S>Таки платите за время, а не за строчки.

То на то и выйдет. Строчки — не бесплатны, даже если их порождает Intellisense.
G>>Если строчек сильно больше чем надо это значит программист уже потратил время (и деньги) на создание этого.
S>При таком подходе имеет смысл работать только одному -- колоссальная экономия.
Нет, никакой экономии нету. Строчки всё равно кто-то должен написать. Можно написать миллион LOC в одно рыло, можно командой в 100 человек.
Во втором случае получится быстрее. Но при фиксированном размере команды написать 3 миллиона строк будет дольше, чем 1 миллион строк.
А ведь у нас же ещё за кадром стоит код тестов, которым нам угрожают фанаты DDD — то есть мало того, что мы пишем больше кода в приложении, мы ещё и вынуждены писать тесты для этого бойлерплейта.
Amplification factor увеличивается, и пока в Виллариба всё ещё отлаживают очередной бессмысленный код абстрактного слоя, Виллабаджо уже запустились в продакшн и расширяют пользовательскую базу.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: DDD протаскивание других слоев через параметры методов Domain
От: #John Европа https://github.com/ichensky
Дата: 20.01.21 22:36
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>А ведь у нас же ещё за кадром стоит код тестов, которым нам угрожают фанаты DDD — то есть мало того, что мы пишем больше кода в приложении, мы ещё и вынуждены писать тесты для этого бойлерплейта.


Тесты — это контракт, документация, которую написал разработчик и которую разработчику придется подправить, если он изменит логику кода.
Тесты помогаю не сломать то что уже написано в старом/новом проекте.
Интеграционные тесты помогают понять логику как работает проект.
Через интеграционный тесты можно продебажить/протестировать код, который просто так не вызвать, потому что проект зависит от других внешних сервисов, которые в тесте мокаются.
Все-таки дешевле что бы программист потратил на написание кода 2-3часа вместо 1го,
но потом не пришлось тратить время кучи менеджеров/qa,архитекторов/девопсов/ба и других на обсуждение, фикс, деплой очередной баги.
Код надо покрывать на столько % на сколько хочешь быть уверенным что код работает корректно.

Если работаешь над каким-то мелким проектом, который тебя попросили сделать на вчера,
где требования меняют каждый день и все горит или это RD проект и непонятно станет он частью продукта или будет выкинут после презентации.
Или на проекте 1-3ри человека и вы просто занимаетесь поддержкой проекта и вам особо плевать как вы пишите код ибо вас ни кто не контролирует.
Можно сделать исключение и тесты не писать.

Покрывать код тестами, большого продукта, у которого есть план развития, который интенсивно развивается, выгодно бизнесу.
Підтримати Україну у боротьбі з країною-терористом.

https://prytulafoundation.org/
https://u24.gov.ua/

Слава Збройним Силам України!!! Героям слава!!!
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.