Как понять, что сотрудник аутсорсит код на стороне?
Есть удаленный сотрудник, который выполняет определенную часть работы. По тому, как он выполняет свои задания (через определенный цикл правок), и как он местами плавает в коде, создается ощущение, что этот код пишет кто-то другой. В целях безопасности нужно подтвердить или опровергнуть наши опасения. Как это можно понять? По коммитам ничего не увидели, все идет с его машины.
1) Спрашивать почему написал тот или иной код
2) Обратить внимание на стиль написание кода имена методов, переменных, коменты, использование специфичных объектов в коде(к примеру все время идет объявление List varName; а потом вдруг ArrayList var_name. Как правило стиль принятый в одном проекте, не меняется)
3) Пригласить в командировку
4) Забуриться в скайп и поспрашивать по смежным темам.
этот код пишет кто-то другой
- этот код может оказаться банальной копипастой с предыдущих проектов
А обязательства какие-нибудь этот сотрудник подписывал? Я так понял, хотите предотвратить утечку кода на сторону? Если сотрудник не подписывал обязательств, независимо от того, нанимает он кого в субаренду или не нанимает - Вы ему все равно ничего не сделаете :) разве только скажете "у, козел".
Игорь, ну, я бы не стал столь категорично... Если поставить полноценную коммерческую тайну (то есть соблюсти все требования по оформлению материалов, к которым применимо положение о коммерческой тайне) - то можно очень даже сделать Другое дело, что для этого нужно долго и нудно морочиться с такими неинтересными вещами, как грифование документов и ведение журнала выдачи-возврата - сейчас же все эффективные менеджеры, тля, всё в облаках хранят ;)
CityCat4, Вы правы. Моя мысль была в том, что одна только подпись ничего не даст. К тому же я не представляю, как обеспечить полноценную коммерческую тайну для кода, с которым работают удалённые сотрудники. Мне кажется это невозможно сделать.
Игорь, возможно. Удаленный сотрудник или не удаленный - это мало волнует. Главная работа должна быть проведена внутри конторы, а там два "супер-пункта", которые тяжело реализовать (но возможно) - централизованное хранение материалов (то есть, git пролетает сразу) и грифование. И в процессе работы - подпись (вот тут она!) документов, что поставлен в известность блаблабла... и журнал работы с материалами. На деле - это централизованный VCS и трекер.
По сути дела - бороться с утечками материала для удаленных сотрудников бессмысленно. Можно только сделать недвусмысленную демонстрацию того, что если спи... что-нибудь - будешь отвечать по закону.
Собственно зачем тратить время на это расследование? Вы его можете потратить с большей пользой для бизнеса и себя. Главный вопрос - вас устраивает результат работы этого разработчика за те деньги, которые вы платите? Если да, то лучше заняться другой проблемой, если нет, просто смените разработчика.
У нас много удаленных филиалов и такой вопрос тоже был. Мы периодически приглашаем в командировку удаленных сотрудников, тут и тимбилдинг и обмен опытом и сразу все видно.
Лучше самому спросить. Всякие таймтрекеры ничего нового не дадут, а принесут неудобства и недовольства.
UPD: Тут дело в том что 98% случаев "ВАШ КОД" разработчику не нужен, и всякое опасение о его использовании бессмысленно. Исключения могут быть если у вас "революционная программа" или сверхсекретное ПО .
Ну и настоятельно рекомендую не хранить в коде секретные данные(всякие ключи доступа к сервисам, токены и тд)
SyavaSyava, Код устраивает, поэтому человека и не дергаем с места, но если он кому-то левому дает доступы к нашему коду - это не устраивает. Тут ситуация именно в этом заключается.
Надо посмотреть какие файлы используются. Так как многие программы сохраняют данные автора в информацию о файле, например пакет офис microsoft. Эти данные зачастую берутся из имени пользователя компьютера и имени компьютера. О них зачастую люди не думают. Если эти данные у файлов отличаются, можно понять что работа ведется с разных компьютеров.
Либо как указал оратор выше (@ocatoll) смотреть скрины экрана во время работы.
Dr_Gonzo, ну это не тот способ, который без дополнительных умственных усилий даст однозначный ответ.
Тут суть скорее в вычислении возможностей. Допустим файлы отдельной библиотеки или модуля программы написаны неким другим человеком, если это общедоступная какая то библиотека, согласен в этом нет ни чего криминального. Да и если тот кто проверяет, думает головой, претензий к ним не выдвинет.
Тут надо смотреть конкретный проект, конкретные файлы. Какая часть проекта уникальна по своей сути? Когда была начата работа над проектом? Какие стадии проходил проект?
Это все влияет на слепки файлов. И зная конкретную подноготную можно сделать выводы.