Когда я читаю Тетеревлёва я эту фразу в голове держу: «Одно из неприятных свойств нашего времени состоит в том, что те, кто испытывает уверенность, глупы, а те, кто обладает хоть каким-то воображением и пониманием, исполнены сомнений и нерешительности»

Странно, что ты так думаешь

прям вот жду не дождусь аргументов

Ну так все верно

аргументы это лишнее

Нет

А Жаров уже ушел отседа?

аргументы это лишнее

Точно. Главное погромче сказать какую-нибудь тупость :)

Если я приведу аргументы

в яве народ немного двинутый в другую сторону. они жить не могут без паттернов... но многие даже не пытаются сами помыслить - для чего и как и в каких ситуациях надо.

да в явке это явно видно и там есть профдеформация, но все же все используют MVC и подобные -это паттерн, синглтоны, фабрики, прототип, object pool и фабричные методы, не говоря о адаптере, декораторе, фасаде и прокси (без них дизайн кода ломается) ровно как и стратегия, состояние, визитор, шаблонный метод и т.д. -это все без чего я хз как жить, та же chain of responsibility -это готовые подходы без которых жить сложно и вот буквально видел ,как народ сам их изобретает или использует не понимая, что это как бы паттерн ))

Это будет лишним

)

"или использует не понимая, что это как бы паттерн ))" - ничего плохого в этом не вижу :)

да в явке это явно видно и там есть профдеформация, но все же все используют MVC и подобные -это паттерн, синглтоны, фабрики, прототип, object pool и фабричные методы, не говоря о адаптере, декораторе, фасаде и прокси (без них дизайн кода ломается) ровно как и стратегия, состояние, визитор, шаблонный метод и т.д. -это все без чего я хз как жить, та же chain of responsibility -это готовые подходы без которых жить сложно и вот буквально видел ,как народ сам их изобретает или использует не понимая, что это как бы паттерн ))

в явке есть учителя и после учителей можно сдать серт и пойти всю жизнь кодить. Как на завод. В ПХП нет, или крайне не массово.

если вы не используете паттерны -паттерны используют вас, по крайней мере вашими фреймворками)

если чел сам додумался, значит у него в голове хоть чтото есть

в явке есть учителя и после учителей можно сдать серт и пойти всю жизнь кодить. Как на завод. В ПХП нет, или крайне не массово.

zend

если чел сам додумался, значит у него в голове хоть чтото есть

это значит только то, что он потратил рабочее время в пустую изобретая велосипед)

это значит только то, что он потратил рабочее время в пустую изобретая велосипед)

и это тоже верно... ладно. пустой спор :)

не знаю, не слышал чтобы ктото интересовался про зенд. Общаясь с коллегами, иногда говорю что чутка умею в зенд фреймворк (а на мой взгляд все остальное надо сжечь), молодые коллеги вообще не понимают о чем я. Смотрят видео с ларакастами. Я не понимаю их.

хотя не. @artem_zi зачем ты используешь фасады?

не знаю, не слышал чтобы ктото интересовался про зенд. Общаясь с коллегами, иногда говорю что чутка умею в зенд фреймворк (а на мой взгляд все остальное надо сжечь), молодые коллеги вообще не понимают о чем я. Смотрят видео с ларакастами. Я не понимаю их.

зенд микрофреймворк выпустил. вроде нормальный. прям как я хотел

выбираешь нужный DI, нужные другие компненты. из нескольких

зенд микрофреймворк выпустил. вроде нормальный. прям как я хотел

Ухты надо позыркать.

я бы может посмотрел какнибудь.

Чего?

хотя не. @artem_zi зачем ты используешь фасады?

как и многие паттерны в java мире нужен он для работы с легаси -как минимум, ну или логично -любой сторонний код, можно конечно сказать, как все, что просто часть апи спрятать, но по сути это обертка для легаси)

как и многие паттерны в java мире нужен он для работы с легаси -как минимум, ну или логично -любой сторонний код, можно конечно сказать, как все, что просто часть апи спрятать, но по сути это обертка для легаси)

прям любой... хотя... в идеальном мире да.

но чот трудозатратно :)

прям любой... хотя... в идеальном мире да.

