Агентство сдало код, а теперь предлагает «аудит кода» — почему мы должны платить за это ещё раз?

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

В аудите кода смотрят на уровень технического долга (technical debt). Программисты иногда пишут спагетти-код или пропускают тесты, чтобы успеть к дедлайну. Система пока работает, но падает при первом же обновлении. Аудит ценен тем, что выявляет эти риски.

Не платите агентству. Подключите к коду в вашем репозитории GitHub или GitLab открытые инструменты статического анализа. Даже автоматические инструменты бесплатно за 10 минут выдадут список дублей кода и базовых уязвимостей.

Мы на проекте за 650 000 RUB аудит не делали, а через 6 месяцев, когда захотели добавить новые функции, другое агентство сказало: «Этот код — мусор, надо писать с нуля», и мы потратили ещё 500 000 RUB. Независимая проверка обязательна.

Если будете заказывать аудит кода, пусть проверят 3 вещи: 1) Оптимизацию запросов к базе данных, 2) Фильтрацию входных параметров, 3) Задокументированность кода. Если с этим всё в порядке, завтра другой программист сможет подхватить работу.

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

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

Если я правильно понял вы имеете в виду следующее: Все, кто торопится с аудит кода, спотыкаются на одном и том же.

Люди защищают не процесс а привычку. Сопротивление идет оттуда. Надеюсь, это будет полезно.

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

Начните с небольшого эксперимента, не привязывайте всё сразу.

Обсуждение размылось, давайте структурируем. График платежей должен быть привязан к этапам работ а не к датам.

Проверено опытом.

Давайте разделим понятия, их путают. Все кто торопится с аудит кода, спотыкаются на одном и том же.

Если критерии приемки не прописаны момент завершения работы становится предметом спора.

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

Люди защищают не процесс, а привычку. Сопротивление идет оттуда. Конечно, если ваша ситуация отличается, всё меняется.

Сведу тему в кучу, так как ответов было несколько разных. Если на один вопрос вы получаете три разных ответа, вопрос задан неправильно.

Надеюсь, это будет полезно.

Верно. Большая часть потерь времени копится на задачах, ожидающих согласования.

То, что делают все, не значит, что это правильно. Надеюсь, это будет полезно.

Я долго занимался этим вопросом. График платежей должен быть привязан к этапам работ, а не к датам.

Самое дешевое предложение обычно самое непродуманное. Надеюсь, это будет полезно.

Спасибо, что написали об этом, это действительно так. Доступы должны открываться на компанию, а не на личные аккаунты.

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

Посмотрю с другой стороны, я на стороне поставщика. Любой пункт, не зафиксированный письменно, в будущем обе стороны будут помнить по-разному.

Спешка в решениях оборачивается исправлениями через полгода.

Спасибо это именно то, что я искал.