Тимлидельник

Тимлидельник 2.0: тимлид строит SaaS для маленьких команд

Я долго не мог нащупать, о чём должен быть этот канал.

Сначала казалось, что это будет просто канал про будни тимлида: команда, процессы, разработка, понедельники, вот это всё.

Но за последнее время жизнь стала насыщеннее😎

Я всё ещё работаю тимлидом в найме. А по вечерам и выходным строю свой SaaS: простой задачник для маленьких команд.
Такой, которого мне самому не хватает в работе: без лишней сложности, но с ясностью по задачам, людям и процессу.

Поэтому дальше этот канал будет про то, что мне сейчас по-настоящему интересно:

🍏 как маленьким командам работать без хаоса
🍏 как строить простые и надёжные системы
🍏 как тимлиду не превращаться в диспетчера
🍏 как делать SaaS после работы
🍏 как использовать AI-инструменты без потери качества
🍏 как думать не только про код, но и про продукт, пользователей и продажи

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

Короче, Тимлидельник остаётся, но становится взрослее.

Как провести дейли за 7 минут? 🤔

✅ Во-первых, подготовиться! Как бы банально это ни звучало, но, чтобы не задерживать команду, необходимо заранее потратить немного времени самому.

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

✅ Во-вторых, я действую по классической схеме: красный – зелёный – рефакторинг! Прошу прощения, это из TDD. Схема дейли такая: вчера – сегодня – вопросы.

Это вместе с первым пунктом это позволяет мне понимать о чём говорит тиммэйт и не затягивать.

✅ В-третьих, крупные вопросы решать на отдельных встречах.

Есть вопросы к кому-то из команды? Необходимо обсудить задачу? Требуется ввести новичка в курс дела? Этому всему не место на дейли.

В таких случаях я собираю отдельную встречу только с заинтересованными сторонами.

Удачи на дейли 🍀

- Как ты всё успеваешь? Работа, проекты какие-то, обучение...
- А вот никак!

... это к вопросу где я был и что я делал 🤭

Источники развития для разработчика 📚

Сейчас на каждом шагу реклама из серии "войти в айти", разные курсы, блоги (один из таких ты сейчас читаешь;), книги и т.д.

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

Я начинал в те времена, когда в основном были книги, форумы и документация. Ах да, ещё журналы "][akep", "Chip", "Системный администратор" и "LINUX Format". Видимо это, а также любовь читать книги, сформировало мои предпочтения.

1. Книги
Книги могут быть "о вечном" и о какой-то конкретной технологии.

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

А вот книги про Монго или Постгрес, про Вью или Реакт, PHP или JS - они в той или иной степени устареют с появлением новой версии технологии. Я не хочу сказать, что такие книги бесполезны, но нужно понимать этот нюанс.
Лично у меня полно таких книг, например, сейчас читаю книгу про Go, держа в уме, что она про крнкретную версию языка, и что уже сейчас могут быть неактуальные моменты и со временем их будет только больше.
Но книги ценны своими примерами. Часто авторы прибегают к сквозным примерам на всю книгу и знакомят с технологией постепенно, давая возможность выполнить задания из книги.

2. Видеокурсы
Тут почти как с книгами, но для тех, кому проще воспринимать информацию визуально. Если для книг, чтобы поддерживать информацию в актуальном состоянии, необходимо делать новые издания, то с курсами проще: авторы обычно их оперативно дополняют и изменяют.
Я проходил пару курсов по программированию, но в целом это не мой формат, я за книги)

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

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

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

6. Конференции
Полезнейшая история, но для новичков, как мне кажется, бесполезно. А вот у кого уже есть опыт в ИТ - тому крайне полезно.
Самому мне, к сожалению, пока не довелось поучаствовать в конфе, но регулярно смотрю выступления с предыдущих Highload, TeamLeadConf и т.д.

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

Успехов в развитии;)

Пустой GIT коммит

Привет!
Недавно (по вселенским меркам) узнал, что есть возможность сделать пустой коммит. 🤓
Как раз то, чего мне очень хотелось при старте проекта.

Создаёшь пустой проект, делаешь первый пустой коммит, а потом уже файлы, каталоги, фреймворк и вот это вот всё.

Итак, это можно сделать благодаря флагу --allow-empty

1️⃣ Для начала проекта:
git init

