Всем привет
#резюме #golang #typescript
Senior Backend-разработчик на TypeScript с опытом тимлида, перехожу на Go
Обо мне:
- Опыт: более 4 лет в backend-разработке (с 2019 года) на TypeScript, включая проектирование архитектуры, код-ревью и управление командой.
- Знаком с Code Complete и Clean Architecture, умею писать поддерживаемый, чистый код.
- Командный игрок с высокой технической экспертизой и навыками решения сложных задач.
- Теоретические знания в области "распределённых систем".
Что могу предложить:
- Технические решения для бизнес-задач, четкое распределение задач по команде.
- Пишу код в соответствии с практиками _Совершенного кода_, провожу код-ревью.
- Готов дать коммерческую ценность, быстро осваиваю новые языки и технологии.
О Go: готов к техническому собеседованию
Технологический стек:
- Отличный опыт: TypeScript, Node.js, PostgreSQL, Docker, Fastify, MongoDB
- Ссылки:
github
hh.ru
stackoverflow
linkedin
npm
leetcode
Ищу удаленную работу с перспективой долгосрочного сотрудничества, быстро вникну в кодовую базу и готов активно участвовать в проекте.
Большое спасибо за уделённое время этому сообщению
фига перец
пока
пока
знаком с принципами Dirty Code
Alexey
Жду момента, когда Clean Code окончательно вымрет, и перестанут упоминать этот ужас
а что ужасного в нëм?
Роман
noi
а что ужасного в нëм?
Сборник вредных советов и говнокода. Есть разумные советы, есть устаревшие, есть просто неправильные.
Функции 2-5 строк - бесмысленное, нечитаемое нечто.
DRY - зло, пораждающее бесконечные абстракции.
Функции без сайд-эффектов - невыполнимо в реальной бизнес логике.
Во flag arguments нет ничего плохого, в меру.
Примеры кода буквально вырвиглазные, такое не прошло бы код ревью.
noi
Много разумных советов, но очень большой упор на маленьких функциях, а это ужасно. Джуны дуреют с этой прикормки после подобных книг начинают слепо следовать догмам и порождать нечто, написано ведь "чистый" код.
Роман
noi
а что стоит изучить джуну ?
Работать. Смотреть на реальные репозитории, либо в гитхабе, либо на работе
Сергей
Сборник вредных советов и говнокода. Есть разумные советы, есть устаревшие, есть просто неправильные.
Функции 2-5 строк - бесмысленное, нечитаемое нечто.
DRY - зло, пораждающее бесконечные абстракции.
Функции без сайд-эффектов - невыполнимо в реальной бизнес логике.
Во flag arguments нет ничего плохого, в меру.
Примеры кода буквально вырвиглазные, такое не прошло бы код ревью.
Так небольшие функции, наоборот упрощают читаемость кода. Куда хуже будет если функция будет из десятков строк кода, её будет гораздо тяжелее понимать
Ilya
noi
Так небольшие функции, наоборот упрощают читаемость кода. Куда хуже будет если функция будет из десятков строк кода, её будет гораздо тяжелее понимать
Нет. Если функции по 3 строки кода, значит будет награмождение вызовов функций, что бы прыгать по ним и понять логику происходящего - нужно держать в голове гигантский контекст и мысленно "выстраивать карту" вызовов.
Если функция требует 20 строк для выполнения своей задачи, пусть будет 20 строк. Необходимо 100? Пиши 100.
Артём
Думаю тут больше проблем с пониманием чистого кода, нежели в самом чистом коде. Мысль о том чтобы логически связные строки кода собирать в функции вполне себе правильная. Проблема начинается когда это начинает делаться всегда, невзирая на контекст и надобность
Edgar
Сборник вредных советов и говнокода. Есть разумные советы, есть устаревшие, есть просто неправильные.
Функции 2-5 строк - бесмысленное, нечитаемое нечто.
DRY - зло, пораждающее бесконечные абстракции.
Функции без сайд-эффектов - невыполнимо в реальной бизнес логике.
Во flag arguments нет ничего плохого, в меру.
Примеры кода буквально вырвиглазные, такое не прошло бы код ревью.
а какой в вашем понимании эталон размера функции?
Awesome
пошла прожарка резюме
Сергей
Awesome
Awesome
интересная статистика
noi
а какой в вашем понимании эталон размера функции?
Никакой, не нужно заниматься дрочкой на метрики, пиши то, что подходит к ситуации. Это как "обязательное покрытие 98% тестами", почему 98%? Непонятно.
Сергей
пошла прожарка резюме
Да там прожаривать нечего. Многие проекты для вида + проект с курса по YouTube)
Alexey
Сборник вредных советов и говнокода. Есть разумные советы, есть устаревшие, есть просто неправильные.
Функции 2-5 строк - бесмысленное, нечитаемое нечто.
DRY - зло, пораждающее бесконечные абстракции.
Функции без сайд-эффектов - невыполнимо в реальной бизнес логике.
Во flag arguments нет ничего плохого, в меру.
Примеры кода буквально вырвиглазные, такое не прошло бы код ревью.
сыглы
>Функции без сайд-эффектов - невыполнимо в реальной бизнес логике.
Вообще возможно, привет Скала
Сергей
Никакой, не нужно заниматься дрочкой на метрики, пиши то, что подходит к ситуации. Это как "обязательное покрытие 98% тестами", почему 98%? Непонятно.
функция 100 строк, из покрытия убираем название функции и конец блока, остается 98 строк, 98 строк из 100 это 98%
тайна разгадана)
noi
Думаю тут больше проблем с пониманием чистого кода, нежели в самом чистом коде. Мысль о том чтобы логически связные строки кода собирать в функции вполне себе правильная. Проблема начинается когда это начинает делаться всегда, невзирая на контекст и надобность
Вот именно, всегда нужно действовать по ситуации, а не по правилам "10 строк = делаю 2 функции"
Артём
директор интернета
надо по вайбам все делать
Vlad
Vlad
функция 100 строк, из покрытия убираем название функции и конец блока, остается 98 строк, 98 строк из 100 это 98%
тайна разгадана)
Покрытие считается по операторам
Сергей
Вот именно, всегда нужно действовать по ситуации, а не по правилам "10 строк = делаю 2 функции"
Не ну разбивать функции по количеству строк) это сильно)
Если ты имел именно количество строк, а не смысловую часть, то я с тобой согласен, это пиздец.
Ilya
Сборник вредных советов и говнокода. Есть разумные советы, есть устаревшие, есть просто неправильные.
Функции 2-5 строк - бесмысленное, нечитаемое нечто.
DRY - зло, пораждающее бесконечные абстракции.
Функции без сайд-эффектов - невыполнимо в реальной бизнес логике.
Во flag arguments нет ничего плохого, в меру.
Примеры кода буквально вырвиглазные, такое не прошло бы код ревью.
От языка зависит. В ФП это всегда очень эргономично, ну а в какой-нибудь Джаве ты будешь вынужден спамить классами
Илья
Да там прожаривать нечего. Многие проекты для вида + проект с курса по YouTube)
noi
сыглы
>Функции без сайд-эффектов - невыполнимо в реальной бизнес логике.
Вообще возможно, привет Скала
Вот это вообще интересный вопрос, например можно ли рассматривать БД как сайд-эффект? Думаю в случае, если от инфы в бд меняется логика - вполне. На эту тему можно часами рассуждать
Vlad
Вот это вообще интересный вопрос, например можно ли рассматривать БД как сайд-эффект? Думаю в случае, если от инфы в бд меняется логика - вполне. На эту тему можно часами рассуждать
Если сервис использует базу, то он не стейтлес короче воооот
noi
От языка зависит. В ФП это всегда очень эргономично, ну а в какой-нибудь Джаве ты будешь вынужден спамить классами
Будем честны, на чистых ФП языках почти никто бизнес-логику не пишет. Elixir где-то применяется, но это весьма экзотично
Ilya
Aleks
Много разумных советов, но очень большой упор на маленьких функциях, а это ужасно. Джуны дуреют с этой прикормки после подобных книг начинают слепо следовать догмам и порождать нечто, написано ведь "чистый" код.
Это в противовес ООП умение декомпозиции для функционального подхода. Просто чуть дургой способ мышления, для джавистов тяжело зайдет. :)
Ilya
С каких порс раст - функциональный? С функциональными фичами - да
А нам с тобой нужны функциональные фичи, или сто тупых ограничений, которые в комплекте с чистым ФП?
Eugene
оспидя, с обсуждения работы и околонаймовых вещей, скатились в какие-то говнохоливары :)
Aleks
Сборник вредных советов и говнокода. Есть разумные советы, есть устаревшие, есть просто неправильные.
Функции 2-5 строк - бесмысленное, нечитаемое нечто.
DRY - зло, пораждающее бесконечные абстракции.
Функции без сайд-эффектов - невыполнимо в реальной бизнес логике.
Во flag arguments нет ничего плохого, в меру.
Примеры кода буквально вырвиглазные, такое не прошло бы код ревью.
В некоторых местах чистые функции возможны, в некоторых нет. Если без фанатизма, советы вполне логичные.
noi
Если сервис использует базу, то он не стейтлес короче воооот
Начнем с того, что компьютеры сами по себе - это stateful машины)
Чистое ФП это круто в теории, на практиктике это встречается редко.
Хотя может ФП специалисты меня поправят, я в этом не эксперт
Aleks
Вот это вообще интересный вопрос, например можно ли рассматривать БД как сайд-эффект? Думаю в случае, если от инфы в бд меняется логика - вполне. На эту тему можно часами рассуждать
Любая внешняя зависимость влияющая на возвращаемый функцией результат. Там чистые функции ловят некие ДТО, отдают другие ДТО, а на вход ДТО поставляет не чистая функция что лазите в базу.
noi
А нам с тобой нужны функциональные фичи, или сто тупых ограничений, которые в комплекте с чистым ФП?
Так речь ведь о чистом ФП. Функциональные фичи уже давно во всех языках есть, это даже обсуждать не надо
Ilya
Так речь ведь о чистом ФП. Функциональные фичи уже давно во всех языках есть, это даже обсуждать не надо
Ну давай — вырази мне sum type на Джаве :)
Aleks
функция 100 строк, из покрытия убираем название функции и конец блока, остается 98 строк, 98 строк из 100 это 98%
тайна разгадана)
Иногда нет нечего плохого в том что функция 100 строк. Есть паттерн транзакшен скрипт.
noi
В некоторых местах чистые функции возможны, в некоторых нет. Если без фанатизма, советы вполне логичные.
Конечно, и чем больше чистых функций - тем лучше. Но совсем без сайд-эффектов не обойтись
Ilya
Конечно, и чем больше чистых функций - тем лучше. Но совсем без сайд-эффектов не обойтись
Ну а кто сказал что Clean Code это инструкция как писать весь код
noi
Ну давай — вырази мне sum type на Джаве :)
Ну не надо докапываться)
Функциональщина давно зарекомендовала себя как удобный инструмент. А pure FP - удел академиков
noi
Ну а кто сказал что Clean Code это инструкция как писать весь код
Может никто не говорил, но воспринимали её именно так, к сожалению
Сергей
Иногда нет нечего плохого в том что функция 100 строк. Есть паттерн транзакшен скрипт.
какие-то вы серьезные сегодня
noi
Пора переименовывать чат в "Golang Discussions + job offers"
Olgen
#вакансия #go #golang #senior #TeamLead
Продукт: Мы разрабатываем продукт в сфере детейлинга, который будет включать функции записи клиентов, учета заработной платы сотрудников, статистики продаж, автоматизации регулярных задач и приема авто в работу.
✔️Наш стек: Go, JS (react), PostgreSQL, MySQL, RabbitMQ, Memcached/Redis, ElasticSearch, Docker.
💻Вакансия: Senior / Team Lead Developer (Go, JS) 💰 Зарплата: 350-450 тыс. руб. ⌚️ Режим работы: гибкое начало рабочего дня, удаленка из РФ 🌍
Чем предстоит заниматься:
- Управлением и планированием работы отдела разработки
- Постановкой задач в разработку, курированием, консультированием и контролем их выполнения на всех этапах развития продукта
- Проектированием архитектуры разрабатываемого продукта
- Интеграцией продукта с внешними сервисами
- Развитием функциональности продукта в соответствии с требованиями бизнеса и пользователей
🚀 Продукт находится в самом начале своего пути, и мы ищем сильного разработчика с опытом построения архитектуры практически с нуля и формирования команды.
Резюме можно отправить тг @HR_ITspb
Илья
+ some pathetic resumes
Судя по обилию критики и 'конструктива' с твоей стороны, возможно ты бы мог поделиться примером идеального, ну или хотя бы not pathetic СВОЕГО резюме и github, по возможности было бы хорошо также приложить leetcode
Ну и, само собой, аргумент о том, что ты не занимался этим, потому что уже работаешь и тебе не до того, не принимается, ведь время на 'конструктивную' критику предоставленного мной резюме и гитхаба у тебя нашлось
Или же это всё попытка "самовыражения" через рыганье желчью в чате ❤️
Eugene
K🤣
пока
Dmitrii
Никакой, не нужно заниматься дрочкой на метрики, пиши то, что подходит к ситуации. Это как "обязательное покрытие 98% тестами", почему 98%? Непонятно.
Редко встретишь разумное мнение)
Обычно настраивают линтер и наяривают на него в 2 руки)
Eugene
Нет, но сеньером стать быстрее чем лет за 6 сложно. Надо прожить несколько проектов , успеть набить шишек и попасть в пару просаков. Если сменить 3 компании по паре лет - это как раз 6 выйдет. Так что я бы взял рамку 6-10 лет. Что касается тим лидовости - это вообще очень специфичная вещь, для нее и возраст нужен. Нужно прожить сотни сложных ситуаций в коллективе и личной жизни, чтоб научиться правильно разруливать. Здесь явно раньше 30 (при старте карьеры в районе 20) сложно сформироваться.
Vladimir
У тимлидов "до 30" есть ещё более страшный эйджизм. Они боятся людей 35+ и не берут их.
Илья
4 года синтертимлид ? :)
Объективно стоит сказать, что тот Senior и Тимлид который у меня указан в резюме, вычислен на уровне небольшой команды до 10 человек, конечно был СТО, который следил за принимаемыми решениями, решения обсуждались с ним и с другими лидами и этот Сеньор и Тимлид в большой команде будет несколько нивелирован
Какой объективный сеньор может быть без опыта в распределённых системах, или без опыта в высоконагруженных системах, без готового собственного движка для работы или без готовых решений минимум 30% готовых задач бизнеса
Всё относительно, я с большим удовольствием оценю объективное моё знание программирования на Middle- в той команде, где мои знания - это Middle-
пока
Редко встретишь разумное мнение)
Обычно настраивают линтер и наяривают на него в 2 руки)
у меня с линтерами особых проблем нет) они говорят разумные вещи, в основном.
а вот упарываться в тесты ради цифры покрытия не нужно)