Расскажу еще один случай раз уж про это говорим) Недавно устроился в одну фирму. Утром пишет мне программист оттуда — не новичок, уже какое‑то время там работает. Сразу с порога спрашивает: — Ну что, под капотом у тебя? Как работаешь? Много успел сделать? Я отвечаю: — Да всё просто — XAMPP: PHP + MySQL. Проверенная схема, всё понятно и работает. А он в ответ: — Так уже никто не делает! Смотри, как надо. Показывает мне Linux, Docker, разворачивает сайт, ввод пароля — и вот форма авторизации. — Вот, говорит, сейчас так надо. Redis, Memcached — всё как в фирмах принято. Я ему объясняю: — Я делаю проекты под клиентов. Беру дешевый хостинг — чтобы меньше платили и не нужно было нанимать сисадмина. Всё должно быть просто и понятно. Он: — Ну, покажи тогда, что у тебя есть. Я открываю систему для медучреждений: стационар, регистратура, кабинеты, онлайн‑очереди. Он: — А как работает? Я показываю вживую — всё работает в онлайне. Он смотрит и говорит: — Сейчас так уже не делают... Я спрашиваю: — А как делают? — Ну как, через Docker надо, всё для оперативности. — А у тебя, кроме формы ввода пароля, ещё что‑то есть на этой твоей Docker‑системе? И тут он замолчал. Сказал, что задачи делает. После этого как‑то сдулся. Видимо, немного обиделся....) Потом, к слову, его уволили. Но знаешь, ведь он и правда умел настраивать окружение: Docker, Linux, всё запускалось. И я думаю — если бы у работодателя стоял выбор: он или я, то могли бы выбрать его. Ведь снаружи «всё красиво». Но весь этот стек — это только инфраструктура, окружение. Настроить окружение — это одно. А вот продумать архитектуру, организовать базы данных, понять логику системы, сделать так, чтобы код был понятен и поддерживаем — совсем другое. Сколько раз я с этим сталкивался. Один Team Lead мне однажды сказал: «Лучше понятный код, чем хитрый, но быстрый.» Как‑то дали задание: из огромного JSON‑файла (несколько гигабайт) нужно было вытащить таблицы. Задача была непростая. Я решил её — всё быстро, даже на старом ПК работало идеально. А мне говорят: — Лучше бы ты сделал тупо и прямо, пусть медленнее, но понятнее. Железо добавим. Это, по сути, тоже провал добавлять железо. Потому что при 100 пользователях — ок. А при 1000? Начнут искать оптимизацию. Только тогда. И это сказал Team Lead. Такая вот реальность. Всё чаще замечаю: не всегда побеждает тот, кто пишет хорошую программу — зачастую выигрывает тот, кто «покрасивее упаковал». Но настоящая сила — в сути, а не в обёртке. Просто в своё время мне приходилось жестко экономить ресурсы. Помнятся времена, когда работали на дискетах, потом — на мелких флешках, а компьютеры были такие, что любое торможение — это уже «норма». И вот тогда учишься делать всё чётко и по делу. Каждую строчку кода обдумываешь, каждый байт — на счету. Выбираешь максимально оптимальные алгоритмы, строишь структуру баз так, чтобы всё работало стабильно и быстро — без Redis, Memcached, Supervisor’ов и прочих костылей, которые жрут ресурсы и требуют сложной настройки. Именно поэтому мои проекты без проблем крутятся даже на дешёвом хостинге. А это, между прочим, означает, что когда действительно понадобится масштабироваться — у вас будет огромный запас по производительности. Ведь система уже изначально спроектирована эффективно.
Просто Гриша Растаргуев
Расскажу еще один поучительный реальный случай из практики: почему важно доверять серьёзные задачи опытным разработчикам Хочу поделиться реальной историей из жизни, которая наглядно показывает, почему для серьёзных проектов нужен не просто «разработчик», а опытный архитектор с пониманием всей картины. Однажды мне позвонил брат из Москвы. Он работает системным администратором в фирме, занимающейся веб‑разработкой. Их компания решила запустить внутренний проект: сделать собственную ERP/CRM‑систему для управления внутренними процессами — филиалами, логистикой, звонками и прочим. Работали над проектом два программиста: один занимался бэкендом на PHP, другой — фронтендом на JavaScript. Руководил ими человек, который в программировании не разбирался, но ставил задачи, как мог. Всё шло по классике: собрания, красивые отчёты, макеты, UI‑дизайны, презентации «как это будет». Зарплаты по 100 тысяч рублей, работы на шесть месяцев. Прошло полгода — а готового решения так и нет. Только пара форм и отчёты в PowerPoint. Начальство начало давить, спонсоры — задавать вопросы. В этой ситуации брат и позвал меня: «Посмотри, что не так, а то все нервничают, а разобраться никто не может.» Созвонились по Skype: я, брат, оба разработчика и их руководитель. Послушал задачу — и сразу сказал: «Такую систему я соберу за неделю. Без лишней мишуры, но с готовым работающим прототипом, который можно показать заказчику.» Они не поверили. Но через 4 дня у меня был работающий прототип. В результате — двух разработчиков уволили, а меня взяли на их место. Я закончил проект и внедрил его. Интересно то, что PHP‑разработчика потом взяли в другую, довольно серьёзную фирму. Он не был плохим, просто ни он, ни фронтендер никогда не создавали серьёзные программы «от и до». Они привыкли к сайтам — «форма, база, вывод» — и это совсем другой уровень задач, чем полноценная система с логикой, структурой данных, архитектурой и поддержкой. Что пошло не так? Отсутствие общего технического видения. Один пишет PHP, другой — JS, и каждый работает сам по себе. Но ERP‑система требует понимания всей цепочки: от бизнес‑логики до интерфейса. Нет опытного архитектора. Никто не мог правильно выстроить структуру данных, продумать модули, предусмотреть будущие изменения. Формальный менеджмент. Руководитель, не разбирающийся в разработке, не мог объективно оценить прогресс. А красивые отчёты — это не код. Отсутствие реального опыта. Да, сайты — это тоже работа. Но сайт ≠ система. Систему надо проектировать, моделировать, поддерживать. Это другой уровень. P.S. про резюме Позже меня попросили помочь с подбором разработчиков. На вакансию с зарплатой 100 000 рублей приходили анкеты с солидным «стажем»: по году в каждой фирме, список технологий — внушительный. Но на деле ни один кандидат не смог показать ни одной законченной программы. Пришёл, поработал — и ушёл. Часто после него ещё и «разгребать» приходилось. А я, к примеру, 20 лет проработал в одной фирме, могу показать реальные системы, которые используются и сейчас. И вот в этом — разница. Вывод: если у вас есть большая задача — особенно внутренняя ERP/CRM — обязательно нужен человек, который уже делал подобные вещи. Не просто «знает PHP» или «умеет делать сайты», а тот, кто понимает, как выстроить систему от начала до конца. Иначе вы рискуете тратить деньги и время, не получив в итоге ничего рабочего.
Я автоматизировал множество организаций «под ключ» — от составления технического задания до реализации выходных форм на разных языках программирования. У меня более 25 лет опыта, в том числе на C++, где ключевыми являются наследование, полиморфизм и другие ООП‑принципы. И вот приходишь устраиваться на новую работу — начинается тестирование: «А что такое полиморфизм?» и прочие теоретические вопросы. Да, я это всё знаю и использую на практике, но не всегда могу объяснить так, как написано в учебнике. В итоге — не берут. Говорят: «А как вы будете работать?». А у меня задачи по сей день работают годами без сбоев. Но, конечно, предпочтение отдают тем, кто может красиво рассказать про полиморфизм. Вот только знание термина не означает умение построить правильную логику и довести систему до реального результата. Часто такие «теоретики» через год уходят, и берут новых — таких же. Потом смотришь, что они понаделали — и диву даёшься: как вообще до такого можно было додуматься? И ведь переделать всё это — задача не из простых. Однажды меня пригласили в организацию, где уже работали три PHP‑программиста, один фронтендер (JS) и «руководитель», не разбирающийся в программировании. Меня позвали делать отчёты. Когда я полез в код, чтобы понять, откуда брать данные, удивился: простая форма открывалась с дикой задержкой. А причина? 180 SQL‑запросов к семи таблицам! Я спросил, зачем так, — а мне: «Не лезьте, куда не надо». Но я ведь должен понимать, откуда брать данные! По сути, то, что они делали впятером, можно было сделать и одному. Я включил запись экрана и с нуля за полтора дня собрал аналог — без лишних фронтендов, всё работало быстро и стабильно. Руководитель сказал: «Ну мы же как‑то до вас работали». Конечно работали — но насколько лучше и чище всё могло бы быть при правильной архитектуре. Но мои слова остались без внимания — там сидели «выпускники вузов», которых, похоже, научили делать вещи, которые не делятся и не масштабируются. В итоге система стала настолько громоздкой, что сами же о неё и спотыкались, вынужденно нанимая людей, чтобы справляться с хаосом, который сами создали. И это была одна организация , программа , которая работает во многих организациях. Это случай из жизни. И такое встречается практически всегда.