Привет! Хотелось бы поделиться с вами своей мудростью примером структуры, которая подойдёт практически для любых сервисов вне зависимости от того, гоняете ли вы JSON-ы в микросервисах или разрабатываете монолитное решение со сложной бизнес-логикой.
В этой статье я рассказываю об эффектах. Несмотря на то, что эффект – понятие столь же простое, как обычная функция, для меня оказалось не так просто найти подходящее объяснение, но, я его нашел.
Вы узнаете, в чем заключается идея использования эффектов и чем они отличаются от классических функций. Я делюсь своим опытом разработчика и показываю примеры кода с использованием эффектов. Вероятно вы найдете для себя что-то интересное.
Если вы никогда не слышали об эффектах или термине "побочный эффект", рекомендую ознакомиться с этой темой для повышения вашего профессионального уровня и технического кругозора!
Статья представляет собой перевод статьи отсюда, на которую я натолкнулся в процессе изучения темы системного проектирования.
В системном дизайне понимание разницы между классами проектирования (design classes) и классами анализа (analysis classes) носит ключевой характер. Классы анализа подобны детективу — они исследуют и понимают проблему. Они сфокусированы на том, что система должна делать, без погружения в то, как именно это должно быть реализовано. Эти классы помогают разработчикам понять требования к программе и ее цели. В то время как классы проектирования подобно архитектору берут результаты изысканий классов анализа и создают план, как именно система будет работать.
Живя в сложное время, наша психика пытается найти способы объяснить происходящее и успокоить себя. Я научился воспринимать наш мир через философию русского сатирика-постмодерниста Виктора Пелевина. Сразу скажу, что я воспринимаю мир сугубо материалистически, но чтобы не умереть от тревоги, я научился благодаря книгам Виктора относиться к событиям с иронией, а к нашему миру как симуляции (что не отменяет диалектической логики вещей).
Я подумал, если я применяю этот инструмент в качестве мировоззрения, то скорее всего невольно эта дзен-буддистская философия перекочевала и в мой код. Поэтому давайте проанализируем вместе, каким образом мы можем применить эти идеи в нашей повседневной работе, чтобы повысить эффективность и бонусом не сойти с ума от происходящего.
В условиях жесткой конкуренции цифровизация производства становится важным фактором успеха для любого предприятия. Компании, игнорирующие цифровую трансформацию, рискуют серьезно отстать от более прогрессивных конкурентов и потерять свои позиции на рынке. Все дело в том, что цифровизация открывает целый ряд возможностей для оптимизации бизнес-процессов и снижения издержек при производстве продукции.
Библиотека функций к Script-fu
Реализовав простейшую объектную систему в Scheme полезно было бы продемонстрировать преимущество от её использования. Чем в этой статье мы и займёмся. Демонстрацию проведём на примере абстракции Фигуры, ведь именно при реализации этой абстракции у меня и возникло сожаление об отсутствии ОО средств в Scheme.
Всем привет! Я Борис Зырянов, разработчик в команде Платформы. В этой статье хочу рассказать про Dependency Inversion Principle, потому что это, пожалуй, один из самых важных принципов SOLID, понимание которого дает ключи к архитектуре программного обеспечения.
Задача, стоящая перед настоящим текстом — придать объем DIP, продемонстрировав, как из лаконичных дефиниций следуют строгие правила по организации кода. В статье будут очерчены критерии корректного использования принципа, разобраны его определения и рассмотрен пример применения. Это даст понятную модель организации зависимостей кода, которую вы сможете применить на практике.
Маленькие заметки для тех, кому сложно понять кучу умных слов,
Single Responsibility Principle — принцип единственной ответственности
Open Closed Principle — принцип открытости-закрытости
Liskov Substitution Principle — принцип подстановки Барбары Лисков
Interface Segregation Principle — принцип разделения интерфейса
Dependency Inversion Principle — принцип инверсии зависимостей
Описания компоновки (управления автоматическим размещением визуальных элементов) которые мне попадались на родном языке мне кажутся не достаточно погружают читателя в реальную проблематику которая стоит за этим процессом. Мне хочется акцентировать внимание на том откуда берется сложность в этом вопросе. Хотелось бы чтобы кто-то покритиковал мои формулировки.
Приветствую всех укротителей событий! Проникнувшись идеей разработки с использованием DDD, я решил реализовать на нем обработку событий для элементов смарт-процессов Bitrix24, коей хочу поделиться с вами.
Привет, Хабр, меня зовут Александра, я программист в отделе разработки серверных решений ЮMoney. В этой статье описываю, как принципы объектно-ориентированного программирования можно использовать в психологии человека. Моя цель — показать, что за техническими терминами часто скрываются идеи, которые могут обогатить наше восприятие не только программирования, но и природы человека.
Роберт Мартин нехило так повлиял на айти‑индустрию. Он придумал принципы SOLID, о которых спрашивают на собесах, пишут статьи на хабре и спорят в комментариях. Он написал книгу «Чистый код» и сделал это словосочетание айтишным мемом. Если зайти на хэдхантер, вбить в поиске слово «чистый», выбрать специализацию «Программист, разработчик» и нажать «Найти», получим больше семисот вакансий. Про чистоту кода и архитектуры спорят на код‑ревью, в комментариях и статьях по всему интернету. Разговоров о чистоте внутри айти‑тусовки бывает так много, словно мы находимся в сообществе клинеров, а не программистов.
Мартин называет себя «дядюшкой Бобом». В своих работах он выступает в образе опытного мудрого и взрослого родственника, который несёт свет и знания таким зелёным и неопытным племянникам. И у него отлично получилось втереться в доверие! Типичный хороший программист‑анальник бессилен перед таким добрым дядей. И я знаю, о чём пишу. Восемь лет назад я сам запоем читал книги дядюшки, а потом до усрачки защищал чистоту кода на код‑ревью. Я на себе почувствовал, насколько Роберт Мартин отличный агитатор и пропагандист. Работая с другими людьми, читая статьи и обсуждения на Хабре и хакерньюс, анализируя требования к вакансиям, я понимаю, что не я один попался на отличную пропаганду от «дядюшки Боба».
В мире разработки программного обеспечения существует множество "священных коров" — принципов и практик, которые принимаются как данность и редко подвергаются критическому анализу. Особенно показательна ситуация с принципами SOLID на русскоязычных ресурсах: достаточно открыть Хабр, чтобы найти 100500 статей о SOLID, и в каждой из них принципы интерпретируются по-разному.
Само существование такого количества "объяснительных" статей говорит о фундаментальной проблеме: если принципы требуют толкования, значит их названия не являются самодостаточными и интуитивно понятными. А если каждый разработчик понимает принципы по-своему, возникает вопрос — зачем вообще нужны принципы, которые не дают однозначного руководства к действию? Принципы SOLID, предложенные Робертом Мартином, давно стали одной из таких "священных коров". Однако пришло время честно признать: то, как мы используем SOLID сегодня, часто противоречит изначальным идеям и в целом иногда может приносить больше вреда, чем пользы. Зависит от контекста.
Самый яркий пример искажения первоначального замысла — это интерпретация принципа единственной ответственности (SRP).
Тут вот какое дело, понимаю, что написаны тысячи, если не миллионы, книг и статей на тему... Сам я безработный разработчик предпенсионного возраста, нахожусь в поиске, и меня, хотя и редко, но приглашают на собеседование, где меня обязательно спросят про "основные принципы ООП", чем всегда ставят меня в тупик, я не знаю, что отвечать на этот вопрос.
Когда-то, лет 30 назад, мне посчастливилось поработать в одном очень продвинутом коллективе известного ВУЗа, и там один из научных руководителей регулярно приходил в бешенстве с конференций, на которых обсуждались видения ООП и подходы к реализациям, потому что его понимание сильно отличалось от коллег-участников конференций с других кафедр. Кстати сказать, он написал java-подобный язык, который вроде до сих пор с успехом используют. Этим воспоминанием я хочу подчеркнуть, что проблема не такая уж и новая, и не такая уж и надуманная.
В современных источниках об ООП-принципах вы непременно найдете тезис об инкапсуляции, наследовании и полиморфизме, тогда как на заре компьютерных наук ни один из разработчиков или компьютерных ученых ничего подобного вам бы не заявил. Наверняка здесь есть какая-то путаница.
Ну, посудите сами, парадигмы процедурного программирования основанные на теореме структурного программирования окончательно сформировались только к началу 70-х годов прошлого века, а первые языки ООП появились еще в начале 60-х годов. Но современное поколение, в основной своей массе, почему-то считает, что ООП - это что-то новое, и к тому же неудачное, и поэтому его надо срочно заменить чем-то типа Питона или на худой конец Скалы итп.
Допустимые глобальные переменные и предполагаемая экономия памяти.
Вот уже 20 лет я преподаю программирование в университете Буэнос-Айреса. На курсе программной инженерии мы изучаем паттерны проектирования, и одна и та же «схема» повторяется раз за разом, вызывая почти де жа вю. Я убедился в этом на нескольких проектах и при обращении со свободным ПО, которым мне приходилось пользоваться:
Как «по волшебству» в коде возникает паттерн синглтон.
Автор: Денис Закусило
Приветствую всех неравнодушных! Это заключительная статья цикла о переходе от модульной архитектуры к сервисам.
[Записки тимлида] Битрикс: от модулей к сервисам
[Записки тимлида] Битрикс: от модулей к сервисам 2
Сегодня мы рассмотрим организацию структуры frontend стороны приложения.
Последние год-полтора я натыкаюсь на статьи и доклады (особенно в англоязычном сегменте) о том, что JOOQ – это современная и более крутая альтернатива Hibernate.
Скажу сразу, что я считаю JOOQ отличной библиотекой (именно библиотекой, а не фреймворком, в отличие от Hibernate). Он прекрасно справляется со своей задачей – работой с SQL в режиме статической типизации, чтобы отловить большинство ошибок на этапе компиляции.
Но когда я слышу аргумент, что время Hibernate прошло и пора все писать на JOOQ, для меня это звучит примерно так же, как то, что время реляционных БД прошло и теперь нужно использовать только NoSQL. Звучит смешно? Но по меркам истории буквально вчера такие разговоры велись вполне серьезно.
Я думаю, дело кроется в непонимании корневых проблем, которые решают эти два инструмента. Этой статьей я хочу ответить на эти вопросы.
Зачастую, когда речь заходит про принцип инверсии зависимостей, можно услышать, что инверсия зависимостей (далее DIP) — это что-то там про зависимость от абстракций, и приводятся примеры, где в качестве «плохого» случая, используются конкретные классы, а в исправленном случае, используются абстрактные классы или интерфейсы. Но такая трактовка принципа в корне неверна.
Почему такая трактовка неверна и в чем же суть принципа — об этом и пойдет речь далее.
Сегодня я расскажу, как можно создать собственную систему репутации с Telegram на Python. Решение будет легким и красивым, обещаю.
