Ох как это знакомо, сталкиваюсь на каждом втором проекте. Даже твой цать-летний опыт в какой-то сфере не помогает убедить местных богов, ведь "я же на проекте уже полтора года, что ты имеешь против меня". Самый железобетонный аргумент это, конечно, "у нас так принято" и "мы так договорились". Изменить что-то не получается даже если соглашаются что твое решение лучше, но "исторически сложилось" сильнее чем "сделать лучше" 🤷♀️
еще из последней недели
"задача выложить наш апи в паблик т.к. новый продукт запускаем"
"ало, давайте закроем все внутренние сервисы за одним общим апи-сервисом, это позволит нам гибче распоряжаться внешним видом апи и уменьшит связность своих сервисов и внешнего апи"
"нет времени на ерунду, давай делать в рамках текущих сервисов"
...
"слушай тут такое дело, у команды php вот такое апи, поэтому надо переделать примерно всё, что бы похоже сделать пути и параметры, а то ведь в паблик выкладываем..." 😂
"задача выложить наш апи в паблик т.к. новый продукт запускаем"
"ало, давайте закроем все внутренние сервисы за одним общим апи-сервисом, это позволит нам гибче распоряжаться внешним видом апи и уменьшит связность своих сервисов и внешнего апи"
"нет времени на ерунду, давай делать в рамках текущих сервисов"
...
"слушай тут такое дело, у команды php вот такое апи, поэтому надо переделать примерно всё, что бы похоже сделать пути и параметры, а то ведь в паблик выкладываем..." 😂
Сижу я читаю твиттер в последнее время и наткнулся на всякие интересные программистские активности типа #100daysofcoding. Спасибо коронавирусу, видимо. А они делают какие-то проекты и отчитываются между собой в онлайне и все так весело и задорно :) Ну и я решил тоже что мне пора обновить портфолио пет-проектов, изучить что-то новое и попробовать себя в смм и ведении каких-то площадок более плотно.
Поэтому решил замутить такое: https://github.com/asundukov/testfor.us
Поэтому решил замутить такое: https://github.com/asundukov/testfor.us
GitHub
GitHub - asundukov/testfor.us
Contribute to asundukov/testfor.us development by creating an account on GitHub.
Что это будет? визард для создания онлайн-тестов и опросов. Довольно интересная структура получается из-за наличия 2-3 видов пользователей, можно что-то нового выдумать или попробовать новые подходы. Бекенд - kotlin и Spring Boot. По фронтенду еще не решил.
На будущее есть еще пару задумок чем заниматься в свободное от работы время.
На будущее есть еще пару задумок чем заниматься в свободное от работы время.
Вот такую штуку от нечего делать я написал за последние пару недель. Это всё выродилось в довольно большую историю и у меня даже получился kotlin-framework для создания stateless-ботов, что я даже оформил это на гитхабе (закос под профи, хаха) - https://github.com/asundukov/kotlin-telegram-framework
А так теперь "мемогенерящего" бота может себе запилить любой скачав исходники с моих репозиториев и запустив это у себя на сервере.
Шучу, конечно я уже это запустил - @MemeBuilderBot
А так теперь "мемогенерящего" бота может себе запилить любой скачав исходники с моих репозиториев и запустив это у себя на сервере.
Шучу, конечно я уже это запустил - @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 ... )
Что ж! С них и начнем!
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
DRY или Don't Repeat Yourself (не повторяй себя), - наверное, один из самых несложных принципов программирования. Он сводится к тому, чтоб каждый кусочек информации в IT системе был представлен в единственном варианте во избежание дублированного представления. Если мы говорим непосредственно про код, то придерживаясь этого принципа во время разработки позволяет вам:
👍🏻 поддерживать минимальное количество кода при той же функциональности
👍🏻 избежать наличия тех багов, от которых вы уже избавились - отсутствие дублирующихся частей кода позволяет избежать необходимости копипаста исправлений при любом исправлении
👍🏻 уменьшить связность кода за счет того, что внешние зависимости используются в каждой части только в единственном экземпляре
Не стоит так же забывать о том что DRY вполне себе тесно связан с качеством кода, в частности с принципом Single Responsibility. В случае SRP это происходит, потому что вам приходится выносить общие кусочки кода в отдельные общие методы, что уменьшает зону ответственности каждого метода.
"Сухого" вам кода ;)
#DRY #SRP
Проектная терминология
Вы когда-нибудь сталкивались с проблемой когда у вас в системе есть 2-3 или больше ролей, часть из которых для других являются "пользователями". В итоге получается такая ситуация когда термином "пользователь" в вашей системе обознаются несколько совершенно не связанных бизнес-сущностей, а помимо этого и сами пользователи называются пользователями. В итоге на некоторых совещаниях можно услышать "Пользователь-админ создает пользователя-модератора, у которого есть право модерировать сообщения пользователей в чате, чтоб пользователи не испытывали проблем с другими пользователями. Но что мы будем делать с VIP-пользователями пользователей-рекламодателей?". Все это приправляется тем что под словом пользователь каждый участник встречи понимает примерно разное - для кого-то сущность в системе с id, user и email, для кого-то - человек сидящий с лэптопом дома. В итоге на каждом совещании мне приходилось держать в голове примерное понимание значения терминов для каждого участника митинга, а потом еще и разруливать споры, возникающие на основе этого смещения смысла.
Примерно с тех пор на каждый командный проект, в котором мне приходилось участвовать с самого начала, я создаю документ (или часть тз) с названием "Терминология". Основной смысл - договориться со всеми участниками проекта о том, что конкретно мы называем и какими терминами. Это позволяет избежать ситуаций, когда один термин начинают обозначать 2-3 сущности, тогда как другая сущность выражается сразу терминами "мерчант", "продавец", "торговец", "магазин" и т.д.
🙄 Впрочем, проблему с терминологией и определениями в спорах я замечаю не только на рабочих митингах - но и в жизни. Зачастую люди начинают спорить о чем-то, не договорившись о смысле того, что они понимают под разными терминами. Попробуй-ка поспорить о любви , у которой в принципе десятки определений.
☝️ Не забывайте мэтчить термины перед обсуждением, спором или стартом проекта ;)
Вы когда-нибудь сталкивались с проблемой когда у вас в системе есть 2-3 или больше ролей, часть из которых для других являются "пользователями". В итоге получается такая ситуация когда термином "пользователь" в вашей системе обознаются несколько совершенно не связанных бизнес-сущностей, а помимо этого и сами пользователи называются пользователями. В итоге на некоторых совещаниях можно услышать "Пользователь-админ создает пользователя-модератора, у которого есть право модерировать сообщения пользователей в чате, чтоб пользователи не испытывали проблем с другими пользователями. Но что мы будем делать с VIP-пользователями пользователей-рекламодателей?". Все это приправляется тем что под словом пользователь каждый участник встречи понимает примерно разное - для кого-то сущность в системе с id, user и email, для кого-то - человек сидящий с лэптопом дома. В итоге на каждом совещании мне приходилось держать в голове примерное понимание значения терминов для каждого участника митинга, а потом еще и разруливать споры, возникающие на основе этого смещения смысла.
Примерно с тех пор на каждый командный проект, в котором мне приходилось участвовать с самого начала, я создаю документ (или часть тз) с названием "Терминология". Основной смысл - договориться со всеми участниками проекта о том, что конкретно мы называем и какими терминами. Это позволяет избежать ситуаций, когда один термин начинают обозначать 2-3 сущности, тогда как другая сущность выражается сразу терминами "мерчант", "продавец", "торговец", "магазин" и т.д.
🙄 Впрочем, проблему с терминологией и определениями в спорах я замечаю не только на рабочих митингах - но и в жизни. Зачастую люди начинают спорить о чем-то, не договорившись о смысле того, что они понимают под разными терминами. Попробуй-ка поспорить о любви , у которой в принципе десятки определений.
☝️ Не забывайте мэтчить термины перед обсуждением, спором или стартом проекта ;)
Чему учить джунов
Немного с болью наблюдаю как на некоторых проектах джунов кидают в легаси со словами "ГОД ЗА ДВА".
Они там бултыхаются и кое-как плавают. Знаете, как если ребенка, не умеющего плавать, кинуть в воду. Он, конечно, поплывет. Под улюлюкание стоящих на борту моряков-сениоров. Но никакой техничности в этом плавании не будет, а переучиться потом будет сложнее.
Вот так же и молодых разработчиков выкидывают, а они легаси читают и потом пишут так же, ведь мало кто им объяснит, что то, что они сейчас видят - антипаттерн, а к результату их деятельности в легаси проекте относятся как "и так сойдет, это же легаси".
Что в итоге? Никакого clean code, сплошные if'ы, тестов нет. Растет новый "сениор".
#cleancode #juniors
Немного с болью наблюдаю как на некоторых проектах джунов кидают в легаси со словами "ГОД ЗА ДВА".
Они там бултыхаются и кое-как плавают. Знаете, как если ребенка, не умеющего плавать, кинуть в воду. Он, конечно, поплывет. Под улюлюкание стоящих на борту моряков-сениоров. Но никакой техничности в этом плавании не будет, а переучиться потом будет сложнее.
Вот так же и молодых разработчиков выкидывают, а они легаси читают и потом пишут так же, ведь мало кто им объяснит, что то, что они сейчас видят - антипаттерн, а к результату их деятельности в легаси проекте относятся как "и так сойдет, это же легаси".
Что в итоге? Никакого clean code, сплошные if'ы, тестов нет. Растет новый "сениор".
#cleancode #juniors
#риторическийвопрос
Полет на марс
🌌 Не так давно смотрел ролик про марсоходы, в частности посадка Curiosity на марс, представляете насколько волнительно наблюдать инженерам за работой своего детища в плохо изученном окружении (environment) в самый сложный момент и опасный момент - выбор точки посадки, нагрузка при торможении, довольно сложная последовательность предпосадочных операций, реактивное торможение, "небесный кран". И все это - без возможности управления и с пингом в 10-20 минут?
🐌 Иногда мне кажется что подобное я чувствую когда мне нужно получить информацию с продакшн-окружения, но из-за политик безопасности у меня нет ни доступа к логам, ни к базе данных. Нужно делать запросы к службе администрирования или безопасности за доступом к логам или событиям за определенный момент или отправлять им SQL-запросы которые бы хоть как-то дали понимание о том что происходит в том окружении, для которого мы собственно и делаем все нашу работу. Только пинги тут могут быть часовые, а результаты могут быть искажены не всегда точным пониманием запроса.
❓ С одной стороны безопасность безусловно важна в реалиях 21го века, с другой стороны - сколько она может стоить? Стоит ли она того что часть процессов разработки замедляется на порядок, а ее точность падает? От части идей в таких случаях мне приходится отказываться, когда я осознаю что с точки зрения скорости воплощения в жизнь это будет слишком медленно или слишком дорого для бизнеса. Но выгоднее ли это, чем иметь более гибкие политики по отношению к данным? Тем более что эти данные зачастую уже защищены - ну правда, никто же в здравом уме не хранит пароли в базе данных в открытом виде или, например, данные банковских карт. По крайней мере в тех системах, где служба безопасности не может расщедриться хотя бы на read-only доступ ведущим разработчикам на проектах которые они ведут. Конечно, я сейчас говорю и малых и средних проектах. На уровнях гугла, фейсбука и т.д. разумеется есть свои внутренние решения по оптимизации таких процессов.
🧠 В общем - в моей голове этот вопрос уже долгое время остается нерешенным и становится риторическим.
#security #management
Полет на марс
🌌 Не так давно смотрел ролик про марсоходы, в частности посадка Curiosity на марс, представляете насколько волнительно наблюдать инженерам за работой своего детища в плохо изученном окружении (environment) в самый сложный момент и опасный момент - выбор точки посадки, нагрузка при торможении, довольно сложная последовательность предпосадочных операций, реактивное торможение, "небесный кран". И все это - без возможности управления и с пингом в 10-20 минут?
🐌 Иногда мне кажется что подобное я чувствую когда мне нужно получить информацию с продакшн-окружения, но из-за политик безопасности у меня нет ни доступа к логам, ни к базе данных. Нужно делать запросы к службе администрирования или безопасности за доступом к логам или событиям за определенный момент или отправлять им SQL-запросы которые бы хоть как-то дали понимание о том что происходит в том окружении, для которого мы собственно и делаем все нашу работу. Только пинги тут могут быть часовые, а результаты могут быть искажены не всегда точным пониманием запроса.
❓ С одной стороны безопасность безусловно важна в реалиях 21го века, с другой стороны - сколько она может стоить? Стоит ли она того что часть процессов разработки замедляется на порядок, а ее точность падает? От части идей в таких случаях мне приходится отказываться, когда я осознаю что с точки зрения скорости воплощения в жизнь это будет слишком медленно или слишком дорого для бизнеса. Но выгоднее ли это, чем иметь более гибкие политики по отношению к данным? Тем более что эти данные зачастую уже защищены - ну правда, никто же в здравом уме не хранит пароли в базе данных в открытом виде или, например, данные банковских карт. По крайней мере в тех системах, где служба безопасности не может расщедриться хотя бы на read-only доступ ведущим разработчикам на проектах которые они ведут. Конечно, я сейчас говорю и малых и средних проектах. На уровнях гугла, фейсбука и т.д. разумеется есть свои внутренние решения по оптимизации таких процессов.
🧠 В общем - в моей голове этот вопрос уже долгое время остается нерешенным и становится риторическим.
#security #management