Программист часто копирует и вставляет, переименовывает и рефакторит. Выделил (подсветил) мышкой переменную или функцию и вот бы сразу видеть их количество в статусной строке. Увы, стандартный поиск (Ctrl+F) требует лишние клики.
Мой небольшой Python-скрипт для Notepad++ по дабл-клику
отображает в Status-Bar количество вхождений,
частичных или полных, с учетом регистра и без.
Эта статья — не критика Agile или Kanban как подходов и не попытка доказать, что в IT «всё делают неправильно». Я делюсь наблюдениями из собственного опыта работы с качеством в промышленности, энергетике, а затем — в IT‑продуктах.
Речь пойдёт не о терминах и инструментах, а о том, как часто теряется системное мышление, когда сложные управленческие модели упрощаются до ритуалов.
Если у вас уже выстроена работа и всё стабильно — это отлично. Если нет — возможно, некоторые наблюдения покажутся полезными.
У нас в компании был один проект, с которым я не справился.
Дело было так: мне сообщили, что знакомый плюсовик написал какой-то скелет проекта на питоне, а теперь мне надо его допилить, подставив в нужные места реализации. Почему тогда делал он, а не я, а сейчас должен делать я, а не он? Да чёрт его знает. Но я подумал, что смогу — унаследуюсь и переопределю методы где нужно, подставлю зависимости во всякие DI, ну что там может быть плохого?
Оказалось, что плохо вообще всё.
Проект был раздут и переусложнён настолько, что буквально не умещался у меня в голове. Я уже начинаю подозревать, что, похоже, я LLM, и у меня контекст в районе 4096 токенов, потому что чем дольше я читаю код, тем меньше помню, что там было в начале. Изучая проект, я прыгал по стеку вызовов, пытаясь понять, что откуда вызывается и в какой последовательности, и просто в какой-то момент терялся. Проект меня победил, и его передали кому-то другому.
Недавно мне дали черновик статьи на редактуру, чтобы я её подправил где считаю нужным. А статья-то оказалась как раз про тот самый проект — автор рассказывал, как он классно всё написал. Вы даже не представляете, как сложно писать дифирамбы проекту, который настолько плох и полон антипаттернов, что можно собрать по нему целую статью. Так, подождите-ка, а что если...
Короче, вот она — анти-статья, собранная из того проекта. А где мне не хватало примеров, я брал код из Django, потому что он вообще полностью собран на антипаттернах.
Разработка программного обеспечения не стоит на месте: меняется технологический стек, совершенствуются подходы к созданию ПО. Вместе с тем уточняются и требования к ПО и процессу разработки в целом. Все больше людей узнает о понятии SSDLC (Secure Software Development Life Cycle) или безопасный жизненный цикл разработки ПО. Как же построить такой цикл в команде? Как сформировать качественную стратегию построения безопасной разработки? Давайте разбираться!
Хаотичные события в Android (навигация, тосты, запросы) часто превращаются в источник багов и нечитаемого кода. В этой статье вы узнаете, как использовать sealed-интерфейсы Kotlin для создания полной, типобезопасной модели экрана, где состояния и события управляются отдельно и предсказуемо. Вы научитесь превращать одноразовые побочные эффекты в строго контролируемый поток команд, получите compile-time гарантии, избавитесь от багов с поворотом экрана и сможете легко тестировать любые события UI. Рассмотренный подход не только защищает от ошибок, но и кардинально упрощает масштабирование логики. Вы сможете добавлять новые события без риска сломать существующую функциональность, а ваш UI-слой станет чистым и декларативным. При этом всё, что нужно для внедрения - это понимание базовых принципов Flow и ViewModel.
Здравствуйте, коллеги программисты!
Большинство фейлов в CI — это мелочи: забытый console.log, форматирование, линт, сломанный импорт, файл без теста. Такие ошибки не должны доезжать до сборки или код-ревью.
Git-хуки позволяют запускать проверки прямо во время git commit и блокировать коммит, если были обнаружены нарушения.
В прошлой статье я рассказывал про скрипты, которые я использую для проверки качества кода в PHP/Laravel.
В этой статье я хочу рассказать о скриптах для JavaScript/TypeScript и Python — линтинг, форматирование, тесты, статический анализ и проверка наличия тестов.
Все скрипты, описанные в статье, находятся здесь.
Я не React разработчик. Я прибыл к вам с далёкой планеты с одной целью: внедриться и изучить слабые места вашей архитектуры, ваших подходов, дабы доказать своему народу, что ваша цивилизация слишком хаотична, чтобы создать что-то по-настоящему долговечное.
Но в процессе внедрения, произошло то, чего никто не мог предугадать. Я полюбил вашу технологию. И теперь я здесь, чтобы дать вам шанс исправиться, указав вам на ваши проблемы.
Моя главная претензия к современному реактивному сообществу проста: вы потеряли фундамент. Вы строите небоскребы на болоте, игнорируя три фундаментальных правила игры, которые заложили авторы библиотеки.
Что должен делать разработчик, чтобы проект, над которым он работает, не имел проблем? Очевидно — нужно просто исправить все баги и больше не писать новых.
Хорошая попытка, но в реальности и для существующего сервиса скорее всего потребуется ещё несколько шагов, чтобы радикально уменьшить количество открытых багов. В том числе нелюбимое многими разработчиками — начать писать тесты. Зачем этим должны заниматься сами программисты, почему нельзя всё переложить на AI, с чего начать и каким принципам следовать, расскажу в статье.
Современный разработчик сталкивается с парадоксальной ситуацией: с одной стороны — колоссальный выбор готовых решений, с другой — невероятная сложность их отбора.
По данным GitHub, количество открытых библиотек растёт экспоненциально. Только в экосистеме npm (JavaScript) насчитывается более 2 миллионов пакетов. При этом:
Наконец таки статья о том как я облажался. Точнее — как облажалась команда, но ответственность все равно моя. Это разбор конкретной ошибки, которая стоила реальных денег.
Когда разработчики 1С слышат о вайбкодинге, у многих возникает скептицизм. И не без оснований если просто скидывать задачу в Cursor и ждать чуда, результат действительно будет плачевным. ИИ генерирует что-то среднее, нарушает архитектуру, ломает существующий код.
Но это не проблема ИИ. Это проблема подхода.
История успешных вайбкодеров напоминает истории успешного успеха: рассказываю о личном опыте, как мой друг вайбкодил бота под свой проект, и не смог, а сервис, который он пытался скопировать не делался за пару вечеров под сериальчик.
Представьте: ваши автотесты проходят стабильно, ошибок почти нет, команда довольна. Но со временем тесты стали работать в «стерильных» условиях и перестали отражать реальность. Именно с такой ситуацией мы столкнулись на крупном продукте после трех лет регулярных прогонов. В этой статье расскажем, как мы перешли от «зашитых» констант к системе динамической генерации данных, сделали тесты «сложнее» и в итоге повысили их реальную эффективность в 10 раз.
Причина такого поведения оказалась в самом фундаменте: автотесты опирались на статичные, «зашитые» данные, созданные еще при первом покрытии кода. Они были разработаны более трех лет назад и для скорости были объявлены в виде констант непосредственно перед кодом теста.
Рекурсия — прекрасный инструмент математического анализа. В математике это реально полезный и фундаментальный инструмент, поэтому математики привыкают мыслить рекурсиями и активно агитируют за перенос этой логики в программирование. Благо в программировании функции технически могут вызывать самих себя. Из‑за этого возникли даже так называемые функциональные языки программирования, основанные на идее отказа от циклов в пользу «универсальной» рекурсии.
Однако, следует понимать что рекурсия в математике и рекурсия в программировании далеко не одно и тоже. Как отметил Ален И. Голуб в книге «Веревка достаточной длины, чтобы… выстрелить себе в ногу» (п. 6. Если вы не можете сказать это по‑английски, то вы не сможете выполнить это и на Си/Си++) — математическое мышление может помешать писать хорошие программы. И как раз рекурсия наглядно демонстрирует эту мысль.
Математика абстрактна — в ней рекурсия работает в рамках математической логики, а это скорее логика вида «что было бы, если бы функция вызывала сама себя» — реальных вызовов функцией самой себя там нет — математики не вычисляют рекурсии пошагово (как это делает компьютер) поэтому там нет и описанных ниже побочных эффектов появляющихся у рекурсии в программировании. В математике рекурсия более универсальна чем цикл, но в программировании всё наоборот — здесь цикл намного гибче и универсальнее.
Негативные эффекты от рекурсии в программировании носят алгоритмический характер поэтому компиляторы языков программирования общего назначения не могут оптимизировать рекурсию — она неуправляема даже для программиста, не то что для компилятора. Компиляторы функциональных языков программирования умеют преобразовывать так называемую «хвостовую» рекурсию в цикл, убирая её негативные эффекты. Но «хвостовая» рекурсия позволяет реализовать лишь простейшие варианты рекурсии. В общем случае рекурсия эквивалентна нескольким псевдоциклам и анализ количества и функционала этих псевдоциклов нетривиален, а потому не подлежит оптимизации компилятором. По сути «хвостовая» рекурсия не более чем «заплатка» позволяющая вернуть в функциональные языки программирования опрометчиво удалённые из них циклы. Вред от мышления рекурсиями в программировании будет рассмотрен ниже на конкретных примерах.
Представьте себе, что вы работаете над относительно простым монолитным приложением в команде из пяти человек. К сожалению, каждый из вас выгружает код в основную ветку всякий раз, когда завершает работу над порученной ему функцией (или, что еще хуже, когда захочет). Вы то и дело правите код друг друга: используете разные соглашения по именованию, переписываете и, возможно, дублируете код. Именно так может выглядеть разработка в отсутствие процесса код-ревью.
Полгода назад я перестал писать код руками. Не потому что разлюбил программирование — наоборот, за это время я узнал больше новых паттернов, подходов и решений, чем за предыдущие два года активной разработки. Просто теперь я занимаюсь другим: планирую, верифицирую, мержу и проверяю результат. Я стал AI-диспетчером.
Теперь легко и просто можно попробовать поиграться в упаковку скиллов - до всяких платных Claude Code и Clawdbot/Moltbot. Напомню, что это способ превращать удачные сессии с агентом в переиспользуемые сценарии /воркфлоу для агента: один раз настроили, дальше запускаете по команде и получаете результат в том же стиле.
В Manus это можно попробовать и бесплатно. К тому же, вы можете даже скачать Skill, который вы сделали совместно с Manus, тоже совершенно бесплатно.
Я проверила это на простом и полезном кейсе: агрегатор свежих AI-новостей с Reddit, который делает выжимки под Telegram. Ниже по шагам и со скринами.
Хороший ли я программист? Если коротко — я не знаю, что это значит.
Вот я программирую уже 52 года, с 1973 года, спасибо урокам в государственной средней школе — тогда это было редкостью и не все школы давали подобную возможность. Я работал в 15 разных компаниях в самых разных отраслях. Болше скажу, я основал две небольшие софтверные компании — одну в 1985 году и вторую в 1987-м, и руководил ими до 1994 года. А потом я вышел на пенсию в 2021-м году.
Так что же, я хороший программист потому, что я в целом 52 года в отрасли и всё это время программирую?
Нет, долгий срок занятий — вообще ни разу не достаточное основание, чтобы заявлять, что ты в чём-то хорош. Для примера — я играл в баскетбол двадцать лет, и никогда не был в нём особенно хорош. На гитаре я играю уже с полвека, но и тут без особых сногсшибательных успехов — так, средне, для себя.
Долговечность — это преимущество лишь в том смысле, что ты всё это время сумел оставаться ценным и востребованным, но это не обязательно значит, что ты хорош.
Большие языковые модели по-прежнему часто выдумывают детали, если им не хватает контекста. Чем сложнее проект, тем сильнее это ощущается: ИИ не знает структуру вашего репозитория, не видел свежую документацию библиотеки, не понимает бизнес-ограничения продукта.
В статье разберем, как аккуратно подложить модели нужный контекст: от встроенных механизмов в IDE и Claude до утилит для выгрузки репозитория и MCP-серверов, которые подтягивают актуальные документы и данные.
Нейросети обещали магию: закидываешь код, получаешь оценку. На практике магия плохо масштабируется — разные результаты при каждом запуске, невозможность объяснить оценку, растущие счета за API. Тогда я сделал шаг назад и спросил: а что именно я пытаюсь автоматизировать? Оказалось, всё можно сделать детерминированно. Один скрипт, нулевые зависимости, одинаковый результат при каждом запуске. Завершающая часть серии про методологию EVA — от философии до готового инструмента.
