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

Или объясняли, почему бутерброд падает маслом вниз?

Или как понять женщину?

Или как понять женщину?

никак

ну ты посмотри что-нибудь из этого

https://vimeo.com/ontico/videos

Рассказывали о тех вещах, о которых людям интересно было послушать

Рассказывали о тех вещах, о которых людям интересно было послушать

Я согласен. Никто не критикует

Но просто мне интересно было, о чем там

Может там собрались мастера мира

И рассказывали почему и как что-то сделали в своем продукте

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

эти на seo форумах сидят и на конференциях для стартаперов

Но просто мне интересно было, о чем там

Выкладывали расписание же раз сто. Может меньше. http://www.highload.ru/2016/schedule.html

"паттернами не надо увлекаться" для меня - это "виноград зелен"

хм... а что у тебя с зеленым виноградом?

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

Обычно это период когда он как раз только выучил эти паттерны

я не понимаю, как это "делать по паттернам", делать "не по паттернам"....

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

Решение проблемы не бинарное, иногда паттерн решает 10% проблемы

И тогда "по паттернам" - это применить его, а "не по паттернам" - проигнорировать

проблема - это что? бизнес проблема, проблема оформления кода, проблема организации кода, проблема тестирования? ;))

бизнес-проблема скорее

Паттерны никогда не были направлены на решение бизнес проблем

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

Ну вот пример, нужно тебе написать скрипт сортировки файлов в 15 строк, ты берешь, подключаешь DI контейнер, парсер yml конфига - в нем параметр по какому алгоритму сортировать, делаешь интерфейс Sorter, фабрику которая генерит эти сортеры. Пишешь 1 сортер, прогоняешь его на своей задаче, скрипт удаляешь :)

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

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

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

Ага, такими вот поделиями и засраны все гисты XD

Ну варинат не хуже твоего примера, такой же абстрактный ;)

Но в общем тогда уж следует говорить о применении паттернов в отрыве от решения проблем.

Такие ситуации в общем то и есть суть деятельности программиста. Решить какие паттерны более подходят а какие менее - и есть то на что он тратит время

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

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

а по каким он паттернам и почему говно?

Короче это нерешаемый спор :) очень сильно зависит от контекста, и как правило круче тот кто умеет лучше угадать будущее.

Ну если мне за год вперед за поддержку и развитие скрипта по сортировке файлов... то будущее очевидно ;)

Вот кстати код в проекте, построенном на command bus и хексагональной архитектуре, на первый взгляд кажется совершенно рандомным месивом из паттернов. И только на больших объемах он себя оправдывает.

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

Вот кстати код в проекте, построенном на command bus и хексагональной архитектуре, на первый взгляд кажется совершенно рандомным месивом из паттернов. И только на больших объемах он себя оправдывает.

есть люди способные разобраться архитектурой за день?

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

Ну тут да, не заметил, что тот методо private... а так можно было предположить о переопределении

есть люди способные разобраться архитектурой за день?

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

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

Но в общем и про паттерны ты прав "хз какие". Так зачем проводить этот код "про паттерны". Это скорее пример, почему они полезны, чем нет ;)

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

И про метод setWriter сложно говорить. Может этот интерфейс еще где-то используется. Опять же, тестировать это легко и счастливо, чем офигивать от захардоренных врайтов

просто нужно понимать что некоторые паттерны появились из-за особенностей языка для которого этот паттерн делался. не нужно делать из php java. в java нельзя new $foo сделать.

например?

new $foo? Счастливого рефакторинга ;)

Фабрики и создатели - они вообще-то не о том, что new $foo нельзя сделать

new $foo? Счастливого рефакторинга ;)

когда увидешь классы вида Document_FactoryCollection_ByFullName для выполнения запроса where fullname = ? тебе будет не до рефакторинга :)

Фабрики и создатели - они вообще-то не о том, что new $foo нельзя сделать

я про злоупотребление паттернами, а не про то что они совсем не нужны

Не следует путать использование и даже злоупотребление паттернов с говнокодом без паттернов ;) Слово Factory в названии класса еще ничего не говорит

Но мне все же про виноград интересно... причем тут зеленый виноград

new $foo? Счастливого рефакторинга ;)

Но рефакторинг не всегда нужен

