Процесс программирования псевдокода по сравнению с разработкой через тестирование

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

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

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

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

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

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

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

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

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

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

TDD лучше всего характеризуется Красный - Зеленый - Осуществляют рефакторинг .

Наличие теста обеспечивает один (два) строки цели. Это - просто первый, минимальный набор требований. Реальной целью является та же цель как "Процесс Программирования Псевдокода" или любая дисциплина дизайна.

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

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

реальной целью является Good Software. TDD не может исключить "совершенство".

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

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

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

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

(не горите меня для этого, я только наполовину серьезен :P)

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

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

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

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