Ты пытаешься найти устраивающее твои взгляды определение

скорее ты.

Я рассказываю про успешный кейс, можешь категоризовать его как тебе будет удобнее

Мне если честно по барабану, теряю интерес к спору о смысле терминов

ну то есть давай вот так: то о чем ты говоришь - это то что я поддерживаю на 100% за исключением терминологии. Для меня это не "переписать с нуля" а именно то, за что топит уди.

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

ну то есть давай вот так: то о чем ты говоришь - это то что я поддерживаю на 100% за исключением терминологии. Для меня это не "переписать с нуля" а именно то, за что топит уди.

Окей, пусть будет так

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

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

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

а все было бы намного проще если бы ты просто посмотрел эти жалкие 10 минут того где Уди про это рассказывает

(7 минут если на 1.5x)

так же не раз собеседовал людей с веселыми историями "решили переписать продукт а через 3 месяца почти всю команду утащили срочно фиксить старый продукт" в итоге балтались 2 версии обе херовые

до боли знакомая ситуация( года 3 назад решили переписать бекенд с большой кодобазой "с нуля". Через пол года имели старый бекенд на корором джуны писали фичи и забивали на качество кода, и так перепишеться. И новый бекенд который покрывал 20% старого и оставал по коду гдето на месяц. приходилось делать фичи по 2 раза. Как итог у нас было 2 инфраструктуры под все это безобразие, 2 различные бд, репозитории и тд, всюду дубляжи под новую и старую версию. В результате через 7 месяцев заказчику надоело и написание с нуля свернули. Пришлось проводить рефакторинг на пару месяцев что бы хоть как то можно было поддерживать код. кстати, каких либо тестов не было для старого кода.

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

за год переписали почти 70% кода, которые теперь покрыты тестами

а все было бы намного проще если бы ты просто посмотрел эти жалкие 10 минут того где Уди про это рассказывает

Да, я просто видео не смотрю — с текстом работать проще и быстрее, видео без расшифровки от автора — это косяк с его стороны, тут ты прав что не надо делать tl tr)

Стоит ещё отметить, что у Уди не самые захватывающие выступления. Смотрел пару его толков, чуть не уснул, но это конечно больше обо мне говорит, чем о нем))

ну rules engine мне зашло, в общем и целом тут как-то чей-то видос проскакивал, который норм смотреть на 2х было, но не помню, чей

Стоит ещё отметить, что у Уди не самые захватывающие выступления. Смотрел пару его толков, чуть не уснул, но это конечно больше обо мне говорит, чем о нем))

я уди всегда смотрю минимум на 1.5x

Эванса на 2x обычно

ибо совсем засыпаю

Господа, а это правда что в среднем клиент-серверном приложение "ООП нужно только что бы DI использовать"? Ибо ооп-шники не могут разделить логику и эффекты, без добавления интерфейсов ? (с одной реализацией для менеджер'Impl)

ну всё...сейчас начнется

ООП для DI не обязателен вообще

кстати в своей паослледней книги Мартин выделяет инверсию зависимостей как лючевую особенность ООП

ну и перед этим три галыв о том что полифморфизм инкапсуляция и наследоание возможны без ооп в принципе

ООП для DI не обязателен вообще

Те в простых информационных системах, ООП вообще лишний

ну и перед этим три галыв о том что полифморфизм инкапсуляция и наследоание возможны без ооп в принципе

Доклад у него есть, где он это все говорит

ну и перед этим три галыв о том что полифморфизм инкапсуляция и наследоание возможны без ооп в принципе

резюмируя, что такое ооп по прежнему решительно не ясно ?

Доклад у него есть, где он это все говорит

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

Те в простых информационных системах, ООП вообще лишний

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

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

Нет, имеет ввиду клиент-серверное приложение (и бекенд и фронт) со сложной бизнес логикой

так ты говоришь "простая информационная система" а потмо "сложная бизнесс логика"

Ну так простая не в смысле логики ?‍♀, а в смысле что берём из базы, обработываем, показываем юзеру.

можешь расшарить линк на книгу? :)

