Комментарии 43
НЛО прилетело и опубликовало эту надпись здесь
Почему же? Паттерны ведь нужны, чтобы на собеседовании про них говорить.
да, практика показывает, что о паттернах знают довольно толковые разработчики с хорошим опытом. На собеседованиях, кто не смог ответить про паттерны или вообще впервые слышал о них, тот как правило мало опыта имел в разработке, т.е. корреляция есть.
НЛО прилетело и опубликовало эту надпись здесь
Помнить названия шаблонов и их определения это одно, а понимать другое. Разница же видна и как понимает человек, что это и как это применять или просто заучил названия. Разве нет?
НЛО прилетело и опубликовало эту надпись здесь
Мы делаем ровно наоборот: если человек написал в резюме, что он знает и применяет паттерны, то на собеседовании его просят описать один-два известных ему паттерна, включая формальное определение, достоинства, недостатки, и, самое главное, где конкретно в его опыте этот паттерн применялся, и чем это применение было обосновано.
Да, это разные вещи. Я, пока читал GoF, всё или почти всё понимал по сути, а вот потом из памяти выудить названия и связь с идеями реализации… с зазубриванием определений всегда плохо было. Впрочем, знания и освежить можно легко, имея книжку под рукой.
Если спрашивать по названиям паттернов, то разумеется, их я тоже не помню на память. Но если попросить что-то сделать, то я покажу умение владеть ими, даже если запамятовал названия.
Не совсем согласен. Зная паттерны, можно лучше разобраться в работе фреймворка и практика воспитания бойцов фронтовиков в своей команде говорит об этом же.
Это все бывает полезно, когда нужно быстро объяснить как приложение спроектировано, при условии, что собеседник о этих паттернах имеет какое-то представление. Каждый раз рисовать схему и рассказывать почему именно так — бывает утомительно. А в целом — конечно да: паттерны становятся нужны только в тот момент, когда ты сам до них дошел и потом просто узнал как это называется.
НЛО прилетело и опубликовало эту надпись здесь
Мы о разном: я — о коммуникациях, вы — о непосредственной реализации. В части реализации — я полностью согласен, но базовые представления о паттернах просто полезны в общении. Если углубляться — да, начинается путанница и все эти религиозные споры становятся пустой тратой времени.
и ты только что пересказал мой второй абзац в тексте, только другими словами. Паттерны дают лишь общее понятие для типовых решений, никто не утверждает, что паттерн является конечным решением и надо организовывать код именно так. В любом учебнике по паттернам это и говорится сразу же.
Паттерны это из области архитектуры, а не программирования. Они больше полезны при проектировании приложения, чем его реализации. Качество проектирования играет меньшую роль на этапе разработки, но становится ключевым на этапе поддержки и развития.
Условно, в мире вещей есть такой конструкторский прием — контрагайка, который при вибрациях повышает надежность, не давая соединению развинчиваться. Технически, это когда на один болт накручивается вместо одной гайки — две. Причем, это могут быть абсолютно одинаковые гайки. Т.е. с точки зрения слесаря, задача которого изготовить гайки, между гайками нет ни какой разницы. Разница заметна только на уровне инженера. Слесари могут искренне «не понимать», зачем нужны все эти конструкторские приемы, когда в результате от них требуется одно и то же.
Так вот, отношение к разработчика паттернам на собеседовании показывает в какой роли он себя представляет «слесаря-кодера» или «инженера-архитектора», и соответственно определяет типы задач, решение которых ему можно будет доверить.
Условно, в мире вещей есть такой конструкторский прием — контрагайка, который при вибрациях повышает надежность, не давая соединению развинчиваться. Технически, это когда на один болт накручивается вместо одной гайки — две. Причем, это могут быть абсолютно одинаковые гайки. Т.е. с точки зрения слесаря, задача которого изготовить гайки, между гайками нет ни какой разницы. Разница заметна только на уровне инженера. Слесари могут искренне «не понимать», зачем нужны все эти конструкторские приемы, когда в результате от них требуется одно и то же.
Так вот, отношение к разработчика паттернам на собеседовании показывает в какой роли он себя представляет «слесаря-кодера» или «инженера-архитектора», и соответственно определяет типы задач, решение которых ему можно будет доверить.
НЛО прилетело и опубликовало эту надпись здесь
Читайте внимательнее, и не только свои комментарии.
Думаю, что все зависит от уровня владения предметом и навыков — результат определяется как уровнем теоретической подготовки, так и практическим опытом. Мне сложно судить про абстрактных студентов, у нас работает несколько старшекурсников, отличные ребята, у которых за плечами уже с десяток проектов.
Расскажите, приходится-ли вам на работе сталкиваться с однотипными проблемами и используете-ли вы в таких случаях какие-то типовые решения? Как вы делитесь ими с коллегами?
Кстати вчерашний студент, который бьет себя в грудь и кричит что он любит паттерны, правильные архитектуры, и вообще он за все хорошее и против всего плохого, вот он имеет правильное отношение для «инженера-архитектора»?
Думаю, что все зависит от уровня владения предметом и навыков — результат определяется как уровнем теоретической подготовки, так и практическим опытом. Мне сложно судить про абстрактных студентов, у нас работает несколько старшекурсников, отличные ребята, у которых за плечами уже с десяток проектов.
Расскажите, приходится-ли вам на работе сталкиваться с однотипными проблемами и используете-ли вы в таких случаях какие-то типовые решения? Как вы делитесь ими с коллегами?
Есть люди, которые умудряются читать нужные книжки вовремя ;)
Назначение паттернов по сути одно — дать единое название типичному способу решения типичной задачи. Описание паттерна, это не императив «это задачу нужно решать так», это декларация «это решение этой задачи называется <pattern_name>». Всё. Фраза «что мне это уже не надо» говорит о том, что вам уже не надо кратко объяснять кому-то (в том числе путем именования артефактов кода) как работает ваш код. Или читай мануал юзера, или читай код досконально.
Также стоит почитать эту статью, где рассказывается почему event-based programming — это тупиковый путь развития :-) http://habrahabr.ru/post/235121/
Угу, вы считаете, что Rx — тупиковый путь развития?
Именно так.
Ууу… пожалуй нет, спасибо.
Боюсь мне нечего ответить на столь убедительный аргумент с вашей стороны :-)
Да я, собственно, и имею в виду, что обсуждать тут нечего.
И правда, ведь все знают, что Rx — это манна небесная и нечего тут еретику что-то объяснять :-)
Да нет, просто обсуждение Rx в этой статье достаточно бессмысленно. Кому надо — и так прочитает.
Ну, я вот почитал, и как-то не уверовал, что императивная реактивность спасёт мир.
Как-то не вижу я преимуществ у такого кода:
var message = config.flatMapLatest( function( config ) {
if( config ) {
return mouseCoords.map( function( coords ) {
return 'Mouse coords is ' + coords
}
} else {
return mouseTarget.map( function( target ) {
return 'Mouse target is ' + target
}
}
} )
Перед таким:
var message = $jin.atom.prop( {
pull: function( ) {
if( config.get() ) {
return 'Mouse coords is ' + coords.get()
} else {
return 'Mouse target is ' + target.get()
}
}
} )
Как-то не вижу я преимуществ у такого кода:
var message = config.flatMapLatest( function( config ) {
if( config ) {
return mouseCoords.map( function( coords ) {
return 'Mouse coords is ' + coords
}
} else {
return mouseTarget.map( function( target ) {
return 'Mouse target is ' + target
}
}
} )
Перед таким:
var message = $jin.atom.prop( {
pull: function( ) {
if( config.get() ) {
return 'Mouse coords is ' + coords.get()
} else {
return 'Mouse target is ' + target.get()
}
}
} )
Ну не видите — и ладно, значит, вам Rx не поможет.
(хотя, конечно, приведенный вами код к Rx отношение имеет весьма условное)
(хотя, конечно, приведенный вами код к Rx отношение имеет весьма условное)
А может всё-таки откроете мне глаза, какую такую великую идею я тут не замечаю? :-)
Первый код на RxJS.
Первый код на RxJS.
А может всё-таки откроете мне глаза, какую такую великую идею я тут не замечаю?
А смысл? Я не знаю, ваших задач, а применимость сильно зависит от задачи.
Первый код на RxJS.
То, что код на чем-то написан, еще не означает, что это идиоматичный код.
Опишите задачу, где Rx покажет себя лучше :-)
Вам же не сложно будет переписать этот код в более идиоматичном виде?
Вам же не сложно будет переписать этот код в более идиоматичном виде?
Опишите задачу, где Rx покажет себя лучше
Лучше, чем что? Вот вам задача, где Rx показывает себя вполне неплохо.
Вам же не сложно будет переписать этот код в более идиоматичном виде?
А какую задачу он решает?
Лучше, чем атомы. Замечательно, как временно поставить распознавание морзе на паузу так чтобы стримы не работали вхолостую на каждое нажатие клавиши?
Переключает источники данных в зависимости от настроек.
Переключает источники данных в зависимости от настроек.
Лучше, чем атомы.
Я не знаю, как работают атомы, поэтому не могу сравнивать.
Замечательно, как временно поставить распознавание морзе на паузу так чтобы стримы не работали вхолостую на каждое нажатие клавиши?
Вставить IConnectableObservable (не знаю эквивалент для JS), подписки диспозить. Но сам не проверял, честно.
Переключает источники данных в зависимости от настроек.
Я, если честно, не вижу смысла в этом случае делать настройку первым стримом. Намного проще на изменение настройки просто менять стрим, выводящий данные. Впрочем, я не уверен, что это более идиоматично.
Будем честными, основной ужас вашего кода (обоих из них) вызван тем, что в JS кривые анонимные функции, а не фреймворком.
var message = config
.SelectMany(config => config
? mouseCoords.Select(coords => "Mouse coords is " + coords)
: mouseTarget.Select(target => "Mouse target is " + target)
.Switch();
Значит у вас есть уникальная возможность узнать что-то новое ;-)
Диспозить конечно же ручками, да? :-) Там в статье про это всё есть и в продолжении конкретно про Rx — http://habrahabr.ru/post/240773/
Ну да, вставить нереактивный костыль проще, чем делать идеоматично на Rx, только потом от таких костылей огребаешь потерей консистентности.
Основной ужас в том, что вместо использования операторов языка используется библиотека, которая повторяет все те же операторы, но в виде методов. При этом использование множества источников для одного состояния — неудобно и требует лишние ресурсы, а динамическое изменение зависимостей требует кучи костылей. Я уж не говорю про ленивые вычисления.
Диспозить конечно же ручками, да? :-) Там в статье про это всё есть и в продолжении конкретно про Rx — http://habrahabr.ru/post/240773/
Ну да, вставить нереактивный костыль проще, чем делать идеоматично на Rx, только потом от таких костылей огребаешь потерей консистентности.
Основной ужас в том, что вместо использования операторов языка используется библиотека, которая повторяет все те же операторы, но в виде методов. При этом использование множества источников для одного состояния — неудобно и требует лишние ресурсы, а динамическое изменение зависимостей требует кучи костылей. Я уж не говорю про ленивые вычисления.
Значит у вас есть уникальная возможность узнать что-то новое
Спасибо, не вижу ничего уникального в этой возможности.
Диспозить конечно же ручками, да?
Как паузить, так и диспозить.
Основной ужас в том, что вместо использования операторов языка используется библиотека, которая повторяет все те же операторы, но в виде методов.
Не те же. Покажите мне «оператор», эквивалентный flatMap.
При этом использование множества источников для одного состояния — неудобно и требует лишние ресурсы, а динамическое изменение зависимостей требует кучи костылей. Я уж не говорю про ленивые вычисления.
У меня создается ощущение, что вы просто пытаетесь применить Rx для задач, где ему плохо.
Попробуйте снять очки суперзвезды :-)
Эти действия относятся к разным уровням приложения. В общем случае, без дополнительных костылей, вы не знаете можно ли диспозить стрим, так как от него кто-то может зависеть.
Ну да, и добавляет свои «операторы», которые без этой библиотеки и не нужны бы были :-)
То есть вы подтверждаете, что Rx не подходит для разработки больших и динамичных веб приложений? :-)
Эти действия относятся к разным уровням приложения. В общем случае, без дополнительных костылей, вы не знаете можно ли диспозить стрим, так как от него кто-то может зависеть.
Ну да, и добавляет свои «операторы», которые без этой библиотеки и не нужны бы были :-)
То есть вы подтверждаете, что Rx не подходит для разработки больших и динамичных веб приложений? :-)
В общем случае, без дополнительных костылей, вы не знаете можно ли диспозить стрим, так как от него кто-то может зависеть.
Так не надо диспозить стрим, надо диспозить свою подписку (от которой точно никто не зависит).
Ну да, и добавляет свои «операторы», которые без этой библиотеки и не нужны бы были
FlatMap — это всего лишь слияние двух последовательностей (если мы говорим об Enumerable или Observable).
То есть вы подтверждаете, что Rx не подходит для разработки больших и динамичных веб приложений?
Нет, не подтверждаю.
Замечательно написанная статья. Спасибо. Полезно иметь под рукой названия постоянно используемых паттернов.
На основе pub-sub строится работа паттерна Mediator
Не согласен. Mediator может быть реализован как угодно.
Более того, скорее pub-sub — это реализация mediator, но не наоборот.
Более того, скорее это даже два разных подхода. Идея паттерна mediator в контроле коммуникаций внутри себя. Т.е. реализация отвечает как за подписку, так и за публикацию. А вот в случае с pub-sub мы как раз уходим от централизованного управления. Мне нравится понимать это, как работу с msmq. Из общего между pub-sub и mediator — тип решаемой задачи и отсутсвие прямых ссылок.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Observer vs Pub-Sub