Разработка

Раньше код-ревью выглядело просто. Разработчик написал код. Другой разработчик посмотрел. Поставил пару комментариев. Попросил переименовать переменную. Нашёл одну ошибку. И обязательно написал: “А почему здесь так?” После этого автор кода либо исправлял, либо начинал аккуратную дипломатическую войну в комментариях. Теперь в эту прекрасную человеческую драму пришёл ИИ. Он смотрит на код за секунды, пишет длинный отзыв, находит подозрительные места, предлагает исправления и делает это с таким видом, будто последние десять лет был главным архитектором проекта...

Есть простой способ понять уровень программиста. Не спрашивать, сколько лет он пишет код. Не смотреть, сколько технологий перечислено в резюме. Не проверять, знает ли он разницу между “паттерном” и “костылём с хорошим названием”. Достаточно сделать одно. В пятницу, в 17:42, написать ему: “Там баг в проде. Кажется, что-то сломалось.” И посмотреть на реакцию. Потому что именно в этот момент человек показывает свой настоящий уровень. Не на собеседовании. Не в красивой презентации. Не в резюме, где все “стрессоустойчивые, командные и быстро обучаемые”...

Когда программист впервые слышит слово Tcl, у него обычно возникает два вопроса. Первый: “Это не те, кто телевизоры делает?” Второй: “А это вообще язык программирования или кто-то случайно уронил клавиатуру?” И вот тут начинается самое интересное. Потому что Tcl — это действительно язык программирования. Причём не какой-то вчерашний эксперимент “мы придумали JavaScript, но на коленке и в подвале”, а старый, живучий и довольно упрямый язык, который пережил столько модных технологий, что уже может смотреть на них как дед на подростков с электросамокатами...

ИИ в программировании — это удивительная штука. Ты пишешь ему: “Сделай форму регистрации” А он через несколько секунд выдаёт код, кнопки, проверки, обработку ошибок и вид делает такой, будто всю жизнь этим занимался. Сидишь, смотришь и думаешь: “Вот это скорость. Я бы только чай успел налить.” Но потом начинается самое интересное. Потому что написать код быстро — это одно. А вот сделать так, чтобы он работал правильно, не ломал проект, не пугал пользователей и не превращался через месяц в цифровой чертополох — это уже совсем другая история...

Новый баг — это неприятно. Ты его видишь, ругаешься, открываешь логи, пьёшь кофе, ищешь причину и в какой-то момент понимаешь: “Ага, вот он, гадёныш”. Старый код — другое дело. Старый код не нападает сразу. Он просто лежит в проекте годами. Тихо. Спокойно. Делает вид, что он часть системы. Иногда даже работает. И вот однажды тебе говорят: “Там нужно просто немного поправить старый модуль.” В этот момент опытный программист не задаёт вопрос “что именно поправить?” Он задаёт вопрос: “А завещание уже писать?” У нового бага есть одно хорошее качество: он свежий...

Есть вещи, которые программист открывает с внутренним спокойствием. Новый ноутбук. Свежий проект. Пустой файл. Документацию, которая действительно существует. И есть вещь, после которой даже взрослый Senior-разработчик на секунду смотрит в окно и думает: “А может, я зря не пошёл разводить кактусы?” Это чужой код. Причём “чужой” — это не обязательно код другого человека. Иногда это твой собственный код, написанный полгода назад. Просто ты уже не помнишь, кто был этот человек, почему он так сделал и чем он вообще тогда руководствовался...