Качество кода *

Всем привет! Меня зовут Щепетков Константин, я TechLead бэкенд разработки компании ZeBrains, работаю в роли TeamLead бэкенда на проекте мобильного приложения Бургер Кинг.

Почти год назад мы запустили полную переработку бэкенда: распиливаем монолит на множество сервисов, всё пишем с нуля. Работы много, сроки плотные — классика.

Чтобы ускорить разработку, решил в качестве эксперимента делегировать часть задач ИИ-инструментам. Негативных кейсов поначалу было много, но со временем качество результата заметно выросло.

В статье делюсь, как давать ИИ чёткие задачи, чтобы он писал рабочий код, соответствующий архитектуре, а не выдумки. Рассказываю про workflow, контекст, шаблоны и кодогенерацию — всё, что превращает ИИ из рискованной игрушки в полезный инструмент для бэкенда. В конце статьи будет ссылка на пример подобных практик.

Тут не будет инструкций к конкретным ИИ-иструментам, но при этом поделюсь практическим опытом применения ИИ. Статья будет полезна не только бэкенд‑разработчикам, но и всем, кто хочет использовать ИИ-инструменты осознанно.

Привет Хаброчитатели!

Все-таки написать статью без технической части дело достаточно творческое. Тут я попробую донести какие-то свои мысли по поводу ИТ в целом и своего 10 летнего опыта в частности, пока у меня есть вдохновение. Поведаю вам в каких профессиональных вакуумах я побывал. Может кто-то найдет мои мысли интересными. Вы тоже от слова вакуум представляете что-то космическое?

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

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

Публикуем новый полный перевод хрестоматийной статьи Эдсгера Дейкстры. Этот текст, опубликованный в 1968 году в журнале Communications of the ACM в формате письма в редакцию, заложил основы структурного программирования, впервые строго аргументировав отказ от оператора go to в пользу использования циклов и условных конструкций.

Привет, Хабр!

Поведаю историю, неизвестную почти никому, но от того не менее занимательную.

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

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

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

Теперь, после того как в предыдущей статье так красочно описаны преимущества Fluent API появилось опасение что все  эти “плюшки” просто не могут быть бесплатными. Наверняка это очень дорого, или нет?

Продолжаем разговор о Fluent API. И теперь, после того как мы из предыдущей статьи (или/и личного опыта) узнали о том что это чудо из себя представляет давайте разберемся зачем оно нужно?

В то время как аналитики жарко спорят на тему станет ли основным языком программирования 6-го (видимо) поколения английский или все-таки китайский предлагаю поговорить немного на другую тему, но в том же направлении: как сделать код программы ближе к человеку? 

Один из ответов на этот вопрос зародился еще в 70-х годах прошлого столетия как method chaining в рамках языка Smalltalk и, благодаря стараниям Эрика Эванса и Мартина Фаулера дошел до нас как Fluent API.

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

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

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

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

Современные движки рабочих процессов (например, Flowable) легко переваривают даже очень сложные модели, но это не значит, что нужно пользоваться этой возможностью на полную. Упрощение дает ощутимые плюсы: модели становятся более читаемыми, требуют меньше усилий на сопровождение и лучше подходят для совместной работы. В итоге простая модель — это ценный актив для любой компании.

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

От переводчика: статья немного сокращена по сравнению с оригиналом, исключён раздел об этимологии слова "Ouroboros", а также полные каламбуров отсылки автора к латинским, прочим романским и английским корням.

Далее - от автора.

Можно ли создать язык программирования, в котором нет синтаксиса? Кажется, что это чистое противоречие. Вся суть языков программирования заключается в синтаксисе, плюс немного в генерации и оптимизации кода, настройке сред выполнения и т.д. Но с точки зрения программиста — именно синтаксис самая важная часть языка. Когда вы приступаете к изучению нового языка программирования, вам обязательно придётся уделить время освоению синтаксиса. 

Можно ли просто избавиться от синтаксиса или, как минимум, предельно его упростить? Другой вариант — можно ли сделать синтаксис произвольным, чтобы программист, пишущий код, мог сам для себя его определять?

Именно этих целей мы попытались достичь, создав язык Ouroboros. Его синтаксис максимально прост. Настолько, что в этом языке даже не предусмотрен синтаксический анализатор. В нём есть только лексический анализатор, код которого составляет 20 строк.

Когда я в прошлом году услышал, что дядя Боб планирует выпустить вторую редакцию «Чистого кода», то был восхищён, а это для меня редкость. Я считал, что и первый выпуск был хорош, хотя сам читаю редко.

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

Или же меня обнадёжило данное Мартином обещание доработать руководства из предыдущей книги. Знаете, то удовольствие, когда читаешь заметки к долгожданным патчам для рабочего ПО.

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

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

Так что представьте, каково было моё разочарование, когда я потратил $60 на электронную версию этой книги, в которой Боб не просто не изменил своей позиции по большинству спорных практик, но и продолжил топить за них ещё круче!

Невероятно!

Но я забегаю вперёд…

Привет народ!

Вот и настала моя очередь исповедоваться перед тобой.

У меня есть, не самая оригинальная, гипотеза о том, что большинство из множества статей жанра "Исповедь Разработчика" - это попытка авторов добавить веса своему персональному бренду, в специфических условиях, сложившихся на рынке труда, когда люди с опытом и, казалось бы, правильным майндсетом, вынуждены стоять в одной очереди с теми, кто вкатился в АйТи только ради денег и удаленки.

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

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

Привет, Хабр. С вами снова Вадим.

В прошлом посте я рассказывал, как написал AI‑бота Аврора, который ищет вакансии вместо меня.

Статья залетела, и к нам пришли первые 100 тестеров. И тут началось веселье.

Представьте: вы нажимаете кнопку «Найти работу», а бот молчит. 10 секунд, 20 секунд. Вы думаете: «Сломалось» и жмете кнопку еще 5 раз.

А на самом деле бот не сломался. Он просто «ушел на кухню готовить».

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

Если вы разработчик — найдете тут код про SKIP LOCKED.

Если вы ищете работу — поймете, почему наш бот теперь быстрее, чем пальцы любого рекрутера.

О вечном — о разумной длине строк кода. Мы недавно встретили ошибку, которая одновременно демонстрирует, чем плох "код-колбаса", "эффект последний строки" и последствия неудачного copy-paste.

Данный документ описывает систему взглядов и практических правил для интеграции ИИ-ассистентов в процесс разработки программного обеспечения. Цель — не запретить использование ИИ, а превратить его в управляемый инструмент, который повышает эффективность, не компрометируя качество, безопасность и ответственность инженера.

Когда программист пишет код, он редко задумывается о том, что происходит с программой после того, как он её написал. Но понимание этого процесса необходимо для эффективной отладки, оптимизации и написания надёжного кода. А ещё, это просто интересно.