CodeClone 2.0: структурное ревью Python-кода для CI, IDE и AI-агентов

Когда я начинал CodeClone, это был довольно понятный инструмент: найти структурные клоны в Python-коде и не дать им незаметно расползаться по проекту. Сейчас вышел CodeClone 2.0.0, и это уже другой продукт. Не “ещё один линтер”, не попытка заменить Ruff, mypy, pytest, Bandit или Semgrep, а отдельный слой ревью: он смотрит на структуру Python-кода, отделяет старый технический долг от новых регрессий, связывает находки с покрытием тестами и дает одну и ту же картину в CLI, HTML-отчете, GitHub Actions, VS Code, Claude Desktop, Codex и через MCP. Эта статья не про список флагов CLI. Про флаги есть документация. Здесь я хочу рассказать, во что CodeClone вырос как продукт и зачем вообще нужен такой класс инструмента сейчас, когда разработка всё заметнее смещается в сторону AI-агентов.

https://habr.com/ru/articles/1031124/

#python #code_review #code_review_ai #quality_gates #ai_agents #static_analysis #test_coverage

Технический долг — тихий убийца

Технический долг – это термин, который вызывает тревогу в рядах IT-специалистов по всему миру. Он способен уничтожить любой успешный проект. В мире, где время – это деньги, а сроки разработки постоянно сокращаются, очень высок соблазн пойти на компромисс с качеством в погоне за поощрением руководства за скорость релизов. Но какова реальная цена этих компромиссов? Как бороться с этим невидимым врагом, который медленно но верно, подрывает все усилия по достижению прогресса?

https://habr.com/ru/articles/797173/

#технологии #технический_долг #разработка #scrum #agile #тестирование #тестирование_по #test_coverage #velocity

#programming #linters #testing #test_coverage #bad_programming_habits

An observation about writing tests in weakly typed languages like Python.

You should DISABLE some linting features when writing tests. Not everywhere and not all of them. But where needed.

Lint being fully enabled for writing tests can guide you to fragile code and poor tests without realizing it because you may avoid writing tests that the linter complains about without thinking about WHY it's a lint issue and not a compiler error.

Linters catch problems that DO NOT violate the compiler's rules. Such as passing a wrongly typed value in a weakly typed language.

That is WHY they're lint issues rather than compiler errors: The compiler DOES NOT CARE if you do a bad thing that a linter complains about.

100% test coverage only proves you CAN execute all the code without generating unexpected results, not that it WILL always do the right thing for unexpected inputs and situations.

It only proves code functionality, NOT code correctness.