Разработчики на C# (уровня мидл и выше), архитекты, тимлидеры
Решается задача системного дизайна типичного бизнес-приложения
Я предоставлю эту информацию как только вы дадите мне достаточно денег на проведение полноценного PoC-тестирования на нескольких проектах и командах :)
Тем, что к web-у не имеет никакого отношения.
Для вас русским языком написано: "статья рассказывающая про реализацию пока что находится в редактуре"
Ради справедливости: "технически можно сделать всё" — довольно инфантильная и глупая позиция. Знаю ребят, которые так делали. Их продукт в итоге превратился в нелогичное и неюзабельное говно. Потому что на любую идею говорилось "да мы! да щас как! да мы можем!". А потом выясняется что технически нереализуемые углы, подразумевающие заглядывание в голову пользователя сглаживаются самыми нелицеприятными методами.
У математиков есть такая позиция: "не используй в рассуждениях то, что не можешь доказать". Вот с перформансом, мне кажется, должно быть то же самое: не используй в своём коде что-либо, если не знаешь как примерно оно работает под капотом, какие оверхеды несёт и как это в случае чего оптимизировать.
Это не значит что надо сверлить оптимизацию покуда не упрёшься в скорость прохождения электронов по проводам. Но надо всегда понимать что любое удобство даётся не бесплатно. Нет языков программирования, в которых бесплатно создание нового класса, вызов лишней функции, наполнение данными лишней коллекции и лишний её обход — просто нет.
Разумеется, есть ряд оптимизаций, которые сокращают стоимость. Что-то новое в этом направлении пытается сказать Rust, но покуда его не знает каждый встречный — надо помнить что удобство не бесплатно. И надо понимать насколько именно и какое удобство не бесплатно для того чтобы, делать простенькие трейд-оффы, когда это возможно.
Да и вообще мне кажется что плохая производительность — она далеко не всегда из-за того, что где-то есть Один Большой и Толстый Ботлнек. Она вполне себе может складываться из сотен неоптимально написанных мест. Уменьшим же их количество!
Аминь.
У меня, честно говоря, в голове не очень укладывается: если я вот прямо сейчас начну делать язык программирования, да ещё и "наберу команду" — моих сбережений хватит в лучшем случае месяца на 3 работы. Откуда у Бреслава такие ресурсы?
Ему это приложение выдало разрабатывать начальство в Google, сочтя поначалу направление бесперспективным. И то не как программисту, а как product manager-у. Отдали бы какой-нибудь Google Read — сейчас бы кто-то другой сидел на интервью у Дудя.
Какой энтузиазм, говорите?
На энтузиазме этот персонаж wap-сайтики делал для продажи рингтонов.
Давайте для простоты на берегу договоримся что "не эффективно" не связано с техническими скиллами. У нас разработчик сферический в вакууме, который всё знает, всё умеет и багов не допускает. :)
Я вам по сути толкую вот о чём: чтобы эффективно решать проблему бизнеса — надо прежде всего чтобы бразды правления в вопросе опознания самой проблемы и подбора решений были у того, кто проблему решает. Покуда это не так — пытаться решить какую бы то ни было проблему — бесполезное занятие. И я так понимаю, вы с этим согласны.
Что касается предлагать решения — вы знаете, культура везде разная, и в некоторых культурах предложение решения могут прочитать не как попытку помочь, а как попытку выпендриться, попытку протолкнуться по карьерной лестнице, подсидеть начальника и т.п. Так что я бы такое с порога не рекомендовал всё же.
Отличное мнение, коллега, только с моей колокольни вы упускаете одну важную деталь.
Дело в том, что бизнес САМ идентифицирует какая у него проблема (а зачастую решение тоже определяет) и отдаёт её разработчику-проблематологу в виде указания "решай вот эту проблему" (зачастую добавляя "вот таким-то образом").
Когда оказывается что проблема идентифицирована неверно, или же что решение, которое хочет бизнес к этой проблеме не подходит (или и то и другое сразу) — в кого летят шишки? Правильно, в разработчика. Не станут же люди на ответственных должностях признавать свои ошибки. В результате получается ситуация:
— Мы аэропорт, мы терпим убытки. Это от того, что мы мало продаём.
— Но…
— Мы приняли решение что наша проблема решится если засадить взлётно-посадочную полосу картошкой.
— Эээ… Но…
— Никаких но, решай проблему бизнеса. Вот проблема, вот тебе даже способ решения. Иди вскапывай ВПП и сажай картошку.
(через время)
— Взлетающий самолёт увяз в грязи, мы неделю его вытаскивали, все рейсы отменились, мы терпим убытки! Кто там занимался этой проблемой?
— Я, но эм…
— Уволен!
Поэтому лично мне такие разговоры и не нравятся — бизнес часто (не всегда, но часто) ставит задачи, а когда выясняется что задачи определены неправильно, оговорка "разработчик должен решать проблемы бизнеса" используется для того, чтобы спихнуть ответственность с больной головы на здоровую.
А вот я в порядке троллинга скажу что разгадка проста: маркетологи-аналитики, менеджеры, продакт-овнеры сами по себе зачастую тупенькие как батон колбасы. Поэтому закономерно привлекают качественно решать встающие перед ними проблемы действительно умных людей.
Не гоните их, научитесь это делать профессионально. Потом можно найти место, где за это будут предлагать многие миллионы деняк.
С радостью бы поддержал дискуссию, но надо пилить датагриды :)
Всё так, тут приходится проектировать решение, которое цепляет максимально возможное количество кейсов и делает это хорошо. У меня вроде как получилось.
Смотрит разработчик на код и спрашивает — "а кааак это поддерживать?".
Тонны редакс-быдлокода, написанные в режиме "главное завалить а там ногами запинаем" мы не спрашиваем как поддерживать. А небольшой, но свой стейт-менеджмент в 500 строк кода суммарно — всё, проблема проблем! Мы не знаем что делать кроме как рыдать "спаситипамагити мамочка тут велосипед!", "да, мы видим его код, мы знаем буквы которыми он написан, мы знаем язык на котором он написан но ОООО УЖАС КАК ЖЕ ЭТО ПОДДЕРЖИВАТЬ?!".
И действительно. Неподвластная человеческому уму задача.
P.S: а вы часто смотрите в код пакетов, которые вы используете? А количество открытых issues? А когда был последний коммит — тоже проверяете? А документацию на сайте с API сопоставляете (вдруг там не всё описано)? А как вы будете поддерживать своё приложение если завтра автора вашего, конечно же, не-велосипедного пакета из npm собьёт автобус вы часто спрашиваете?
Нет, одно дело когда ты делаешь что-то на коленке чтобы протестировать гипотезы (и потом выкидываешь, процесся параллельно фидбек пользователей и перерабатывая результаты A/B тестирования и полученных метрик в PBI/дизайн-док и прочие тикеты в жире со всеми остановками — митингами, кофе-брейками, приоритезацией и прочим планированием спринтов). Другое дело когда "нахерачить абы работало" является драйвером процесса разработки. Тут, как в том анекдоте, есть нюанс. Хотя есть большой соблазн не выкидывать MVP. Я его понимаю и признаю, но это — тот самый путь где мертвецы с косами стоят, а вокруг — тишинаа...
Дайте угадаю… потому что каркас, предусматривающий решение описанных проблем написан на C#? :)
Спрашивали — отвечаем:
То есть по сути дела мы защищаем пароли от production-а от своих собственных сотрудников?
Что-то как-то не очень понятно — а от чего защищаемся-то? Что и от кого пытаемся скрыть?
А то пока что выглядит как театр безопасности.
Ради справедливости: "технически можно сделать всё" — довольно инфантильная и глупая позиция. Знаю ребят, которые так делали. Их продукт в итоге превратился в нелогичное и неюзабельное говно. Потому что на любую идею говорилось "да мы! да щас как! да мы можем!". А потом выясняется что технически нереализуемые углы, подразумевающие заглядывание в голову пользователя сглаживаются самыми нелицеприятными методами.
У математиков есть такая позиция: "не используй в рассуждениях то, что не можешь доказать". Вот с перформансом, мне кажется, должно быть то же самое: не используй в своём коде что-либо, если не знаешь как примерно оно работает под капотом, какие оверхеды несёт и как это в случае чего оптимизировать.
Это не значит что надо сверлить оптимизацию покуда не упрёшься в скорость прохождения электронов по проводам. Но надо всегда понимать что любое удобство даётся не бесплатно. Нет языков программирования, в которых бесплатно создание нового класса, вызов лишней функции, наполнение данными лишней коллекции и лишний её обход — просто нет.
Разумеется, есть ряд оптимизаций, которые сокращают стоимость. Что-то новое в этом направлении пытается сказать Rust, но покуда его не знает каждый встречный — надо помнить что удобство не бесплатно. И надо понимать насколько именно и какое удобство не бесплатно для того чтобы, делать простенькие трейд-оффы, когда это возможно.
Да и вообще мне кажется что плохая производительность — она далеко не всегда из-за того, что где-то есть Один Большой и Толстый Ботлнек. Она вполне себе может складываться из сотен неоптимально написанных мест. Уменьшим же их количество!
Аминь.
Но в статье-то речь о том, что нам продаванов средней руки выдают за ИНЖЕНЕРОВ.
У меня, честно говоря, в голове не очень укладывается: если я вот прямо сейчас начну делать язык программирования, да ещё и "наберу команду" — моих сбережений хватит в лучшем случае месяца на 3 работы. Откуда у Бреслава такие ресурсы?
Ему это приложение выдало разрабатывать начальство в Google, сочтя поначалу направление бесперспективным. И то не как программисту, а как product manager-у. Отдали бы какой-нибудь Google Read — сейчас бы кто-то другой сидел на интервью у Дудя.
Какой энтузиазм, говорите?
На энтузиазме этот персонаж wap-сайтики делал для продажи рингтонов.
Давайте для простоты на берегу договоримся что "не эффективно" не связано с техническими скиллами. У нас разработчик сферический в вакууме, который всё знает, всё умеет и багов не допускает. :)
Я вам по сути толкую вот о чём: чтобы эффективно решать проблему бизнеса — надо прежде всего чтобы бразды правления в вопросе опознания самой проблемы и подбора решений были у того, кто проблему решает. Покуда это не так — пытаться решить какую бы то ни было проблему — бесполезное занятие. И я так понимаю, вы с этим согласны.
Что касается предлагать решения — вы знаете, культура везде разная, и в некоторых культурах предложение решения могут прочитать не как попытку помочь, а как попытку выпендриться, попытку протолкнуться по карьерной лестнице, подсидеть начальника и т.п. Так что я бы такое с порога не рекомендовал всё же.
Поправьте меня если я ошибаюсь, но по-моему вы только что предложили НЕ решать проблемы бизнеса :)
Отличное мнение, коллега, только с моей колокольни вы упускаете одну важную деталь.
Дело в том, что бизнес САМ идентифицирует какая у него проблема (а зачастую решение тоже определяет) и отдаёт её разработчику-проблематологу в виде указания "решай вот эту проблему" (зачастую добавляя "вот таким-то образом").
Когда оказывается что проблема идентифицирована неверно, или же что решение, которое хочет бизнес к этой проблеме не подходит (или и то и другое сразу) — в кого летят шишки? Правильно, в разработчика. Не станут же люди на ответственных должностях признавать свои ошибки. В результате получается ситуация:
Поэтому лично мне такие разговоры и не нравятся — бизнес часто (не всегда, но часто) ставит задачи, а когда выясняется что задачи определены неправильно, оговорка "разработчик должен решать проблемы бизнеса" используется для того, чтобы спихнуть ответственность с больной головы на здоровую.
А вот я в порядке троллинга скажу что разгадка проста: маркетологи-аналитики, менеджеры, продакт-овнеры сами по себе зачастую тупенькие как батон колбасы. Поэтому закономерно привлекают качественно решать встающие перед ними проблемы действительно умных людей.
Не гоните их, научитесь это делать профессионально. Потом можно найти место, где за это будут предлагать многие миллионы деняк.
Не, почему. Я мержу по мере наличия времени. Просто рук на всё не хватает.
С радостью бы поддержал дискуссию, но надо пилить датагриды :)
Всё так, тут приходится проектировать решение, которое цепляет максимально возможное количество кейсов и делает это хорошо. У меня вроде как получилось.
Беларусы сверхлюди, считают в троичной :) Потому что б-гоугодно
Если в вашем конфетном мире существует только React 16+, то мои вам поздравления.
Смотрит разработчик на код и спрашивает — "а кааак это поддерживать?".
Тонны редакс-быдлокода, написанные в режиме "главное завалить а там ногами запинаем" мы не спрашиваем как поддерживать. А небольшой, но свой стейт-менеджмент в 500 строк кода суммарно — всё, проблема проблем! Мы не знаем что делать кроме как рыдать "спаситипамагити мамочка тут велосипед!", "да, мы видим его код, мы знаем буквы которыми он написан, мы знаем язык на котором он написан но ОООО УЖАС КАК ЖЕ ЭТО ПОДДЕРЖИВАТЬ?!".
И действительно. Неподвластная человеческому уму задача.
P.S: а вы часто смотрите в код пакетов, которые вы используете? А количество открытых issues? А когда был последний коммит — тоже проверяете? А документацию на сайте с API сопоставляете (вдруг там не всё описано)? А как вы будете поддерживать своё приложение если завтра автора вашего, конечно же, не-велосипедного пакета из npm собьёт автобус вы часто спрашиваете?
Ну… наверное вот поэтому у нас в индустрии всё… так (потрясает руками в воздухе) :)
Нет, одно дело когда ты делаешь что-то на коленке чтобы протестировать гипотезы (и потом выкидываешь, процесся параллельно фидбек пользователей и перерабатывая результаты A/B тестирования и полученных метрик в PBI/дизайн-док и прочие тикеты в жире со всеми остановками — митингами, кофе-брейками, приоритезацией и прочим планированием спринтов). Другое дело когда "нахерачить абы работало" является драйвером процесса разработки. Тут, как в том анекдоте, есть нюанс. Хотя есть большой соблазн не выкидывать MVP. Я его понимаю и признаю, но это — тот самый путь где мертвецы с косами стоят, а вокруг — тишинаа...