​Насчёт принципов программирования.

Предлагаю в ближайшее время именно их поизучать, ведь принципы - это довольно частый вопрос на различных собеседованиях. Начнём с простенького, более основного, как мне кажется, принципа.

KISS - "Keep it simple, stupid" - принцип, который утверждает, что все компоненты программы должны оставаться простыми. Именно в такой расшифровке я дам его тут, хотя есть и немного другие варианты. Главное, что суть одна и та же.

Этот принцип - отличное подспорье для декомпозиции и упрощения вашего кода. Никаких огромных структур, никаких ненужных дополнительных функций и фишек, никаких избыточных функций "про запас". Только то, что действительно нужно для решения конкретной задачи.

Вся программа - небольшие логически разделенные блоки, где каждый блок отвечает за что-то своё.

Надеюсь, что всё верно объяснил. Если что-то не так, то моя личка открыта для всех, буду рад подискутировать 🙂

#useful #principles #theory

​Принцип проектирования DRY.

Продолжу эту полезную на мой взгляд рубрику. Сегодня поговорим о принципе DRY - "Don't repeat yourself". Акроним, который просит нас не повторяться. Суть принципа заключается в том, что каждый компонент программы должен иметь единственное и авторитетное представление.

Самый простой пример - какая-то функция. Функция - это сущность в коде, которая имеет единственную реализацию в одном месте и множество вызовов в других местах. Это централизует управление поведением функции в одном месте, из-за чего при необходимости внесения изменений в поведении функции нужно будет изменить лишь один блок кода.

При соблюдении DRY вы избегаете клонирование кода и тем самым делаете код более читабельным, выразительным и упрощаете его поддержку в будущем.

Что интересно, нарушение принципа DRY - это WET - "Write Everything Twice" или "We enjoy typing". Интересная игра слов получается.

Но важно знать, что иногда DRY бывает даже вреден - в системах реального времени. Это те системы, в которой компоненты зависят от состояний друг друга. В таких случаях задержка передачи данных по сети может оказаться критически большой, так что многие вычисления просто делаются на стороне клиента.

И кратенько на этом всё. Про все принципы советую почитать ещё, я не смогу изложить их одновременно кратко и очень ёмко. Ну и на этом всё, спасибо за прочтение

#useful #principles #theory

​Принцип проектирования YAGNI.

YAGNI - «You aren't gonna need it» - «Вам это не понадобится».
Достаточно интересный принцип, который должен знать каждый программист. Он просто позволяет вам делать меньше. Хотя это, наверное, слишком громко сказано🙂
Принцип продвигает идею того, что именно сейчас вы должны максимально отказаться от избыточного функционала даже в том случае, если он понадобится в будущем. То есть только самое нужное, только самое необходимое и всё по очереди, постепенно.
Чем-то напоминает KISS, о котором мы говорили тут, но это всё же немного о другом. Да и в целом в принципах одно на другое частенько похоже, так что этому удивляться не стоит.

У YAGNI есть целый список правил, которые он содержит в себе. Они даже в википедии описаны неплохо, что меня убедило, полный список можете прочитать тут.

Если кратенько, то:
•‎ Тестирование существующего лучше добавления нового функционала.
•‎ Чем больше функций, тем сложнее обслуживать код.
•‎ ПО может становится неоправданно сложным.

Да и тем более, помяните Джобса с его радикальным минимализмом.
На этом кратенько вроде всё. Спасибо за прочтение ❤️

#useful #principles #theory

​SOLID - Принцип единственности ответственности.

Продолжаем обсуждать принципы проектирования и сейчас начнём разбирать, наверное, самую популярную группу принципов SOLID - акроним от пяти аббревиатур, где каждая буква в слове - отдельный принцип. Эти принципы - набор рекомендаций к вашему ООП коду.

Первая буква акронима и первый принцип - SRP - Single Responsibility Principle.
Принцип единственности ответственности говорит нам о том, что у модуля должна быть только одна причина для изменения, а также постулирует то, что каждый класс должен отвечать за что-то одно.
Суть заключается в том, чтобы при возникновении любых изменений в программе задействовалось как можно меньше её модулей. В идеале каждое изменение будет затрагивать только один класс.
Также нужно думать и о будущем, чтобы классы можно было легко расширять без нарушения этого принципа. Есть такой антипаттерн God object, вот его точно допускать нельзя.
Как итог получаем очень серьёзную деструктуризацию, которая помогает нам на всех этапах работы с кодом и делает его более читабельным.

