Объекты легче описать на понятный язык. Представить объект машины в голове и придумать ему свойства и функционал может каждый в бизнесе, а так сказать стать актором, не каждый
ООП вообще никак не влияет на синхронность. Вам не кажется странным, впринципе, разделять ООП и ФП? Чем отличается метод от функции? Мне кажется контекстом, отсюда и DDD, бизнес хочет глубже знать разработку, вот пожалуйста готовый подход.
Мне кажется ИТ вообще огромное поле для манипуляций. А в продакт попадают модные штучки как у гугл (микросервесы с gRPC), всякие реакты как в твиттере, вью.джс и прочее (возможно, чтобы потом продукт менеджер всем рассказывал что у нас все как у больших игроков рынка). Всё это время ИТ подогревается инфоцыганщиной ( меня если честно немного смешит что Яндекс после своих курсов не берет сразу людей к себе, по крайней мере я не видел такого в их рекламах), обучись годик и будет зарплата 200+. Вот рынок и сломался под количеством вкатунов, если честно из-за этого вообще избегаю найма как огня. Да и после того как образование и достижения в своей сфере не котируется, а котируется только что ты писал точно на таком же фреймворке как в команде. В компаниях вообще не понимают что если ты пишешь на нативном языке, то и фреймворк ты осилишь и куча куча таких вот моментов которые дают понять модель бизнеса. Заплатил деньги - получаю результат, все остальное мишура и прихоти этих странных ИТшников.
Получается что разработчик должен упрощать взаимодействие с продуктом, отстраняя пользователя от условного "компилятора" (технической части продукта?) Не уверен что до конца понял что хотите сказать, но плюс поставил)
Да, я понимаю как это происходит в коммерческой разработке. Я больше про то что, впринципе 140+ человек для такого приложения это перебор 2 раза :) Это скорее про корпоративные моменты, и как видно из статьи диаграммы не помогают сократить количество участников процесса. Я к тому что 2 программиста не сделают приложение в 2 раза быстрее, а скорее наоборот все усложнят.
Статья интересная, диаграммы и показатели круто. Но если честно у меня глаз зацепился за 140+ человек участвующих в работе над продуктом, диаграммами можно все покрыть и посмотреть, но точно ли нужно столько людей?
Да, есть такое, тоже заметил всплывающию информацию как правильно переехать с NOSql на Sql и что в этом одни плюсы) Смешно и грустно конечно, мне кажется микросервисы тоже на волне хайпа, все начали ругать "монолит" и показывать пальцем какой у них крутой (нет) и модный (да) микросервис.
Сколько лет уже боты и всякие ИИ у руля тех. поддержки, но это до сих пор удручающее зрелище, получается ИИ не может заменить уже долгое время сотрудника поддержки? А программистов уже завтра заменит...
Может бизнесу тоже стоит маленько посмотреть в себя, и стать маленько софт, а не относится к ИТ отделам как к воронке которая только деньги тянет. Особенно сочувствую безопасникам.
Не знаю на счёт культа, меня тоже, как видимо многих, вводит в ступор собеседования и вообще отбор в компании. Но мне кажется тут все прозаичнее, бизнес боится нового из-за убытков, вот и шлепают как у всех, от собеседований до рабочего процесса.
Инкапсуляция - это сокрытие внутреннего состояния и функций объекта и предоставление доступа только через открытый набор функций
НАРОД! Давайте зафиксируем - инкапсуляция нужна для сокрытия работы объекта, вот вам и АБСТРАКЦИЯ. Вы прячете свойства и методы объекта, от КЛИЕНТСКОГО КОДА, что-бы нельзя было поменять его свойства (фиксируете при создании и строго настраиваете взаимодесйтвие с ними). А функции нужны что-бы, опять же КЛИЕНТСКИЙ КОД, был в контексте, когда вы открываете файл с объектом, у вас есть внутрення логика (приватные функции) и логика работы с объектом (публичные методы). Вижу опять лайки хейтерам ООП летят, фронтендеры, хватит)
Не думаю что там можно до кого-то достучаться, зарплатами скорее хотят себе набить выхлоп, чем сделать лучше сотруднику. По итогу просто на тебя наваливают работу, просят не ходить в отпуск и все такое.
По началу мне казалось круто отдаваться компании, я думал что вложенные силы окупятся, но не в одной компании я не видел поощрение за переработки, скорее наоборот, кто тащит на того и накидывают, дак ещё и потом придут спрашивать в случае чего
Отличная статья! Если честно пока осилил только половину, получил прозрение на одном моменте:
Буквально сегодня писал код и чувствовал легкий зуд от пробела знания в этом моменте, теперь думаю мне станет чуточку легче)
Объекты легче описать на понятный язык. Представить объект машины в голове и придумать ему свойства и функционал может каждый в бизнесе, а так сказать стать актором, не каждый
ООП вообще никак не влияет на синхронность. Вам не кажется странным, впринципе, разделять ООП и ФП? Чем отличается метод от функции? Мне кажется контекстом, отсюда и DDD, бизнес хочет глубже знать разработку, вот пожалуйста готовый подход.
Но мне если честно не кажется пошаговая подсветка (обучение на сайте, думаю видели) хорошим юзер экспириенсом.
Ну если платишь за готовый продукт я думаю это логично, отдал деньги - максимально быстро и удобно решил проблему.
Мне кажется ИТ вообще огромное поле для манипуляций. А в продакт попадают модные штучки как у гугл (микросервесы с gRPC), всякие реакты как в твиттере, вью.джс и прочее (возможно, чтобы потом продукт менеджер всем рассказывал что у нас все как у больших игроков рынка). Всё это время ИТ подогревается инфоцыганщиной ( меня если честно немного смешит что Яндекс после своих курсов не берет сразу людей к себе, по крайней мере я не видел такого в их рекламах), обучись годик и будет зарплата 200+. Вот рынок и сломался под количеством вкатунов, если честно из-за этого вообще избегаю найма как огня. Да и после того как образование и достижения в своей сфере не котируется, а котируется только что ты писал точно на таком же фреймворке как в команде. В компаниях вообще не понимают что если ты пишешь на нативном языке, то и фреймворк ты осилишь и куча куча таких вот моментов которые дают понять модель бизнеса. Заплатил деньги - получаю результат, все остальное мишура и прихоти этих странных ИТшников.
Получается что разработчик должен упрощать взаимодействие с продуктом, отстраняя пользователя от условного "компилятора" (технической части продукта?) Не уверен что до конца понял что хотите сказать, но плюс поставил)
Да, я понимаю как это происходит в коммерческой разработке. Я больше про то что, впринципе 140+ человек для такого приложения это перебор 2 раза :) Это скорее про корпоративные моменты, и как видно из статьи диаграммы не помогают сократить количество участников процесса. Я к тому что 2 программиста не сделают приложение в 2 раза быстрее, а скорее наоборот все усложнят.
Статья интересная, диаграммы и показатели круто. Но если честно у меня глаз зацепился за 140+ человек участвующих в работе над продуктом, диаграммами можно все покрыть и посмотреть, но точно ли нужно столько людей?
Да, есть такое, тоже заметил всплывающию информацию как правильно переехать с NOSql на Sql и что в этом одни плюсы) Смешно и грустно конечно, мне кажется микросервисы тоже на волне хайпа, все начали ругать "монолит" и показывать пальцем какой у них крутой (нет) и модный (да) микросервис.
Сколько лет уже боты и всякие ИИ у руля тех. поддержки, но это до сих пор удручающее зрелище, получается ИИ не может заменить уже долгое время сотрудника поддержки? А программистов уже завтра заменит...
Может бизнесу тоже стоит маленько посмотреть в себя, и стать маленько софт, а не относится к ИТ отделам как к воронке которая только деньги тянет. Особенно сочувствую безопасникам.
Не знаю на счёт культа, меня тоже, как видимо многих, вводит в ступор собеседования и вообще отбор в компании. Но мне кажется тут все прозаичнее, бизнес боится нового из-за убытков, вот и шлепают как у всех, от собеседований до рабочего процесса.
Смотрю в код, а там одна магия.
Мужики, композиция в ООП есть.
Монолит, возможно, получился в противовес микросервисам. До них такого понятия не было?
НАРОД! Давайте зафиксируем - инкапсуляция нужна для сокрытия работы объекта, вот вам и АБСТРАКЦИЯ. Вы прячете свойства и методы объекта, от КЛИЕНТСКОГО КОДА, что-бы нельзя было поменять его свойства (фиксируете при создании и строго настраиваете взаимодесйтвие с ними). А функции нужны что-бы, опять же КЛИЕНТСКИЙ КОД, был в контексте, когда вы открываете файл с объектом, у вас есть внутрення логика (приватные функции) и логика работы с объектом (публичные методы). Вижу опять лайки хейтерам ООП летят, фронтендеры, хватит)
Не думаю что там можно до кого-то достучаться, зарплатами скорее хотят себе набить выхлоп, чем сделать лучше сотруднику. По итогу просто на тебя наваливают работу, просят не ходить в отпуск и все такое.
Извините, я просто человек
По началу мне казалось круто отдаваться компании, я думал что вложенные силы окупятся, но не в одной компании я не видел поощрение за переработки, скорее наоборот, кто тащит на того и накидывают, дак ещё и потом придут спрашивать в случае чего