ну нет не прям любой, есть различные паттерны для отражения типичных задач, иногда нужно изменить апи наружу, иногда подмешать или заменить логику

Чего?

ты не HR?

говоришь также

ну нет не прям любой, есть различные паттерны для отражения типичных задач, иногда нужно изменить апи наружу, иногда подмешать или заменить логику

что ты имеешь в виду под апи

внутреннее апи для соседских компонентов?

что ты имеешь в виду под апи

часть доступная пользователю твоего кода, вот даже не знаю, какой пример приводить... есть паттерны, помогающие определять состояние объекта по умолчанию определяя значение, делать снапшот или восстанавливать состояние объекта, инкапсулировать команды и передавать запросы через цепочку классов, это довольно частые задачи

просто паттерны -это проверенные способы решать типичные задачи, их не нужно везде пихать, но их нужно знать, чтобы на основе их уже строить свое решение, не обязательно реализовать по книжке, важно понимать downsides и использовать нужное

можно сказать, что это достаточная практика работы на том языке, и в той сфере, где ты претендуешь на сеньера?

можно сказать, что это достаточная практика работы на том языке, и в той сфере, где ты претендуешь на сеньера?

нет, но мы изначально кажется о разном. Вот смотри чем инженер отличается от любителя? Инженер понимает стоимость принятых им решений

как ты можешь говорить о том, что твое решение (даже если ты используешь его 10 лет) достаточно эффективно, если ты не знаешь, как его решали 20 лет до тебя в системах используемых в крупнейших продуктах?

как ты можешь говорить о том, что твоя задача решена, пока твой код не прошел ревью?

Разные же инженеры есть. Есть технологи, есть конструкторы.

Разные же инженеры есть. Есть технологи, есть конструкторы.

не имеет значение, инженер должен понимать стоимость принятого решения, иначе это не инженер

просто выражение стоимости меняется, это разные метрики

Ну вот если взять проще. Допустим инженер-технолог металлургических процессов пускай. Один всю жизнь успещно занимается автомобилестроением, а другой танками

при базовом образовании одинаковом, абсолютно разные ценности

и знания

и стоимость решений

и один второго не заменит, хотя в начале пути, они могли друг друга заменить (пока были ждунами)

но и понятно, что без базового образования с металлом работать нельзя

Ну вот если взять проще. Допустим инженер-технолог металлургических процессов пускай. Один всю жизнь успещно занимается автомобилестроением, а другой танками

не имеет значения тип метрики, важно ее наличие. Ты не можешь сказать, что твое решение решило задачу, если ты не понимаешь как задача решиться с помощью паттерна поскольку этот паттерн учитывает опыт поколений разработчиков столкнувшихся с проблемами о которых ты даже не слышал

но и понятно, что без базового образования с металлом работать нельзя

они оба знают стоимость принятого решения, не важно в чем она выражается, важно, что они способны произвести оценку на основе объективных критериев понимая эффективность использования элементов системы. И не важно люди этот элемент или материалы

Да, но они это могут на основе практики или на основе пары книг?

которые они зазубрили

в любом случа время программиста стоит дороже всего сегодня в продукте, ты должен создавать поддерживаемый код и не тратить время на изобретение велосипедов и более того код должен быть тестируемый и расширяемый, паттерны решающие классические задачи не всегда такие и нужно понимать что и где использовать, но не использовать их там, где это возможно -это уже априори усложнение продукта там, где это не нужно

Да, но они это могут на основе практики или на основе пары книг?

зазубривание паттернов тебе ничем не поможет пока ты не увидишь на реальных примерах как они используются, для этго нужно идти в комнду на большой продукт, где будет у кого учиться

Да, но они это могут на основе практики или на основе пары книг?

вот ты же понимаешь почему MVC лучше, чем держать все в одном файле?

Да, но они это могут на основе практики или на основе пары книг?

не забывай, что твоя практика -только твоя, а кто придет после тебя? ты уверен, что он поймет о чем ты?

в любом случа время программиста стоит дороже всего сегодня в продукте, ты должен создавать поддерживаемый код и не тратить время на изобретение велосипедов и более того код должен быть тестируемый и расширяемый, паттерны решающие классические задачи не всегда такие и нужно понимать что и где использовать, но не использовать их там, где это возможно -это уже априори усложнение продукта там, где это не нужно