О SOLID буду рассказывать очень кратенько. В целом, в этих принципах нет ничего сложного и они абсолютно легко гуглятся. А я тут поболтаю немного и на этом хватит) Но по всем вопросам всегда открыта личка, прошу.

#principles #theory

​SOLID - Принцип открытости/закрытости.

Второй принцип из группы SOLID - OCP - Open/closed principle - Принцип открытости/закрытости.
Этот принцип утверждает, что каждый элемент программы (модуль, функция, класс) должен быть открыт для расширения, но закрыт для изменения. Это ментальная сущность, скажем так.
Это совсем не значит, что нужно запретить редактирование фала и открыть его только на чтение, нет. Это означает, что все эти элементы программы способны менять свою функциональность без изменения уже написанного кода. То есть то, что мы уже написали - это закрытая для изменения часть, а то, что мы допишем для расширения функционала - это открытая для расширения часть.

Принцип крайне полезен, особенно в коммерческой разработке, потому что мы максимально расширяем базу протестированного, отлаженного кода. Любые изменения вносятся быстро и без больших трудозатрат.

Если принцип не соблюдается, а старые фрагменты кода постоянно переписываются, то это влечёт за собой очень большие затраты как по времени, так и по деньгам. Вы уже не можете быть на столько уверены в отказоустойчивости системы, да и на мотивацию влияет плохо. Никто не хочет писать одну и ту же функцию по 10 раз.

Спасибо тем людям, что терпят моё долгое отсутствие и остаются читателями в любом случае. Это невозможно недооценить ❤️

#principles #theory

​SOLID - Принцип подстановки Барбары Лисков.

Почему-то я слышал мнение, что это самый сложный для понимания принцип, но по моему мнение крайне ошибочное.
LSP - Liskov substitution principle - один из самых простых принципов. Суть его заключается в том, что компоненты программы (функции, модули и т.д.) должны одинаково успешно обрабатывать как экземпляр класса родителя, так и экземпляр потомка класса не зная об этом.

Для понимания достаточно описать супер простой пример, скажем, на том же питоне:

class Person:
    def __init__(self, name):
        self.name = name

class Programmer(Person):
    def __init__(self, name, language):
        Person.__init__(self, name)
        self.language = language

person = Person('Денис')
programmer = Programmer('Макс', 'Python')

А теперь реализуем функцию, которая вернёт имя человека:

def getName(person): 
    return person.name

Вообще было бы лучше сделать соответствующий метод класса, но пишем так для примера.
Вызовем функцию:

print(getName(person))  // Денис
print(getName(programmer))  // Макс

Всё прекрасно работает как с классом родителем, так и с классом наследником. Если бы было бы иначе, то такая ситуация - нарушение LSP.

В оригинале Барбара Лисков даёт определение этого принципа чисто математически. Возможно, именно из-за этого оно и кажется непонятным. Надеюсь, что я смог объяснить яснее.

Спасибо за прочтение, это важно ❤️

#principles #theory

​SOLID - Принцип разделения интерфейсов.

ISP - Interface segregation principle - один из самых простых для понимания принципов. Его суть заключается в том, что большое количество интерфейсов для разных пользователей лучше, чем один большой интерфейс для всех.

Проще всего понять это можно на примере:
Допустим, что у нас есть класс представления базы данных интернет магазина, в котором реализованы различные методы для добавления/удаления/изменения товаров, поиска и т.д.
В этом случае ограничимся двумя пользователями - это администратор сайта и обычный покупатель. В таком случае делать общий интерфейс для двух этих пользователей будет нарушением принципа разделения интерфейсов. Обычному покупателю не нужны методы добавления или удаления товара. Ему нужен только поиск, возможно методы для управления пользовательской корзиной товаров. А для администратора, в свою очередь, нужны все методы, позволяющие управлять его магазином.

В этой ситуации мы рассмотрели так называемый «Узкий-Широкий интерфейс», что возможно в ситуации с двумя пользователями. В реальности же пользователей может быть больше и чтобы не нарушить этот принцип придётся выделить собственный интерфейс под каждого пользователя.

Иначе этот принцип трактуется определением «интерфейсы не должны зависеть от методов, которые они не используют». После вышеописанного примера должно быть понятно в чём суть. Изменения неиcпользуемых методов не должно приводить к повторному развёртыванию интерфейса.

