Если убрать за скобки советы, в стиле «не обманывай — не обманутым будешь», и прочие «мотивационные штуки на рабочих местах», то такие вопросы легко решаются (или не возникают вовсе) введением
код-ревью в
pre-commit-to-master ветке Git и полным покрытием тестами.
Даже строгий договор и прочие юридические штуки — не могут обезопасить проект от такого произвола. Нет, с точки зрения «кто виноват и сколько он за это заплатит» — всё хорошо.. но оставшейся команде или новым разработчикам — от этого не холодно не жарко — им же всё исправлять. Это я уже из своего опыта разгребания подобного кейса говорю :)
Работает это довольно просто: в продакшен проект попадает только после обсуждения каждой функции в спец. ветке на гите и только после прохождения всех тестов. Любая сомнительная функциональность — просто не пройдёт такой контроль и будет вызывать подозрения. Например, в вашем кейсе, про удаление БД при заходе с определённого пользователя — это будет сразу видно. Как в коде функции (на код-ревью), так и в тестах.
Нужно разбираться в коде и быть профессионалом на своём месте, чтобы совершать такой контроль — не спорю, но... а как по-другому, если потеря данных и/или функциональности сайта — может стоить гораздо дороже, чем з/п человека в штате (на аутсорсе), который будет следить за качеством кода и бить по рукам всех, кто будет пытаться испортить его?
Да, это дольше, но такой подход плюс продвинутая система бэкапирования БД — даёт хоть какие-то гарантии.
«Большой брат» — это благо для компании, если вы не уверены в своих сотрудниках.
