Действительно ли фрилансер ответственен за плохой код, который он наследовал от кого-то еще?

Когда я работаю внештатно, я выполняю работу, которую мне платят / меня просят сделать, и консультирую по работе, которую, как мне кажется, следует делать.

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

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

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

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

Я не думаю, что вы можете нести ответственность (но я не юрист - обратитесь к одному из них, если есть реальная неотложная юридическая проблема) по ранее существующим проблемам, ЕСЛИ вы дадите клиенту понять, что знаете о них.

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

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

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

Здесь есть два отдельных вопроса:

Как вы защитите себя в этой ситуации?

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

Как вы поступаете правильно со стороны клиента в этой ситуации?

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

Почему заранее? Потому что в противном случае вы получите синдром автомеханика, когда вы садитесь в свою машину, и механик говорит: «О, кстати, мы нашли эту проблему здесь», и вы чувствуете себя неловко, потому что не уверены, реально это или нет. . Но если вы попросите механика повсюду хорошенько изучить его, по крайней мере, вы будете чувствовать себя более комфортно, если он что-то найдет.

Точно так же, если вы получите предварительное согласие. искать такие вещи,

DateUtil.parseDate (dateString) из http-компонентов apache

(унаследованные: DateUtil.parseDate (dateString) (из apache commons-httpclient))

Он имеет правильный формат, определенный как константа, который гарантированно соответствует протоколу.

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