Мы переживаем величайший кризис качества программного обеспечения в истории вычислительной техники. Калькулятор теряет 32 ГБ оперативной памяти. ИИ-помощники удаляют рабочие базы данных. Компании тратят 364 миллиарда долларов, чтобы избежать решения фундаментальных проблем.
Когда я впервые вернулся к старому коду на Pascal, меня поразило, насколько спокойным и уверенным был этот язык. Без магии, без догадок, без самоуверенности динамической типизации. Pascal не прощал халтуру — и именно поэтому программы на нём жили десятилетиями. Эта статья — не ностальгия, а попытка разобраться, почему мы потеряли культуру типобезопасности и почему сейчас снова к ней возвращаемся.
Подсветка синтаксиса - это инструмент. Она помогает быстрее читать код. Быстрее находить нужную информацию. Ориентироваться в большом файле.
Как и любой инструмент, её можно использовать правильно или неправильно. Чаще всего дефолтная подсветка выглядит как новогодняя елка, что делает текст трудночитаемым. Давайте посмотрим, как изменить это.
Всем привет. Меня зовут Аня (SavAnna) я работаю AppSec и как хобби занимаюсь багбаунти. Багбаунти - отличный способ отдохнуть от своих сервисов и сменить фокус с "защиты" на "нападение". Не всегда баги ищутся целенаправленно - иногда это происходит случайно. Хочу показать, что много странных и простых багов может найти каждый.
Хватит спорить — пора запускать и сравнивать.
Тестируем реальные сценарии, измеряем RPS, смотрим на потребление памяти и разбираемся, когда самая разумная стратегия — это просто подождать и обновить Python на free-threading версию.
Привет, Хабр! Меня зовут Игорь Анохин, я — руководитель платформенной разработки в K2 Cloud и более 8 лет программирую на Python.
Технический вкус — это не то же самое, что технический навык. Вы можете быть технически подкованы, но иметь плохой технический вкус и наоборот. Как и любой вкус в принципе, технический вкус зачастую не зависит от наличия фактического навыка. Вы же можете отличить хорошую еду от плохой, не умея готовить? То же самое с ПО — вы вполне способны понять, нравится ли оно вам, не имея возможности его создать. И если технические навыки можно наработать через усердное изучение и повторение, то хороший вкус вырабатывается менее очевидным путём.
Да, это очередная статья по чистому коду. Но по разным источникам, соотношение времени, затрачиваемого на чтение и написание кода, может достигать 7 к 1 и даже больше. Когда вы исправляете ошибку, добавляете новую функциональность или проводите рефакторинг, вы сначала погружаетесь в логику, написанную другими людьми (или вами же, но несколько месяцев назад). Именно поэтому читаемость кода становится более важным фактором, чем скорость его первоначального написания. Нечитаемый код — это технический долг, который замедляет всю команду и увеличивает стоимость разработки в долгосрочной перспективе.
В сентябре 1985 года Джон Бентли опубликовал книгу Programming Pearls — сборник афоризмов об истинах в программной отрасли.
Прошло сорок лет. Наверняка спустя множество революций в нашей отрасли они потеряли актуальность? Эти советы относятся к той же категории, что и «всегда держи при себе пучок сена для лошадей» или «карманный калькулятор не всегда будет под рукой».
Ох, какая наивность! Ничто не ново под луной. Почти все приведённые афоризмы болезненно актуальны.
Здорово, когда ты получаешь готовое работающее приложение с одного запроса. Пусть даже долго оттачиваемого, как меч самурая. Это апофеоз одновременно профессионализма и лени: ты смог сформулировать задачу так, что ИИ тебя понял и с первого раза сделал всё верно.
Конечно, в крупных проектах такое стремление к лаконичности совершенствованию ни к чему. Очень часто мы даже не можем заранее сформулировать ТЗ и двигаемся шагами, только постепенно понимая направление совершенствования нашего проекта. Современные среды разработки заточены на диалог с ИИ-агентом, который по шагам добавляет функциональность в наше приложение, исправляет возникшие ошибки и т.д.
Эта статья содержит разбор эксперимента по вайб-кодингу, проведённого oldschool-разработчиком с 20+ летним стажем (Assembler, 1C, C/C++, Go, Pascal, Perl, PL/SQL, Python). Я покажу:
• В каких случаях вайб-кодеру достаточно минимальных знаний предмета, а в каких необходимы экспертные навыки и опыт?
• Что изменилось в инструментах вайб-кодинга за текущий год, и что изменится в ближайшем будущем?
• Сравним обычные и «премиум» языковые модели.
• Поймём, есть ли предел у диалога с ИИ-ассистентом, и как понять, что он достигнут?
Не торопитесь пролистывать эту статью. Я не собираюсь, подобно множеству других статей на Хабре, рассказывать о плюсах или минусах вайб-кодинга и сравнивать это с плюсами и минусами традиционного программирования. Потому что сравнивать нечего, ведь не случилось ничего такого, что бы как-то значительно изменило ситуацию. По сути, я буду говорить о том же, о чём говорил в предыдущей статье ( https://habr.com/ru/articles/938028/ -Михаил Елисейкин «IT-лягушка и новая нормальность» ) - о том, что мир меняется, а наши о нём представления от этих изменений отстают.
Антонио Куни — инженер, давно занимающийся повышением производительности Python, а также разработчик PyPy. Он провёл на EuroPython 2025 в Праге презентацию «Мифы и легенды о производительности Python». Как можно догадаться из названия, он считает многие общепринятые сведения о производительности Python как минимум вводящими в заблуждение. На множестве примеров он показал, где, по его мнению, таятся истинные проблемы. Инженер пришёл к выводу, что управление памятью в конечном итоге наложит ограничения на возможности повышения производительности Python, но у него есть проект SPy, который, возможно, станет способом реализации сверхбыстрого Python.
Он начал своё выступление с просьбы: «Если вы считаете Python медленным или недостаточно быстрым, поднимите руку»; поднялось много рук, в отличие от презентации на PyCon Italy, где руку не поднял почти никто из присутствующих. «Совершенно другая аудитория», — сказал он с улыбкой. Антонио уже много лет работает над производительностью Python, он общался с множеством разработчиков на Python и слышал кучу устоявшихся мифов, которые захотел развеять.
Данная статья будет полезна начинающим разработчикам игр, да и вообще, любым людям, кто хочет связать свою жизнь с программированием. Я постарался сделать статью интересной и полезной тем, кто не знает программирование, но знание хотя бы основ С++ увеличит удовольствие от статьи.
Когда-то всё было проще. В достопамятные двухтысячные годы джунов и в самом деле нанимали. Не спрашивали о «релевантном опыте», не требовали ссылки на боевые проекты и не строили сложных лабиринтов из HR-интервью, технических сессий, тестовых заданий и многоступенчатых собеседований. Но прошло 15–20 лет — и всё изменилось до неузнаваемости. Новички (стажёры и джуны) теперь бесправны и даже подозрительны.
Как визуальные платформы ломают культуру разработки и зачем нам нужен контроль над кодом
У меня 25 лет опыта в веб-разработке. Я видел, как появлялись и умирали сотни инструментов, фреймворков, "революций" и "новых парадигм". Я устал повторять, что я не нео-луддит. Я не против прогресса. Но есть момент, когда вместо прогресса тебе продают иллюзию простоты, замаскированную под инновацию.
Так вот, теперь наш CEO влюбился попал под очарование Lovable и хочет, чтобы мы начали использовать его или Base44 для ускорения разработки и быстрого внедрения новых фич. По его задумке, дизайнер "набрасывает интерфейс" (в этих визуальных платформах для сборки UI/UX дизайнером), а мы "допиливаем чуть-чуть на бэке" (через API, Карл!), и всё - фича в проде. Time-to-Market стремительно сокращается, мир спасён, а мы свободны от "лишней инженерии".
Я против. Категорически. И да, это война.
Эта статья — краткая заметка о двух связанных друг с другом эмпирических правилах.
Поднимайте If вверх
Если внутри функции есть условие if, то подумайте, нельзя ли его переместить в вызывающую сторону:
// ХОРОШО
fn frobnicate(walrus: Walrus) {
... }
// ПЛОХО
fn frobnicate(walrus: Option<Walrus>) {
let walrus = match walrus {
Some(it) => it,
None => return,
};
...
}
В подобных примерах часто существуют предварительные условия: функция может проверять предусловие внутри и «ничего не делать», если оно не выполняется, или же может передать задачу проверки предварительного условия вызывающей её стороне, а при помощи типов (или assert) принудительно удовлетворить этому условию. Подъём проверок вверх, особенно в случае предварительных условий, может иметь лавинообразный эффект и привести к уменьшению общего количества проверок. Именно поэтому и возникло это правило.
Ещё год назад я смеялся над мемами про Copilot, который «пишет весь код за тебя». Теперь — я уже не смеюсь. Потому что вижу, как всё чаще код влетает в main почти без участия человека. Его не пишут — его принимают. Почти как оракульское послание.
Это не всегда плохо. Но иногда — страшно.
В этой статье попробуем разобраться, почему ООП — худшее, что было придумано в программировании, как оно стало таким популярным, почему опытные программисты Java (C#, C++ и т.п.) в принципе не могут считаться крутыми инженерами, а код на Java - хорошим.
Роберт Мартин нехило так повлиял на айти‑индустрию. Он придумал принципы SOLID, о которых спрашивают на собесах, пишут статьи на хабре и спорят в комментариях. Он написал книгу «Чистый код» и сделал это словосочетание айтишным мемом. Если зайти на хэдхантер, вбить в поиске слово «чистый», выбрать специализацию «Программист, разработчик» и нажать «Найти», получим больше семисот вакансий. Про чистоту кода и архитектуры спорят на код‑ревью, в комментариях и статьях по всему интернету. Разговоров о чистоте внутри айти‑тусовки бывает так много, словно мы находимся в сообществе клинеров, а не программистов.
Мартин называет себя «дядюшкой Бобом». В своих работах он выступает в образе опытного мудрого и взрослого родственника, который несёт свет и знания таким зелёным и неопытным племянникам. И у него отлично получилось втереться в доверие! Типичный хороший программист‑анальник бессилен перед таким добрым дядей. И я знаю, о чём пишу. Восемь лет назад я сам запоем читал книги дядюшки, а потом до усрачки защищал чистоту кода на код‑ревью. Я на себе почувствовал, насколько Роберт Мартин отличный агитатор и пропагандист. Работая с другими людьми, читая статьи и обсуждения на Хабре и хакерньюс, анализируя требования к вакансиям, я понимаю, что не я один попался на отличную пропаганду от «дядюшки Боба».
