Добрый день (или вечер, или утро, в зависимости от того, когда выйдет этот пост).
Я хочу высказаться об элитарной части программирования и донести, в общем-то, очевидную мысль до начинающих в back-end (и не только) разработке, попутно используя попытку начать писать на Хабре.
Любой программист с хоть немного хорошим вкусом, начавший программировать по своей воле, после понимания основ языка и написания первых проектов, будет задаваться вопросом не «как сделать что-то», а «как сделать что-то правильно» и «какие тут есть стандарты красоты».
Эти, безусловно верные, вопросы, рано или поздно приведут его к непонятным названиям «Абстрактная фабрика», «Синглтон», «Медиатор» и не менее понятным аббревиатурам SOLID, GRASP.
Обратите внимание, что я не привел в пример ООП, MVC, ORM — это концепции с весьма конкретным смыслом и областью применения, имеющие минимальный уровень абстракции.
ООП говорит: «чувак, я нашел наглядный и понятный способ представления программ».
MVC говорит: «чел, будет лучше, если ты разделишь код, а правила разделения под катом».
ORM говорит: «псс, парень, я тут нашел способ помирить две разные идеологии — ООП и БД».
Тут все понятно.
Я говорю про вещи, которые предполагают максимальный уровень абстракции. Пример:
«Посредник»:
То же самое про другие паттерны:
«Фабрика»:
S (single responsibility):
Я веду к тому, что основная сфера применения паттернов вовсе не в приучении к хорошему коду. Паттерны нужны для обсуждения уже написанной кем-то программы, для формализации хорошего кода. Чтобы можно было сказать («а это чего за класс?» — «а, это часть посредника»). Но не для того, чтобы сверять свою писанину с uml-ками паттернов в судорожном приступе «ааа, какой же паттерн применить в этом случае?».
Программист, хорошо владеющий какой-то концепцией (например, из приведенных выше), сам будет писать код, используя best practices, даже если он не слышал о них ни слова. А те самые best practices нужны, чтобы формализовать отношение его тимлида к его коду — и квинтэссенцией тут является, конечно же, GRASP.
Что я хотел бы сказать начинающим программистам:
Что я хотел бы сказать гуру Хабра:
Ну и напоследок: статья, конечно же, субъективная, я никого ни к чему (воевать с фабриками) не призываю. Это просто мое мнение :)
Более того, я всего лишь junior, но я просто вижу противоречия и говорю о них.
Хорошего дня!
Я хочу высказаться об элитарной части программирования и донести, в общем-то, очевидную мысль до начинающих в back-end (и не только) разработке, попутно используя попытку начать писать на Хабре.
Итак
Любой программист с хоть немного хорошим вкусом, начавший программировать по своей воле, после понимания основ языка и написания первых проектов, будет задаваться вопросом не «как сделать что-то», а «как сделать что-то правильно» и «какие тут есть стандарты красоты».
Эти, безусловно верные, вопросы, рано или поздно приведут его к непонятным названиям «Абстрактная фабрика», «Синглтон», «Медиатор» и не менее понятным аббревиатурам SOLID, GRASP.
Обратите внимание, что я не привел в пример ООП, MVC, ORM — это концепции с весьма конкретным смыслом и областью применения, имеющие минимальный уровень абстракции.
ООП говорит: «чувак, я нашел наглядный и понятный способ представления программ».
MVC говорит: «чел, будет лучше, если ты разделишь код, а правила разделения под катом».
ORM говорит: «псс, парень, я тут нашел способ помирить две разные идеологии — ООП и БД».
Тут все понятно.
Я говорю про вещи, которые предполагают максимальный уровень абстракции. Пример:
«Посредник»:
чел, если у тебя есть много разных объектов, сделай один центральный, к нему подключи все остальное.Программист просто странно посмотрит в его сторону, если он общительный, скажет «спасибо, кэп!», а за глаза будет называть не иначе как «капитан очевидность».
То же самое про другие паттерны:
«Фабрика»:
чел, а ты знал, что можно конструировать объекты посредством другого класса?«Data mapper»:
а почему бы тебе не использовать дополнительный слой абстракции для сохранения данных?«Наблюдатель»:
парень, а давай намутим интерфейсов?«Стратегия»:
ты знаешь что такое полиморфизм?И особенно SOLID:
S (single responsibility):
один модуль должен выполнять только одну задачу, не забывай об этом!I (interface segregation):
для разных операций используй разные интерфейсы!Ну и так далее.
Я веду к тому, что основная сфера применения паттернов вовсе не в приучении к хорошему коду. Паттерны нужны для обсуждения уже написанной кем-то программы, для формализации хорошего кода. Чтобы можно было сказать («а это чего за класс?» — «а, это часть посредника»). Но не для того, чтобы сверять свою писанину с uml-ками паттернов в судорожном приступе «ааа, какой же паттерн применить в этом случае?».
Программист, хорошо владеющий какой-то концепцией (например, из приведенных выше), сам будет писать код, используя best practices, даже если он не слышал о них ни слова. А те самые best practices нужны, чтобы формализовать отношение его тимлида к его коду — и квинтэссенцией тут является, конечно же, GRASP.
Что я хотел бы сказать начинающим программистам:
- учите концепции, а не паттерны. Концепции реально важны.
- если вы вдруг опомнились, что не знаете паттернов, не надо паниковать. Это будет иметь значение только для рекрутера, но никак не для вашего кода и хорошего стиля.
Что я хотел бы сказать гуру Хабра:
- Я могу быть неправ. Серьезно.
- Я понимаю, мысль банальна. Но, тем не менее, почему-то я часто встречаю подобный подход у начинающих.
- Исходя из пункта 2, подобная статья может быть уже написана до меня. Я не знаю.
Ну и напоследок: статья, конечно же, субъективная, я никого ни к чему (воевать с фабриками) не призываю. Это просто мое мнение :)
Более того, я всего лишь junior, но я просто вижу противоречия и говорю о них.
Хорошего дня!
BalinTomsk
Я работал в куче крупнейших софтвеpных компаний — никто этими терминами из статьи не пользуется и ни разу на спросили на интервью.
vasyan
Да ладно, все знают, что паттерны нужны для интервью и ещё Java-программистам, там без паттернов даже в файл «Hello world» не запишешь.
MaxVetrov
bRUtality
Ужасный код — ни одного паттерна =)
MaxVetrov
Он не ужасен. Это самый прекрасный и чистый код.
Учителя не могут учить ужасному коду!
Только то, что начинается после него — можно назвать ужасным.)
tangro
Так писать на Java нельзя! Вот, как надо: github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
MaxVetrov
Да, видел ранее :)
NewLineStringPrinter.java — для \n.
Какой популярный, надо тоже использовать ))
Сообщество опять же.
Eldhenn
А если вам понадобится завтра другую фразу вывести? А если не на экран, а в файл, или по сети, или брокеру сообщений? А если этот код будет кем-то вызываться в многопоточной среде? Нет, тут без пары абстрактных фабрик никак не обойтись.
cyberly
О, я такое видел… когда один несчастный вызов curl был обернут во все вот это вот, но при этом не было никакой обработки ошибок :)
Bkmz
Вы про вот такую реализацию Fizz-Buzz?
github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
Eldhenn
Это высший пилотаж, недостижимый идеал, к которому каждый, тем не менее, должен стремиться.
SeApps Автор
Смешанные чувства… но я сохраню это)
Calc
KISS + YAGNI
shandy
Стыдно не знать — Front Controller ))
MaxVetrov
Вроде, Front Controller к веб-сайтам относится:)
cyberly
Ну, это как бы иллюстрация к тому, о чем статья: желательно понимать идею, которая стоит за паттерном. Главное по ссылке: «The Front Controller consolidates all request handling by channeling requests through a single handler object» для того, чтобы избежать "...much of this behavior can end up duplicated. Also, it's difficult to change behavior at runtime.". Важно, что все запросы проходят через одну точку и за счет этого их потоком легче управлять и вообще понимать, что происходит с их обработкой, а не то, что это веб-сайт или не веб-сайт. Например, если установить правило, что все запросы в ваш отдел всегда проходят через определенного сотрудника, это вполне будет реализацией этого паттерна.
MaxVetrov
Походит на «Посредник» :)
makssieve
Синглтон?)
MaxVetrov
Нет, у класса HelloWorld конструктор не приватный. А это значит, что можно создать несколько экземпляров класса снаружи. Что в свою очередь противоречит паттерну Одиночка.
eumorozov
Меня изредка спрашивают. Недавно был на собеседовании в одной очень крупной компании, спросили, какие паттерны я знаю и использовал в коде.
nshipyakov
Вообще подобные вопросы на мой взгляд бесполезные. Те если работодатель реально хочет проверить соискателя то нужно или дать код написать или скажем оценить уже написанный. А спрашивать просто названия шаблонов такое себе на мой взгляд. Или вопросы на расшифровку solid. Это ещё глупее как по мне.
DEADMC
Чем вопрос про SOLID — то плох?
nshipyakov
Ну просто человек может не знать абревиатуру, но писать хороший код. Знание или не знание самого термина не особо помогает при опросе кандидата. Написать или найти недостаток в коде как по мне более действенный метод оценки кандидата
lair
Если человек не знает аббревиатуру, значит, мимо него прошло ощутимое количество литературы и обсуждений. Это не значит, что он пишет плохой код, конечно же, но это тоже некая характеристика.
Что характерно, если человек знает аббревиатуру, это тоже не значит, что он пишет хороший код (или хотя бы понимает, что в реальности означает каждая буква в аббревиатуре).
nshipyakov
Да я с этим согласен. Но на работе нас все-таки интересует как человек работает(пишет код). Поэтому и некий скепсис к знанию самих названий
lair
А то, как он пишет код, связано с тем, что он читает и обсуждает. И, что важнее, то, как он будет писать код через год-другой.
nshipyakov
Ну опять же человек может очень много читать и развиваться, но не помнить/заучивать какие — то абревиатуры
lair
Угу. А на работе он "может" много читать требования, но не помнить ключевые термины из них.
nshipyakov
Ну всякое может быть. Я не говорю что не надо знать термины. Моя мысль, что дать написать код более эффективно, чем спрашивать определения и абревиатуры
lair
А наиболее эффективно — и дать написать код, и спросить термины.
Особенно если в коде есть примеры на эти термины.
nshipyakov
В идеале наверное да. Реально обычно времени не хватает. По моему опыту по крайней мере обычно не хватает времени
lair
Это означает только то, что собеседование плохо спланировано. Если нет времени задать человеку вопросы, какой вообще смысл?
nshipyakov
Ну если вам всегда хватает условного часа на то чтобы узнать общую инфу о кандидате, его прошлый опыт и задать все технические вопросы — мое уважение вам. Я не настолько крут
lair
Я просто никогда не планирую собеседование в "условный час".
Kanut
Я не так уж и часто меняю работу. Скажем где-то каждые 3-5 лет. И если я уж решил её поменять, то чтобы не менять шило на мыло, я обычно спрашиваю о возможности "поторчать" на новой работе с новыми коллегами один день. Даже может и немного "поработать". То есть посмотреть процессы, пощупать тулсы, увидеть как работают мои потенциальные коллеги.
Пока ни одна фирма не была против, а некоторые что-то подобное даже сами предлагали ещё на первых порах собеседования. И ради такого лично мне один день отпуска взять не жалко. И даже два-три если вдруг есть несколько хороших кандидатов.
0xd34df00d
Ну это зависит. Я во всех этих
срдискуссиях про ООП участвую периодически, но из SOLID вспомню только что-то там про single responsibility principle, потому что оно первой буквой идёт, и про то, что в каждом обсуждении возникает мысль, что все остальные принципы самоочевидные.Если у меня всерьёз начнут спрашивать по терминологии, то у меня возникет большое желание спросить интервьювера в ответ о (так, ООП, да?), например, принципе подстановки Лисков, как это связано с иммутабельностью, и плавно перевести разговор в то, какие элементы лямбда-куба потребуются для реализации ООП в чистом функциональном языке программирования, и насколько глубоко (нужна ли вся System F?, или хватит её подмножества, и, кстати, раз зашёл разговор, что такое ? и какое отношение это имеет к арифметике ординалов).
lair
Ну, я же вам уже рассказывал в одной дискуссии, чем это потенциально может закончиться?
0xd34df00d
Чем это закончится, уже будет не так важно, так как после вопроса про расшифровку аббревиатур мне будет интереснее не максимизировать вероятность трудоустройства, а минимизировать ощущение потраченного на интервью времени, а встать и выйти не позволяет врождённая скромность.
Но разговор-то не о том, чем это закончится, а о том, какие вопросы имеют смысл и почему. Мне вот вопрос про то, как сделать ООП, и что для этого нужно, представляется куда более интересным, чем вопрос на зазубривание аббревиатур.
Да и вон eumorozov ниже про теоретические основы говорит. А это разве не теоретические основы?
lair
И это тоже вполне может быть желаемым для (несостоявшегося) работодателя результатом.
А вопрос про SOLID (правильно заданный) — это не вопрос на зазубривание аббревиатур. Это вопрос на общий контекст.
0xd34df00d
Ну супер, побыстрее разобрались, кто кому нужен и зачем. Он пусть дальше ищет тех, кто знает расшифровку SOLID назубок, но не знает, что там в основе лежит (я не зря про всю эту лямбда-ерунду начал говорить с LSP), я пусть дальше ищу тех, кому будут интересны (или кого не отпугнут, хехе) мои прочие познания.
Ну, ваш же тезис:
Я его немного додумал, конечно (в частности, я сделал вывод, что из вашего тезиса следует, что вопрос на знание аббревиатуры вполне подходит для собеседования).
lair
Ну вот видите же: работает.
Совершенно правильный вывод. Просто вопрос на знание аббревиатур и вопрос на зазубривание аббревиатур — это два разных вопроса.
retran
Вопросы «как устроена система типов и почему?» и «как моделировать предметную область средствами java-like ООП?» ортогональны друг другу. И, нет, люди прочитавшие тапл (в чем, кстати, особого достижения нет) не начинают автоматически хорошо понимать второй вопрос и писать поддерживаемый код, несколько примеров вполне себе знаю.
0xd34df00d
Так фокус в том, что люди, знающие, что такое SOLID, тоже не начинают автоматически что-то там хорошо писать.
Проверять, как кандидат умеет моделировать предметную область, ИМХО лучше всего через обсуждение некоей игрушечной предметной области и её моделирования, а не через обсуждение, что какая буковка в аббревиатуре означает.
Ну а в прочтении тапла действительно особой заслуги нет. Вот через несколько лет после прочтения вывести с нуля объектную систему, не занимаясь все эти года исследованием оснований объектных систем, уже интереснее, но, наверное, среднему программисту не особо нужно.
retran
И все ещё ортогонально умению писать поддерживаемый код, проектировать и решать бизнесовые задачи в рамках той или иной предметной области, только если предметная область не состоит в написании компиляторов или статических анализаторов для языков программирования со статической типизацией и выводом типов. Люди в реальной индустрии до сих пор спорят о нужности и практической пользе var в c# и java, программируют на javascript, а вы хотите на собеседованиях разговаривать о теории (одной из), результатом которой являются несколько абстрактных языков программирования, на которых никто не пишет, ага.
0xd34df00d
Ну помечтать-то можно же, ну.
Kanut
А "ООП" это не аббревиатура? А почему вы тогда здесь написали "ООП", а не просто описали весь концепт своими словами? :)
Так и с аббревиатурами на собеседовании(да впрочем и в работе): если вы не знаете базовых для вашего поля деятельности аббревиатур, то начинаются проблемы с пониманием и объяснением. И на это уходит куча времени и сил.
П.С. Правда открытым остаётся вопрос что и где можно/нужно считать базовыми понятиями/аббревиатурами.
0xd34df00d
Я не понимаю связи этого вопроса с моим тезисом. Но если бы у меня на собеседовании спрашивали расшифровку «ООП», я бы тоже, скажем так, озадачился.
А я устраиваюсь теоретиком в ООП, что ли, писать книжки вместе с Дядей Бобом?
Kanut
Связь в том что даже если вы начнёте обуждать ваше "как сделать ООП, и что для этого нужно", то вы не обойдётесь без аббревиатур. И если в какой-то момент вам нужно будет упомянуть концепт вроде "SOLID" или просто одну из его составляющих, то если вы не знаете как он называется/его аббревиатуру вам придётся и его описывать своими словами.
0xd34df00d
Да, безусловно.
Но, скорее всего, сам концепт целиком упоминать не придётся. Конечно, мы пройдёмся по некоторым его составляющим, но их даже упоминать явно не придётся, и уж тем более в том виде, в котором они упоминаются в расшифровке этой аббревиатуры.
gmuz
Меня мягко говоря подбешивает когда на собеседованиях начинают устраивать теоретические экзамены. Да не помню я что такое ООП, Фабрика, Наюлюдатель и прочие термины и помнить не хочу, я хочу писать код, а когда надо что то вспомнить открою справочник или доку. С чего вдруг джуниору или пре-джуниору знать все это наизусть, одних колекций в джаве вагон и тележка и что бы их понимать и знать когда и где их применять надо иметь опыт их использования, а джун на то и джун что опыта у него нет.
eumorozov
Это вопрос спорный. Побыв с другой стороны баррикад — нанимая людей, чтобы работать с ними, поражаешься какое количество людей не знает теоретических основ вообще. Начиная порой с таких банальных вещей как рекурсия. Какие-там Domain-Driven Development или паттерны.
По моему скромному опыту, затем эти люди пишут просто отвратительный код. Реально отвратительный. Да, они могут писать. Но они не понимают разницы между iterable, iterator, container, list и set. Поэтому, например, в их коде любой iterable всегда приводится к list, потому что это — единственное, с чем они умеют работать.
Они могут выполнить любую задачу, возможно, но делают это в виде стены нечитаемого кода с жуткими 5-кратными вложенными операторами
if, циклами, и т.п.Этот код потом разлетается от малейшего дуновения ветерка и совершенно невозможно расширять. Любое малейшее изменение требований приводит к тому, что рядом встает вторая стена кода, а количество ошибок растет как N^2.
И справедливости ради, меня никогда не просили дать дословные формальные определения каждого паттерна, скорее, интересовались, о каких слышал, и как применял.
P.S. С другой стороны, все адские проекты и программисты из ада, которые я видел, продолжают существовать. Есть продукт, код которого я видел лет 14 назад, в котором разработчики не знали о вызове процедур, и заменяли его copy-paste'ом повторяющегося кода (серьезно). Этот продукт до сих пор на рынке (не знаю, правда, возможно за 14 лет его не раз переписали). Поэтому хотя работать с таким кодом и людьми мне кажется адски тяжелым, но жизнь показывает, что бизнес, основанный на адском коде вполне может существовать десятилетями. Увы.
Ar234
Простите, а когда вы использовали в своих проектах рекурсию в последний раз? И что плохого в том, что ужасный код приносит деньги? Будучи идеалистами, разработчики часто ставят себе задачи идущие в разрез с целями бизнеса. Только позже приходит осознание, что код пишется для продажи, а не для девелопера. Возможно, в open source немного другая культура.
lair
Это серьезный вопрос?
Kanut
Плохо то что он приносит деньги только до тех пор пока его не надо изменять, исправлять или расширять. И вот тогда он внезапно начинает стоить очень много денег.
Ага. Я это "позже" уже много раз в своей профессиональной жизни встречал. Ну то есть когда "позже" все начинают удивляться почему добавление простейшей фичи занимает три недели и/или сопровожается кучей багов. Ведь вроде бы раньше таких фич по пять штук в день могли клепать…
dkdkdk
Про рекурсию — ну по нескольку раз в год, это уж как минимум.
waxtah
Если ты работаешь с рекурсивными структурами данных, то так или иначе будешь использовать рекурсию. Либо развернёшь её в цикл с использованием стека или без.
Но коли ты клепаешь формочки для очередного магазина/банка/чего-либо ещё, и вся работа заключается в положить в базу, считать с базы, сложить/вычесть, то конечно тебе не нужно рекурсия.
В общем it depends.
cyberly
В базе может дерево лежать
transcengopher
… и даже если оно там не лежит на первый взгляд, индексы по таблицам могуть быть бинарными деревьями (да, и их кто-то наверное даже иногда разворачивает, только не на доске).
SeApps Автор
Видишь дерево? И я нет. А оно есть
MaxVetrov
Суслика
0xd34df00d
Ну, технически сложение [натуральных чисел] определяется рекурсивно, так что даже в этом случае рекурсия нужна.
jetcar
был у нас один такой идеалист, толку от него было мало, так как перформанс в простых задачах никакой из-за желания сделать на века, изменять потом такой код тоже не всегда просто потому что надо разобраться со сложной логикой компонентов, а с этой переделкой джуниоры могут не справиться, и вот когда происходит разделение кода на для поумнее и не очень наступают сложные времена, так что уж лучше пускай будет всё просто сделано и понятно всем, чем мегаумно и понятное единицам
помниться кто-то говорил что «хорошие» программисты всегда пытаються сделать универсальное решение, что и чайник и утюг и стиралка всё было в одном устройстве, раз все они работают с теплом, водой и электричеством, так вот не надо так делать
Gryphon88
Кстати, писать докуметацию на свой код с помощью UML — это хороший тон, за который угощают пивом, или просто эту документацию никто не ищет и не смотрит?
eumorozov
Отвечу вам и Ar234 сразу.
Вот вам банальный недавний пример. Человек, один из тех, кто не понимает рекурсию, а так же, вряд ли способен внятно объяснить разницу между iterator и container, написал в методе сохранения объекта в ORM колбасу из 4-х вложенных операторов
if, в которой делаются 3-4 вызова REST API сторонних (не наших) сервисов.То есть, на любой чих, в любом месте, например, какая-то batch job будет обновлять данные объекты (а это нам необходимо периодически делать), будут, #*%^, возникать задержки на сохранении вплоть до нескольких минут! И когда пользователи через UI создают или меняют объекты данного типа (а это основные объекты, с которыми взаимодействуют пользователи нашего проекта), так же будут непредсказуемые задержки вплоть до нескольких минут. А если, не дай бог, на 500 мс пропал DNS, то при сохранении может возникнуть исключение, и объект не будет сохранен.
Или, когда, из-за таких головотяпов пришлось полностью рефакторить проект, потому что в говнокоде просто не было возможности исправить маленькую, но очень важную ошибку. Я не могу привести все подробности из-за NDA и просто не хочется делиться всеми подробностями fuckup'а, но суть в том, что архитектура в корне оказалась неверной, и развивать продукт на ее основе оказалось не то что сложным — просто совершенно точно абсолютно невозможным. И это не мое мнение, а мнение нескольких человек, в том числе это признал автор говнокода, когда его ткнули носом в эту проблему. Пришлось переписать едва ли не 80% проекта, потому что иначе ждала смерть. Ни исправить существующие проблемы, не добавить новые возможности в говноархитектуру было просто невозможно никакими силами.
Есть баланс между идеализмом и перфекционизом и говнокодом. Человек, который не слышал о паттернах, чаще всего ближе ко второму концу этого диапазона, увы. Во всяком случае, из моего достаточно уже богатого опыта.
P.S. При этом я уважаю людей, которые критикуют паттерны, и не используют их, и сам с опаской отношусь к Architecture Argonauts или как их там зовут. Но только когда это обоснованное мнение, основанное на изучении вопроса и обоснованном скептицизме, основанном на опыте и рациональных доводах. А не на том, что "говно-джуниоры, которых мы нашли на помойке, согласных работать за доширак, не понимают эти ваши паттерны-шаматтерны, но они за миску лапши смогут решать все вопросы бизнеса все равно».
jetcar
я не спорю что есть недалёкие, которых в код пускать не стоит, но их можно с помощью тестирования отсеивать, + задания со звёздочкой, что будет если будет не 10, а миллион записей, кто-то сделает, а кто-то не сможет.
И вот тем кто не сможет надо более подробные технические инструкции давать ну и код ревью, оно и против адептов которые любят писать сложно помогает
Ar234
Люди обычно требуют от других того, чего сами выучили в университете, и за что их преподы гоняли на пересдачи. Для студентов паттерны, солид, асид — это магия. Для опытного разработчика — аксиомы, которая доведены до автоматизма и здравого смысла. Спрашивать академ вопросы на собесе — это самоутверждение закомплексованых неудачников. И не нужно врать что у Вас код написан по всем канонам. Даже в гугле велосипедов хватает, и это абсолютно нормально, если того требует бизнес.
lair
Ну, это — конкретное отношение. Можно спорить, плохое оно или хорошее, но тимлиду оно может не нравиться, потому что он считает его вредным для работы, и тимлид в своем праве.
Для этого надо знать, что искать. А обычно задача стоит в другую сторону.
Ну, лично я от джуниора этого знания и не ожидаю (пока он сам им не решит похвастаться), в моем словаре этот вопрос на уровень повыше.
koperagen
Можете рассказать, какие знания вы ожидаете от джуна? Спрашиваю с позиции студента
lair
Знание языка, на котором предстоит писать, на уровне "могу написать большой фрагмент кода/некрупную программу не обращаясь к соседу за помощью" (помощь и совет — две разные вещи), несколько написанных программ, хотя бы и учебных. Дальше все на уровне "поговорить".
cyberly
Хм, а у меня почти каждый раз спрашивают… Правда, я на собеседования хожу редко и, в основном, просто так (я фрилансер, и мне иногда интересно сходить живьем посмотреть на других программистов).
Feihoa
В течение этого месяца побывал на 15 собеседованиях, примерно на 10 из них спрашивали про паттерны, какие знаю, какие использовал и прочую дичь. c#
lair
Вопрос только в том, по какому "учебнику".
aknew
Вопрос про учебник и для паттернов актуален, особенно когда на собеседовании тебя спрашивают просто что такое XXX. Я даже как-то захотел показать это на примере и найтинесоответствие названий в разных книгах. В итоге обошелся одной бандой четырех — у них wrapper это синоним сразу и адаптера, и декоратора (я на всякий случай даже нашел английское издание 94 года — там так же)
lair
Для паттернов они по крайней мере есть. А вот найти учебник, в котором были бы концепции, но не было бы паттернов...
raamid
Судя потому, что автор называет концепциями: ООП, MVC, ORM — вот по этим учебникам.
lair
"ООП, MVC, ORM" — это не учебники. Это аббревиатуры (причем разного уровня конкретики). И, честно признаться, учебников по MVC или ORM я не видел ни разу (не считая книг по конкретной имплементации, которые на концепцию никак не тянут), а обычно и то, и другое описывается в книжке про… паттерны. Типа PoEAA. Собственно, потому, что и MVC, и ORM — это паттерны.
Остается ООП. Ну да, можно учить ООП по учебнику ООП. Но мне вот интересно, сколько современных учебников по ООП не упоминают ни паттерны, ни SOLID?
funca
Паттерны проектирования это из области проектирования, а не кодинга. Поэтому да, они помогают прорабатывать решение на уровне концепций. Описание каждого паттерна содержит формулировку класса задач и принцип решения, программный код приводится только для иллюстрации.
0xd34df00d
Меня на собеседованиях иногда спрашивают, как бы я спроектировал распределённый кэш/распределённую ФС/распределённую шину данных (блин, что-то всё распределённое), и как-то разговор идёт скорее не о том, где бы я фабрику использовал, а где бы визитор, а об алгоритмах, допущениях и гарантиях системы.
besitzeruf
Cerberuser
Если я правильно понял автора, суть в том, что при владении концепциями (и правильном применении их, да) известные паттерны будут получаться естественным путём, а значит, нет смысла им следовать целенаправленно.
pankraty
Знание паттернов полезно для того, чтобы все участники процесса говорили примерно на одном языке и схожие вещи называли одинаково. Например, не называли фасад посредником. Тогда не погружаясь в детали реализации каждого класса можно примерно понять, что он делает, и сэкономить время.
Незнание паттернов, в свою очередь, может приводить к их повторному изобрели — что, безусловно, является отличной зарядкой для ума (да и понимание в этом случае глубже, чем если в учебнике прочитать), но не всегда оптимально с точки зрения трудозатрат.
dyadyaSerezha
"Что бы" — вместе, а "неправ" — раздельно.)
ArsenAbakarov
больше пишите и читайте чужой код, понимание само придет, я когда первый раз прочел «Банду четырех», понял что я уже много чего и сам использовал, сам того не понимая.
gasizdat
КМК, знание паттернов необходимо, чтобы взгляд за код цеплялся. Очень помогает разбираться в чужом (да и своем) коде. Иначе придется детально вникать в каждую строчку кода, подавляя многочисленные wtf. Копаясь в строчках общую картину можно и упустить.
cyberly
Ну не знаю… некоторые налепят в именах классов названия паттернов, которые эти классы типа реализуют, но забудут, например, как-то в имени отразить, зачем, собственно, этот класс нужен. Толку от того, что у нас есть ФабрикаНепонятноЧего? Ну или кроме декларируемой роли еще какую-нибудь абсолютно левую функциональность в класс засунут… ну, чтобы интереснее было потом искать, где данные портятся.
По меему, это сама суть софтверной археологии.Carbonade
Ага, теперь я знаю, как красиво обозвать первую стадию рефакторинга
говнокодалегаси! Спасибо.gasizdat
Согласен, но это другая крайность, типа фабрики фабрик визиторов. KISS в помощь.
DEADMC
Ну observer это не совсем
А сами паттерны это столько не про формализацию, сколько про типичное решение типичных проблем, что очень нужно знать джуну, но синьор и так напишет то же самое, даже не помня про конкретный паттерн.
yakimchuk-ry
Мое мнение — используете паттерны там, где у вас есть типовая задача, и применение паттерна упрощает решение, а не наоборот. Пишите как умеете (исходя из опыта), и когда дойдете до возникновения повышенной сложности без паттерна, применяйте его.
fougasse
Меня про Лисков(LSP) спрашивали, как оказалось, подавляющее большинство людей даже не слышали этого термина.
Подобное меня, если честно, удивило.
Да, я в курсе, что не ООП единым.
alphasigma
Мне очень понравился стиль. Может следующей статьей напишите продолжение описания многих концепций таким же неформальным языком? Потому что по сути мы читаем сухое описание, а между собой стараемся в 2 х словах описать.
pavel_77
Поделитесь, пожалуйста, какие паттерны Вы наиболее часто используете в работе. Т.е. хочется список, с которым джуниор ну на 100% столкнется, чтобы изучить их в первую очередь.
SeApps Автор
Builder, factory, repository(и/или DAO — вообщем уметь работать с абстракциями БД) — это если бэк(я про Java, хотя подозреваю, что в других отраслях также или легче) и начальный уровень.
Я написал это по Вашей просьбе, но не по душевному веянию, так как учить по паттернам, не зная зачем это нужно(концепции) — я считаю неправильным. А все это умещается в три замечательные концепции, описанные в статье, а если хочется пойти немного дальше — IoC и его реализация DI, если предмет изучения — Java enterprise, то там это точно пригодится(ибо Spring).
pavel_77
Спасибо, действительно имелась в виду Java. На счет использования паттернов, не понимая зачем это нужно, тоже соглашусь. Брать паттерн и подгонять под него свою задачу, конечно, неправильно
kravtsov_victor
Так получилось, что на старте своей карьеры первые два года своей работы я не знал ни одного паттерна. Но то самое понимание самих концепций привело к тому, что я неосознанно использовал некоторые паттерны. Потом, когда первый раз читал литературу по паттернам, я периодически ловил себя на мысли «ух ты, а я этот паттерн уже использовал в своём коде».
Gryphon88
По-моему, это у всех так.
S-e-n
Не у всех, к сожалению. Некоторые просто начинают применять их бездумно, потому что Так Правильно.
Kryshtop
или утра… или вечера…
rboots
Концепции не конфликтуют с паттернами, а объясняют их происхождение. Да, зная исходные принципы можно вывести многие паттерны, но я, например, часто смотрю новые паттерны просто для вдохновения, чтобы понять, что «эту задачу можно решить ещё и вот так». Конечно можно и без паттернов, я первые пять лет работы вообще боялся этого слова, оказалось они очень просты и от них есть польза, если применять из без фанатизма. Плюс помогают в коммуникации, проще сказать «добавь туда фасад», чем «сделай функцию, которая пребразует исходный интерфейс в нужный», просто меньше слов.
Tanner
«Я воспринимаю паттерны в своём коде как плохое предзнаменование. Код должен отражать только ту проблему, которую решает программа. Любые другие регулярности означают, по крайней мере, для меня, что мои абстракции недостаточно мощны, как будто я пытаюсь развернуть вручную некий макрос, который должен был написать.»
Пол Грэм.
Vocler
ИМХО, паттерны придумали скорее для общения с коллегами, для того что-бы не описывать абстракцию несколько минут, а использовать одно слово.
Разумеется пытаться подогнать свой код под паттерны — бред. Если соблюдать SOLID и GRASP (в разумных пределах) они выстроятся сами по себе.
poxvuibr
Вот это конкретика! Вот это точность! Правда многие то же самое имеют в виду под ФП или под любой другой аббревиатурой. А вот фабрика и синглтон это размыто и неточно, да.