Ох как это знакомо, сталкиваюсь на каждом втором проекте. Даже твой цать-летний опыт в какой-то сфере не помогает убедить местных богов, ведь "я же на проекте уже полтора года, что ты имеешь против меня". Самый железобетонный аргумент это, конечно, "у нас так принято" и "мы так договорились". Изменить что-то не получается даже если соглашаются что твое решение лучше, но "исторически сложилось" сильнее чем "сделать лучше" 🤷‍♀️

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

...

"слушай тут такое дело, у команды php вот такое апи, поэтому надо переделать примерно всё, что бы похоже сделать пути и параметры, а то ведь в паблик выкладываем..." 😂

Сижу я читаю твиттер в последнее время и наткнулся на всякие интересные программистские активности типа #100daysofcoding. Спасибо коронавирусу, видимо. А они делают какие-то проекты и отчитываются между собой в онлайне и все так весело и задорно :) Ну и я решил тоже что мне пора обновить портфолио пет-проектов, изучить что-то новое и попробовать себя в смм и ведении каких-то площадок более плотно.
Поэтому решил замутить такое: https://github.com/asundukov/testfor.us

Что это будет? визард для создания онлайн-тестов и опросов. Довольно интересная структура получается из-за наличия 2-3 видов пользователей, можно что-то нового выдумать или попробовать новые подходы. Бекенд - kotlin и Spring Boot. По фронтенду еще не решил.

На будущее есть еще пару задумок чем заниматься в свободное от работы время.

Вот такую штуку от нечего делать я написал за последние пару недель. Это всё выродилось в довольно большую историю и у меня даже получился kotlin-framework для создания stateless-ботов, что я даже оформил это на гитхабе (закос под профи, хаха) - https://github.com/asundukov/kotlin-telegram-framework

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

Шучу, конечно я уже это запустил - @MemeBuilderBot

На днях собеседовался в одну компанию в Польшу. В целом меня оценили очень хорошо, но один коммент меня удивил:
Andrei has in general quite long experience in IT but still, he doesn't know some term, names popular in IT words (TDD, SOLID, YAGNI ... )

Что ж! С них и начнем!

DRY

DRY или Don't Repeat Yourself (не повторяй себя), - наверное, один из самых несложных принципов программирования. Он сводится к тому, чтоб каждый кусочек информации в IT системе был представлен в единственном варианте во избежание дублированного представления. Если мы говорим непосредственно про код, то придерживаясь этого принципа во время разработки позволяет вам:
👍🏻 поддерживать минимальное количество кода при той же функциональности
👍🏻 избежать наличия тех багов, от которых вы уже избавились - отсутствие дублирующихся частей кода позволяет избежать необходимости копипаста исправлений при любом исправлении
👍🏻 уменьшить связность кода за счет того, что внешние зависимости используются в каждой части только в единственном экземпляре

Не стоит так же забывать о том что DRY вполне себе тесно связан с качеством кода, в частности с принципом Single Responsibility. В случае SRP это происходит, потому что вам приходится выносить общие кусочки кода в отдельные общие методы, что уменьшает зону ответственности каждого метода.

"Сухого" вам кода ;)

#DRY #SRP

Проектная терминология

Вы когда-нибудь сталкивались с проблемой когда у вас в системе есть 2-3 или больше ролей, часть из которых для других являются "пользователями". В итоге получается такая ситуация когда термином "пользователь" в вашей системе обознаются несколько совершенно не связанных бизнес-сущностей, а помимо этого и сами пользователи называются пользователями. В итоге на некоторых совещаниях можно услышать "Пользователь-админ создает пользователя-модератора, у которого есть право модерировать сообщения пользователей в чате, чтоб пользователи не испытывали проблем с другими пользователями. Но что мы будем делать с VIP-пользователями пользователей-рекламодателей?". Все это приправляется тем что под словом пользователь каждый участник встречи понимает примерно разное - для кого-то сущность в системе с id, user и email, для кого-то - человек сидящий с лэптопом дома. В итоге на каждом совещании мне приходилось держать в голове примерное понимание значения терминов для каждого участника митинга, а потом еще и разруливать споры, возникающие на основе этого смещения смысла.