Ты рассматриваешь видимо только коммерческие проекты с длительным циклом поддержки, в таких да нужен

Павел, рефакторинг никогда не нужен... вплоть до того момента, когда он становится нужен ;)

Хз, я вот даже свой ansible конфиг для вагранта рефакторю переодически ;)

А это может быть какая-нибудь ниндзя-библиотека размером в килобайт, которая никогда не рефакторится и там new $foo помогает сэкономить 0.5кб кода

Но когда рефакторинг становится нужен - уже поздно пить боржоми... Вот у меня один юниор тоже не думал про рефакторинг, когда назвал свой кастомный класс валидатора в Yii просто и незатейлево class Validator, а я это по болезни упустил... потом были счастливые часы рефакторинга, ибо Validator:class тогда еще не было, да и не уверен, что он бы его использовал,если бы было ;)

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

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

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

Так рефакторинг как раз о том, что бы об именовании не спорить ;) А что бы потом отрефакторить ;)

Ну мы проводили рефакторинг регулярно

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

На это все время и потратили в итоге.

Знаешь, тут есть вторая сторона медали. Когда через пол года ты приходишь и говоришь - а теперь мне нужно еще пол года, что бы все переписать. И отгадай, куда и какими словами тебя посылают. О "понимающих заказчиках", что тут dypa рассуждал - это так, скорее миф ;) Исключение

> нужно еще пол года, что бы все переписать. У нас кстати в итоге так и вышло. Мы развивали систему не в ту сторону.

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

Получилось как раз очень крутая инфраструктурная часть по паттернам, все на ансибле и с oauth авторизацией, а предметная область убогая и ненужная пользователям

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

Ну вот в больших проектах это суровая реальность. Баду только так и живет.

> нужно еще пол года, что бы все переписать. У нас кстати в итоге так и вышло. Мы развивали систему не в ту сторону.

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

И такое ощущение что это даже не компетентность конкретной команды, а вселенский закон.

Ну вот в больших проектах это суровая реальность. Баду только так и живет.

Ну они это делают осозанно, вкладывают в тестирование и не так все и плохо, на самом деле

А могли бы все делать по паттернам и в конце концов разориться

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

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

Потому что я собирал всю эту инфу по крупицам и отзывам

Ну, скажем, фишер тоже "отсюда", но ему уже не интересно в формах трепаться ;)

Знаешь, тут есть вторая сторона медали. Когда через пол года ты приходишь и говоришь - а теперь мне нужно еще пол года, что бы все переписать. И отгадай, куда и какими словами тебя посылают. О "понимающих заказчиках", что тут dypa рассуждал - это так, скорее миф ;) Исключение

дело не только в заказчике, я же говорил что ему нужно это продать правильно. причем экономит заказчик очень не плохо.

axure знаешь как хорошо заходит? при этом ни строчки кода не пишется.

А кто такой заказчик? ;) Понимашь, это хорошо, когда на против тебя заказчик - владелец бизнеса с кошельком. А если это - технический директор у которого есть план, бюджет и ничего больше?

Это ему придется объяснять совету директоров, почему следует в этом году потратить столько же на готовый сайт, что и при его создании. А зачем ему это надо? Все, тупик.

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

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

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

Не стоит увлекаться проектированием на абстрактное будушее, оставляя необходимый минимум, что подсказывает опыт. А паттерны тут непричем ;)

Отвлеку вас. В соседнем чате ищем решение в один цикл - может здесь кто найдет Есть массив range(1,9), есть список операций + - / * Задача - вывести результаты арифм.действий чисел массива между парно. То есть для массива [1, 2, 3] ответ: 1 + 1 = 2 1 + 2 = 3 .... 1 * 1 = 1 ... 1 / 1 = 1 ... 1 - 1 = 0

Похоже на обычную задачу находжения перестановок

то есть 12 вариантов получается?

Задача - попробовать решить в 1 цикл

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

А что из этих параметров вариативно? Набор операций и набор чисел?

набор чисел

операции постоянны

то есть 12 вариантов получается?

не. 36 же вроде? после 1 + 3= 4, пойдет 2 + 1 =3, 2+2=4...

то есть это еще и выборка с возвращением :)

Наверное )

array_* (filter, map, walk...) - это считается за цикл