Господа, а это правда что в среднем клиент-серверном приложение "ООП нужно только что бы DI использовать"? Ибо ооп-шники не могут разделить логику и эффекты, без добавления интерфейсов ? (с одной реализацией для менеджер'Impl)

ты не забывай на каких языках они пишут

сек

https://www.youtube.com/watch?v=4hvIwRHylj0

вот может тебе будет интересно

там как раз на ту тему о которой ты говоришь и почему фримонады в c# не взлетают

а переучить всех джавистов и прочих шарпистов писать на хаскеле/ocaml/f# че-то как-то сложно

а переучить всех джавистов и прочих шарпистов писать на хаскеле/ocaml/f# че-то как-то сложно

Пфф, дайте денег и вакансий и будет на изичах.

https://www.youtube.com/watch?v=4hvIwRHylj0

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

Вечер в хату, часик в радость, AbstractSingletonProxyFactoryBean в сладость.

Те в простых информационных системах, ООП вообще лишний

У меня такое ощущение, что если бы API аутофака в C# было было тьюринг-полным, на нем бы писали бизнес-логику.

Вечер в хату, часик в радость, AbstractSingletonProxyFactoryBean в сладость.

Наркоман? Наркоман.

Наркоман? Наркоман.

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

ООП нельзя любить, можно понять и простить. Ладно, понять тоже нельзя т.к. все хз что это за зверь такой "настоящее ооп".

ООП нельзя любить, можно понять и простить. Ладно, понять тоже нельзя т.к. все хз что это за зверь такой "настоящее ооп".

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

Ну Серег, так можно наскоку и DDD объяснить. Жирные модели, репозитории и агрегаты. А то что там Еванс придумал - все уже болт положили

Ну Серег, так можно наскоку и DDD объяснить. Жирные модели, репозитории и агрегаты. А то что там Еванс придумал - все уже болт положили

ну так и есть же

Что такое изоляция состояния и динамическая диспетчеризация. Что такое классы я тоже не обо понимаю, но давай начнем с этих двух?

"О сколько нам открытий чудных" (с) кто-то

Я вот в школе помню признаки параллелепипеда и свойства параллелепипеда. Можно так же просто признаки изоляции состояния и свойства.

"О сколько нам открытий чудных" (с) кто-то

Пушкин же)

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

(можно отрицание этого факта тоже определить)

Про "как вы это понимаете" (что любят на собеседованиях спрашивать) не надо плиз.

"зачем нам это надо." чтобы управлять сложностью...

ERROR: S client not available

"управлять сложностью" - отлично просто

"абстракция данных" - это тоже непроверяемая херня

не я придумал

Дядя Мартин?

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

Вот мы от простой попытки что-то понять ушли опять в философию.

это не философия

Если не философия - давай какие-то проверяемые параметры определим.

В видео Егора обычно "I believe it should be ..."

нету их, сугубо эмпирика

эпирически - это значит от практики

То есть были какие-то показатели, сделали что-то, стали другие показатели

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

(двигал формочки на сишарпе 8 лет ITT)

То есть были какие-то показатели, сделали что-то, стали другие показатели

я не видел пока метрик способных однозначно и объективно описать качество кода

Не понимаю совершенно как ООП помогает двигать формочки.

я не видел пока метрик способных однозначно и объективно описать качество кода

сколько долларов стоит сделать эту фичу - отличная метрика

как показывает практика "сделать" понятие относительное

все правильно

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

И мы скатились куда-то вместо того, чтобы их обсудить.

блин ну это не философия

Шизофрения?

ты хочешь цифр и метрик? их нет

Craftmanship!

сколько долларов стоит сделать эту фичу - отличная метрика

не только сделать, но и поддерживать

не только сделать, но и поддерживать

и расширять

И ООП тут спешит на помощь и экономит деньги?

а это невозможно оценить, потому что невозможно знать какие будут требования в будущем