2️⃣ Затем делаем пустой коммит:
git commit -m 'Initial commit' --allow-empty

И вот так мы получаем чистое начало работы над проектом.

P.S. Не забудь затем добавить в проект файл .gitignore, без него в проект неминуемо попадёт мусор. Подробнее про него в посте https://t.me/teamlead_monday/18

🥦 Тестовые задания на собеседованиях Джун/Мидл

До недавнего времени не имел собственной определённой позиции насчёт тестовых заданий.
Вроде и неплохая идея, но что-то не то.

Но тут на работе образовалась необходимость протестировать кандидата не только в игре вопрос-ответ, но и в деле.
К счастью, я понял это накануне собеседования и успел подготовить тестовое задание 😆

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

📌 Программно это всё представляет собой гит-репозиторий, в котором простейшая структура.
В корне - два каталога и стандартные composer.json, composer.lock и .gitignore + readme с заданиями.
В каталоге app/ находится существующий код + там же испытуемому нужно писать своё решение.
В каталоге tests/ располагаются тесты PHPUnit, успешное прохождение которых говорит о выполнении задания.
Также в тестах есть несколько todo - доп. задания.

📌 На более высоком уровне задание проверяет:
- базовое знание PHP и окружения (composer, PHPUnit, типизация)
- знание ООП, а именно интерфейсов, классов, наследования и использования всего этого
- знание паттернов проектирования (некоторых, которые встречаются у нас в рабочем коде)
- способность понять и выполнить задачу, которая могла бы возникнуть в работе

📌 Также во время кодинга можно увидеть ход мыслей, как разработчик пользуется инструментарием (IDE, командная строка), как поступает если что-то не ясно.

В общем сегодня протестировали это дело "в бою", и я остался доволен. Всем рекомендую 😉

🎄 Напоминаю! 2024 год подходит к концу! 🎄

❗️ Не забудь:

📌 выбрать подарки и открытки близким и друзьям
📌 подстричься
📌 купить себе вкусняшку
📌 подвести итоги 2024 года
📌 купить ежедневник
📌 поставить цели на 2025
📌 написать список книг на прочесть в 2025

🙈 🙉 🙊 CMS, фреймворк, генератор сайтов - что для чего

Привет!
Вопросом "а на чём сделать мой ...", как мне кажется, задаются не все. А следовало бы...

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

❗️И, сюрприз, они не всегда совпадают.

Для начала стоит разобраться в чём состоит задача:
📌 сделать простенький лендинг, чтобы разместить рекламу
📌 сделать блог / сайт компании / интернет-магазин
📌 сделать крутой сервис типа соцсети, сервис службы доставки и т.д.

После этого станет понятно что использовать в проекте.

✅ Если нужен лендинг, то как правило достаточно генератора сайтов, а фреймворк будет избыточным и сильно увеличит сроки, стоимость и сложность разработки.

✅ Для типового сайта или магазина хорошо подходят CMS: они содержат много всего нужного "из коробки", не придётся всё это разрабатывать.

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

Отдельно хочу выделить цель "потренироваться в использовании какой-либо технологии".
Против неё бессильны любые правила и логические доводы 😃

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

Ну а я пошёл пилить блог на фреймворке потому что разглагольствовать тут - одно, а потыкать последнюю версию Симфони - совсем другое 😆

🍆 У вас короткий спринт, а у нас длинный

Привет!
Сегодня на планировании немного зацепились за длину спринта.

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

Однако, что хорошо для бизнеса - не обязательно подходит разработчикам.

✅ Я же считаю две недели оптимальной длиной спринта.

Пять причин внедрить двухнедельные спринты.

1️⃣ На этот отрезок времени возможно построить выполнимый план
2️⃣ За это время реально успеть его выполнить
3️⃣ По коротким итерациям проще отчитываться о проделанной работе
4️⃣ Если прилетела довольно срочная (но не критичная) задача, её реально отодвинуть на следующий спринт, вместо втискивания в текущий
5️⃣ Короткий спринт не позволяет откладывать дела на потом и прокрастинировать их, т.к. дедлайн уже близко

Возникает вопрос: раз я говорю, что короткие спринты это хорошо, может тогда недельный спринт ещё лучше?

А вот тут не соглашусь: на таких коротких дистанциях только и успевай что планировать следующую итерацию 😄
Хотя, возможно, кому-то подойдёт и такой вариант.

