Какими инструментами и методами проверки кода принимать проект у агентства?

Запуская статические анализаторы, смотрите не только на кодстайл, но и на правила безопасности SAST. SQL-инъекции, IDOR (небезопасные прямые ссылки на объекты) и слабая валидация входящих данных ловятся правилами на ура. И обязательно гляньте тестовое покрытие: если агентство не написало юнит-тесты, рефакторить это добро потом будет сущим адом.

Мы в прошлом году так же за 40.000 долларов принимали бэкенд для мобилки. Автосканеры светились зеленым, кодстайл идеальный. А через две недели после релиза база намертво легла — оказалось, подрядчик в реляционной БД вообще не создал внешние ключи и индексы. Сканеры такое в жизни не поймают.

Мы при сдаче проекта отдали независимому сеньор-архитектору 2.500 долларов за 15 часов детального аудита. Он нашел 4 критические проблемы в архитектуре, которые убили бы масштабирование, и 8 дыр в авторизации. Эти затраты окупились с лихвой.

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

Первое, что можно сделать уже завтра: посмотрите историю версий репозитория (git log). Агентство в панике пушило всё за последние 3 дня или 4 месяца шло с регулярными коммитами и понятными сообщениями? Дисциплина версионирования — главный показатель внутреннего качества кода.

Чек-лист при приёмке работы от агентства: 1) Не забыты ли в коде API-ключи внешних сервисов? 2) Подходят ли лицензии open-source библиотек для вашего коммерческого использования? 3) Работают ли шаги деплоя (deployment) и локальной установки полностью по одному документу?

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

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

Взял на заметку, спасибо.

Мне тоже интересно.

Слежу за темой.

Отличная работа. Ответ сильно зависит от отрасли, универсального правила нет.

Оставлю как заметку, пригодится.

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

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

После того случая мой взгляд на вещи изменился. Код без документации не принадлежит вам, даже если он у вас есть.

Если напишете результат здесь, это поможет и другим.

Согласен.

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

Я бы пошел этим путем.

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

У нас так же. Все, кто торопится с инструменты проверки кода, спотыкаются на одном и том же.

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