Работал в одной из компаний принадлежавших ВК. На нас так же распространялась эта история. Годовая премия правда нет.
Ничего сверхсложного в истории нет. Ничего сверхурочного тоже не предполагается. Ты работаешь в своем темпе и
1. Видишь что тебе нужно сделать по продукту (обычно это техдолг и его нужно грамотно декомпозировать на n* целей).
2. Оцениваешь задачи бизнеса базируясь на том что тебе нужно закрыть и твои (они гибче чем кажется, цеплять одно за другое так же никто не мешает).
3. Балансируешь 1 и 2.
Там ещё масса хаков на эту тему. Но первично - думать головой и иметь перспективу в своей работе над продуктом. Это как бы и есть цель практики.
И да. Мне эти приседания не нравятся от слова совсем, я привык к небольшим конторам и некоторой свободе планирования. Но для большой это вполне адекватный способ массово потыкать веточкой сотрудников которые только делают вид что соображают.
Ровно наоборот. Мы (все те кто проживает на участке суши от восточной европы до дальнего востока по долготе и от полярного круга до средней азии по широте) берем не математикой, а прикладной сферой. А еще тем что можем пояснить как эта математика живет с другим инженерным багажом. Не все правда. И чем дальше тем больше не все, потому что селекция в индустрии направлена на рекрутинг "индусов" именно по вашим заблуждениям. Которые выдают полное непонимание и самой индустрии и людей которые там работают.
Вы видели хоть когда-нибудь код этих "индусов"? Типовой индус настроен на гугл-лайк собес, и не тренирует ничего кроме этого навыка. Алгоритмы, структуры данных, паттерны проектирования, языковые конструкции. Всё на пятерку. На практике же - хранение пересоздаваемого контекста в синглтоне и "я не понимаю что не так".
Я с большим умилением слушаю как собеседуемый привязывает принципы солид к своему опыту, приводя конкретные примеры из реализованных проектов, даже если мне приходится подсказывать что там за очередной буквой. Это показывает что он их осмыслил, а не зазубрил. И мне вообще неинтересно как он переложит жейсон, или байтики в задачке которая формализована до уровня применения алгоритмов. По факту у меня нет таких задач. И у него не будет. Собственно это я и вижу в статье - ищите человека по тем критериям которые нужны для его вакансии. Спрашивайте его о том что ему придется делать. Это единственно правильный подход. Я и сам именно так веду собеседования и когда их прохожу то стараюсь не слить и переживаю именно за те которые прошли не по методичкам для олимпиадников. Потому что с людьми которые подходят к собесам столь формально я банально не сработаюсь.
Реальность же индустрии такова, что написав куб вы не навредите проекту так как навредите ему не продумав апи своего очередного модуля. Или выстроите взаимодействие слоев так что заложите бомбу под дальнейшее сопровождение. Если уж вас так волнует будет ли человек писать кубы и квадраты - пусть он вам расскажет что это такое. А потом спросите ейчара понятно ли ему. Заодно проверите навык донесения технической мысли до будущего ПО у которого понимания той самой технической мысли примерно столько же сколько у HR, а планировать надо опираясь на разного уровня невнятности бормотание разработчика.
Касаемо вк и прочих спешал олимпикс - погуглите "чат активити" телеги. Этот мем в дроид-разработке давно стал классикой.
От евентбаса в мобильной разработке отказались уже лет эдак 8 назад. Именно как от концепта общей шины. И именно на больших и сложных проектах. Все дело в том, что при достаточно большом количестве гоняемых данных может возникнуть необходимость по-разному обходиться с backpressure, иметь разнообразные (горячие и холодные) стримы (а шина всегда горячая), а так же (что неактуально для дарта) исполнять обработчики цепочек на разных тредпулах. Плюс отлаживать на общей трубе крайне мерзко, потому что правило единого эмиттера конвенциональное, а не контролируется компилятором. Честно-честно, я приходил на проекты с евентбасом и это боль.
Отказались в пользу реактивных стримов на источниках конкретных типизированных данных. Обычно это библиотека "rx[Вставьте свой любимый язык]". RxDart в том числе. То что вы написали называется в rx-терминах PublishSubject (если передвинуть дженерик наверх в сам класс), правда урезанный, обычно у него есть буфер и стратегии поведения при переполнении буфера (backpressure strategy) есть еще один - с фиксированным и обязательно заполненным (seeded) буфером размером в 1, он называется BehaviorSubject и чертовски подходит как раз для UI-стейта в bloc и других разных MV*. Или для выноса в репозиторий.
Таким образом нашим сопричастным к счетчику кубитам остается только дернуть метод репо для инкремента счетчика и подписаться на типизированный стрим счетчика, отдаваемый репозиторием. Иногда потребителю нужны многие стримы и композить их в единый ивент можно при помощи разных combine/merge.
От самого Rx в нативном дроиде тоже отказались в пользу котлиновских Flow, но это уже другая история, тем более что у нас тут дарт. Можно пользоваться или не пользоваться rx, сами стримы в дарте достаточно мощные, но вот использовать именно EventBus я бы крайне не рекомендовал.
Интересный тренд. Большие ребята кинулись строчить о найме с человеческим лицом. Хотя все знают что у больших ребят процессы найма далеки от человеческого лица. Что у вас случилось-то? :) Хотя это все тоже знают. Осталось врубиться что делать вид осознанного выбора это не совсем то же что делать выбор осознанно.
С ентити не особо понял вашу мысль. Ядро у нас это доменные интерфейсы, сигнатуры его методов в хорошей архитектуре всегда зависят от сущностей и более ни от чего. Сущности же не зависят ни от чего вообще. Пользуясь вашей аналогией, если в вашей системе появится сущность бигмака - она появится и в ядре (надеюсь я верно уловил аналогию). В фудтехе, раз уж мы про еду, это обычно блюдо, наследуемое от товара, который в свою очередь наследует какую-нить "позицию", если там появдяется например "услуга", то у нее появятся свои специфические бизнес-кейсы и она так же унаследует позицию, чтобы посредством общих кейсов для позиции например оказаться в чеке.
Насчет ультимативности - мне например не нравится такое деление. И такая терминология. И тут я отдаю себе отчет что это вкусовщина. Мне как раз и не нравится что нет допуска вкусовщине в рамках фундаментальный принципов. Помните VIPER? Был еще шуточный репозиторий на гитхабе с его перефразом. История его зашла в тупик довольно быстро. Сам по себе подход ок. Но это конкретная имплементация некоторых принципов для конкретного случая. Мир куда разнообразнее и строить архитектуру и инфраструктуру проекта надо с оглядкой на совсем не технические факторы. Тут даже дело не в бигтехе, точнее не совсем в нем. Супераппом станет дай бог 1% приложений, 99% не дорастут даже до объема в 300K строк. Из них еще меньше дорастет до своего объема не за счет богатого домена, а не бесконечного дублирования презентационных фич с вариациями. Опять же из-за плохой структурированности GUI. Вследствие отсутствия ресурсов на подготовку собственного юай-кита и плохой продуктовой проработки. Видите: одно за другое, одно за другое.
Тут и упомянутый плохой архитектурный контроль вылезет. И приходим мы на проект чаще всего не на начальной стадии, а когда эти детские болезни развиваются в патологию. То есть особенности принятых решений вносят существенное время в реализацию не только новых фич, но и в стабилизацию старых. И тут нельзя просто взять схему и все пересобрать. Берется что есть, это "что есть" рефакторится по чистым фундаментальным вещам. И уже после этого этапа можно работать с архитектурой. Но. Это. Все. Очень. Дорого. И тут я за 20 лет практики рецепта не придумал. Если вы думаете что ваша ультимативность поможет проекту лет через пять, уже без вас, не упасть в эту яму - вы заблуждаетесь. Максимум - его не успеют слишком уж изуродовать до тех пор пока он не перейдет под контроль к хорошему лиду.
Насчет модулей примерно те же возражения - я видел как вы выражаетесь "монолиты" которые более приспособлены для разделения на модули нежели изначально многомодульные приложения которым имеет смысл такими быть. Хотя "монолиты" вовсе из другой оперы. Сервисы в бекенде это по своей сути отдельные приложения, выполняющие свои узконаправленные функции, а не какие-то там библиотеки, которые компонуются в одно. В общем случае монолитный сервис бека может быть так же попилен на модули. И собираться в монолит, который фиг попилишь на отдельные. Так что, опять же, терминологическая путаница нас тут поджидает. Но в целом хорошо что мы сходимся в целях модульности.
А претензий у меня на самом деле нет. У вас есть свое мнение и какое-то видение. У меня есть свое. Я тут ради подискутировать на досуге.
ага-ага, и главное при этом пишется всегда красиво про то что "нужна не энциклопедия", с которой мы спросим как с большого энциклопедического словаря
я проводил собеседований больше чем их проходил и неподсознательно знаю что если ты человека заслушался - надо его попробовать, а вот если не заслушался, то будь он хоть трижды бестящим в "базе", то в автономе он сдуется почти сразу
первое при этом может не сработать, но второе сработает всегда, однако логика собесов на 99% за энциклопедию
а еще мы ж все помним что навык прохождения технических собеседований это асболютно отдельная дисциплина, отличная от навыков нужных в работе и не все готовы ее дрессировать в ущерб работе, слава богу, нафига мне заряженные на собесовские задачки роботы, не умеющие думать и искать
так что пока кто-то стартельно упражняется в дисциплине "мне мало было экзаменов в универе, теперь я принес эту срань в кадровую политику", вменяемые собеседующие щупают релевантность опыта конкретной позиции, птушта есть ключевые навыки, а есть те которые мы сами приобретали в процессе нового проекта с чистого листа и мы про это помним
Есть правила клин, есть правила солид, еще теперь эти правила которые те же яйца только сбоку. И в которых, кстати, упущена судьба ентити. Про направление есть, а про ентити нет - а ведь это важная деталь об которую и ломаются, собственно, эти направления.
Ну то есть ты говоришь человеку что интерфейс репозитория это доменная сущность, и он отдает доменный же ентити, которые не могут иметь зависимостей от аннотаций его ORM/Serializer, а он прикидывает сколько ему делать конвертеров для DTO/DBO и не делает буквально только для этого. А потом вместо него приходит еще один и начинает использовать имеющуюся зависимость и в хвост и в гриву, хотя для одного автора такой подход был допустимым. И будет допустимым в проекте с небольшим или однообразным доменом и жесткой конвенцией. Но у тебя текучка, слабый архитектурный контроль и все накрывается одним местом.
А так конечно неплохой пример имплементации клина для внутренних конвенций конкретного проекта. Несколько царапают глаз ультимативные заявления, потому что можно эту схему переколбасить десятком способов не нарушая ни самого клина, ни заявленных дополнительных правил. Есть, например, чудесные комбайны которые делают BLoC, причем не как ui-стейт-менеджмент, а вполне себе подходящим для доменного уровня образом. Да и еще много чего есть.
Ну и на вкусненькое мое любимое - разбиение на модули не предназначено для ускорения сборки проекта. То есть это не значит что оно не может ускорить. Но оно не для этого. В реальной жизни почти всегда накладных расходов на градл наваливается столько, что выигрыш от распараллеливания сборки модулей съедает весь профит. Максимум
Вообще эта легенда родилась у незатейливых слушателей на конференциях, где докладчики из бигтеха, вынужденные пользоваться разбиением в инфраструктурных целях, сталкиваются с тем что градл у них немножечко умирает от тысяч модулей. И они начинают уже эту проблему решать. А после гордо несут ее на конференцию, неосмотрительно назвав доклад "как я ускорил сборку проекта разбив его на модули", хотя это, мягко говоря, не совсем так. Сначала мы родили проблему разбиением, потом переразбили, частично решив проблему. За кадром как обычно самое главное - жирнющие монорепы на всю линейку продуктов, необходимость структурирования кода для нескольких автономных команд в десятки человек и прочие инфраструктурные фокусы. Не у всех, но как правило. Обычно говорят о том как правильно разбивать, а не о том зачем.
Сколько языков вы знаете, поддерживающих одновременно и сильную и статическую? Я вот всего два. И только один практикую. В упомянутой жабе - типизация статическая, но слабая. Однако автобрекетинг и прочее неявное приведение не делает ее менее пригодной для промышленного применения чем сильные но динамические пхп и жс, а выведения у нее появились для тех кто не залип на мобайле (>1.8).
Так вот собственно вопрос. Что именно вы все-таки будете защищать до последнего? Явные типы в компайл-тайме или отсутствие неявных приведений? Потому что оба двое - редкое явление.
Работал в одной из компаний принадлежавших ВК. На нас так же распространялась эта история. Годовая премия правда нет.
Ничего сверхсложного в истории нет. Ничего сверхурочного тоже не предполагается. Ты работаешь в своем темпе и
1. Видишь что тебе нужно сделать по продукту (обычно это техдолг и его нужно грамотно декомпозировать на n* целей).
2. Оцениваешь задачи бизнеса базируясь на том что тебе нужно закрыть и твои (они гибче чем кажется, цеплять одно за другое так же никто не мешает).
3. Балансируешь 1 и 2.
Там ещё масса хаков на эту тему. Но первично - думать головой и иметь перспективу в своей работе над продуктом. Это как бы и есть цель практики.
И да. Мне эти приседания не нравятся от слова совсем, я привык к небольшим конторам и некоторой свободе планирования. Но для большой это вполне адекватный способ массово потыкать веточкой сотрудников которые только делают вид что соображают.
Хосподи какой порожняк
Ровно наоборот. Мы (все те кто проживает на участке суши от восточной европы до дальнего востока по долготе и от полярного круга до средней азии по широте) берем не математикой, а прикладной сферой. А еще тем что можем пояснить как эта математика живет с другим инженерным багажом. Не все правда. И чем дальше тем больше не все, потому что селекция в индустрии направлена на рекрутинг "индусов" именно по вашим заблуждениям. Которые выдают полное непонимание и самой индустрии и людей которые там работают.
Вы видели хоть когда-нибудь код этих "индусов"? Типовой индус настроен на гугл-лайк собес, и не тренирует ничего кроме этого навыка. Алгоритмы, структуры данных, паттерны проектирования, языковые конструкции. Всё на пятерку. На практике же - хранение пересоздаваемого контекста в синглтоне и "я не понимаю что не так".
Я с большим умилением слушаю как собеседуемый привязывает принципы солид к своему опыту, приводя конкретные примеры из реализованных проектов, даже если мне приходится подсказывать что там за очередной буквой. Это показывает что он их осмыслил, а не зазубрил. И мне вообще неинтересно как он переложит жейсон, или байтики в задачке которая формализована до уровня применения алгоритмов. По факту у меня нет таких задач. И у него не будет. Собственно это я и вижу в статье - ищите человека по тем критериям которые нужны для его вакансии. Спрашивайте его о том что ему придется делать. Это единственно правильный подход. Я и сам именно так веду собеседования и когда их прохожу то стараюсь не слить и переживаю именно за те которые прошли не по методичкам для олимпиадников. Потому что с людьми которые подходят к собесам столь формально я банально не сработаюсь.
Реальность же индустрии такова, что написав куб вы не навредите проекту так как навредите ему не продумав апи своего очередного модуля. Или выстроите взаимодействие слоев так что заложите бомбу под дальнейшее сопровождение. Если уж вас так волнует будет ли человек писать кубы и квадраты - пусть он вам расскажет что это такое. А потом спросите ейчара понятно ли ему. Заодно проверите навык донесения технической мысли до будущего ПО у которого понимания той самой технической мысли примерно столько же сколько у HR, а планировать надо опираясь на разного уровня невнятности бормотание разработчика.
Касаемо вк и прочих спешал олимпикс - погуглите "чат активити" телеги. Этот мем в дроид-разработке давно стал классикой.
От евентбаса в мобильной разработке отказались уже лет эдак 8 назад. Именно как от концепта общей шины. И именно на больших и сложных проектах. Все дело в том, что при достаточно большом количестве гоняемых данных может возникнуть необходимость по-разному обходиться с backpressure, иметь разнообразные (горячие и холодные) стримы (а шина всегда горячая), а так же (что неактуально для дарта) исполнять обработчики цепочек на разных тредпулах. Плюс отлаживать на общей трубе крайне мерзко, потому что правило единого эмиттера конвенциональное, а не контролируется компилятором. Честно-честно, я приходил на проекты с евентбасом и это боль.
Отказались в пользу реактивных стримов на источниках конкретных типизированных данных. Обычно это библиотека "rx[Вставьте свой любимый язык]". RxDart в том числе. То что вы написали называется в rx-терминах PublishSubject (если передвинуть дженерик наверх в сам класс), правда урезанный, обычно у него есть буфер и стратегии поведения при переполнении буфера (backpressure strategy) есть еще один - с фиксированным и обязательно заполненным (seeded) буфером размером в 1, он называется BehaviorSubject и чертовски подходит как раз для UI-стейта в bloc и других разных MV*. Или для выноса в репозиторий.
Таким образом нашим сопричастным к счетчику кубитам остается только дернуть метод репо для инкремента счетчика и подписаться на типизированный стрим счетчика, отдаваемый репозиторием. Иногда потребителю нужны многие стримы и композить их в единый ивент можно при помощи разных combine/merge.
От самого Rx в нативном дроиде тоже отказались в пользу котлиновских Flow, но это уже другая история, тем более что у нас тут дарт. Можно пользоваться или не пользоваться rx, сами стримы в дарте достаточно мощные, но вот использовать именно EventBus я бы крайне не рекомендовал.
Интересный тренд. Большие ребята кинулись строчить о найме с человеческим лицом. Хотя все знают что у больших ребят процессы найма далеки от человеческого лица. Что у вас случилось-то? :) Хотя это все тоже знают. Осталось врубиться что делать вид осознанного выбора это не совсем то же что делать выбор осознанно.
С ентити не особо понял вашу мысль. Ядро у нас это доменные интерфейсы, сигнатуры его методов в хорошей архитектуре всегда зависят от сущностей и более ни от чего. Сущности же не зависят ни от чего вообще. Пользуясь вашей аналогией, если в вашей системе появится сущность бигмака - она появится и в ядре (надеюсь я верно уловил аналогию). В фудтехе, раз уж мы про еду, это обычно блюдо, наследуемое от товара, который в свою очередь наследует какую-нить "позицию", если там появдяется например "услуга", то у нее появятся свои специфические бизнес-кейсы и она так же унаследует позицию, чтобы посредством общих кейсов для позиции например оказаться в чеке.
Насчет ультимативности - мне например не нравится такое деление. И такая терминология. И тут я отдаю себе отчет что это вкусовщина. Мне как раз и не нравится что нет допуска вкусовщине в рамках фундаментальный принципов. Помните VIPER? Был еще шуточный репозиторий на гитхабе с его перефразом. История его зашла в тупик довольно быстро. Сам по себе подход ок. Но это конкретная имплементация некоторых принципов для конкретного случая. Мир куда разнообразнее и строить архитектуру и инфраструктуру проекта надо с оглядкой на совсем не технические факторы. Тут даже дело не в бигтехе, точнее не совсем в нем. Супераппом станет дай бог 1% приложений, 99% не дорастут даже до объема в 300K строк. Из них еще меньше дорастет до своего объема не за счет богатого домена, а не бесконечного дублирования презентационных фич с вариациями. Опять же из-за плохой структурированности GUI. Вследствие отсутствия ресурсов на подготовку собственного юай-кита и плохой продуктовой проработки. Видите: одно за другое, одно за другое.
Тут и упомянутый плохой архитектурный контроль вылезет. И приходим мы на проект чаще всего не на начальной стадии, а когда эти детские болезни развиваются в патологию. То есть особенности принятых решений вносят существенное время в реализацию не только новых фич, но и в стабилизацию старых. И тут нельзя просто взять схему и все пересобрать. Берется что есть, это "что есть" рефакторится по чистым фундаментальным вещам. И уже после этого этапа можно работать с архитектурой. Но. Это. Все. Очень. Дорого. И тут я за 20 лет практики рецепта не придумал. Если вы думаете что ваша ультимативность поможет проекту лет через пять, уже без вас, не упасть в эту яму - вы заблуждаетесь. Максимум - его не успеют слишком уж изуродовать до тех пор пока он не перейдет под контроль к хорошему лиду.
Насчет модулей примерно те же возражения - я видел как вы выражаетесь "монолиты" которые более приспособлены для разделения на модули нежели изначально многомодульные приложения которым имеет смысл такими быть. Хотя "монолиты" вовсе из другой оперы. Сервисы в бекенде это по своей сути отдельные приложения, выполняющие свои узконаправленные функции, а не какие-то там библиотеки, которые компонуются в одно. В общем случае монолитный сервис бека может быть так же попилен на модули. И собираться в монолит, который фиг попилишь на отдельные. Так что, опять же, терминологическая путаница нас тут поджидает. Но в целом хорошо что мы сходимся в целях модульности.
А претензий у меня на самом деле нет. У вас есть свое мнение и какое-то видение. У меня есть свое. Я тут ради подискутировать на досуге.
А можно просто bloc взять, как любой мобильный разработчик
ага-ага, и главное при этом пишется всегда красиво про то что "нужна не энциклопедия", с которой мы спросим как с большого энциклопедического словаря
я проводил собеседований больше чем их проходил и неподсознательно знаю что если ты человека заслушался - надо его попробовать, а вот если не заслушался, то будь он хоть трижды бестящим в "базе", то в автономе он сдуется почти сразу
первое при этом может не сработать, но второе сработает всегда, однако логика собесов на 99% за энциклопедию
а еще мы ж все помним что навык прохождения технических собеседований это асболютно отдельная дисциплина, отличная от навыков нужных в работе и не все готовы ее дрессировать в ущерб работе, слава богу, нафига мне заряженные на собесовские задачки роботы, не умеющие думать и искать
так что пока кто-то стартельно упражняется в дисциплине "мне мало было экзаменов в универе, теперь я принес эту срань в кадровую политику", вменяемые собеседующие щупают релевантность опыта конкретной позиции, птушта есть ключевые навыки, а есть те которые мы сами приобретали в процессе нового проекта с чистого листа и мы про это помним
Есть правила клин, есть правила солид, еще теперь эти правила которые те же яйца только сбоку. И в которых, кстати, упущена судьба ентити. Про направление есть, а про ентити нет - а ведь это важная деталь об которую и ломаются, собственно, эти направления.
Ну то есть ты говоришь человеку что интерфейс репозитория это доменная сущность, и он отдает доменный же ентити, которые не могут иметь зависимостей от аннотаций его ORM/Serializer, а он прикидывает сколько ему делать конвертеров для DTO/DBO и не делает буквально только для этого. А потом вместо него приходит еще один и начинает использовать имеющуюся зависимость и в хвост и в гриву, хотя для одного автора такой подход был допустимым. И будет допустимым в проекте с небольшим или однообразным доменом и жесткой конвенцией. Но у тебя текучка, слабый архитектурный контроль и все накрывается одним местом.
А так конечно неплохой пример имплементации клина для внутренних конвенций конкретного проекта. Несколько царапают глаз ультимативные заявления, потому что можно эту схему переколбасить десятком способов не нарушая ни самого клина, ни заявленных дополнительных правил. Есть, например, чудесные комбайны которые делают BLoC, причем не как ui-стейт-менеджмент, а вполне себе подходящим для доменного уровня образом. Да и еще много чего есть.
Ну и на вкусненькое мое любимое - разбиение на модули не предназначено для ускорения сборки проекта. То есть это не значит что оно не может ускорить. Но оно не для этого. В реальной жизни почти всегда накладных расходов на градл наваливается столько, что выигрыш от распараллеливания сборки модулей съедает весь профит. Максимум
Вообще эта легенда родилась у незатейливых слушателей на конференциях, где докладчики из бигтеха, вынужденные пользоваться разбиением в инфраструктурных целях, сталкиваются с тем что градл у них немножечко умирает от тысяч модулей. И они начинают уже эту проблему решать. А после гордо несут ее на конференцию, неосмотрительно назвав доклад "как я ускорил сборку проекта разбив его на модули", хотя это, мягко говоря, не совсем так. Сначала мы родили проблему разбиением, потом переразбили, частично решив проблему. За кадром как обычно самое главное - жирнющие монорепы на всю линейку продуктов, необходимость структурирования кода для нескольких автономных команд в десятки человек и прочие инфраструктурные фокусы. Не у всех, но как правило. Обычно говорят о том как правильно разбивать, а не о том зачем.
Сколько языков вы знаете, поддерживающих одновременно и сильную и статическую? Я вот всего два. И только один практикую. В упомянутой жабе - типизация статическая, но слабая. Однако автобрекетинг и прочее неявное приведение не делает ее менее пригодной для промышленного применения чем сильные но динамические пхп и жс, а выведения у нее появились для тех кто не залип на мобайле (>1.8).
Так вот собственно вопрос. Что именно вы все-таки будете защищать до последнего? Явные типы в компайл-тайме или отсутствие неявных приведений? Потому что оба двое - редкое явление.