Интересная тема. Как новичок, иногда сталкиваюсь с прокси, но не знал, что в Java есть готовая поддержка динамических прокси.
Ещё тут подумал, может в разделе «Что такое прокси?» добавить уточнение, каким образом прокси добавляет функционал (оборачивает методы проксированного объекта новой функциональностью), и привести пример простейшего прокси в стиле:
public class ProxyActor implements Actor {
private Actor wrappedActor;
//Constrector(s)
public void doSomething() {
// do things before
wrappedActor.doSomething();
//do things after
}
}
Вот и 2019 год клонится к концу, а воз Perforce и ныне там. Несколько рабочих дней упорного изучения и многомесячный опыт коллег сидящих рядом показывает, что дешевле использовать Git-P4 или GitSwarm, чем понять сам Р4 с его периодическими потерями изменений и абсолютно неочевидной логикой работы доброй половины команд.
Любопытненько… Как личность склонная к состоянию стресса, замечал за собой очень похожие симптомы: скорость реакций резко вырастает при длительном воздействии стресса, а степень подобия при которой различные участки мозга образуют ассоциативные связи — резко уменьшается, обычные нормальные желания людей при этом подавляются на время. В результате, во время длительного стресса у меня резко вырастают творческие способности, также как и скорость генерации новых идей, что в среднем увеличивает problem solving skill. Но приходится бороться с негативными симптомами вроде падения мотивации, постоянного чувства тревоги, смешанными мыслями при частых переключениях контекста задач, бессонницей из-за периодических приступов паники из-за слишком ярких сновидений и т.д.
К автору: а есть ещё информация по теме, кроме публикации приведённой в статье?
О-о-о… Это многое объясняет о моём предыдущем месте работы (не в ИТ). Только у меня была ситуация другая: меня тайно ненавидели местные старожилы, которые пережили несколько отечественных «оптимизаций». А ненавидели за то, что я всегда пытался во всём разобраться и всё перепроверить, находил древние, как говно мамонта, ошибки кочующие из периода в период и дружно игнорируемые всеми. А ошибка становится ошибкой с момента её нахождения и публикации в письме ответственному за её недопущение лицом не вовлечённым в круговую поруку.
У меня сложилось похожее впечатление, что одним из источников «практик перегибания палки» является несостоятельный подход к составлению методик/сценариев проверки кандидата, нежелание заниматься их (методик) проработкой, адаптацией, нежелание анализировать и строить модели проверки именно релевантных в своей ситуации знаний и умений. Как результат: «я просто возьму лучшие практики и буду их пошагово повторять» (не понимая сути и принципов), «я просто буду спрашивать базовые вопросы по основам технологий и ждать точное совпадение ответа с Википедией, хороший специалист должен знать все формулировки всего-всего в нашем стеке». Хотя также часто попадаются на собеседованиях HR или тех. специалисты, которые за 5 минут вызывают дичайшее желание работать именно в этой фирме.
Хотя для «зелёных джунов», вроде меня, подобные придирчивые проверки даже в плюс — закаляет, заставляет учить больше, тщательнее, заставляет учиться правильно и чётко доносить свою мысль и не теряться на элементарных вопросах (и кроме метода проб и ошибок — не представляю других способов этому научиться). Вот бы ещё больше простеньких практических задачек на 5-10 минут задавали, они обычно позволяют понять, как мыслит человек и в ходе решения задачки в голос волнение и стеснительность тут же улетучивается и начинают работать реальные знания.
P.S. А истории интересные, здравомыслящему человеку и в голову бы не пришло, что у него работает один человек на два фронта или двое — на один.
Всё же, копирование кода — крайне ужасная практика. Пару-тройку копий вы ещё сможете отслеживать, но их количество будет расти вслед за новыми требованиями и в разных частях проекта. Рано или поздно предел контроля будет превышен и начнётся опасный хаос.
Мне кажется, если DRY не стыкуется с SOLID, то стоит посоветоваться с GoF. Данный пример очень напоминает ситуацию в красках описанную в «Head First: Design Patterns» в главе о Strategy.
Ещё тут подумал, может в разделе «Что такое прокси?» добавить уточнение, каким образом прокси добавляет функционал (оборачивает методы проксированного объекта новой функциональностью), и привести пример простейшего прокси в стиле:
public class ProxyActor implements Actor {
private Actor wrappedActor;
//Constrector(s)
public void doSomething() {
// do things before
wrappedActor.doSomething();
//do things after
}
}
возPerforce и ныне там. Несколько рабочих дней упорного изучения и многомесячный опыт коллег сидящих рядом показывает, что дешевле использовать Git-P4 или GitSwarm, чем понять сам Р4 с его периодическими потерями изменений и абсолютно неочевидной логикой работы доброй половины команд.К автору: а есть ещё информация по теме, кроме публикации приведённой в статье?
Хотя для «зелёных джунов», вроде меня, подобные придирчивые проверки даже в плюс — закаляет, заставляет учить больше, тщательнее, заставляет учиться правильно и чётко доносить свою мысль и не теряться на элементарных вопросах (и кроме метода проб и ошибок — не представляю других способов этому научиться). Вот бы ещё больше простеньких практических задачек на 5-10 минут задавали, они обычно позволяют понять, как мыслит человек и в ходе решения задачки в голос волнение и стеснительность тут же улетучивается и начинают работать реальные знания.
P.S. А истории интересные, здравомыслящему человеку и в голову бы не пришло, что у него работает один человек на два фронта или двое — на один.
Мне кажется, если DRY не стыкуется с SOLID, то стоит посоветоваться с GoF. Данный пример очень напоминает ситуацию в красках описанную в «Head First: Design Patterns» в главе о Strategy.