Является ли «Вы ломаете это, вы покупаете это» лучшая политика?

Question

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

Один пример, который можно себе представить, - это когда кто-то программирует на интерфейсе таким образом, который предполагает поведение, специфичное для реализации du jour, но не гарантированное существующими контрактами.Затем кто-то другой вносит изменения в реализацию, которая вписывается в контракт, но нарушает зависимый код.Никакие тесты не пройдены, потому что никакие тесты не написаны для зависимого кода.Кто на самом деле виноват?

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

РЕДАКТИРОВАТЬ: Я действительно плохо сформулировал это.Я имел в виду, что речь идет о том, как написать правильное программное обеспечение по отношению к зависимостям, включая скрытые зависимости.Я имел в виду, что это вопрос о том, что ответственность программиста состоит в том, чтобы избежать ошибок, а не в том, что делать, если обнаружена неожиданная ошибка.НО, поскольку уже было дано так много ответов, я оставлю вопрос в том виде, в каком он есть, и соответственно укажу ответ.

Answer 1

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

Answer 2

«Вы ломаете его, вы покупаете его» имеет смысл с точки зрения поломки сборок, а не более серьезных проблем.

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

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

ShortТермин, человек, который сделал кодовую базу неработоспособной, быстро делает ее снова работоспособной.В долгосрочной перспективе, лучший человек для работы (баланс различных факторов) делает работу.

Answer 3

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

Answer 4

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

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

Answer 5

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

При этом, если что-то не работает, вся команда должна принять падение.

Answer 6

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

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