Вы просто упускаете один интересный момент: тест это своего рода спецификация, как ваш код будет выглядеть и как работать.
Перед его написанием тоже нужно продумать архитектуру (в рамках тестируемого функционала) и просто свои мысли выразить в тесте, а не в голове. Хотите, чтобы был класс А — не сразу создаёте класс А, а сначала пишете тест: var a = new A(); Тест упал (даже не скомпилировался) -> создали класс. Затем думаете, а зачем этот класс? Да, чтобы складывать два числа. А как? Методом add(int a, int b) -> написали тест: var a = new A(); a.add(1, 2); Опять не скомпилилось -> реализовали метод. И понеслась.
Т.е. моя мысль сводится к тому, что тесты, которые так тяжело по-началу начать писать, это в действительности ваши мысли об архитектуре создаваемого ПО, ваши предположения и рассуждения, но зафиксированные в коде. После осознания этого становится проще жить :)
Пишу прописью как по-русски, так и по-английски. И выглядит более красиво, и писать — проще и быстрей!
А в печатных буквах не знаю как разделять «Ч» и 4 :)
Проходит время, и нам требуется добавить дополнительную логику в программу — например, находить у ордера товар с самой высокой ценой. Здесь уже могут возникнуть проблемы, если ваша orm не поддерживает внешние связи (т.е. сущностные классы ничего не знаю о контексте данных), в этом случае, придется создавать сервис, в котором будет метод — по ордеру вернуть нужный продукт. Но, наша orm хорошая, умеет работать с внешними связями, и мы просто добавляем метод в класс ордера. Снова радуемся жизни, цель достигнута, в класс добавлен метод, у нас почти настоящее ООП.
Это и на два абзаца ниже.
Во-первых, что значит «внешние связи»? Как это связано с поиском товара?
Во-вторых, это не DDD. В методологии явно указано, как нужно поступать в таких случаях. И это совсем не «добавляем метод». Так что одинаковых методов в итоге бы не было, и рефакторинга бы не было, и анемичной модели бы не было.
Если верить документации, после перезагрузки данные на диске будут устаревшие, но на SSD же все обновлённые блоки должны сохраниться и в целом потерь быть не должно. Разве нет?
Но вообще, стораджей на самом деле у нас два и виртуальные диски собраны в RAID1 на бездисковых нодах. В нашем случае этого достаточно
Спасибо, приятно видеть подобные комментарии :) Сколько же нервных клеток умерло в процессе расследования и сколько их восстановилось обратно после окончания!
Ну вот вы обоснованно ругаете декоратор за «нужно создать комментарий где-то ещё». А что, если где-то ещё мне, создавая комментарий, не нужно посылать сообщение по электропочте? А тут этот Observer, о котором я, кстати, будучи новичком в проекте, ещё и не знаю. Связь то неявная.
Перед его написанием тоже нужно продумать архитектуру (в рамках тестируемого функционала) и просто свои мысли выразить в тесте, а не в голове. Хотите, чтобы был класс А — не сразу создаёте класс А, а сначала пишете тест: var a = new A(); Тест упал (даже не скомпилировался) -> создали класс. Затем думаете, а зачем этот класс? Да, чтобы складывать два числа. А как? Методом add(int a, int b) -> написали тест: var a = new A(); a.add(1, 2); Опять не скомпилилось -> реализовали метод. И понеслась.
Т.е. моя мысль сводится к тому, что тесты, которые так тяжело по-началу начать писать, это в действительности ваши мысли об архитектуре создаваемого ПО, ваши предположения и рассуждения, но зафиксированные в коде. После осознания этого становится проще жить :)
Простите, но это рукалицо.жпг
А в печатных буквах не знаю как разделять «Ч» и 4 :)
Это и на два абзаца ниже.
Во-первых, что значит «внешние связи»? Как это связано с поиском товара?
Во-вторых, это не DDD. В методологии явно указано, как нужно поступать в таких случаях. И это совсем не «добавляем метод». Так что одинаковых методов в итоге бы не было, и рефакторинга бы не было, и анемичной модели бы не было.
Но вообще, стораджей на самом деле у нас два и виртуальные диски собраны в RAID1 на бездисковых нодах. В нашем случае этого достаточно
И плюс возлагаем большие надежды на его request merging. Оно даже иногда работает :-)