IT + Опрос

Чаще всего под шаблонами проектирования понимают некую часть программы, которая должна выполнить часто повторяющуюся задачу. Для таких частых, стандартных задач были написаны алгоритмы и, даже, специальная книга "Design Patterns".

Вот об этих шаблонах или паттернах, описанных в книге, и поговорим.

В статье на Википедии предлагают следующую классификацию шаблонов:

• Основные

• Порождающие шаблоны (Creational)

• Структурные шаблоны (Structural)

• Поведенческие шаблоны (Behavioral)

Мне кажется, что самый простой и популярный шаблон, который можно разобрать в первой статье - это Порождающий шаблон "Фабричный метод". Основная идея его в том, что наша программа будет создавать разные классы в зависимости от некоторых условий. Причем, во время разработки программы, мы не будем знать какой класс нам будет необходим. И программа должна будет определить и создать класс сама. Да, объяснить без примеров это не просто, поэтому посмотрим на код.

Фреймворк

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

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

А бот можно найти в телеграме, написать ему сообщение и проверить работу нашего Фабричного метода.

Код проекта

Идея программы очень простая - вы пишите сообщение телеграм боту. Бот отправляет callback сообщение на бекэнд нашего приложения. И в зависимости от текста этого сообщения, код на бекэнде определяет какое сообщение отправить боту обратно, чтобы вывести его в телеграм клиенте.

Сообщение от телеграма приходит на роут, который мы указали при создании бота в BotFather. А во фреймворке создали этот роут в "\project\config\routes.php"

use \Core\Route;

return [

new Route('/telegram/:var1/', 'telegram', 'index'), // роут для telegram bot

];

Роут находит Telegram Controller и выполняет метод index. В этом методе мы выполняем ряд проверок. И если сообщение пришло от нашего телеграм бота, передаем сообщение в Фабричный метод, чтобы создать нужный объект и получить обратное сообщение для бота.

$ms = new MessageFactory($params);

$msObject = $ms->create();

В классе MessageFactory есть два метода. В конструкторе мы разбираем параметры сообщения и пытаемся получить текст сообщения от телеграма и id чата от которого сообщение пришло.

А в методе create мы проверяем существует ли класс для конкретного сообщения и если существует создаем объект этого класса и возвращаем его в контроллер. Если же класса нет, значит мы должны создать дефолтный класс.

public function __construct(array $params)

{

$this->command = preg_replace('/\//', '_', $params['message']['text']??'sdsfsdf');

$this->params['chatId'] = $params['message']['chat']['id']??0;

}

public function create()

{

$className = ucfirst($this->command);

$messageFile = $_SERVER['DOCUMENT_ROOT'] . DIRECTORY_SEPARATOR . "project/classes/messagefactory/messages/Message$className.php";

$messageClass = $this->namespace."Message$className";

if(file_exists($messageFile) && class_exists($messageClass)){

return new $messageClass($this->params);

} else {

return new MessageDefault($this->params);

}

}

Для каждого конкретного сообщения, которое мы хотим обработать на бекэнде по уникальному сценарию, мы должны создать класс реализации. Например, класс "\project\classes\messagefactory\messages\MessageTest.php"

Этот класс расширяет абстрактный класс MessageAbstract и реализует интерфейс IMessage. class MessageTest extends MessageAbstract implements IMessage {}

У него есть только конструктор, в котором мы вызываем конструктор родителя и заполняем свойство $message = 'Test Message'. Соответственно, если мы напишем в телеграм бот сообщение 'test', то наш Фактори метод создаст класс MessageTest, в свойстве $message у него будет строка 'Test Message' и контроллер отправит эту строку обратно в телеграм бот.

Что если

Что если бы мы не использовали все эти модные паттерны, классы и ооп. Конечно, такую программу можно реализовать и без ооп, возможно это даже проще. Но тогда описать обработку каждого сообщения придется в блоках if/else или switch/case. На первом этапе это будет не трудно. Просто напишем нужную строку для каждого case. Но, что если логика реакции на каждое сообщение будет сложной. Если при сообщении '/start' мы захотим зарегистрировать пользователя в системе и добавить его в базу данных. А при дефолтном сообщении создать еще несколько вариантов сценариев. Тогда наш контроллер будет огромного размера и поддерживать такую программу станет слишком сложно.

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

