Здравствуйте, уважаемые подписчики и гости канала!
Навеяно книгой - Принципы: Жизнь и работа, которую написал Рей Далио
Зачем нужны принципы?
Принцип - это когда не нужен менеджер, который тебе скажет как, ты можешь сам принять решение на основании принципа или, если угодно стратегии. Также на основе принципов можно делать автоматизации процессов. Это позволяет передавать знания от более опытных членов команды и растить новеньких быстрее.
Плохая архитектура, не оптимальные нагруженные места, сложный код и излишне долгие размышления или обсуждения о "лучшем" варианте - усложняют и удорожают обслуживание сервисов и бизнес вынужден платить больше денег, что сказывается на фин. результатах работы команды в целом. Некоторые вещи стоит заложить в фундамент команды и возвращаться к их обсуждение редко, но применять часто в повседневной работе.
Принципы у каждой команды скорее всего будет отличаться, вот мои.
Принцип 1. Простота
Если нет необходимости в адской оптимизации (а ее как правило нет), то нет смысла делать сложные решения, так как потом твои коллеги будут испытывать проблемы с пониманием архитектуры и все в итоге будут недовольны. Надо сказать, что если для простоты вы копируете кучу кода из скрипта в скрипт уже третий раз (а иногда даже второй, если это 20-30 строчек бизнес логики по каким-нибудь зачислениям денег), то это сложно назвать простым решением, так как потом это возможно будет неудобно поддерживать и это - хорошее место для абстракции.
Принцип 2. Единая ответственность (расширяемость под проекты)
Старайся не обобщать абсолютно все, так как ты создашь единую точку изменения между проектами. Например у тебя какая-то хранимка, которая считает исчерпание лимитов в других БД всех продуктов. Это может быть не очень хорошим вариантом, так как приводит к аккумуляции изменений всех проектов в едином месте, что сложно и добавляет связанности, однако не впадай в крайности - есть куча примеров, когда такие места успешно эксплуатируются, годами никому не мешая. Задумайся о микросервисной архитектуре под управлением gateway api для разделения ответственности, сохраняя обобщение.
Принцип 3. Экономия ресурсов
Если место нагруженное и речь идет о сотнях миллионов записей в БД, то необходимо использовать оптимальные типы данных, например int4 или int2 вместо int8, date вместо datetime. Обработка данных почти всегда должна делаться непосредственно в БД, а не так, что 1 млн. строк выбираются в python и там группируются, join-ятся или фильтруются. Это как правило эффективнее делать в БД.
Принцип 4. Удобство пользователя
Имеется в виду не только пользователь интерфейса, а например программист-пользователь API. Хорошо не заставлять делать больше минимального. Правда порой лучше заставить вписывать больше параметров для того, чтобы пользователь или программист понимали как именно все будет работать. Однако, если это будет долговременная работа,то задумайтесь, действительно ли важно удобство именно сейчас? Не стоит ли сперва сделать рабочий вариант для того, чтобы просто проверить хотя бы на себе - будет ли оно работать в принципе или нет? К этому пункту также относится и скорость работы - например скорость API или скорость пересчета счетчиков для чего-то.
Важно: Если пользователь не видит результата своих действий в интерфейсе, то он будет считать, что результата не было и что-то не работает
Принцип 5. Исправление ошибок и недочетов
Принимай свои ошибки спокойно и старайся их исправлять как можно быстрее, не в ущерб текущим важным делам. Пользователи или коллеги рано или поздно обратят внимание на ошибку или недочет, коллеги скорее всего будут недовольны, а пользователи могут перестать пользоваться продуктом, поэтому в идеальном мире надо исправлять ошибку сразу же. Однако это не всегда возможно по разным причинам - если есть более важные задачи, вам надоело исправлять ошибки в этом продукте, вам надоел продукт. В этих случаях обсуди с менеджером проблему, так как ее надо решать в любом случае.
API, конечно, должно в первую очередь выполнять свою роль, но также и работать достаточно быстро (не дольше 5 сек это точно, если речь не идет про отдачу статистики и пр. нагруженной штуки), не должно падать с 500-мы, так как это вызывает еще большое количество запросов из-за того, что клиенты делают дополнительные запросы и это только ухудшает ситуацию.
Стремись писать код так, чтобы в случае если он долго работал и упал посередине он мог начать примерно с того же места или в худшем случае хотя бы сам перезапускался. Например, хорошо будет, если вы посчитали какие-нибудь счетчики 40% клиентов попутно записывая результат и при падении начали с того же места.
Принцип 6. Скрипты автоматизации под задачи
Цени свое время и пиши python скрипты для автоматизации твоей работы, даже если это, как тебе кажется, единоразовая, но долгая и муторная процедура. Скрипты обязательно крепи к задачам - как ни странно, довольно часто их нужно доставать из истории. Когда я стараюсь это делать:
- когда мне надо сравнить данные в таблицах или БД
- когда надо в удалить что-то в БД и для этого надо много раз что-то запускать, так как удалить запросом за один раз невозможно и приходится запускать удаление пачки, следить, пока не доработает и запускать следующую
Принцип 7. Используй и улучшай наработки коллег
Прежде чем делать что-то новое, убедись, что тоже самое или похожее сейчас не делает какой-то фоновый скрипт или api. Если там не всего хватает рассмотри возможно доработки сервиса, так как таким образом мы не будем топтаться на месте и кодить одно и тоже, а наоборот будем быстрее и качественнее развиваться, при этом экономя время.
Да, порой, это делать не хочется, но это часто лучшее решение, чем писать с нуля. Если переписать все же стоит, как вы думаете, то стоит в задаче описать конкретные причины этого и обсудить с коллегами, прежде чем кодить. Помните про Why, What, DOD
Принцип 8. Не затягивай с принятием решений и деплоем задач
Любое решение имеет недостатки и с любым придется жить долгое время. Бездействие в принятии решения почти так же плохо как и выбор плохого решения, так как ничто никуда не двигается, гипотезы не проверяются, развитие не идет. Речь идет не о том, чтобы вообще не думать, а том, что мы очень любим откладывать сложные решения или деплой задачи в продакшен из-за каких-то внутренних терзаний, совсем не связанных с реалиями.
Принцип 9. Предлагайте реальные выполнимые решения
Проще всего предложить "все переделать с нуля" или сказать, что надо бы использовать технологию Х (но сейчас этой технологии в компании нет). Такие разговоры хороши для моделирования в голове будущих далеки целей. Но если надо сделать исследование на улучшение того, что есть и при этом получить вменяемый срок выполнения и понятный roadmap, то вы должны исходить из того, что у вас есть под рукой прямо сейчас.
В рамках конкретной задачи не предлагайте велосипедов, которые отдаленно похожи на технологию Х, но при этом сильно не дотягивают до ее уровня. Не предлагайте технологию Х, если вы ее не обкатали заранее на других задачах и не знаете ее подводных камней. Это все нужно делать только на специальных задачах типа "Проверить технологию Х на применимость", где есть цель и метрики проверки.
Материалы
1. Прекрасное видео про передачу знаний, с примерами.
2. Видео про то, как важно делегировать все - в том числе знания.
---
А на этом всё, спасибо за внимание!
Подписывайтесь на канал, ставьте лайки, оставляйте комментарии - это помогает продвижению в Дзене.
Кроме этого:
Подписывайтесь в Telegram: https://t.me/lets_goto_it