про Actor Model обязательно почитай

схоронил

про Actor Model обязательно почитай

вставать через 3 часа, доброй ночи, спасибо, вопросов потом будет не меньше

я схоронил как-то сообщение @fes0r про порядок изучения: 1. Инкапсуляция 2. Закон Деметры 3. Полиморфизм 4. LSP 5. OCP 6. ISP 7. DIP 8. Coupling/cohesion 9. GRASP 10. GoF 11. P of EEE

Что за `P of EEE`?

Что за `P of EEE`?

еще неделю назад обсуждали, там еще вроде сошлись на P of AEE кажется так

https://www.martinfowler.com/books/eaa.html

https://www.martinfowler.com/books/eaa.html

угу, eaa

ok

а следует начинать с поведения. Что будет делать объект. А проперти - потом разберемся что там надо

начинать нужно с тестов!

TDD = Telegramm Driven Development

начинать нужно с тестов!

при помощи тестов ты описываешь поведение. То есть это еде один способ заставить себя правильно подходить к декомпозиции. Ну мол тестами ты проектируешь интерфейсы объектов.

я схоронил как-то сообщение @fes0r про порядок изучения: 1. Инкапсуляция 2. Закон Деметры 3. Полиморфизм 4. LSP 5. OCP 6. ISP 7. DIP 8. Coupling/cohesion 9. GRASP 10. GoF 11. P of EEE

еще бы ссылки на это все

при помощи тестов ты описываешь поведение. То есть это еде один способ заставить себя правильно подходить к декомпозиции. Ну мол тестами ты проектируешь интерфейсы объектов.

а заодно халявные тесты)

а заодно халявные тесты)

ну как халявные) ты за них своим временем чутка заплатил)

я заплатил за проектирование

а тесты остались за так

ну если тебе так приятнее думать)

ну так, а зачем тогда писать тесты до?)

тесты до, пишутся, чтобы блджад можно было написать код, который ты не знаешь как писать

что за код, который ты не знаешь как написать?

он видимо про поведение.

т.е. мы говорим про алгоритмическую проблему

или про архитектурную?

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

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

у дяди Боба есть видос с факторизацией числа и сортировкой

дай определение "архитектурной" проблемы

дай определение "архитектурной" проблемы

ты не знаешь, где должен жить код, решающий задачу

дай определение "архитектурной" проблемы

это когда у тебя регрессии например из-за высокой связанности

ты не знаешь, где должен жить код, решающий задачу

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

у дяди Боба есть видос с факторизацией числа и сортировкой

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

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

для меня пока что именно эту и решают

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

неделю назад я писал калькулятор распределений отчислений пользователям.

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

и там у меня 2-3 тест кейса и 100 итераций на рандомных данных что бы проверить что суммы сходятся.

когда начинали пилить - понятия не имели что в итоге получится

но поведение требуемое было известно. а все остальное не столь важно на самом деле

ну как... про архитектуру отдельно пришлось подумать

тип когда должен происходить пересчет (этого юнит тесты за меня не сделают)

неделю назад я писал калькулятор распределений отчислений пользователям.

эти сценарии не геркином покрываете?

эти сценарии не геркином покрываете?

зачем, есть калькулятор, хороший такой юнит тест выходит

геркин это прикольно но у нас пока кроме разработчиков его никто не хочет ни писать ни читать.

вот только недавно нашел пару БА которые хотят попробовать

зачем, есть калькулятор, хороший такой юнит тест выходит

ну юнит тест перпендикулярен геркину или спеке

но еще не стартовало новых проектов.

кмк

ну юнит тест перпендикулярен геркину или спеке

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

геркин это прикольно но у нас пока кроме разработчиков его никто не хочет ни писать ни читать.

огурец ИМХО только в огромных фирмах

check24

огурец ИМХО только в огромных фирмах

вот нет) скорее в командах хоть больших хоть малых которым это нужно

документацию по проекту писать то кто-то должен)

"как что работает" с точки зрения логики

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

сложно с ним потому что)

сложно с ним потому что)

а что сложного?)

ага, в которых другие программисты - уровня "сколько отступов нужно делать на новой строке" и что лучше, "var_dump" или "print_r"

ага, в которых другие программисты - уровня "сколько отступов нужно делать на новой строке" и что лучше, "var_dump" или "print_r"

мы размеры или уровень обсуждаем?)

"главное не размер, а уровень владения"

а что сложного?)

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

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

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

огурцы - критерии приемки

я отказываюсь называть их тестами)

я вообще отказываюсь называть что-то тестами)

ERROR: S client not available

т.е. тесты не пишу)

потому что они занимаются верификацией а не тестированием?)

спеки пишу

сценарии)

)

сценарист)

потому что они занимаются верификацией а не тестированием?)

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

пришлось придумывать новые слова bddшникам

проблемы человеческих языков(

)

сценарист)

да, даже звучит хорошо

а еще IoC это принцип голливуда и совсем тогда ?

а еще IoC это принцип голливуда и совсем тогда ?

малаца

а еще IoC это принцип голливуда и совсем тогда ?

Don't call us, we call you?

ага

DRY! DRY! SRP!

DRY! DRY!

TRY to DRY

SRP in MVP

иногда лучше оставить дублирование нежели пытаться его устранить. У меня было много примеров когда люди тратили время и DRYили код а потом оказалось что то что казалось одинаковым стало разным функционалом)

SRP in MVP

аббривиатуры штука веселая согласен

http://verraes.net/2014/08/dry-is-about-knowledge/

TL;DR; -?

DRY is about Knowledge Code duplication is not the issue.

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

DRY is about Knowledge Code duplication is not the issue.

ну а своими словами

ну а своими словами

не пытайся выделить несколько повторений в новую общую для них абстракцию, возможно(скорее всего) они не имеют и не должны иметь общей абстракции. Выноси несколько повторений, если ты узнал, что за ними должна стоять общая абстракция

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

часто: отсутствие абстракций дешевле, чем неправильная абстракция