И снова спасибо тем людям, что не решаются отписываться из-за моей неактивности в последнее время. Не могу сказать, что вуз не нужен, но в период сессии он уж точно старается отнять гораздо больше времени, чем я хотел бы ему дать. Когда-нибудь отпишу что думаю на этот счёт, но не сегодня. Ещё раз спасибо за прочтение, это важно ❤️

#principles #theory

​​Что такое BFF

В мире разработки чуть ли не каждый день возникают новые архитектурные подходы, особенно во FrontEnd'e. Один из относительно новых затрагивает и BackEnd.

BackEnd for FrontEnd, или BFF — это архитектурное направление, которое подразумевает создание отдельного интерфейса взаимодействия для каждого из FrontEnd'ов. Вместо создания одного общего API разработчики ограничивают зоны ответственности и появляются отдельные интерфейсы для каждого из клиентов.

На примере телеграм, у нас есть:
— Веб версия
— Десктопные клиенты
— Мобильные приложения
— Sticker API
— Bot API
— и так далее

И BFF, как часть микросервисного мышления гласит, что один интерфейс-монолит — это неудобно. Зачем делать огромный API, если мы можем сделать несколько поменьше, дабы увеличить скорость работы, поставить зоны ответственности и сделать систему более динамичной, уменьшив связность?

При соблюдении BFF, у Telegram будет несколько интерфейсов API:
— Bot API
— Sticker API
— Mobile API
— Web API

При том допускается разделение Mobile и Web API на, например:
— Chat API
— Channel API
— Audio Call API
— Video Call API
— и так далее

Этих интерфейсов может быть достаточно много для такого большого сервиса. Подробнее можно почитать в разборе Сэма Ньюмана, автора книги «Building Microservices» в издательстве O'REILLY.

На этом у меня всё. Спасибо за прочтение, это правда важно для меня.

#web #theory #patterns #principles

В общих словах о Serverless Environment

Serverless Environment (он же Serverless Architecture) — это подход, в котором разработка программного обеспечения концентрируется вокруг бизнес-логики приложения. Разработчикам больше не нужно заниматься логикой менеджмента инфраструктуры, а можно сконцентрироваться на написании функциональности, максимально прямо направленной на пользователя и бизнес. Управление же инфраструктурой возьмёт на себя облачный провайдер.

В этом контексте, облачный провайдер, — это компания посредник, которая возьмёт на себя ответственность по управлению и масштабированию используемых серверов. Разработчики же платят только за использование ресурсов, что делает эту модель экономически более выгодной. Вместо того чтобы думать о серверах, разработчик может сосредоточиться на разработке приложения и его функциональности.

Подобные услуги предлагает множество облачных провайдеров, но самые популярные из них — AWS Lambda, Azure Functions и Google Cloud Functions. В СНГ регионе же, самыми крупными провайдерами будут Yandex Cloud и Selectel.

Никто за упоминания не заплатил, а жаль..)

#web #useful #theory #principles

Что такое декларативность и императивность?

Императивный подход написания кода фокусируется на том, КАК именно должна быть выполнена задача. В императивном стиле вы указываете шаг за шагом, что должно происходить, ничего не скрывая, например:

// Императивный способ создания списка из элементов массива
const items = [1, 2, 3, 4, 5];
const ul = document.createElement('ul');

for (let i = 0; i < items.length; i++) {
  const li = document.createElement('li');
  li.textContent = items[i];
  ul.appendChild(li);
}

document.body.appendChild(ul);

В этом примере мы явно указываем, как именно нужно создать список: создаем элементы, задаем им текст и добавляем в список.

Декларативный же подход фокусируется на том, ЧТО нужно сделать. В декларативном стиле вы описываете результат, который хотите получить, а не процесс его достижения, например:

import React from 'react';
import ReactDOM from 'react-dom';

const items = [1, 2, 3, 4, 5];

const App = () => (
  <ul>
    {items.map(item => (
      <li key={item}>{item}</li>
    ))}
  </ul>
);

ReactDOM.render(<App />, document.getElementById('root'));

В этом примере с использованием React мы описываем, что хотим увидеть: список элементов. Мы не указываем, как именно React должен создать и добавить эти элементы, мы просто описываем структуру, которую хотим получить

Императивный стиль дает вам полный контроль над процессом выполнения, что может быть полезно для сложных алгоритмов и точной настройки.

Декларативный стиль, как правило, делает код более читаемым и легким для понимания, так как вы описываете только конечный результат. Также декларативный код часто легче поддерживать и изменять, так как он фокусируется на описании желаемого состояния, а не на пошаговом выполнении.

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #theory #code #javascript #principles