✅ Список советов которых я хотел бы получить лет так 10 назад часть 1
Yegor Karpachev🎯 Раздел 1: КОД — Твой враг и твой памятник
Правило №1: Код пишется не для компьютера, а для твоего коллеги в 3 часа ночи через 2 года
Что говорят на курсах:
javascript
// Оптимизированная функция подсчета const c=(a)=>a.reduce((x,y)=>x+y,0)/a.length;
Что ты будешь читать в 3 ночи:
javascript
/**
* Вычисляет среднее арифметическое массива чисел
* @param {number[]} numbers - Массив чисел для усреднения
* @returns {number} Среднее значение
* @example calculateAverage([1, 2, 3]) // возвращает 2
*/
function calculateAverage(numbers) {
const sum = numbers.reduce((accumulator, current) => {
return accumulator + current;
}, 0);
return sum / numbers.length;
}
Простая истина: Большая часть времени разработки уходит на чтение кода, а не на его написание. Ты будешь читать код чаще, чем писать. Намного чаще.
Эволюция отмазок:
- День 1: "Я же понимаю, что тут происходит"
- Через 6 месяцев: "Кто этот психопат написал? А, это я..."
- День 1: "Названия переменных неважны, главное логика"
- Через 6 месяцев: 40 минут на поиск, где используется
tmp2
- День 1: "Потом отрефакторю"
- Через 6 месяцев: Потом = НИКОГДА
Правило №2: Комментарии — это не баг, это фича
❌ Плохо:
python
x = x + 1 # инкремент x
✅ Хорошо:
python
# Добавляем 1 к счетчику попыток, потому что API Яндекса # падает после 3-й попытки из-за их внутреннего rate limit. # См. тикет JIRA-4815 и переписку с их техподдержкой от 12.03.2024 attempt_count = attempt_count + 1
🐕 Сравнение с собаками #1:
Моя собака запоминает, где закопала кость, через 3 месяца. Ты без комментариев не вспомнишь, почему добавил setTimeout на 237мс, уже через неделю.
Правило №3: Магия — для Хогвартса, не для продакшена
javascript
// Это работает, но никто не знает почему
// Если убрать setTimeout — всё падает
// Если изменить на 100мс — тоже падает
// Мы боимся это трогать с 2019 года
setTimeout(() => {
initializeWidget();
}, 237);
Формула проекта:
Магический код × Текучка кадров = Технический долг^∞
Если твой код работает "почему-то", а не "потому что" — это не skill, это мина замедленного действия.
Правило №4: DRY (Don't Repeat Yourself) — но с умом
Плохое понимание DRY:
javascript
// У меня есть функция formatUserName и formatProductName
// Они обе делают capitalize, создам универсальную!
function formatAnyName(name, type, options, context, metadata) {
// 150 строк универсального ужаса
if (type === 'user') {
if (options.middle && context.locale === 'ru') {
// ещё 50 строк
}
} else if (type === 'product') {
// и снова ад
}
}
Хорошее понимание DRY:
javascript
// Это разные сущности, у них просто похожая логика СЕЙЧАС
// Через месяц форматирование имён пользователей усложнится
// А форматирование товаров останется простым
function formatUserName(user) {
return capitalize(user.name);
}
function formatProductName(product) {
return capitalize(product.name);
}
Правило большого пальца: Повторение кода 2 раза — нормально. 3 раза — подумай о рефакторинге. Универсальная функция, которая обрабатывает 7 разных случаев — преступление против человечности.
Правило №5: Тесты — это не «когда будет время», это инвестиция
Диалог, который был у всех:
Ты: "Надо написать тесты"
PM: "Нет времени, давай в следующем спринте"
Ты: "Но это сэкономит время в будущем"
PM: "В следующем спринте"
Через 2 месяца:
PM: "Почему всё падает после обновления?"
Ты: "Потому что нет тестов"
PM: "Ну так напиши!"
Ты: "Уже поздно, сломано 40% функционала"
Истина: Писать тесты ПОСЛЕ того, как код написан — это как покупать огнетушитель, когда дом уже горит. Технически возможно, но эффективность стремится к нулю.
Ещё одна истина: Код без тестов — это не legacy код. Это код, который СТАНЕТ legacy через 3 месяца.
💼 Раздел 2: КАРЬЕРА — Лестница не туда, куда ты думал
Правило №6: Senior — это не 5 лет опыта, это 1 год опыта, повторённый 5 раз
Признаки роста: ✅ Каждый проект учит тебя новому
✅ Ты читаешь чужой код для обучения, а не только когда он сломан
✅ Ты споришь с архитектурными решениями и предлагаешь альтернативы
✅ Ты знаешь 3 языка/фреймворка глубоко
Признаки стагнации: ❌ Каждый проект — копипаста прошлого
❌ "Всегда так делали" — твой главный аргумент
❌ Ты знаешь 10 языков поверхностно
❌ Новые технологии изучаешь только под дулом пистолета
Реальный случай из жизни:
Собеседую кандидата с резюме "8 лет React"
Я: "Расскажи про хуки"
Он: "А что это?"
Я: "Ну... базовая фича с 2019 года"
Он: "А, мы на классовых компонентах"
Оказалось: человек 8 лет писал на React 15 в одной компании, где запрещали обновляться. Формально — 8 лет опыта. Фактически — опыт 2016 года.
Правило №7: Рынок тебе ничего не должен
Неприятная правда: Твои навыки устаревают быстрее, чем ты думаешь. То, что было актуально 3 года назад, сегодня может быть мертво.
Ещё более неприятная правда: Твоя зарплата внутри компании растёт медленнее, чем на рынке. Намного медленнее. Лояльность работодателю — это не благородство, это финансовая безграмотность.
Практический пример:
Вася: Работает в компании А 5 лет. Начал с 80к, вырос до 120к (+50%)
Петя: Меняет работу каждые 2 года. 80к → 110к → 150к → 200к (+150%)
Угадай, кто из них покупает квартиру, а кто жалуется на жизнь?
Правило №8: Техлид/Архитектор ≠ больше денег + меньше работы
Что ты думаешь про роль техлида:
- Больше власти = больше контроля ✨
- Меньше кода = больше отдыха 🏖️
- Принимаю решения = все меня слушают 👑
Реальность:
- Больше власти = больше ответственности за чужие косяки 💀
- Меньше кода = бесконечные митинги, где обсуждают очевидное 🔄
- Принимаю решения = виноват всегда я, даже если решение приняли вопреки моему мнению 🎯
Эволюция благодарности:
Junior: Пишет код 95% времени → "Норм, но вот тут переделай"
Middle: Пишет код 70% времени → "Ок"
Senior: Пишет код 40% времени → Молчание
Техлид: Пишет код 10% времени → "Почему проект опаздывает?"
Совет от меня через 15 лет:
Если тебе нравится код — не иди в менеджмент. Серьёзно. Это как стать поваром, а потом всю жизнь только составлять меню и объяснять официантам, почему салат нельзя подавать в супнице.
🗣️ Раздел 3: КОММУНИКАЦИЯ — Половина работы, о которой не говорят
Правило №9: "Просто" и "быстренько" — триггерные слова
Словарь выживания:
PM говорит: "Просто добавь кнопку"
PM имеет в виду: "Переделай всю авторизацию"
Реальность: 3 недели + баги в продакшене
PM говорит: "Быстренько поправь"
PM имеет в виду: "У меня дедлайн вчера"
Реальность: Твои выходные в офисе
PM говорит: "Это же мелочь"
PM имеет в виду: "Я не понимаю, как это работает"
Реальность: Рефакторинг 4 модулей
PM говорит: "Сделай красиво"
PM имеет в виду: "Я сам не знаю, чего хочу"
Реальность: 7 итераций и твои нервы
PM говорит: "Клиент просит"
PM имеет в виду: "Я обещал, не спросив вас"
Реальность: Технический долг +1000
🐕 Сравнение с собаками #2:
Собака виляет хвостом, когда рада. PM виляет дедлайнами, когда накосячил. Но собака хотя бы честна.
Правило №10: Документируй ВСЁ, или молчи навсегда
Сценарий без документации:
PM: "Почему это работает так?"
Ты: "Мы обсуждали это на встрече в марте"
PM: "Я не помню"
Ты: "Я отправлял письмо"
PM: "Не нашёл"
Результат: Переделываем
Сценарий с документацией:
PM: "Почему это работает так?"
Ты: "Вот confluence-страница, вот email-цепочка, вот протокол встречи"
PM: "А..."
Результат: Не переделываем
Что документировать:
- ✅ Архитектурные решения (почему выбрали PostgreSQL, а не MongoDB)
- ✅ Компромиссы (почему согласились на костыль вместо правильного решения)
- ✅ Договорённости с бизнесом (что обещали делать и чего НЕ обещали)
- ✅ Известные ограничения (система не выдержит больше 10к пользователей)
- ✅ Временные решения (это временный хак, потом переделаем на...)
Формула успеха:
Хорошая память × Без документации = Переделываем всё заново Плохая память × С документацией = Живём спокойно
Правило №11: "Нет" — это полноценный ответ
Плохой разработчик:
Бизнес: "Можем сделать за неделю?"
Разработчик: "Ну... наверное... попробуем..."
Результат: Овертаймы, стресс, баги, все недовольны
Хороший разработчик:
Бизнес: "Можем сделать за неделю?"
Разработчик: "Нет. Реалистичный срок — 3 недели. Могу объяснить почему"
Результат: Адекватный план, нормальный темп, качественный результат
Истина: Каждое "да", которое должно было быть "нет" — это долг. Рано или поздно его придётся возвращать с процентами в виде багов, переработок и репутации "ненадёжного разработчика".
Ещё одна истина: Бизнес уважает тех, кто говорит реалистичные сроки, а не тех, кто обещает невозможное и не выполняет.
⚡ Раздел 4: HARD SKILLS — Что реально важно
Правило №12: Git — это не «просто сохранялка»
Признаки того, что ты не умеешь в Git:
❌ Все коммиты называются "fix", "update", "changes"
❌ Ты боишься rebase как огня
❌ Конфликты решаешь через "взять всё своё" или "взять всё чужое"
❌ Ветки называются "test", "test2", "test_final", "test_final_final"
❌ История коммитов выглядит как результат землетрясения
Что должен уметь любой разработчик:
✅ Писать осмысленные коммиты: "Добавил валидацию email в форме регистрации (TASK-123)"
✅ Делать rebase для чистой истории
✅ Решать конфликты, понимая код
✅ Работать с ветками по Git Flow или аналогу
✅ Откатывать изменения без паники
Реальный кейс:
Junior: "Я случайно удалил важный файл и запушил!"
Senior (плохой): "ААААА, всё пропало!"
Senior (хороший): git revert HEAD && git push — "Готово, откатил"
Правило №13: Знать фреймворк ≠ знать язык
Типичная ошибка:
Кандидат: "Я 5 лет на React"
Я: "Расскажи про замыкания в JavaScript"
Кандидат: "Это... ээээ... в React есть хуки..."
Суровая правда: Если ты не понимаешь, как работает язык под фреймворком, ты не программист. Ты оператор фреймворка.
Чек-лист:
Ты пишешь на React/Vue/Angular? Понимаешь ли ты:
- ✅ Как работает event loop в JavaScript
- ✅ Что такое прототипное наследование
- ✅ Разница между
==и=== - ✅ Что такое hoisting
- ✅ Как работает
this
Ты пишешь на Django/Flask? Понимаешь ли ты:
- ✅ Как работают декораторы в Python
- ✅ Разница между list comprehension и генераторами
- ✅ Что такое GIL и почему это важно
- ✅ Как работает garbage collector
Формула карьеры:
Знание фреймворка = Работа сегодня Знание языка = Работа через 5 лет
Правило №14: Базы данных — это не "просто таблички"
Как думает джун:
sql
SELECT * FROM users WHERE id IN ( SELECT user_id FROM orders WHERE status = 'active' ) -- Работает? Работает. Запускаем!
Что видит база данных:
1. Найти ВСЕ заказы со статусом 'active' (500,000 записей) 2. Для КАЖДОГО заказа найти пользователя 3. Время выполнения: 45 секунд 4. Сервер упал
Как думает senior:
sql
SELECT u.* FROM users u INNER JOIN orders o ON u.id = o.user_id WHERE o.status = 'active' GROUP BY u.id -- Добавляем индекс на orders.status -- Время выполнения: 0.3 секунды
🐕 Сравнение с собаками #3:
Моя собака понимает, что надо искать кость там, где она её закопала, а не перекапывать весь двор. А джуны делают SELECT * из миллионной таблицы без WHERE.
Что ОБЯЗАН знать каждый разработчик:
✅ Разница между INNER JOIN, LEFT JOIN, RIGHT JOIN
✅ Что такое индексы и когда они нужны
✅ Почему SELECT * — зло
✅ Что такое N+1 проблема
✅ Как работают транзакции
✅ Разница между UNIQUE и PRIMARY KEY