Вместо заключения. Это первый шаблон проектирования ПО который мы рассмотрели. Впереди еще много работы и полезных штук, поэтому... Спасибо всем, кто смог дочитать этот пост до конца несмотря на ужасное оформление, примеры на php и общую безграмотность. Отдельное спасибо всем, кто заходит и подписывается на ютуб канал. Я начинаю готовить видео на тему Шаблонов проектирования. Может быть примеры кода на видео будут более понятны.

• Проследить развитие от идеи до ее реализации и монетизации

• Посмотреть на путь другого человека, что-то подчерпнуть для себя

• Доза мотивации

• Минимальный научпоп в JS, где я хоть что-то понимаю(правда же, так мало материалов, где описывается судьба хоть сколь интересного продукта до момента расцвета/смерти во всех красках и со всеми полагающимся читателям литературных подробностей)

• В моей голове это буквально самая интересная вариация сериала из всех возможных, если это увидит хотя бы один человек, которому это будет интересно на 1/100 от моего интереса, то все уже не зря.

Как можно заметить, слишком много причин все это скрывать и не показывать миру, а потому я здесь.

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

Враги и не только

В хорошей истории должна быть не только экспозиция, но и качественные, хорошо прописанные враги, а в идеале (на мой скромный вкус) антагонисты, у нас они тоже будут, позвольте представить:

• Моя абсолютная некомпетентность в технических вопросах. Я буквально мог только добавить табы через JS на лэндинг.

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

• Отсутствие опыта. Ничего подобного никогда не делал, спросить не у кого.

• Отсутствие мало-мальски прописанной бизнес-модели и понимания монетизации

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

Это была экспозиция, вы знакомы со всеми ключевыми персонажами, но нам пора бежать дальше, нас ждет ИДЕЯ.

Идея собственной персоной

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

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

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

Заключение

Говоря честно, это все небольшая проба пера и попытка заинтересовать читателя, вся история - правдивая, была в нашем мире, текст мой и будет таковым.

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

Рад, что вы дочитали, удачи!

PS: Коли вы дочитали, значит либо время пролетело так незаметно, либо вам понравилось, а на самом деле деле вам понравилось в обоих из этих случаев, если желаете, то можете видеть меня чащи в моем канале в знаменитом месседжере телеграм, там будет тоже самое, только чаще, сильнее и больше.

Написали 5 программистов код на 5 разных фич, причем, некоторые фичи огромные и требуют большого отсмотра кода. Тимлиду нужно несколько раз пройти цикл по каждой фиче: ревью - написание замечаний - исправление - новое ревью. Каждое ревью включает и тестирование кода у себя на предмет работает / не работает + ключевые фичи.

То есть пока программист пишет 1 фичу - тимлид переключается между 5 разными контекстами. Кроме того - за ним созвоны, составление и декомпозиция задач.

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

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

Самое главное - тимлид отвечает за проект. Чтобы он не валился на проде. Чтобы все изменения были безопасными и своей квалификацией и вниманием гарантирует, что программисты не насажают дыры в код, через которые потом будет слита база или положен сервис.

Сколько должен стоить Тимлид?

От х2 до х3 от цены сеньора. Просто прикинем математику.

Сеньор свою работу успевает делать в основном часа за 4 - 6 (лично мне хватает 4 часов). Никто 8 часов не может и не станет неотрывно барабанить по клавиатуре. Это все понимают и в сфере интеллектуального труда не получится как на конвейере без перерыва 8 часов давать продукт.

Поэтому средний программер может взять вторую работу на полставки и получать х1.5 от ЗП (то есть в месяц он будет получать уже не 250К , а 250К + 250К х 0.5 = 375 К) не имея геморрой с код ревью, подчиненными и не отвечать за весь проект.

Отбарабанил свои 8 - 10 часов за компом и пошел пить ванильный латте. Я например умудрялся работать сразу на 2 проектах на полную ставку и закрывал все задачи вовремя за счет высокой концентрации и опыта. Ну один проект сложный - второй - простой и там были типовые задачи. В итоге я имел около 600К в месяц без геморрой и привязки к cозвонам и прочей ерунде, которой приходится страдать тимлидам.

Чтобы сознательно взять на себя геморрой и его квалифицированно разгребать, осознавая, что ты не делаешь подарка компании на благо которой ты работаешь, я бы согласился на должность тимлида минимум за 400К (если проект очень интересный), но ориентировался бы на 500К.

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

Какую пользу принесет опытный тимлид?

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

Поднимайте ставки тимлидам и нанимайте лидов правильно, господа и поменьше доверяйте HR'ам. Они часто дурят вам голову.

Братья-программисты, а что вы думаете - сколько должен стоить тимлид и хотели бы сами стать тимлидом?