❗️Конечно же, продолжительность спринта это индивидуальная штуковина для каждой отдельно взятой команды, здесь я лишь описал мой опыт работы в спринтах, длящихся от 2 недель до 1 месяца.

Удачи в планировании! 🍀

🤦‍♂️ ѣѣ (double Ять)

Dev: все остальные пуллы приняты, будут еще правки,
но ошибок, связанных с либой не должно быть
TL: у меня тесты в микросервисе падают, так и должно быть?
Dev: что за тесты?
TL: abcde, 6 штук. у тебя норм прошли?
Dev: да, composer update сделал?
TL: да
Dev: этот тест C поправит, остальные сейчас запушу
TL: так стоп, у тебя проходят тесты или нет?
на том коде который сейчас в мастере микросервиса?
Dev: у меня есть несколько незакомиченных изменений.
с ними у меня падает 1 тест который правит С
TL: ѣѣ

⚠️ Что добавить в .gitignore

Привет!
Кажется, сегодня про GIT знают все, ну или хотя бы слышали. Эта система контроля версий сегодня заслуженно самая популярная.

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

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

Зачем же нам нужен хорошо настроенный gitignore? Может без него как-то проживём?

Действительно, без этого файла вполне можно жить, но качество жизни определённо пострадает:) Ведь его правильная настройка поможет держать репозиторий в чистоте, сэкономить место на гит-хостинге и увеличить скорость скачивания репозитория.

🟢 Что стоит добавлять в .gitignore

▫️Файлы и папки, сгенерированные автоматически
- Компилируемые файлы (например, .class, .o, .out и другие).
- Файлы сборки (например, dist/, build/, target/).
Нет никакого смысла их хранить, т.к. это промежуточные файлы и их легко можно получить на основе исходного кода.

▫️Данные локальной конфигурации и среды
- Конфигурационные файлы IDE (например, .vscode/, .idea/).
- Файлы среды (например, .env с секретными ключами и настройками).
Локальные настройки также не нужны в репозитории т.к. они актуальны только на машине конкретного разработчика. У других разработчиков и на сервере настройки будут иными.

▫️Кэшированные и временные файлы
- Временные файлы операционной системы (например, Thumbs.db, .DS_Store).
- Кэшированные зависимости (например, node_modules/ в проектах Node.js, .venv/ для Python).
Тут всё как с автоматически сгенерированными - это промежуточный результат работы, ценность он представляет только во время работы/сборки приложения

▫️Логи и файлы с результатами работы программы
- Файлы журналов (например, .log).
- Выходные данные и отладочные файлы (например, .tmp, *.log).
По своей сути это те же временные файлы, актуальные "здесь и сейчас" - нет смысла в их хранении (для этого есть специальные места хранения)

🔴 Что не стоит добавлять в .gitignore

▫️Исходный код и важные файлы конфигурации
- Файлы исходного кода и ключевые конфигурационные файлы, необходимые для работы проекта.

▫️Скрипты для развёртывания и инфраструктуры
- Скрипты развёртывания и инфраструктурные файлы (например, Dockerfile, docker-compose.yml).

▫️Документация и примеры данных
- Файлы документации (например, README.md, файлы с инструкциями).
- Примеры данных (если они важны для тестирования).

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

🟢 Файл .gitignore чрезвычайно полезен. Он позволяет держать репозиторий в чистоте и порядке.
❗️Помни, что его не получится сгенерировать раз и навсегда: по мере роста и усложнения проекта, он будет расти вместе с ним.

🔔 Подписывайся на Тимлидельник — тут внезапно может оказаться интересно, а ты не подписан🧐
@teamlead_monday

Соблюдение баланса: правильность приложения vs. скорость разработки.

Привет!
Сегодня хочу поговорить про создание архитектуры на скорую руку. Делаю для себя один сервис и пишу эту заметку по горячим следам.

В моей голове я всё сделал красиво, масштабно, правильно и так далее.
Система состоит из микросервисов, которые общаются при помощи событий. Используется брокер сообщений, РСУБД, несколько NoSQL хранилищ разных типов, фронт написан на Vue.Js, всё завёрнуто в контейнеры и автоматически деплоится после мерджа в мастер ветку в репозитории, для оркестрации используется kubernetes.

