Клиентский код

Привет!

Вот варюсь я в этом айти уже долгое время. Почитываю Хабр, ищу работу, работаю, потом снова ищу работу. Посмотрел разные компании изнутри, крупные и не очень. Сходил за свою жизнь на 25+ собеседований, еще до времен удаленки и на на ней.

Я честно, не знаю как в других профессиях, но в программировании, как мне кажется, собеседования — это чистая лотерея. Мое видение этого возможно подтверждает рынок труда — накрути себе опыта побольше, примени нейросеть, расскажи красиво о себе и вот работа (зарплата) мечты уже твоя. Следствием этого — по 300 отзывов на вакансию. Но, к слову, вакансии эти висят месяцами. Ты просто попадаешь в огромную кучу кандидатов, которых работодатель хочет отсеять и выбрать лучшего из вас. По каким критериям (по всем кроме трудовой книжки) вас будут сортировать одному Нео известно. Так‑же имел личный опыт, когда я отвечал полностью на все вопросы в течение часа. Получив оценку своим знаниям на 5+, заветную работу (зарплату) мечты я так и не получил.

Мне, как и возможно многим программистам, присуще чувство самозванца в профессии. Но, дорогой читатель с опытом, можешь ли ты честно ответить в первую очередь себе, откудо это чувство берется? Как и с любой эмоцией, тут я думаю стоит задаться вопросом, что это чувство скрывает в себе? Чем оно вызванно? У всех ли есть оно? (Это наверное больше вопрос к автору). В общем — может я один так считал, что если я посмотрю на процессы ИТ изнутри, это ощущение со временем пройдет.

И оно не прошло

Хабр, как так вышло, что токсичность ИТ специалиста стала какой‑то, нормой или даже ассоциируется с программистом? Ведь это ломает бизнес процессы, это не просто не приятно по человечески, по моему мнению это приносит убытки компании. В следствии затруднения межличностных взаимодействий в компаниях как минимум очень затруднено движение знаний, может это только мой опыт, но я встречал такое:
— Читай книгу «Чистый код» и все станет понятно.
— Прочитай страничку на вики трёхлетней давности, все станет понятно.
Простите конечно, но в этой книге не описывается архитектура 10 летнего монолита (а то и старше), там описывается рекомендуемый подход к организации кода.

Об организации кода я бы и хотел поговорить

Много, конечно, о чем хочется и можно говорить в ИТ. Но очень часто, когда я открываю Хабр, к слову, читаю я его на 80 процентов только по теме кода, я вижу статьи, которые в один голос, под разную тоналность говорят, что ООП не нужен, вообще‑то все и так работает, как вы могли этого не знать? Зачем вам все эти непонятные объекты, напичканные закрытыми методами и свойствами которые может вообще и не используются. Фабрики непонятные, которые только усложняют процесс использования объектов. Хочется на это ответить — что в системе используется, а что нет зависит от организации работы программиста с системой, а не от организации самой системы.

Проблема монолита

Скажи мне, Хабр, а что можно считать монолитом? Если мы, например, говорим про PHP, и анализируем его фреймворки, это - MVC. В противовес ему как микросервесное решение конечно же было-бы предложен язык Go. Но разве можно считать MVC, MVVM, MVP, MMM, KFC монолитом? Ведь это разбиение кода как минимум на слои. Как мне видится исходя из собственного опыта - монолит это понятие где в какой-то момент начинают забывать (забивать) (не понимать) архитектуру кода. Может из-за не понимания самой концепции MVC, MVVM, MVP, MMM, KFC, или пришли джуны на проект, причин этому может быть много, но понятие монолит как явление мы имеем

Клиентский код (Client code)

Собственно возвращаясь к теме статьи, что такое клиентский код? Думаю многим читателем литературы по программированию, будь то книги или документация, знакомо это понятие. По сути Клиентский код - код который использует другой код. Обычно его пишут программисты, на языке который имеет свои правила и возможности (если вы напишите код который вызывает стандартную функцию языка, ваш код = клиентский код). Интересно это понятие тем что оно может выражать не только конкретную реализацию функционала, но также код до его фактического существования, то есть это код, который напишет программист, когда ему необходимо использовать библиотеку, добавить функционал в существующий код (код, который вы придумали и написали до этого, в той или иной степени подразумевался разработчиками языка).

Написанный код нужно предвещать

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

Пример

Пример, к сожалению (многих) или к счастью (надеюсь, тоже многих) будет на ООП языке - PHP.

Сделаем простую авторизацию по логину и паролю/

И сразу же мы сталкиваемся с магией. Да в мире программирования она существует и это - магические методы. Их магия заключается в том что они помогают предвещать работу с классом. Контролировать - создание объекта, вызов методов и свойств (приватных или не существующих), уничтожение объекта и еще почти с десяток операций.

Но в данном примере мы остановимся на контроле создания объекта из клиентского кода.

Давайте создадим класс POSTUserCreds — его назначение обслуживать HTTP POST данные от пользователя и аутентифицировать их. Нужно сказать что объектом мы задаем не только набор свойств и методов, необходимых для обработки данных, сам класс по своей сути существует для создания контекста. Контекст нужен разработчику, разработчик пишет клиентский код. Надеюсь, ход мысли понятен.

<?php

class POSTUserCreds {
  //Задаем приватные поля для объекта. Это значит что они будут неизменны 
  //со стороны клиентского кода во время жизни объекта
  private string $login;
  private string $pass;


  //При помощи этого магического метода гарантируем что клиентский код при
  //создании объекта должен передать данные которые он принимает от 
  //пользователя как логин и пароль
  public function __constructor(
    string $http_post_login,
    string $http_post_pass
  ) {
    //Заполняем поля у создаваемого объекта, которые хочется напомнить 
    //нельзя поменять в клиентском коде
      $this->login = $http_post_login;
      $this->pass = $http_post_pass;

    //Выполняем приватный метод класса, гарантирует что больше нигде 
    //не будет вызван
      if(!$this->auth_user()) {
        //Заверщаем программу если пользователь не авторизован
        throw new Exception('Access denied');
      }
  }
}

По сути в 10 строк (рабочего) кода мы заложили следующую логику:

• Данные для аутентификации пользователя не могут быть изменены по ходу выполнения программы

• Нельзя создать объект аутентификации пользователя не передав логин/пароль

• При создании объекта аутентификации пользователя в системе, будет выполнена аутентификация (простите за тавтологию) и при ее отрицательном результате, код дальше выполняться не будет.

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