Комментарии 107
А если вам понадобится завтра другую фразу вывести? А если не на экран, а в файл, или по сети, или брокеру сообщений? А если этот код будет кем-то вызываться в многопоточной среде? Нет, тут без пары абстрактных фабрик никак не обойтись.
… тут без пары абстрактных фабрик никак не обойтись.
О, я такое видел… когда один несчастный вызов curl был обернут во все вот это вот, но при этом не было никакой обработки ошибок :)
github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
А если вам понадобится завтра другую фразу вывести?
KISS + YAGNI
Если человек не знает аббревиатуру, значит, мимо него прошло ощутимое количество литературы и обсуждений. Это не значит, что он пишет плохой код, конечно же, но это тоже некая характеристика.
Что характерно, если человек знает аббревиатуру, это тоже не значит, что он пишет хороший код (или хотя бы понимает, что в реальности означает каждая буква в аббревиатуре).
А то, как он пишет код, связано с тем, что он читает и обсуждает. И, что важнее, то, как он будет писать код через год-другой.
Угу. А на работе он "может" много читать требования, но не помнить ключевые термины из них.
А наиболее эффективно — и дать написать код, и спросить термины.
Особенно если в коде есть примеры на эти термины.
Это означает только то, что собеседование плохо спланировано. Если нет времени задать человеку вопросы, какой вообще смысл?
Я просто никогда не планирую собеседование в "условный час".
Я не так уж и часто меняю работу. Скажем где-то каждые 3-5 лет. И если я уж решил её поменять, то чтобы не менять шило на мыло, я обычно спрашиваю о возможности "поторчать" на новой работе с новыми коллегами один день. Даже может и немного "поработать". То есть посмотреть процессы, пощупать тулсы, увидеть как работают мои потенциальные коллеги.
Пока ни одна фирма не была против, а некоторые что-то подобное даже сами предлагали ещё на первых порах собеседования. И ради такого лично мне один день отпуска взять не жалко. И даже два-три если вдруг есть несколько хороших кандидатов.
Ну, я же вам уже рассказывал в одной дискуссии, чем это потенциально может закончиться?
Чем это закончится, уже будет не так важно, так как после вопроса про расшифровку аббревиатур мне будет интереснее не максимизировать не вероятность трудоустройства, а минимизировать ощущение потраченного на интервью времени, а встать и выйти не позволяет врождённая скромность.
И это тоже вполне может быть желаемым для (несостоявшегося) работодателя результатом.
Мне вот вопрос про то, как сделать ООП, и что для этого нужно, представляется куда более интересным, чем вопрос на зазубривание аббревиатур.
А вопрос про SOLID (правильно заданный) — это не вопрос на зазубривание аббревиатур. Это вопрос на общий контекст.
я пусть дальше ищу тех, кому будут интересны (или кого не отпугнут, хехе) мои прочие познания.
Ну вот видите же: работает.
в частности, я сделал вывод, что из вашего тезиса следует, что вопрос на знание аббревиатуры вполне подходит для собеседования
Совершенно правильный вывод. Просто вопрос на знание аббревиатур и вопрос на зазубривание аббревиатур — это два разных вопроса.
Он пусть дальше ищет тех, кто знает расшифровку SOLID назубок, но не знает, что там в основе лежит
Вопросы «как устроена система типов и почему?» и «как моделировать предметную область средствами java-like ООП?» ортогональны друг другу. И, нет, люди прочитавшие тапл (в чем, кстати, особого достижения нет) не начинают автоматически хорошо понимать второй вопрос и писать поддерживаемый код, несколько примеров вполне себе знаю.
Вот через несколько лет после прочтения вывести с нуля объектную систему, не занимаясь все эти года исследованием оснований объектных систем, уже интереснее, но, наверное, среднему программисту не особо нужно.
И все ещё ортогонально умению писать поддерживаемый код, проектировать и решать бизнесовые задачи в рамках той или иной предметной области, только если предметная область не состоит в написании компиляторов или статических анализаторов для языков программирования со статической типизацией и выводом типов. Люди в реальной индустрии до сих пор спорят о нужности и практической пользе var в c# и java, программируют на javascript, а вы хотите на собеседованиях разговаривать о теории (одной из), результатом которой являются несколько абстрактных языков программирования, на которых никто не пишет, ага.
Мне вот вопрос про то, как сделать ООП, и что для этого нужно, представляется куда более интересным, чем вопрос на зазубривание аббревиатур.
А "ООП" это не аббревиатура? А почему вы тогда здесь написали "ООП", а не просто описали весь концепт своими словами? :)
Так и с аббревиатурами на собеседовании(да впрочем и в работе): если вы не знаете базовых для вашего поля деятельности аббревиатур, то начинаются проблемы с пониманием и объяснением. И на это уходит куча времени и сил.
П.С. Правда открытым остаётся вопрос что и где можно/нужно считать базовыми понятиями/аббревиатурами.
Я не понимаю связи этого вопроса с моим тезисом.
Связь в том что даже если вы начнёте обуждать ваше "как сделать ООП, и что для этого нужно", то вы не обойдётесь без аббревиатур. И если в какой-то момент вам нужно будет упомянуть концепт вроде "SOLID" или просто одну из его составляющих, то если вы не знаете как он называется/его аббревиатуру вам придётся и его описывать своими словами.
Если названия паттернов или принципов SOLID активно используются при разработке, то вполне важное. Не все готовы, например, при код ревью вместо "нарушение SRP, используй абатрактную фабрику" не просто расписывать что не так и что надо изменить конкретно типа "в этом методе ты и создаешь сложный объект, и отправляешь его по сети — раздели их, а то непонятно даже где создание закончилось и отправка началась". И, главное, почему это "не так" объяснять не надо.
Простите, а когда вы использовали в своих проектах рекурсию в последний раз? И что плохого в том, что ужасный код приносит деньги? Будучи идеалистами, разработчики часто ставят себе задачи идущие в разрез с целями бизнеса. Только позже приходит осознание, что код пишется для продажи, а не для девелопера. Возможно, в open source немного другая культура.
Простите, а когда вы использовали в своих проектах рекурсию в последний раз?
Это серьезный вопрос?
И что плохого в том, что ужасный код приносит деньги?
Плохо то что он приносит деньги только до тех пор пока его не надо изменять, исправлять или расширять. И вот тогда он внезапно начинает стоить очень много денег.
Только позже приходит осознание, что код пишется для продажи, а не для девелопера
Ага. Я это "позже" уже много раз в своей профессиональной жизни встречал. Ну то есть когда "позже" все начинают удивляться почему добавление простейшей фичи занимает три недели и/или сопровожается кучей багов. Ведь вроде бы раньше таких фич по пять штук в день могли клепать…
Но коли ты клепаешь формочки для очередного магазина/банка/чего-либо ещё, и вся работа заключается в положить в базу, считать с базы, сложить/вычесть, то конечно тебе не нужно рекурсия.
В общем it depends.
И что плохого в том, что ужасный код приносит деньги?
Плохо, не то, что код приносит деньги. Плохо, что стоимость поддержания и развития такого кода растет. И либо у заказчика заканчиваются ресурсы (бюджет на разработку), либо появляются требования по качеству кода.
помниться кто-то говорил что «хорошие» программисты всегда пытаються сделать универсальное решение, что и чайник и утюг и стиралка всё было в одном устройстве, раз все они работают с теплом, водой и электричеством, так вот не надо так делать
И вот тем кто не сможет надо более подробные технические инструкции давать ну и код ревью, оно и против адептов которые любят писать сложно помогает
Люди обычно требуют от других того, чего сами выучили в университете, и за что их преподы гоняли на пересдачи. Для студентов паттерны, солид, асид — это магия. Для опытного разработчика — аксиомы, которая доведены до автоматизма и здравого смысла. Спрашивать академ вопросы на собесе — это самоутверждение закомплексованых неудачников. И не нужно врать что у Вас код написан по всем канонам. Даже в гугле велосипедов хватает, и это абсолютно нормально, если того требует бизнес.
Да не помню я что такое ООП, Фабрика, Наюлюдатель и прочие термины и помнить не хочу, я хочу писать код
Ну, это — конкретное отношение. Можно спорить, плохое оно или хорошее, но тимлиду оно может не нравиться, потому что он считает его вредным для работы, и тимлид в своем праве.
когда надо что то вспомнить открою справочник или доку
Для этого надо знать, что искать. А обычно задача стоит в другую сторону.
С чего вдруг джуниору или пре-джуниору знать все это наизусть
Ну, лично я от джуниора этого знания и не ожидаю (пока он сам им не решит похвастаться), в моем словаре этот вопрос на уровень повыше.
учите концепции, а не паттерны. Концепции реально важны.
Вопрос только в том, по какому "учебнику".
"ООП, MVC, ORM" — это не учебники. Это аббревиатуры (причем разного уровня конкретики). И, честно признаться, учебников по MVC или ORM я не видел ни разу (не считая книг по конкретной имплементации, которые на концепцию никак не тянут), а обычно и то, и другое описывается в книжке про… паттерны. Типа PoEAA. Собственно, потому, что и MVC, и ORM — это паттерны.
Остается ООП. Ну да, можно учить ООП по учебнику ООП. Но мне вот интересно, сколько современных учебников по ООП не упоминают ни паттерны, ни SOLID?
Паттерны проектирования это из области проектирования, а не кодинга. Поэтому да, они помогают прорабатывать решение на уровне концепций. Описание каждого паттерна содержит формулировку класса задач и принцип решения, программный код приводится только для иллюстрации.
учите концепции, а не паттерны. Концепции реально важны.А почему не все сразу? По мне больше важнО не знание, а умение применять то что знаешь правильно.
Знание паттернов полезно для того, чтобы все участники процесса говорили примерно на одном языке и схожие вещи называли одинаково. Например, не называли фасад посредником. Тогда не погружаясь в детали реализации каждого класса можно примерно понять, что он делает, и сэкономить время.
Незнание паттернов, в свою очередь, может приводить к их повторному изобрели — что, безусловно, является отличной зарядкой для ума (да и понимание в этом случае глубже, чем если в учебнике прочитать), но не всегда оптимально с точки зрения трудозатрат.
"Что бы" — вместе, а "неправ" — раздельно.)
КМК, знание паттернов необходимо, чтобы взгляд за код цеплялся. Очень помогает разбираться в чужом (да и своем) коде. Иначе придется детально вникать в каждую строчку кода, подавляя многочисленные wtf. Копаясь в строчках общую картину можно и упустить.
… придется детально вникать в каждую строчку кода, подавляя многочисленные wtf.По меему, это сама суть софтверной археологии.
парень, а давай намутим интерфейсов?
А сами паттерны это столько не про формализацию, сколько про типичное решение типичных проблем, что очень нужно знать джуну, но синьор и так напишет то же самое, даже не помня про конкретный паттерн.
Мое мнение — используете паттерны там, где у вас есть типовая задача, и применение паттерна упрощает решение, а не наоборот. Пишите как умеете (исходя из опыта), и когда дойдете до возникновения повышенной сложности без паттерна, применяйте его.
Меня про Лисков(LSP) спрашивали, как оказалось, подавляющее большинство людей даже не слышали этого термина.
Подобное меня, если честно, удивило.
Да, я в курсе, что не ООП единым.
Data mapper»: а почему бы тебе не использовать дополнительный слой абстракции для сохранения данных?
Мне очень понравился стиль. Может следующей статьей напишите продолжение описания многих концепций таким же неформальным языком? Потому что по сути мы читаем сухое описание, а между собой стараемся в 2 х словах описать.
Builder, factory, repository(и/или DAO — вообщем уметь работать с абстракциями БД) — это если бэк(я про Java, хотя подозреваю, что в других отраслях также или легче) и начальный уровень.
Я написал это по Вашей просьбе, но не по душевному веянию, так как учить по паттернам, не зная зачем это нужно(концепции) — я считаю неправильным. А все это умещается в три замечательные концепции, описанные в статье, а если хочется пойти немного дальше — IoC и его реализация DI, если предмет изучения — Java enterprise, то там это точно пригодится(ибо Spring).
Хорошего дня!
или утра… или вечера…
Пол Грэм.
Разумеется пытаться подогнать свой код под паттерны — бред. Если соблюдать SOLID и GRASP (в разумных пределах) они выстроятся сами по себе.
ООП говорит: «чувак, я нашел наглядный и понятный способ представления программ».
Вот это конкретика! Вот это точность! Правда многие то же самое имеют в виду под ФП или под любой другой аббревиатурой. А вот фабрика и синглтон это размыто и неточно, да.
А так как в большинстве случаев будущий программер начинает от обратного, с реализации, то и возникает подобный диссонанс.
Это ни хорошо ни плохо, просто так есть. В каком порядке этот путь проходить — ну как уж получится. При любом раскладе найдётся история успеха
один модуль должен выполнять только одну задачу, не забывай об этом!
Интересно, почему так много ошибок в понимании S из SOLID? "A class should have only one reason to change" не означает что задача только одна. Это означает что пользователи модуля или используют его полностью или не используют никак.
Ну а посыл в статье нормальный. Я про это давно уже повторяю.
Все такие умные... Но вот я хочу стать разработчиком и у потенциального джуна эти паттерны и принципы спрашивают через раз, если не чаще. И понятно, что учить их - тупо или тупо - их учить, не имеет глобального смысла. Но если хочешь пройти собес и стать тем, кто может на Хабре "пальцы гнуть" тебе придется это учить!!! По крайней мере в 2022 году 100%. Поэтому эта статья скорее вред для того кто начинает свой путь .....
Не учите паттерны, учите концепции