|
Professor Seleznov
|
Когда человек приходит в программирование, он думает, что главное — выучить язык.
Python. C#. Java. Go. Неважно.
Кажется: выучил → стал программистом.
Нет.
Язык — это самая простая часть профессии.
Настоящие проблемы начинаются потом
Когда код нужно:
— поддерживать
— развивать
— масштабировать
— отдавать другим
— привязывать к бизнесу
— защищать от пользователей
— деплоить
— тестировать
— чинить в три часа ночи после фразы «мы ничего не меняли»
И вот тут выясняется: писать код и быть инженером — разные вещи.
Программирование — это не код
Если убрать романтику, программирование — это перевод человеческих желаний на язык, который понимает компьютер.
Бизнес говорит:
«Хочу, чтобы клиент получал купон через три дня после покупки».
Пользователь говорит:
«Почему кнопка "Удалить" рядом с "Сохранить"?»
Администратор говорит:
«Почему сервер умер от тысячи запросов?»
А программист должен превратить всё это в алгоритмы, ограничения, архитектуру, проверки, интерфейсы, базы данных, логи, тесты и работающую систему.
Компьютер не понимает «примерно», «наверное» или «и так сойдёт».
Он понимает только точные инструкции.
Программирование — это устранение неопределённости.
Почему знание языка не делает инженером
Сегодня можно:
— пройти курсы
— выучить фреймворк
— научиться собирать CRUD
— подключить ORM
— вызвать ChatGPT
— и даже устроиться на работу
Но в реальном проекте человек внезапно обнаруживает, что кроме синтаксиса существует огромный мир:
— архитектура
— бизнес-логика
— базы данных
— сети
— тестирование
— инфраструктура
— UX
— безопасность
— поддержка
— и последствия собственных решений
Код может быть рабочим и одновременно:
— хрупким
— нечитаемым
— опасным
— нетестируемым
— убийственным для тех, кто будет его поддерживать
Этим во многом объясняется, почему индустрия завалена легаси.
Три вещи, которые отличают инженера
1. Алгоритмическое мышление
Алгоритм — это не задача из учебника.
Это способность разложить хаос на последовательность шагов.
Пример:
«После покупки от 5000 рублей отправить скидочный купон через три дня».
Для человека это просто.
Для системы — нет.
Нужно:
— проверить сумму
— сохранить дату
— запланировать задачу
— не отправить купон дважды
— обработать ошибку почты
— учесть часовые пояса
— пережить перезапуск сервера
— и не забыть про всё это, когда через полгода поменяются правила
Инженерия начинается именно здесь.
2. Декомпозиция
Новичок видит: «сделать приложение доставки еды».
Инженер видит:
— авторизацию
— каталог
— корзину
— оплату
— уведомления
— статусы
— доставку
— отчёты
— роли
— логи
— интеграции
Большие системы всегда собираются из маленьких понятных частей.
Без декомпозиции любой проект превращается в кашу.
3. Понимание бизнес-логики
Вот здесь ломаются очень многие.
Потому что программист пишет код не для абстрактной «системы».
Он автоматизирует реальный бизнес-процесс.
Простой пример.Заказчик говорит:
«Сделайте кнопку отмены рейса».
Начинающий разработчик удаляет рейс из базы данных.
Технически код работает.
Но в реальном бизнесе отмена рейса — это:
— пересадка пассажиров
— возвраты
— уведомления
— документы
— отчёты
— изменение расписаний
Код работает. А бизнес ломается.
Код не живёт в вакууме
Многие начинающие думают так:
«Я написал код. У меня работает. Значит, всё нормально».
Нет.
Код живёт внутри огромной экосистемы.
DevOps и инфраструктура
У тебя на ноутбуке — одна версия Python, нужные библиотеки, права админа и локальная база.
На сервере — всё другое.
Отсюда и рождается бессмертная фраза: «У меня работает».
Docker, CI/CD, логи, мониторинг — это не модные слова. Это попытка сделать систему предсказуемой.
Базы данных
Пока пользователей 10 — можно хранить всё в List или JSON-файле.
Когда пользователей 100 тысяч — начинаются индексы, транзакции, блокировки, N+1 запросов и деградация производительности.
База данных — это отдельная инженерная дисциплина.
Безопасность
Интернет — враждебная среда.
Если хранить пароли в открытом виде — база утечёт.
Если подставлять пользовательский ввод прямо в SQL — прилетит SQL-инъекция.
Если не понимать разницу между аутентификацией и авторизацией — пользователь однажды увидит чужие данные.
И это уже не «баг». Это инцидент.
Пользователь не хочет думать
Это ещё одна вещь, которую программисты понимают слишком поздно.
Пользователь:
— не хочет читать документацию
— не хочет разбираться
— не хочет бояться нажать кнопку
— не хочет ждать
Если интерфейс заставляет человека думать — это плохой интерфейс.
Программисты очень любят фразу: «Ну это же логично».
Нет. Логично только тому, кто знает внутренности системы.
Хороший интерфейс не демонстрирует ум разработчика.
Он снижает усталость пользователя.
И техподдержки, кстати, тоже.
Язык — это инструмент, а не религия
Одна из самых забавных болезней индустрии — фанатизм вокруг технологий.
Можно потратить три дня на «правильный» сервис на Rust.
А можно за 20 минут решить задачу VBA-скриптом внутри Word.
И бизнес выберет второй вариант.
Потому что задача решена.
Хороший инженер не спрашивает: «Какой язык самый крутой?»
Он спрашивает: «Какое решение даст результат быстрее, дешевле и надёжнее?»
Иногда это C#. Иногда Python. Иногда Bash. Иногда SQL.
А иногда — старый страшный VBA, который внезапно экономит неделю работы.
Главная проблема современной индустрии
Сейчас стало очень легко научиться писать код.
ИИ генерирует шаблоны.
Фреймворки скрывают сложность.
Курсы обещают «профессию за 6 месяцев».
Но инженерное мышление не появляется автоматически.
Оно появляется:
— через ошибки
— через поддержку легаси
— через ответственность
— через понимание бизнеса
— через боль от плохих решений
— и через осознание того, что любой «временный костыль» однажды придёт мстить
Итог
Код пишут многие.
Инженерами становятся единицы.
Потому что инженер думает:
— о системе
— о последствиях
— о людях
— о поддержке
— о будущем проекта
— о цене решений
Язык можно выучить за месяцы.
Инженерное мышление формируется годами.-Источник
|
|
|