Примерно с тех пор на каждый командный проект, в котором мне приходилось участвовать с самого начала, я создаю документ (или часть тз) с названием "Терминология". Основной смысл - договориться со всеми участниками проекта о том, что конкретно мы называем и какими терминами. Это позволяет избежать ситуаций, когда один термин начинают обозначать 2-3 сущности, тогда как другая сущность выражается сразу терминами "мерчант", "продавец", "торговец", "магазин" и т.д.

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

☝️ Не забывайте мэтчить термины перед обсуждением, спором или стартом проекта ;)

Чему учить джунов

Немного с болью наблюдаю как на некоторых проектах джунов кидают в легаси со словами "ГОД ЗА ДВА".

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

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

Что в итоге? Никакого clean code, сплошные if'ы, тестов нет. Растет новый "сениор".

#cleancode #juniors

#риторическийвопрос

Полет на марс

🌌 Не так давно смотрел ролик про марсоходы, в частности посадка Curiosity на марс, представляете насколько волнительно наблюдать инженерам за работой своего детища в плохо изученном окружении (environment) в самый сложный момент и опасный момент - выбор точки посадки, нагрузка при торможении, довольно сложная последовательность предпосадочных операций, реактивное торможение, "небесный кран". И все это - без возможности управления и с пингом в 10-20 минут?

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

❓ С одной стороны безопасность безусловно важна в реалиях 21го века, с другой стороны - сколько она может стоить? Стоит ли она того что часть процессов разработки замедляется на порядок, а ее точность падает? От части идей в таких случаях мне приходится отказываться, когда я осознаю что с точки зрения скорости воплощения в жизнь это будет слишком медленно или слишком дорого для бизнеса. Но выгоднее ли это, чем иметь более гибкие политики по отношению к данным? Тем более что эти данные зачастую уже защищены - ну правда, никто же в здравом уме не хранит пароли в базе данных в открытом виде или, например, данные банковских карт. По крайней мере в тех системах, где служба безопасности не может расщедриться хотя бы на read-only доступ ведущим разработчикам на проектах которые они ведут. Конечно, я сейчас говорю и малых и средних проектах. На уровнях гугла, фейсбука и т.д. разумеется есть свои внутренние решения по оптимизации таких процессов.

🧠 В общем - в моей голове этот вопрос уже долгое время остается нерешенным и становится риторическим.

#security #management

SOLID

👆 SOLID - одни из самых известных принципов для написания качественного ООП кода. Насколько бы простыми и интуитивно понятными они не казались - в своем конечном варианте они были сформулированы только в 2000м году Робертом Мартином.

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

👇 В первый раз когда я про это прочитал и осознал - у меня буквально перевернулся взгляд на то, как писать код, почему его надо писать по-другому. Итак:

🪑 SRP (Single Responsibility Principle) - Принцип единственной ответственности. О том, что каждый класс должен отвечать за одну и только одну функциональность.
🚪 OCP (Open-Closed Principle) - Принцип открытости закрытости. О том, что классы должны быть открыты для расширения, но закрыты для изменения.
👨‍👩‍👧 LSP (Liskov Substitution Principle) - Принцип подстановки Барбары Лисков. О правильном поведении при наследовании.
🧩 ISP (Interface-Segregation Principle) - Принцип разделения интерфейса. О том, как правильно использовать интерфейсы и абстракции.
🔃 DIP (Dependency Inversion Principle) - Принцип инверсии зависимостей. О правильной организации зависимостей на разных уровнях программы.

💬 В следующих постах периодически буду раскрывать подробнее что тут происходит.

#SOLID #Principles

Оператор if

Чем больше программирую, тем больше не люблю оператор if и стараюсь избегать его использования. Все дело в том, что из-за него вы начинаете генерировать ветки кода, что усложняет его понимание. Более того ваш код сложнее тестировать т.к. на тот же метод нужно написать больше тестов чтоб покрыть ими все возможные ветки выполнения. Например, 3 структуры if-else в теле метода уже генерируют до 8 возможных разных веток выполнения кода.

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

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

#if #SRP