Наследования (реализации) как такового в ФП нет, но те задачи, которые решаются
наследованием можно решить другими путями.
важна инкапсуляция, тоесть мы забываем про иммутабельность
Какая связь то? Посмотрите модель акторов (на примере Erlang/Elixir)… Инкапсуляция такая, что мейнстрим языкам даже в самых влажных мечтах не снилось, но при этом абсолютно все данные иммутабельны.
Единственное, что отличает ООП от ФП, — это угол зрения:
Можно применять ООП в функциональных языках и ФП в объектно-ориентированных, ничто этому не препятствует. Разница лишь в акцентах, а не в чём-то фундаментальном.
Наверно, надо указывать точнее, а то мы все регионы зачем-то обобщаем…
Россия — большая, я сужу по регионам ЦФО, т.к. с ситуацией в остальных не знаком. Конкретно про ваш регион я не могу ничего оспорить. Может и всё тухло в IT, как Вы утверждаете, а может Вы и сами не все возможности увидели. Но это только люди, которые владеют информацией по Дагестану, могут уточнить.
Расходы компании связаны с тем, что стажеру надо всё равно выделить рабочее место, и самое затратное — выделить время квалифицированных сотрудников на то, чтобы проверять его работу, обучать в формате обратной связи, т.е. потратить в разы больше времени, чем требуется, чтобы сделать самому. По сути это скорее инвестиции в расчёте на то, что компания получит джуна, которому можно будет делегировать рутинную работу и в перспективе, может быть, даже мидла.
Бывают, конечно, компании, которые пишут код на выброс. Но в них нет резона задерживаться, на начальных уровнях вы там ничему толком не научитесь, а на высоких уровнях — самому противно будет в таком участвовать.
В приличных компаниях стажёры — это практически чистые расходы (даже если они бесплатно работают), джуниоры — околонулевой финансовый выхлоп, но возможность разгрузить более квалифицированных сотрудников от тривиальных задач. Сами стажеры и джуны с этим, конечно, не согласятся. В их представлении они уже вносят незаменимый вклад, но это банальный эффект Даннинга-Крюгера.
Самые выгодные по финансовому выхлопу на единицу зарплаты — мидлы и начинающие сеньоры. От тех, кто выше, уже процентное отношение прибыли становится меньше, но без них невозможно реализовать сложные проекты.
Стажёры всегда работают за еду и это нормально, они пока своей работой приносят компании больше расходов, чем доходов. И так же обычное дело за первые 3-5 лет карьеры увеличить свой доход в 5-10 раз в рамках одного региона. Автор этот первичный буст связал с переездом, что тоже вариант, но тут нужно учитывать, что переезд, как правило, и расходы увеличивает.
Вижу что можно местами и больше просить, но наглости уже не хватает…
И как вы с этим боретесь? Имхо, тут наглость не причём, просто у каждого есть какой-то психологический рубеж, за которым начинается синдром самозванца.
У меня типичная задача — перевести пожелания стейкхолдеров в архитектуру так, чтобы не убить при этом перформанс. Плюс мониторинг мест, которые превращаются в бутылочное горлышко, и их устранение.
Это зависит от города и стека технологий. Если город не миллионник, или стек не самый попсовый, то удалённых вакансий скорее всего окажется больше, чем офисных.
Так штатный режим заключался в том, что в заранее известную дату компания обращается к нему за тех.поддержкой, он меняет дату и получает оплату. И тут он сам лишил себя возможности поменять дату...
Да всё гораздо проще: когда вас нанимают, чтобы сделать конкретный, заранее оговоренный объём работы за указанный срок и деньги — это фриланс. Офис, удалённо — не суть важно. Во всех остальных случаях — это не фриланс.
Должен, только уже осознанно. Просто инвертируйте условия в предыдущем комментарии и получится:
Писать код, выяснив какова его роль в удовлетворении пользовательской потребности. При сомнениях в архитектурных решениях, обсуждать эти вопросы с архитектором или с CTO, или при их отсутствии с другими сеньорами.
P.S. Роль сеньора — это уже про ответственность по отношению к написанному коду. Поэтому проявления безответственности можно и нужно называть нарушением профессиональной этики.
P.P.S. Кстати, часть пользовательских задач вполне может решиться и без написания кода, когда выяснишь, что по факту нужно. А, как известно, лучший код — ненаписанный код. Такие кейсы, конечно, редко дойдут до сеньора, но с другой стороны не во всех компаниях есть архитекторы.
Можно много разделений придумать, но есть же уже Junior/Middle/Senior.
Если первые 2 могут не понимать что-то из-за нехватки опыта и знаний, то Senior должен быть способен понять и осознанно обсудить задачу, даже если путь её решения уже прописан архитектором или CTO. Тут уже нет места реактивному поведению.
а схему в миддлеваре не проверишь, про неё только бд знает
Миддлвара вполне может спрашивать что-то у сервиса с доступом к БД.
Ну да ладно, не будем вдаваться в детали. Единственное, что я хочу Вам сказать, что жёстко связывать проверку доступа и сами запросы на получение/изменение данных — не очень хорошая идея. И лучше подумать, как развязать эти ответственности (с учётом специфики вашего проекта) до того, как это станет большой проблемой.
Наследования (реализации) как такового в ФП нет, но те задачи, которые решаются
наследованием можно решить другими путями.
Какая связь то? Посмотрите модель акторов (на примере Erlang/Elixir)… Инкапсуляция такая, что мейнстрим языкам даже в самых влажных мечтах не снилось, но при этом абсолютно все данные иммутабельны.
Эта часть отрабатывает в 4096 раз реже, так что экономия будет уже не столь существенна.
Функциональное проектирование вы можете применять вообще где угодно, даже далеко за пределами программирования.
Единственное, что отличает ООП от ФП, — это угол зрения:
Можно применять ООП в функциональных языках и ФП в объектно-ориентированных, ничто этому не препятствует. Разница лишь в акцентах, а не в чём-то фундаментальном.
Наверно, надо указывать точнее, а то мы все регионы зачем-то обобщаем…
Россия — большая, я сужу по регионам ЦФО, т.к. с ситуацией в остальных не знаком. Конкретно про ваш регион я не могу ничего оспорить. Может и всё тухло в IT, как Вы утверждаете, а может Вы и сами не все возможности увидели. Но это только люди, которые владеют информацией по Дагестану, могут уточнить.
Расходы компании связаны с тем, что стажеру надо всё равно выделить рабочее место, и самое затратное — выделить время квалифицированных сотрудников на то, чтобы проверять его работу, обучать в формате обратной связи, т.е. потратить в разы больше времени, чем требуется, чтобы сделать самому. По сути это скорее инвестиции в расчёте на то, что компания получит джуна, которому можно будет делегировать рутинную работу и в перспективе, может быть, даже мидла.
Бывают, конечно, компании, которые пишут код на выброс. Но в них нет резона задерживаться, на начальных уровнях вы там ничему толком не научитесь, а на высоких уровнях — самому противно будет в таком участвовать.
В приличных компаниях стажёры — это практически чистые расходы (даже если они бесплатно работают), джуниоры — околонулевой финансовый выхлоп, но возможность разгрузить более квалифицированных сотрудников от тривиальных задач. Сами стажеры и джуны с этим, конечно, не согласятся. В их представлении они уже вносят незаменимый вклад, но это банальный эффект Даннинга-Крюгера.
Самые выгодные по финансовому выхлопу на единицу зарплаты — мидлы и начинающие сеньоры. От тех, кто выше, уже процентное отношение прибыли становится меньше, но без них невозможно реализовать сложные проекты.
Стажёры всегда работают за еду и это нормально, они пока своей работой приносят компании больше расходов, чем доходов. И так же обычное дело за первые 3-5 лет карьеры увеличить свой доход в 5-10 раз в рамках одного региона. Автор этот первичный буст связал с переездом, что тоже вариант, но тут нужно учитывать, что переезд, как правило, и расходы увеличивает.
Ахах, ну я, кстати, подумал, что можно нолик приписать для получения верхней границы. Так и получилось.
И как вы с этим боретесь? Имхо, тут наглость не причём, просто у каждого есть какой-то психологический рубеж, за которым начинается синдром самозванца.
Странно, что конкретные суммы, а не диапазоны.
У меня типичная задача — перевести пожелания стейкхолдеров в архитектуру так, чтобы не убить при этом перформанс. Плюс мониторинг мест, которые превращаются в бутылочное горлышко, и их устранение.
Нет, с физ.лицом возможен и договор подряда. И это тоже будет фриланс, если договор не рамочный.
Размечтались… Их выгода в том, чтобы сделать разработку на Windows более удобной, а не сокращать неудобства запуска Windows-программ под GNU/Linux.
Это зависит от города и стека технологий. Если город не миллионник, или стек не самый попсовый, то удалённых вакансий скорее всего окажется больше, чем офисных.
Так штатный режим заключался в том, что в заранее известную дату компания обращается к нему за тех.поддержкой, он меняет дату и получает оплату. И тут он сам лишил себя возможности поменять дату...
Да всё гораздо проще: когда вас нанимают, чтобы сделать конкретный, заранее оговоренный объём работы за указанный срок и деньги — это фриланс. Офис, удалённо — не суть важно. Во всех остальных случаях — это не фриланс.
Я ещё не понял, если он заранее знал дату срабатывания, зачем он в отпуск то уехал на эту дату?
Должен, только уже осознанно. Просто инвертируйте условия в предыдущем комментарии и получится:
Писать код, выяснив какова его роль в удовлетворении пользовательской потребности. При сомнениях в архитектурных решениях, обсуждать эти вопросы с архитектором или с CTO, или при их отсутствии с другими сеньорами.
P.S. Роль сеньора — это уже про ответственность по отношению к написанному коду. Поэтому проявления безответственности можно и нужно называть нарушением профессиональной этики.
P.P.S. Кстати, часть пользовательских задач вполне может решиться и без написания кода, когда выяснишь, что по факту нужно. А, как известно, лучший код — ненаписанный код. Такие кейсы, конечно, редко дойдут до сеньора, но с другой стороны не во всех компаниях есть архитекторы.
Можно много разделений придумать, но есть же уже Junior/Middle/Senior.
Если первые 2 могут не понимать что-то из-за нехватки опыта и знаний, то Senior должен быть способен понять и осознанно обсудить задачу, даже если путь её решения уже прописан архитектором или CTO. Тут уже нет места реактивному поведению.
Миддлвара вполне может спрашивать что-то у сервиса с доступом к БД.
Ну да ладно, не будем вдаваться в детали. Единственное, что я хочу Вам сказать, что жёстко связывать проверку доступа и сами запросы на получение/изменение данных — не очень хорошая идея. И лучше подумать, как развязать эти ответственности (с учётом специфики вашего проекта) до того, как это станет большой проблемой.