Не согласан с началом. Время программиста ничего особо не стоит. А вот херовый код, не сам код, а вообще решение херовое (причем не обязательно велосипед), которое нужно будет поодерживать всю жизнь - это бич. Олд бич.

вот ты же понимаешь почему MVC лучше, чем держать все в одном файле?

все понимаю, скзаать не могу и когда читаю об этом - зачастую думаю - омайгад, омайгад, что он несет. * некоторых авторов

Не согласан с началом. Время программиста ничего особо не стоит. А вот херовый код, не сам код, а вообще решение херовое (причем не обязательно велосипед), которое нужно будет поодерживать всю жизнь - это бич. Олд бич.

ну вот так получается в реальности, что время программиста -это очень дорогой ресурс и одна из самый больших статей расхода и потому принципиально важно использовать его эффективно.

все понимаю, скзаать не могу и когда читаю об этом - зачастую думаю - омайгад, омайгад, что он несет. * некоторых авторов

да но ты же используешь фреймворк? как ты думаешь на сколько усложнилась бы миграция между ларавель и симфони, если бы вместо MVC каждый использовал свой велосипед? а если пойти глубже и DI был бы реализован иначе предоставляя другое api

ну вот так получается в реальности, что время программиста -это очень дорогой ресурс и одна из самый больших статей расхода и потому принципиально важно использовать его эффективно.

в действующем проекте пхпшника, время прогграммиста не стоит нихрена, время простоя - генерирует убытки. Это тоже самое что взять в автобусный парк китайские автобусы. У нас в Питере пробывали. В итоге разорились (бы, если бы не бездонный карман государства), а автобусы уже лет 10 гниют у всех на виду

да но ты же используешь фреймворк? как ты думаешь на сколько усложнилась бы миграция между ларавель и симфони, если бы вместо MVC каждый использовал свой велосипед? а если пойти глубже и DI был бы реализован иначе предоставляя другое api

ну тут патерны тоже нужно понимать по одному тот же симфони не MVC же да и само MVC как то не особо верно применяется в PHP по самой трактовке патерна

в действующем проекте пхпшника, время прогграммиста не стоит нихрена, время простоя - генерирует убытки. Это тоже самое что взять в автобусный парк китайские автобусы. У нас в Питере пробывали. В итоге разорились (бы, если бы не бездонный карман государства), а автобусы уже лет 10 гниют у всех на виду

продукт в котором работают те, кто ничего не стоит -не стоит ничего, поскольку эти люди ничего создать не могут. Собственно смысла вообще учитывать таких не вижу

Да даже МВЦ - только через опыт. Читать об этом бесполезно и видосики смотреть

ну тут патерны тоже нужно понимать по одному тот же симфони не MVC же да и само MVC как то не особо верно применяется в PHP по самой трактовке патерна

потому, что паттерн -это не панацея, и использовать нужно так, как будет наиболее эффективно в твоем продукте. Но важно, что общая концепция позволяет людям находить общие признаки и снижает порог входа изначально уже сглаживая кучу углов, поскольку мы принимая решение о использовании паттерна четко понимаем почему и что изменится, если к примеру модель мы разобьем на несколько слоев

Да даже МВЦ - только через опыт. Читать об этом бесполезно и видосики смотреть

хз есть база, ее нужно знать, как раз мвс, синглтон и фабричную ф-ию кажется понимать должен каждый. Там очевидна причина разделения слоя, переиспользование инстанса и инкапсуляция параметров конструктора, дальше -практика и изучение чужого кода

Да даже МВЦ - только через опыт. Читать об этом бесполезно и видосики смотреть

не использовать паттерны -это примерно как перед созданием сайта визитки брать Си и писать свой пхп...

ERROR: S client not available

хз есть база, ее нужно знать, как раз мвс, синглтон и фабричную ф-ию кажется понимать должен каждый. Там очевидна причина разделения слоя, переиспользование инстанса и инкапсуляция параметров конструктора, дальше -практика и изучение чужого кода

Изначально мы говорили, что отличает ждуна от сениора. Если база одна и таже. На мой взгляд опыт и психика, которая позволяет нормально общаться с ждунами и начальством.