А потом, как говорится, я проснулся:)

А точнее трезво взглянул на ситуацию и принялся отбрасывать всё ненужное и всё, что может замедлить работу.

🫐 Микросервисы? - долго делать, начнём с монолита с несколькими воркерами для асинхронных задач.
🌽 Брокер сообщений? - РСУБД справится на первом этапе.
🍋 NoSQL? - и тут РСУБД сгодится.
🍓 Фронт на фреймворке? - долго, обычный html+js быстрее и не хуже.
🥒 Автодеплой? - тут да, но позже, не с первого коммита.
🥑 Контейнеры? - не обязательно, но мне привычнее, да и теперь уже быстрее, честно говоря.
🥬 Оркестрация? - Portainer в помощь.
🥦 РСУБД? - а вот без неё и правда никуда:)

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

В общем, есть два варианта разрабатывать приложение:
🍏 выпускать релизы как можно скорее, собирать обратную связь и выпускать новые релизы
🍎 разрабатывать приложение пока оно не достигнет идеала, не выпуская его в свет.

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

🔔 Подписывайся на Тимлидельник — тут внезапно может оказаться интересно, а ты не подписан🧐
@teamlead_monday

✅ Десять вещей, которые нужно уметь разработчику (кроме написания кода)

Привет!
Сегодня поговорим о полезных знаниях и навыках для программиста помимо, собственно, языка программирования.

Со стороны может показаться, что среднестатистический разработчик в вакууме просто сидит, набирает какие-то тексты и получает за это зарплату. Отсюда предположение, что кроме языка ничего знать-то и не требуется.
А вот как на самом деле😊
Язык это всего лишь основа, но есть кое-что ещё😉. Часть списка универсальная, а часть – для бэкенд разработки, без обид – я тимлид🤭

1. Операционная система
Большая часть ПО запускается в какой-либо ОС, кроме JS в браузере и «бессерверных» вычислений. А значит многим из нас необходимо хотя бы базово знать свою ОС.
Я работаю в Linux, поэтому для меня базовым знанием является командная строка (команды + сам bash), vim, systemd итд.

2. Серверы
Nginx например. Я не девопс, но периодически появляется необходимость сервер настроить. Или какие-нибудь настройки для проекта поправить.

3. GIT (ну или другая система контроля версий)
Я, честно говоря, ни разу не сталкивался с чем-то кроме ГИТа, поэтому считаю что он – база.

4. Контейнеры
Сейчас что-то всё в них, и базовые знания Докера нужны. Хотя бы понимать, что это за технология и знать пару базовых команд, чтобы контейнеры запустить, остановить, логи посмотреть.

5. РСУБД (базы данных)
Базовые запросы, связи и т.д. ORM тоже надо знать.

6. NoSQL решения
Это почти БД, но специализированные. Какие-то рекомендации сложно давать какую нужно знать, всё индивидуально, но надо точно понимать их отличия от РСУБД.
А если ещё знать пару-тройку типов NoSQL БД и в каких ситуациях они нужны – вообще кайф.

7. Фреймворк (-и)
На чистом языке, конечно, ещё бывают проекты, но чаще есть какой-то фреймворк, на котором построено приложение. У каждого фреймворка будут свои особенности, и их нужно знать.

8. Паттерны проектирования, парадигмы, алгоритмы, SOLID и их друзья
Объединю это в один пункт, т.к., по сути, это теоретический базис нашей работы. Паттерны нужно знать, чтобы видеть их в коде, и чтобы писать самому хороший поддерживаемый код. Алгоритмы – про эффективность работы программы, SOLID – про поддерживаемый код. Всё это не требуется от Джуна, но дальше – нужно наращивать осведомлённость.

9. IDE
В блокноте уже даже не работаю, и тебе не советую. IDE помогает быстрее читать и писать код, что тут ещё добавишь.

10. Отладчики, линтеры, статические анализаторы, системы тестирования
Всё, что помогает находить некачественный код, ошибки, нестыковки. Эти штуковины помогают сделать твой код лучше и надёжнее. Кайф.

Вот суперкраткий обзор штуковин, которые нужно знать разработчику. Ты всё ещё уверен (-а), что программисты умеют только загагулины в текстовом редакторе печатать?😉

Лайк, репост, подписка❤️ Тимлидельник @teamlead_monday