Можете ли вы порекомендовать эффективные способы защиты разработчиков в команде, по ошибке нарушающих бизнес-логику?

Question

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

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

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

Answer 1

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

Мы также проводим еженедельные совещания группы разработчиков для обсуждения различных способов решения проблем с программным обеспечением, а также разработанных нами методов и т. Д.Мы могли бы обсудить WCF, Linq, SQL Server во время этих встреч.Идея состоит в том, чтобы держать команду в курсе того, как мы решаем проблемы.

Answer 2

Реализация доменной логики в отдельном проекте / библиотеке и покрытие этой библиотеки модульными тестами .

Answer 3

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

Given <a context>
When <an event happens>
Then <an outcome occurs>.

Они должны искать то, о чем они не знают или о чем не думают, но что делают тестеры.

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

Given <the context in which we start>, 
when <I do this with the system>,
then <this happens>.

Is there any other context in which the same event produces
a different outcome?
Have we covered all the similar combinations?

И ставлю под сомнение результат:

Given <the context in which we start>
when <I do this with the system>
then <this happens>

If I were to make that happen using something different - 
a manual process, say - would that cover the outcome you're 
hoping to achieve?

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

Если у вас возникли проблемы с аналитиками / представителями бизнеса и / или тестировщиками, с которыми можно обсуждать эти проблемы, то именно поэтому вашУ разработчиков есть ошибки!

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