ПСЕВДОКОД Процесс программирования против Test Driven Development

С Test Driven Development вы все равно должны делать некоторое планирование в начале. Он должен сначала быть взглядом на высоком уровне, что вы пытаетесь сделать. Не подходите со всеми деталями, но получить представление о том, в простом английском языке о том, как решить эту проблему.

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

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

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

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

Я использовал оба вместе с Большим Upfront развитием, все три имеют свои места, в зависимости от проблем, таких как язык, динамика команды и размера программы / сложности.

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

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

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

Просто потому, что тест пройден, не означает, что вы сделали.

TDD лучше всего характеризуется красный - зеленый - Refactor .

Имея тест обеспечивает один (из двух) линии ворот. Это только первый, минимальный набор требований. Реальная цель та же цель, как «псевдокод процесса программирования» или любой дизайн дисциплины.

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

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

Реальная целью является хорошим программным обеспечением. TDD не может исключить «Совершенство».

Методика не является ограничительным мандат. А методы следует рассматривать как костыль, чтобы помочь вам продукт хороший код. Если бы я был умнее, богаче и лучше выглядящим, я бы не нужен TDD. Но так как я такой тупой, как я, мне нужен костыль, чтобы помочь мне рефакторинг.

Для меня TDD имеет туз pseudocoding просто не может конкурировать с - как помочь вам абстрактно и планировать развитие, но как только вы закончили разработку в TDD земли у вас еще есть юнит - тесты .

AS полезный подход, как описано СС2 pseudocoding, оно просто не может соответствовать. TDD только половина о проектировании, она также обеспечивает строгую леску вы можете развиваться проект вперед с. Однако я не вижу причин, почему вы не можете псевдокод для решения множества проблем TDD.

Я не должен развиваться органически.
ПСЕВДОКОД ум-убийца.
Это мало-смерть , которая приносит забвение памяти проекта.
Столкнусь мою методологию 90 -х годов.
Я позволю ему пройти через меня и через меня.
И когда она прошла мимо обращу внутренний глаз , чтобы увидеть свой путь.
Где псевдокод пошел там будет TDD.
Только единичные тесты останутся.

(Пожалуйста, не пламя меня за то, что я только полусерьезно: P)

Моя команда смешивает оба подхода, и это удивительным образом развиваться (по крайней мере, для нас). Нам нужны модульные тесты, потому что у нас есть большая и сложная система программного обеспечения. Но процесс программирования ПСЕВДОКОДА рука вниз лучший подход к разработке программного обеспечения я сталкивался. Для того, чтобы заставить их работать вместе:

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

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

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