Недавно знакомый мне расписывал прелести рефакторинга. Как я понял, это тест-драйвен разработка, где тесты для кода пишутся раньше самого кода. И я подумал, что все что я делал при переводе ТАДСа, я делал примерно по этой методике. Сначала видел проблему, потом подгонял библиотеки пока не получалось то, что я хотел. Игры служат набором тестов. Чем больше разнообразие ситуаций, чем больше тестеров прошлись, тем больше шансов отловить ошибки.
Отсюда следует, что к новой системе обязательно должна прилагаться игра, максимально использующая её возможности.
Когда-то тут пробегала теме о ГОСТе в ИФ. Таким "гостом" может быть некоторая игра. Неважно как что-то реализовано в системе, главное, она позволяет пройти эту игру. Она задает определенный минимум возможных действий и позволяет сравнить особенности разных сред разработки.
P.S. Я вовсе не стимулирую разработку новых платформ, но поговорить на эту тему интересно
Неактивен
Гранд, осмелюсь тебя поправить, рефакторинг не имеет прямого отношения к тест-драйвену, хотя тоже является одной из методик XP.
Рефакторинг - это реструктуризация и изменение кода без изменения интерфейсов и функциональности для его лучшей читабельности и прозрачности. И ничего больше
А тест-драйвен девелопмент позволяет убедиться в том, что после рефакторинга модуль не поменял функциональности, и не появились никакие баги.
А вместе их описывают по той простой причине, что и рефакторинг и тдд являются методиками, входящими в одну методологию, называющуюся "экстремальное программирование"(XP).
Подробнее почитать можно, например, здесь:
http://ru.wikipedia.org/wiki/Экстремаль … ммирование
P.S. Сорри, за очепятки, я сильно сонный ))
Неактивен