Здравствуйте, CreatorCray, Вы писали:
CC>Вне зависимости от, тут он таки прав: надо подбирать в команду людей, с которыми таки сработаешься. Потому как делать в команде лебедьракощуку — себе дороже.
Видел задорные менеджерские заметки, что чем разношерстней команда, тем лучше.
Что ошибка менеджера искать точно такого же как он. Не будет разных мнений. Что плохо.
Здравствуйте, Miroff, Вы писали:
KP>>А что такое IoC? Это интерфейс скормить, вместо реализации?
M>Интерфейс вместо реализации это примерно 1% всего дела. Гораздо интереснее когда и как создается, собственно, реализация. В случае Java Spring, он читает аннотации на полях классов и пытается угадать, какой конкретно экземпляр и какой имплементации интерфейса будет уместен для каждого поля. А потом создает и инициализирует эти зависимости. С учетом того что зависимости мало того что образуют граф, так еще и в этом графе могут быть циклы. Сдизайнить такое на пальцах, ну такое себе развлечение.
На самом деле ничего сложного, если не переизобретать спринг.
var myClass1 = new MyClass1();
var myClass2 = new MyClass2();
myClass1.setMyClass1(myClass1);
myClass1.setMyClass2(myClass2);
myClass2.setMyClass1(myClass1);
myClass1.afterPropertiesSet();
myClass2.afterPropertiesSet();
Такой паттерн позволяет делать DI с произвольным графом зависимостей. afterPropertiesSet должен проверить все требуемые свойства. Паттерн абсолютно "тупой", можно руками делать, выключив мозг, можно через рефлекцию или кодогенерацию.
Здравствуйте, kaa.python, Вы писали:
KP>Звучит так себе. Я вообще крайне против неявной конфигурации чего бы то ни было. Если лимитировать IoC только в рамках замены подобного кода (утащил отсюда)
Спринг начинал с явной конфигурации в XML файлах. Получалось плохо, эти XML файлы становились еще той головной болью из-за того что корректность конфигурации толком не проверяется во время компиляции. Сейчас IDE умеют отлавливать простейшие ошибки, но только в самых примитивных случаях.
KP>то идея более чем здравая и активно используется и в C++, и в Go. Но вот делать неявную инициализацию конфигурации уже ведет к проблемам. Так же сам факт наличия неявной конфигурации говорит о том, что подобным подходом злоупотребляют на столько, что разрешить зависимости явно становится не возможным, иначе зачем она нужна?
Если ты делаешь явную инициализацию в коде ты просто смещаешь проблемы на уровень выше. Кто создаст экземпляр IocSpellChecker? Вызывающий код? Непосредственно main()? Какой-то глобальный registry/factory? В любом случае где-то в коде у тебя заведется куча бойлерплейта по инициализации сервисов. И тебе придется в этом месте руками тасовать вызовы чтобы обеспечить правильный порядок инициализации. А потом тебе придется протаскивать эти сервисы везде, где они требуются:
class ServiceRegistry {
ServiceRegistry() {
initializeApplicationPropertiesService()
if (applicationProperties.get("spellcheker.enabled")) {
initializeRealSpellChecker()
} else {
initializeDummySpellChecker()
}
}
}
class MainWindow {
MainWindow(ServiceRegistry registry) {
new TextField(registry.acquireSpellChecker())
}
}
Особенно весело становится, когда тебе требуется конфигурируемое в рантайме приложение. Скажем, спеллчекер может быть как встроенный, так и внешний интернет сервис, или эта фича может быть вообще отключена и менять это нужно без перезапуска приложения. Причем если внешний сервис оказывается недоступен, то должен срабатывать автоматический откат до dummy implementation.
Не то чтобы это все нельзя было сделать врукопашную явным способом, но в какой-то момент возня с инициализацией начинает занимать большую часть времени разработчика. Чтобы этот момент немного отсрочить и придумали спринг.
Здравствуйте, Miroff, Вы писали:
M>Если ты делаешь явную инициализацию в коде ты просто смещаешь проблемы на уровень выше. Кто создаст экземпляр IocSpellChecker? Вызывающий код? Непосредственно main()? Какой-то глобальный registry/factory?
Да, вызывающий код создаст. Да, непосредственно в main() создаст.
M>В любом случае где-то в коде у тебя заведется куча бойлерплейта по инициализации сервисов. И тебе придется в этом месте руками тасовать вызовы чтобы обеспечить правильный порядок инициализации. А потом тебе придется протаскивать эти сервисы везде, где они требуются:
А вот тут уже интереснее. А почему у тебя в коде "куча бойлерплейта по инициализации сервисов"? Может быть потому, что у тебя приложение слишком много задач выполняет? А может быть его тогда стоит на независимые куски попилить, вместо того что бы сложно конфигурировать? А куски будут на основании оговорённых протоколов общаться, и проблема с конфигурацией отпадёт.
M>Особенно весело становится, когда тебе требуется конфигурируемое в рантайме приложение. Скажем, спеллчекер может быть как встроенный, так и внешний интернет сервис, или эта фича может быть вообще отключена и менять это нужно без перезапуска приложения. Причем если внешний сервис оказывается недоступен, то должен срабатывать автоматический откат до dummy implementation.
Это более чем нормально, до тех пор пока приложение содержит в себе 2-3, ну может быть 5 таким образом конфигурируемых сервисов.
M>Не то чтобы это все нельзя было сделать врукопашную явным способом, но в какой-то момент возня с инициализацией начинает занимать большую часть времени разработчика. Чтобы этот момент немного отсрочить и придумали спринг.
Но есть и альтернатива — провести декомпозицию и упростить приложения.
Здравствуйте, avovana, Вы писали:
A>Добрый день, дорогие форумчане!
A>В ближайшем будущем, возможно, буду нанимать в свою команду.
Нанимал достаточно много, по моему опыту, главное — три вещи:
— знание базовой теории алгоритмов: алгоритмическая сложность коллекций и кода, обход деревьев, рекурсия, для людей посильнее — сетевые протоколы, ОС, многопоточность
— сеанс онлайн-кодинга: что-то, связанное с проектированием нескольких классов и привязанное к реальной жизни. Например, логику турникета в метро, бронирования билетов на поезд, оплаты заказа.
— адекватность! Кандидат должен делать, что ему говорят (не бычить), понимать условие задачи (не тупить), проявить гибкость и умение выбирать компромисс (синдром ЕдинственноПравильногоРешения), уметь обосновывать свои решения
Хибернейты, спринги и прочие фреймворки такая мелочь — адекватный человек легко вольется в существующий настроенный проект и начнет штамповать код.
Здравствуйте, avovana, Вы писали:
A>Видел задорные менеджерские заметки, что чем разношерстней команда, тем лучше.
И чем же лучше? Как в том анекдоте — "чем грузины"?
Гемору по координации точно будет больше, а вот бонусы какие?
Разношёрстность команды по опыту, когда люди имели разнообразный опыт и всякое видели с разных сторон — хорошо.
Разношёрстность по отношению к качеству кода — плохо.
A>Что ошибка менеджера искать точно такого же как он. Не будет разных мнений.
Далеко не всегда разница во мнениях это что то хорошее, особенно когда стоит задача собрать команду, которая будет работать над одной задачей и иметь единую цель.
Здравствуйте, vsb, Вы писали:
vsb>На самом деле ничего сложного, если не переизобретать спринг. vsb> ... vsb>Такой паттерн позволяет делать DI с произвольным графом зависимостей. afterPropertiesSet должен проверить все требуемые свойства. Паттерн абсолютно "тупой", можно руками делать, выключив мозг, можно через рефлекцию или кодогенерацию.
Более того, можно кидать конкретное исключение, если найден цикл зависимостей. Хотя на практике обычно IoC-авторы не заморачиваются и кидают инфу про исходный класс, а не про весь цикл. Далее включаешь дедукцию "а что ж недавно поменялось" и находишь причину.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Более того, можно кидать конкретное исключение, если найден цикл зависимостей. Хотя на практике обычно IoC-авторы не заморачиваются и кидают инфу про исходный класс, а не про весь цикл. Далее включаешь дедукцию "а что ж недавно поменялось" и находишь причину.
Нет никаких проблем в цикле зависимостей. Проблема это когда зависимости инициализируются через конструктор. А так в моём примере два цикла зависимостей. Глупый запрет.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Более того, можно кидать конкретное исключение, если найден цикл зависимостей.
Это стоит отдельного вопроса на засыпку. Если кандидат быстро рассказал про инжектор, и осталось время неиспользованное. Еще вопрос на засыпку- как инициализировать зависимости параллельно (а не цепочкой).
Здравствуйте, Тёмчик, Вы писали:
Тё>Здравствуйте, kaa.python, Вы писали:
Тё>Т.е. ты против всего хорошего, aka loose coupling, polymorphism, extensibility Тё>и за все плохое, aka кусок связанного явными вызовами кала.
loose coupling не имеет ничего общего с неавной инициализацией, в то время как extensibility от неявной инициализации только страдает.
Да, считаю polymorphism изжившим себя подходом. А вообще я за простоту и поддерживаемость кода, как-то так, самое важное применительно к данной ситуации я выделил:
Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested.
Sparse is better than dense. Readability counts.
Special cases aren't special enough to break the rules. Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
Здравствуйте, Тёмчик, Вы писали:
Тё>Т.е. ты против всего хорошего, aka loose coupling, polymorphism, extensibility
Не, это ты, видимо, не понимаешь, что это все прекрасно делается без IoC-контейнеров. Которые, как правило, ничего кроме головной боли не добавляют.
Тё>и за все плохое, aka кусок связанного явными вызовами кала.
Кал получается, когда IoC-контейнеры начинают пихать во все дырытуда, где можно спокойно обойтись явным созданием зависимостей в main с последующим их явным пробросом по иерархии.
Здравствуйте, Lexey, Вы писали:
L>Не, это ты, видимо, не понимаешь, что это все прекрасно делается без IoC-контейнеров. Которые, как правило, ничего кроме головной боли не добавляют.
Просто ты не умеешь их готовить
Тё>>и за все плохое, aka кусок связанного явными вызовами кала.
L>Кал получается, когда IoC-контейнеры начинают пихать во все дырытуда, где можно спокойно обойтись явным созданием зависимостей в main с последующим их явным пробросом по иерархии.
Здравствуйте, kaa.python, Вы писали:
KP>loose coupling не имеет ничего общего с неавной инициализацией, в то время как extensibility от неявной инициализации только страдает.
IoC — про декларативное описание зависимостей. Что куда более явное, чем простыни говнокода ручной инициализации.
KP>Да, считаю polymorphism изжившим себя подходом.
Inheritance vs Composition. IoC- про composition.
KP>Любовь джавистов наплодить абстркций и конфигураций ради самого процесса, а не результата, мне всегда казалось странной
Результат — чистый, поддерживаемый, расширяемый код.
Здравствуйте, Тёмчик, Вы писали:
Тё>IoC — про декларативное описание зависимостей. Что куда более явное, чем простыни говнокода ручной инициализации.
Задумайся о том, откуда у тебя столько зависимостей, что тебе нужен аж целый фреймворк для их инициализации и декларативное описание? Это просто как бы красивый способ спрятать кривой дизайн, который был популярен во времена монолитных монстров. Я допускаю что в корпоративной Java и сейчас так пишут, конечно.
Тё> Inheritance vs Composition. IoC- про composition.
IoC про интерфейсы, вообще-то, но вот наследование и реализация интерфейса не совсем одно и то же. Да, это одно и то же в мире C++, но даже в Java это не так.
KP>>Любовь джавистов наплодить абстркций и конфигураций ради самого процесса, а не результата, мне всегда казалось странной Тё>Результат — чистый, поддерживаемый, расширяемый код.
Нет, в результате у тебя есть гора абстракций и вечно тормозящее приложение, а не "чистый, поддерживаемый, расширяемый код"
Здравствуйте, Ip Man, Вы писали:
IM>Кандидаты отлично мотивируются большими деньгами или их перспективой.
Еще хотелось бы видеть перспективу повышения каждый год.
Растёт экспертиза — растёт вознаграждение.
Слышал про случай, когда человек выбирал работу.
1ый вариант с бОльшими деньгами. Вроде бы, уже на собеседование понял, что с руководителем не сможет нормально сработаться.
2ой вариант с меньшими деньгами.
Он выбрал 1ый. Думал, что плохие отношения — это не страшно. По-моему, через пол года уволился. Не смог.
Возникли еще вопросы:
1. У кого-нибудь были такие кейсы?
2. Какая была у вас мотивация сменить работу?
а) Уходили из-за...
б) или стремились к...
в) ...
3. По каким критериям выбирали очередное предложение среди аналогичных?
4. Сколько лет работали на предыдущих местах?
5. Сколько считаете надо?
6. Ваша работа мечты? Где вы хорошо работаете и не собираетесь уходить? Как меня как-то спросили — "что бы тебя заякорило надолго в компании"?
Здравствуйте, blacktea, Вы писали:
B>После, давал тестовое задание, на выполнение которой обычно уходит примерно 2-3 часа и на следующем собесе мы обсуждали его решение. Заранее готовил разные вариации на тему, а что мы будем делать, если требования к этой задачке чуть-чуть изменятся в эту сторону. А что будет, если мы применим тут такой-то паттерн или подход? Представь себе, что у нас появился редкий баг, который сложно отловить, как будем действовать? Ну и все в таком роде.
Вы готовы рассказать это же о себе и своих недавних задачах? Показать пример кода, задачу, коммит?
Здравствуйте, Skorodum, Вы писали:
S>Вы готовы рассказать это же о себе и своих недавних задачах? Показать пример кода, задачу, коммит?
Если нет никаких препятствий в виде NDA, то в пределах разумного, почему бы и нет. Я примерно на такое как-то раз отвечал, но то был переход человека из другого отдела в наш.