потому, что паттерн -это не панацея, и использовать нужно так, как будет наиболее эффективно в твоем продукте. Но важно, что общая концепция позволяет людям находить общие признаки и снижает порог входа изначально уже сглаживая кучу углов, поскольку мы принимая решение о использовании паттерна четко понимаем почему и что изменится, если к примеру модель мы разобьем на несколько слоев

все верно, я больше про то, что зачастую люди также не всегда верно интерпретуют патерны, из-за этого становиться сложнее другим людям расбирать все ну это так, к слову

Изначально мы говорили, что отличает ждуна от сениора. Если база одна и таже. На мой взгляд опыт и психика, которая позволяет нормально общаться с ждунами и начальством.

я бы сказал скорее понимание стоимости принятого решения и альтернатив, как собственно и вообще способность это решение принять.

всетаки решения принимает не сеньер а архитектор

глобальные

хотя на практике - ждуна архитектора видел, а отдельного архитектора не видел

Изначально мы говорили, что отличает ждуна от сениора. Если база одна и таже. На мой взгляд опыт и психика, которая позволяет нормально общаться с ждунами и начальством.

просто не нужно слишком много ставить на опыт, сам по себе он ничего не стоит. Опыт должен быть подкреплен реальными знаниями, иначе никто не мешает и 20 лет делать свою работу плохо и продолжать делать ее плохо сегодня

ну успешный опыт, я же говорю.

ну то есть у конкурентов схантить надо =)

стива джобса

=)

всетаки решения принимает не сеньер а архитектор

ты упускаешь важный аспект. Даже то, как ты называешь переменную, как создаешь объект и есть решение. Сеньер понимает, стоимость решения, а значит знает что меняется, если переменная передается по ссылке или возвращая данные вместо интерфейса. Описывая код сеньер должен понимать, что произойдет и что может повлиять на изменение поведения, когда джун обычно смотрит на результат и меняет код "подгоняя" его

ты упускаешь важный аспект. Даже то, как ты называешь переменную, как создаешь объект и есть решение. Сеньер понимает, стоимость решения, а значит знает что меняется, если переменная передается по ссылке или возвращая данные вместо интерфейса. Описывая код сеньер должен понимать, что произойдет и что может повлиять на изменение поведения, когда джун обычно смотрит на результат и меняет код "подгоняя" его

Да, полностью поддержу.

но это ждун совсем ждун, кого ты описываешь

но это ждун совсем ждун, кого ты описываешь

это просто джун. Он уже знает теорию и имеет какой -то опыт, но когда код попадает в прод и под реальные нагрузки -он может только угадывать, что будет дальше)

Это звездец.

но в этом конечно суперплюч попасть в крутую команду джуном

чем сеньером в болото

"сеньером"

чем сеньером в болото

естественно, название не стоит ничего. В Сбертехе сегодня с годом опыта можно быть "ведущим" и "старшим", но мало кто из этих ребят может пройти собеседование например в Дойче банк или тот же Яндекс. задачи у них разные

*это кстати именно так практика, о которой я говорил. Когда ты джун, делаешь говно, а тебе объясняют и показывают как надо. Есть хоть какойто шанс в чем-то разобраться.

да есть команды и в стартапчиках даже, и у обычных комерсов - лидеров своих сегментов, но не супербогатых.

Это не просто практика, а подкрепленная знаниями, без развития и получения новых знаний, практика ничего не стоит

ну это и есть практика. А если ты каждый день практикуешь говнокод без улучшений - то и пару недель не продержишься

*в моей идеальной команде мечты )

ну это и есть практика. А если ты каждый день практикуешь говнокод без улучшений - то и пару недель не продержишься

Ты можешь каждый день делать интернет магазины и через 20 лет так и не пройдёшь собеседование на джуна в гугл, а можешь сделать один и прийти на чифа

ничего плохого не вижу в интернет магазинах

если это озон например

или ситилинк

ну или ещё ктото

а если это очередной интернет магазин для госпожи ИПешницы на битриксе, где надо нажать кнопку инсталл, а потом выбить с ИПшницы бабло за работу - то это и не программист

это модератор!!!