Спасибо за лекцию! У меня одна просьба: пожалуйста, перед выкладыванием материла вырезайте с помощью аудио- редакторов шумы и эффект эха (например, бесплатный audacity). Слушать очень тяжело.
Спасибо за материал. Хотелось бы еще и практических занятий. Где бы брался какой-либо OpenSource с указанием хэша ревизии и потом доводился бы до ума. В процессе рефакторинга пояснялись бы действия. К примеру такого вида "Тут перед нами два варианта, в первом мы делаем .... во втором ... " и как из таких вот развилок выбираться, а то очень часто похоже на сказку: "направо пойдешь коня потеряешь, налево меч". ;) Вот сейчас у меня есть класс Instruction , суть которого хранить информацию об инструкции(офсет, опкод и др.) и есть метод isJump() который говорит "А это инструкция перехода?" и возникает другой вопрос "Правильно ли метод расположен? Он действительно должен находиться в Instruction классе?". С одной стороны метод работает с данными которые только в Instruction. Но с другой стороны мы часто видим классы которые хоть и работают с данными другого класса, но все-таки методы выделены в отдельный класс, пример String и StringUtils. И таких вот ситуаций и дилем много! Как их быстрее решать? )
***** А ну отставить "занижать себя". Вам удается доносить мысли, а это и есть главная задача того кто учит. Смысл от образований и корочек, если у человека не получается доносить мысль? Другими словами, попробуйте. Возьмите простейшее элементарнейшее приложение. Присмотритесь, Вы сразу же увидите запахи. Выпишите их, а потом расскажите. Мы, сообщество, уверяю быстро же закидаем Вас фидбэком ;) Могу поделиться своим проектом в качестве подопытного кролика ;)
***** Но Вы же программист! ;) Следовательно можете сделать видео на основе показываемого на экране с мыслями в слух! ;) Кто-то вот смотрит как люди в танчики режутся часами, а мы вот программисты будем смотреть увлекательное кино "рефакторинг говнокода". ;)
7:10 работа с наследованиями. Моё мнение лишь мнение новичка, который пишет на python простую IDE (типа android studio, но конечно не такую навороченную). Есть много вещей, которые надо реализовать. И архитектура такова, что многие поведения (скажем, группы методов) будут одни и те же в разных компонентах, и таких дубликатов будет много. И тут просто просится переиспользование. А как это сделать удобно без разрастания кода, без нескольких уровней наследования, пока не знаю.
Если в классах есть какая-то группа методов, то становится очевидно, что эти методы нужно вынести в отдельный класс. А потом делать вызов методов этого класса из нужных компонентов. Таким образом избавляемся от драя и повышаем зацепление. Из минусов разве что добавляем дополнительную связь.
Сергей, спасибо за уроки и лекции. Хотел спросить - в одном из видео про антипатиерны Вы (или Боб?) говорите, что DTO - зло, если используется без передачи через внешнюю среду (сеть). Но в видео про Clean Code Вы призываете использовать Value Objects (если аргументов метода больше трех). Но ведь VO и DTO практически родственники? Как правильно в итоге?
26:40 повна хрень.. так може міркувати лише людина, яка не має з чим порівнювати -- ну тиму в мене один варіант, і мені норм, і я знайду 100500 "аргументів" щоб уникнути іншого варіанту. Категорично варто мовчати про ті речі, в яких нема досвіду
если вам не интересен этот материал, то не смотрите, кто-то что-то может с этого и почерпнуть. Не все такие умные. А автору респект за запись, человек постарался и потратил время и силы.
офигенный курс, спасибо.
Спасибо за лекцию!
У меня одна просьба: пожалуйста, перед выкладыванием материла вырезайте с помощью аудио- редакторов шумы и эффект эха (например, бесплатный audacity). Слушать очень тяжело.
спасибо, круто, очень понравилось, продолжаю смотреть остальное )
Спасибо за материал. Хотелось бы еще и практических занятий. Где бы брался какой-либо OpenSource с указанием хэша ревизии и потом доводился бы до ума. В процессе рефакторинга пояснялись бы действия. К примеру такого вида "Тут перед нами два варианта, в первом мы делаем .... во втором ... " и как из таких вот развилок выбираться, а то очень часто похоже на сказку: "направо пойдешь коня потеряешь, налево меч". ;) Вот сейчас у меня есть класс Instruction , суть которого хранить информацию об инструкции(офсет, опкод и др.) и есть метод isJump() который говорит "А это инструкция перехода?" и возникает другой вопрос "Правильно ли метод расположен? Он действительно должен находиться в Instruction классе?". С одной стороны метод работает с данными которые только в Instruction. Но с другой стороны мы часто видим классы которые хоть и работают с данными другого класса, но все-таки методы выделены в отдельный класс, пример String и StringUtils. И таких вот ситуаций и дилем много! Как их быстрее решать? )
***** А ну отставить "занижать себя". Вам удается доносить мысли, а это и есть главная задача того кто учит. Смысл от образований и корочек, если у человека не получается доносить мысль?
Другими словами, попробуйте. Возьмите простейшее элементарнейшее приложение. Присмотритесь, Вы сразу же увидите запахи. Выпишите их, а потом расскажите. Мы, сообщество, уверяю быстро же закидаем Вас фидбэком ;) Могу поделиться своим проектом в качестве подопытного кролика ;)
***** Но Вы же программист! ;) Следовательно можете сделать видео на основе показываемого на экране с мыслями в слух! ;) Кто-то вот смотрит как люди в танчики режутся часами, а мы вот программисты будем смотреть увлекательное кино "рефакторинг говнокода". ;)
То, что люди за два месяца все забыли, подтверждает ваше высказывание об искаженной памяти программистов и о малом количестве долговременной памяти)))
7:10 работа с наследованиями.
Моё мнение лишь мнение новичка, который пишет на python простую IDE (типа android studio, но конечно не такую навороченную).
Есть много вещей, которые надо реализовать. И архитектура такова, что многие поведения (скажем, группы методов) будут одни и те же в разных компонентах, и таких дубликатов будет много.
И тут просто просится переиспользование.
А как это сделать удобно без разрастания кода, без нескольких уровней наследования, пока не знаю.
Если в классах есть какая-то группа методов, то становится очевидно, что эти методы нужно вынести в отдельный класс. А потом делать вызов методов этого класса из нужных компонентов. Таким образом избавляемся от драя и повышаем зацепление. Из минусов разве что добавляем дополнительную связь.
Сергей, спасибо за уроки и лекции. Хотел спросить - в одном из видео про антипатиерны Вы (или Боб?) говорите, что DTO - зло, если используется без передачи через внешнюю среду (сеть). Но в видео про Clean Code Вы призываете использовать Value Objects (если аргументов метода больше трех). Но ведь VO и DTO практически родственники? Как правильно в итоге?
Это разные вещи
Здесь Indirection == Dependency Injection ?
Dependency inversion
прочитал бы "Серебрянную пулю" не балаболил бы про то, что первая версия лучше второй ...
26:40 повна хрень.. так може міркувати лише людина, яка не має з чим порівнювати -- ну тиму в мене один варіант, і мені норм, і я знайду 100500 "аргументів" щоб уникнути іншого варіанту. Категорично варто мовчати про ті речі, в яких нема досвіду
автор этой лекции - совершенно бесполезный балабол
Почему?
если вам не интересен этот материал, то не смотрите, кто-то что-то может с этого и почерпнуть. Не все такие умные. А автору респект за запись, человек постарался и потратил время и силы.