вполне эффективны были много лет и сейчас вполне себе работают ситуативно и в другой форме и не надо на свой счет все принимать, этот комент в другой ветке и к вам отношения не имеет
Как раз таки были. За редким исключением. Спич про то что люди путают божий дар с яичницей, а гуманизм со здравым смыслом. И уж точно не стоит принимать за чистую монету переводные маркетинговые статьи об импортном бигтехе. Мне тут недавно один чувак подсовывал статью про гугл и "особый склад ума" который выявляется их подходом к собесам. Оч смешно, учитывая что я лично знаю нескольких людей оттуда и они весьма скептически настроены в отношении этих восторженных соплей. Везде люди как люди.
И знаете еще что? Заметил что коллеги часто кичатся своими аналитическими способностями и критичным взглядом на вещи. Но именно среди коллег процветает махровейший догматизм. Копни - аж страшно.
Ну я лично вижу подмену понятий на этапе постановки задачи. Мы с самого начала окрестили гуманным подходом ситуацию когда нет переработок например. И на этом как бы все, как модель ни крути мы уже вынесли за скобки соображения гуманности назначив им наличие по умолчанию. А их может и не было. Как в армии. Не сменил постового - тот заснул, проспал диверсию. Вздрючат тебя. Вот прям не сомневайся. Поэтому ты меняешь, но где тут гуманизм?
Я оспариваю выводы о гуманизме. Внезапно оказалось что у талантливого организатора процессов работники не рабы. Как бы "причина<=>следствие". Оптику при анализе надо менять и лучше всего не один раз. А то можно попасть в неудобное положение. Взяли постулат и носимся с ним показывая корреляцию. Корреляцию нашли, а о ее источнике не позаботились. Вот же ж блин, да?
Исследования предназначены подтвердить или опровергнуть точку зрения. Но человек слаб. Так что исследуя что-то он непроизвольно склоняется в пользу фактов которые подтверждают изначальное мнение. Крайне малый процент людей способен пересмотреть точку зрения в результате исследования, или же вовсе сменить парадигму (об этом тоже, лол, много исследований). Для этого надо признать что ошибаешься. Или что построил теоретическую модель не в той парадигме. Фактически человек так устроен что всегда ищет подтверждения своим предположениям и готов отвергать любые противоречащие ему факты.
Дальше просто несколько фактов и скромное наблюдение.
Факт 1. У работника и работодателя разные цели и приоритеты. Работник хочет больше денег, хочет меньше работы и у него есть своя жизнь. Работодатель хочет большее кпд за меньшие деньги, потому что он отвечает в этом тандеме за прибыль. И хотя цели разные - одной без другой не достичь. Работодателю нужен сотрудник который сыт, одет, обут и спокойно выполняет служебные обязанности, это помогает ему получить прибыль. Работнику нужен работодатель с хорошей прибылью чтобы хорошо платил и голова скажем там за семью или за здоровье (которое дорого стоит) не болела.
Факт 2. Между работником и работодателем может быть построено взаимовыгодное сотрудничество. Построение баланса между разнонаправленными векторами целей этих "условно двоих" может быть симбиозом. Если баланса не выстроено - это паразитирование в любую сторону. Либо галера, где людей выжмут, либо шаляй-валяй, где выжмут бизнес.
Факт 3. Баланс выгоден обеим сторонам, но он очень далек от плоскости гуманизма. Из гуманистичных соображений, например, можно держать сотрудника с депрессией. Мало того, это может даже казаться выгодным - он будет изо всех сил мимикрировать под нормального, рапортовать об успехах и брать на себя все больше обязательств. Но на длинном треке это принесет проблем и самому больному работнику и работодателю. Лучший выход - уволить по соглашению сторон с максимальной доплатой которую может работодатель себе позволить. Для обоих лучший и - выгодный. Потеря ценного сотрудника все равно случится. Она уже случилась. Не дайте следующему на его месте сломаться под тяжестью ошибок с прошлым. Вам же еще остальных кормить.
Наблюдение. Наибольшую эмоциональную отдачу и наибольшее ощущение ответственности работник получает в коллективе который в первую голову устраняет препоны мешающие эффективной работе. Не приседает по методичке на утренних стендапах чтобы показать какие мы умнички и какой у нас [скрам] (вставить любое другое карго-культурное), а регулирует рабочий процесс ровно тем образом который поможет человеку не биться лбом в стену корпоративных правил - он тратит на это рабочее время. Но - это про работу, а не про заботу. Работодатель не мама и не жена. Он дает работнику ресурсы и время, а работник изволь отчитаться об их трате. Если оба в меридиане, то жить будут долго и счастливо.
Короче в моей модели все ведет к взаимной ответственности и здравому смыслу. Не исключено что я ошибаюсь. Но двадцатилетний опыт буквально вопит что это наилучший вариант развития отношений работник-работодатель, да и вообще лучший вариант выстраивания сообществ. И все довольно цинично без всякого гуманизма. Есть цели, которые разные, но взаимозависимы. Есть способы их достижения. В сотрудничестве как только одеяло начинает тянуться в одну сторону - страдают обе и все сыпется. Ну и конечно не делать плохо работнику, или не саботировать процесс, отчего будет плохо тебе в любой роли - это здравый смысл, а не гуманизм.
Гуманизм и бизнес понятия не совместимые. Есть КЗоТ. Есть внутренний регламент который должен подчиняться закону по букве и духу. Есть адекватные оценки которые помогут сформировать ФОТ приемлемый для работника и работодателя. Позиция "делайте хорошее а плохое не делайте" например вообще никак не будет работать на рынке труда низкоквалифицированного персонала. Потому что поработав с ним вы навсегда откажетесь копать исследования в пользу теорий о гуманизме. Даже от самого слова будет тошнить. Да и с высококвалифицированным тоже, просто можно налететь на лапочек и долго пребывать в счастливом заблуждении что в индустрии все такие. Дисциплинарные требования к персоналу и вознаграждение за эту дисциплину должны быть прозрачны и непререкаемые для всех. И да, конфликты, злоупотребление и прочее должна курировать самая негуманная и циничная мразь которую сможете найти. С рычагами влияния на владельца бизнеса. Потому что человек так устроен что всегда ищет простые решения. И ими все портит. Надо его постоянно взбадривать чтобы этого не было.
Нененене. НАДО ОТВЛЕЧЬСЯ. Социальные взаимодействия, личные вопросы, зарядка, что-то чтобы во время перерыва сменить фокус. Вне фокуса задача требующая глубокого погружения будет крутиться мозгом бе зацикливания на одной ее стороне.
Clean Architecture это принципы построения архтектуры, не архитектура и не паттерн.
DDD это так же набор принципов.
MVC это таки паттерн. Для слоя презентации, ни разу не архитектура, славится довольно сильной для последней моды связностью, предоставляя вьюшке самой обращаться за данными в модель и интерпретировать их, хотя двунаправленно общается с обеими, если это убрать будет уже MVP.
BLoC это брендированная реализация MVI с упором на "некий компонент бизнес-логики" в аббревиатуре не фигурирующий. Но вы же не понимаете паттерны буквально? Если у нас три буквы - это не означает что в реализации будет только три класса. Он у нас в примитивном виде и стейт-менеджер и интерактор, причем в одноименном пакете есть вместо Bloc-а Cubit который тупо вью модель из MVVM (так же легким движением руки превращающееся в MVI), так что можно вот этими самыми лапками из него сделать такой же блок. Или свалить эту обязанность на настоящий интерактор, который применим и в блоке. Короче так похожи, что мама родная не узнает.
GetX - в первую голову сервис-локатор и потом все остальное, стейт менеджмент там прямо скажем так себе, локаль требует доработки напильником, чо там еще есть? У меня есть в проде поделка с гетиксом, он там только для di и локали, причем последнюю приходится генерить самопальным скриптом иначе это оч плохо бьется с командой когда у тебя есть, например, чувак отвечающий за локализацию. С тем же успехом можно было бы взять гет ит как сервис-локатор и нагенерить удобную для себя локализацию самому (+1 не сильно-то и сложный класс). На то и рассчитывал если что-то пойдет не так. Но вроде покашляет еще.
Дальше больше. Как будто надергали кусков ото всюду даже не попытавшись их осмыслить. Немного страшно за флаттер-комьюнити с такими спикерами и таким залом.
1) У них нет мистической возможности не блочить тред для тяжелых вычислений. И это вообще не задача асинка которую решают корутины.
2) Корутина сама по себе (не касаясь структурной конкурентности) не дает вообще ничего принципиально иного нежели коллбек. Который мы используем чтобы не блочить текущий тред для ожидания вычисления или IO от другого треда. Корутина делает его удобным.
3) Саспенд сам по себе это коллбек через каждую строчку (для стейтмашины в диспетчере)
4) Чтобы сделать что-то асинхронно надо заявить это явно (async или launch), в отличие например от js|dart где async-функции порождают Future, которую можно забыть await, так что асинхронный код именно что отличается от синхронного
5) За счет стейтмашины то время пока мы что-то там await в саспенд функции - диспетчер может заняться другими задачами которые ему направлены - и вот это вот основная вкусность когда нам надо написать синхронный, но неблокирующий код. Пока корутина что-то ждет - она в принципе остановлена.
6) Со звездочкой. У Елизарова в одном из докладов звучит мысль о том что в саспенде нельзя совершать длительных операций блокирующих тред. Не "нельзя технически", а скажем так это нарушает явность происходящего. То есть IO-операции и вычисления мы заявляем в обычных функциях. Они не менеджерятся диспатчерами и на них не порождается континуаций. Мы про них сразу понимаем что они займут тред ровно настолько насколько будут выполняться. Их мы можем вызвать внутри саспенда через async|launch над другим контекстом с другим диспетчером, что направит их в нужный для их выполнения тредпул, а нам отдаст управляемый уже в нашем саспенде deferred|job.
Скорее под всякую административную цель нужны администраторы с подходящей парадигмой. И крайние для вас проявления будут полезны при взаимодействии (внутри/снаружи) с системой, в которой эти проявления не крайние, а обычные. И не обижайтесь, про опыт это я это для красного словца ввернул, а не чтобы вас задеть.
Ну в большой системе это будет нафиг выпилено при первом же случайном рефакторинге. Даже апи референс читает программист больше от безысходности, а уж метод вычисления квадратного корня который как правило лежит сильно ниже - и в бок никому не уперся. А вот архитектурные решения и бизнес-логика бывают таковы что ты воешь, лезешь на стенку и требуешь нанять и техписа и аналитика, потому что "хватит это тепеть".
Прям разочаровывает меня аудитория. Забыли классиков: "Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing."
При живых-то статьях об организации системы документирования на этом же вот вашем хабре.
Ох вот мало вам семи лет опыта руковводства. Трагично мало. Поработайте на госзаказе и вы просто захотите себе в команду кого-то с "той стороны", того самого мерзкого и въедливого клерка из той самой бюрократии. Потому что, во-первых, вы начнете понимать как она работает, а во-вторых, он вас научит в нее играть по-настоящему. И потом за уши не оттащишь. А аджайл не работает нигде, потому что он суть манифестация нездоровых половых увлечений группы извращенцев.
Как человек самой тонкой и трепетной душевной организации могу передать только короткий трехсимвольный сигнал с координатами по которым можно отправиться менеджеру влезающему в чужую предметную область и лакирующего все соусом "просто сделай как я сказал, просто надо работать". Следом пойдет чувак, который придумал что в его компании менеджеру это можно, или, упаси господь, нужно. Если ты нанял инженера - он инженерит, а не ты. Не можете договориться - привлеки других инженеров, ака "архитектурная сессия" и они либо тебе мозги поставят на место, либо ему. В зависимости от того кто не прав. И вот это вот и называется - просто работать.
Я человек простой. Вижу гиперболу - гну ее в другую сторону. Уверен что в мире существует не менее одной компании в которой все ваши советы практикуются прямо в таком гиперболизированном варианте и при этом приносят позитивный результат.
вполне эффективны были много лет и сейчас вполне себе работают ситуативно и в другой форме
и не надо на свой счет все принимать, этот комент в другой ветке и к вам отношения не имеет
Как раз таки были. За редким исключением. Спич про то что люди путают божий дар с яичницей, а гуманизм со здравым смыслом. И уж точно не стоит принимать за чистую монету переводные маркетинговые статьи об импортном бигтехе. Мне тут недавно один чувак подсовывал статью про гугл и "особый склад ума" который выявляется их подходом к собесам. Оч смешно, учитывая что я лично знаю нескольких людей оттуда и они весьма скептически настроены в отношении этих восторженных соплей. Везде люди как люди.
И знаете еще что? Заметил что коллеги часто кичатся своими аналитическими способностями и критичным взглядом на вещи. Но именно среди коллег процветает махровейший догматизм. Копни - аж страшно.
Называть отсутствие переработок гуманизмом же. Я ж не дебил спорить с тем что без них лучше.
Ну я лично вижу подмену понятий на этапе постановки задачи. Мы с самого начала окрестили гуманным подходом ситуацию когда нет переработок например. И на этом как бы все, как модель ни крути мы уже вынесли за скобки соображения гуманности назначив им наличие по умолчанию. А их может и не было. Как в армии. Не сменил постового - тот заснул, проспал диверсию. Вздрючат тебя. Вот прям не сомневайся. Поэтому ты меняешь, но где тут гуманизм?
Я там писал.
Я эту жизнь тоже в первый раз живу. И в дискуссии вступаю чтобы прощупать свои мнения. А не чтобы что-то кому-то доказать.
Я оспариваю выводы о гуманизме. Внезапно оказалось что у талантливого организатора процессов работники не рабы. Как бы "причина<=>следствие". Оптику при анализе надо менять и лучше всего не один раз. А то можно попасть в неудобное положение. Взяли постулат и носимся с ним показывая корреляцию. Корреляцию нашли, а о ее источнике не позаботились. Вот же ж блин, да?
Это буквально перефраз "сам дурак". Я думал у нас тут нормальная дискуссия.
Исследования предназначены подтвердить или опровергнуть точку зрения. Но человек слаб. Так что исследуя что-то он непроизвольно склоняется в пользу фактов которые подтверждают изначальное мнение. Крайне малый процент людей способен пересмотреть точку зрения в результате исследования, или же вовсе сменить парадигму (об этом тоже, лол, много исследований). Для этого надо признать что ошибаешься. Или что построил теоретическую модель не в той парадигме. Фактически человек так устроен что всегда ищет подтверждения своим предположениям и готов отвергать любые противоречащие ему факты.
Дальше просто несколько фактов и скромное наблюдение.
Факт 1. У работника и работодателя разные цели и приоритеты. Работник хочет больше денег, хочет меньше работы и у него есть своя жизнь. Работодатель хочет большее кпд за меньшие деньги, потому что он отвечает в этом тандеме за прибыль. И хотя цели разные - одной без другой не достичь. Работодателю нужен сотрудник который сыт, одет, обут и спокойно выполняет служебные обязанности, это помогает ему получить прибыль. Работнику нужен работодатель с хорошей прибылью чтобы хорошо платил и голова скажем там за семью или за здоровье (которое дорого стоит) не болела.
Факт 2. Между работником и работодателем может быть построено взаимовыгодное сотрудничество. Построение баланса между разнонаправленными векторами целей этих "условно двоих" может быть симбиозом. Если баланса не выстроено - это паразитирование в любую сторону. Либо галера, где людей выжмут, либо шаляй-валяй, где выжмут бизнес.
Факт 3. Баланс выгоден обеим сторонам, но он очень далек от плоскости гуманизма. Из гуманистичных соображений, например, можно держать сотрудника с депрессией. Мало того, это может даже казаться выгодным - он будет изо всех сил мимикрировать под нормального, рапортовать об успехах и брать на себя все больше обязательств. Но на длинном треке это принесет проблем и самому больному работнику и работодателю. Лучший выход - уволить по соглашению сторон с максимальной доплатой которую может работодатель себе позволить. Для обоих лучший и - выгодный. Потеря ценного сотрудника все равно случится. Она уже случилась. Не дайте следующему на его месте сломаться под тяжестью ошибок с прошлым. Вам же еще остальных кормить.
Наблюдение. Наибольшую эмоциональную отдачу и наибольшее ощущение ответственности работник получает в коллективе который в первую голову устраняет препоны мешающие эффективной работе. Не приседает по методичке на утренних стендапах чтобы показать какие мы умнички и какой у нас [скрам] (вставить любое другое карго-культурное), а регулирует рабочий процесс ровно тем образом который поможет человеку не биться лбом в стену корпоративных правил - он тратит на это рабочее время. Но - это про работу, а не про заботу. Работодатель не мама и не жена. Он дает работнику ресурсы и время, а работник изволь отчитаться об их трате. Если оба в меридиане, то жить будут долго и счастливо.
Короче в моей модели все ведет к взаимной ответственности и здравому смыслу. Не исключено что я ошибаюсь. Но двадцатилетний опыт буквально вопит что это наилучший вариант развития отношений работник-работодатель, да и вообще лучший вариант выстраивания сообществ. И все довольно цинично без всякого гуманизма. Есть цели, которые разные, но взаимозависимы. Есть способы их достижения. В сотрудничестве как только одеяло начинает тянуться в одну сторону - страдают обе и все сыпется. Ну и конечно не делать плохо работнику, или не саботировать процесс, отчего будет плохо тебе в любой роли - это здравый смысл, а не гуманизм.
Гуманизм и бизнес понятия не совместимые. Есть КЗоТ. Есть внутренний регламент который должен подчиняться закону по букве и духу. Есть адекватные оценки которые помогут сформировать ФОТ приемлемый для работника и работодателя. Позиция "делайте хорошее а плохое не делайте" например вообще никак не будет работать на рынке труда низкоквалифицированного персонала. Потому что поработав с ним вы навсегда откажетесь копать исследования в пользу теорий о гуманизме. Даже от самого слова будет тошнить. Да и с высококвалифицированным тоже, просто можно налететь на лапочек и долго пребывать в счастливом заблуждении что в индустрии все такие. Дисциплинарные требования к персоналу и вознаграждение за эту дисциплину должны быть прозрачны и непререкаемые для всех. И да, конфликты, злоупотребление и прочее должна курировать самая негуманная и циничная мразь которую сможете найти. С рычагами влияния на владельца бизнеса. Потому что человек так устроен что всегда ищет простые решения. И ими все портит. Надо его постоянно взбадривать чтобы этого не было.
Нененене. НАДО ОТВЛЕЧЬСЯ. Социальные взаимодействия, личные вопросы, зарядка, что-то чтобы во время перерыва сменить фокус. Вне фокуса задача требующая глубокого погружения будет крутиться мозгом бе зацикливания на одной ее стороне.
Clean Architecture это принципы построения архтектуры, не архитектура и не паттерн.
DDD это так же набор принципов.
MVC это таки паттерн. Для слоя презентации, ни разу не архитектура, славится довольно сильной для последней моды связностью, предоставляя вьюшке самой обращаться за данными в модель и интерпретировать их, хотя двунаправленно общается с обеими, если это убрать будет уже MVP.
BLoC это брендированная реализация MVI с упором на "некий компонент бизнес-логики" в аббревиатуре не фигурирующий. Но вы же не понимаете паттерны буквально? Если у нас три буквы - это не означает что в реализации будет только три класса. Он у нас в примитивном виде и стейт-менеджер и интерактор, причем в одноименном пакете есть вместо Bloc-а Cubit который тупо вью модель из MVVM (так же легким движением руки превращающееся в MVI), так что можно вот этими самыми лапками из него сделать такой же блок. Или свалить эту обязанность на настоящий интерактор, который применим и в блоке. Короче так похожи, что мама родная не узнает.
GetX - в первую голову сервис-локатор и потом все остальное, стейт менеджмент там прямо скажем так себе, локаль требует доработки напильником, чо там еще есть? У меня есть в проде поделка с гетиксом, он там только для di и локали, причем последнюю приходится генерить самопальным скриптом иначе это оч плохо бьется с командой когда у тебя есть, например, чувак отвечающий за локализацию. С тем же успехом можно было бы взять гет ит как сервис-локатор и нагенерить удобную для себя локализацию самому (+1 не сильно-то и сложный класс). На то и рассчитывал если что-то пойдет не так. Но вроде покашляет еще.
Дальше больше. Как будто надергали кусков ото всюду даже не попытавшись их осмыслить. Немного страшно за флаттер-комьюнити с такими спикерами и таким залом.
Кажется что посты про собеседования в стиле "алгоритмы не нужны" и в стиле "алгоритмы нужны" уже одинаково огребают хейта.
И снова про корутины. Глаз царапнуло.
1) У них нет мистической возможности не блочить тред для тяжелых вычислений. И это вообще не задача асинка которую решают корутины.
2) Корутина сама по себе (не касаясь структурной конкурентности) не дает вообще ничего принципиально иного нежели коллбек. Который мы используем чтобы не блочить текущий тред для ожидания вычисления или IO от другого треда. Корутина делает его удобным.
3) Саспенд сам по себе это коллбек через каждую строчку (для стейтмашины в диспетчере)
4) Чтобы сделать что-то асинхронно надо заявить это явно (async или launch), в отличие например от js|dart где async-функции порождают Future, которую можно забыть await, так что асинхронный код именно что отличается от синхронного
5) За счет стейтмашины то время пока мы что-то там await в саспенд функции - диспетчер может заняться другими задачами которые ему направлены - и вот это вот основная вкусность когда нам надо написать синхронный, но неблокирующий код. Пока корутина что-то ждет - она в принципе остановлена.
6) Со звездочкой. У Елизарова в одном из докладов звучит мысль о том что в саспенде нельзя совершать длительных операций блокирующих тред. Не "нельзя технически", а скажем так это нарушает явность происходящего. То есть IO-операции и вычисления мы заявляем в обычных функциях. Они не менеджерятся диспатчерами и на них не порождается континуаций. Мы про них сразу понимаем что они займут тред ровно настолько насколько будут выполняться. Их мы можем вызвать внутри саспенда через async|launch над другим контекстом с другим диспетчером, что направит их в нужный для их выполнения тредпул, а нам отдаст управляемый уже в нашем саспенде deferred|job.
Скорее под всякую административную цель нужны администраторы с подходящей парадигмой. И крайние для вас проявления будут полезны при взаимодействии (внутри/снаружи) с системой, в которой эти проявления не крайние, а обычные. И не обижайтесь, про опыт это я это для красного словца ввернул, а не чтобы вас задеть.
Ну в большой системе это будет нафиг выпилено при первом же случайном рефакторинге. Даже апи референс читает программист больше от безысходности, а уж метод вычисления квадратного корня который как правило лежит сильно ниже - и в бок никому не уперся. А вот архитектурные решения и бизнес-логика бывают таковы что ты воешь, лезешь на стенку и требуешь нанять и техписа и аналитика, потому что "хватит это тепеть".
Прям разочаровывает меня аудитория. Забыли классиков: "Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing."
При живых-то статьях об организации системы документирования на этом же вот вашем хабре.
Ох вот мало вам семи лет опыта руковводства. Трагично мало. Поработайте на госзаказе и вы просто захотите себе в команду кого-то с "той стороны", того самого мерзкого и въедливого клерка из той самой бюрократии. Потому что, во-первых, вы начнете понимать как она работает, а во-вторых, он вас научит в нее играть по-настоящему. И потом за уши не оттащишь. А аджайл не работает нигде, потому что он суть манифестация нездоровых половых увлечений группы извращенцев.
Да не сказал бы. Все как везде, такие же люди. Причем в разработке это еще на собесе видно - кому просто работать надо, а кому мозги сношать.
Как человек самой тонкой и трепетной душевной организации могу передать только короткий трехсимвольный сигнал с координатами по которым можно отправиться менеджеру влезающему в чужую предметную область и лакирующего все соусом "просто сделай как я сказал, просто надо работать". Следом пойдет чувак, который придумал что в его компании менеджеру это можно, или, упаси господь, нужно. Если ты нанял инженера - он инженерит, а не ты. Не можете договориться - привлеки других инженеров, ака "архитектурная сессия" и они либо тебе мозги поставят на место, либо ему. В зависимости от того кто не прав. И вот это вот и называется - просто работать.
Я человек простой. Вижу гиперболу - гну ее в другую сторону. Уверен что в мире существует не менее одной компании в которой все ваши советы практикуются прямо в таком гиперболизированном варианте и при этом приносят позитивный результат.