Подделка реализации при проектировании интерфейсов
До меня дошло.
Напомню, что методология разработки программного обеспечения через тестирование (Test Driven Development) состоит в следующей простой концепции:
1. Написать тест для разрабатываемой функции.
2. Сделать так, чтобы все компилировалось (в этот момент тест не проходит).
3. Любыми средствами заставить тест срабатывать.
4. Провести рефакторинг.
5. Еще раз запустить тесты и убедиться, то после рефакторинга ничего не отвалилось.
Посмотрим внимательно на пункт три: «Любыми средствами заставить тест срабатывать.» TDD требует, чтобы мы заставили тест проходить как можно быстрее. Но как этого добиться, если разрабатываемая функция весьма сложная? TDD предлагает элегантный метод - подделать реализацию.
Это значит, что если мы пишем функцию function Sum(A, B: Integer): Integer и тестируем её с помощью теста Assert(Sum(2, 2) = 4), то на третьем этапе разработки по TDD функцию Sum можно реализовать так:
function Sum(A, B: Integer): Integer
begin
Result := 4;
end;
То есть на самом деле ничего не реализовывать, а вернуть такой результат, чтобы тест сработал. Правильная реализация будет написана позже на этапе рефактиринга.
До меня дошло, что подделка реализации может неплохо работать и при проектировании интерфейсов. Более того, я использовал это метод уже множество раз, просто не осознавал это.
Итак. Если вам нужно разработать новый интерфейс, то:
1. Напишите первую часть сценария, где говорится о намерениях пользователя и результатах, которые он хочет увидеть. Например: Управдом хочет узнать кто не заплатил в этом месяце за свет. Это будет тест.
2. С помощью любых интерфейсных решений добейтесь того, чтобы интерфейс мог сделать то, что нужно пользователю. Пусть это будет через жопу, пусть будет закопано в меню, пусть нужно будет прыгать на одной ноге и играть на волынке. Главное - должно работать и давать желаемый результат.
3. Найдете и исправьте все интерфейсные ошибки. Теперь, когда есть хоть какой-то интерфейс найти ошибки и исправить их очень просто.
4. Проверьте, что исправленный интерфейс все еще делает то, что нужно пользователю. После изменений, как после рефакторинга, нужно проверить, что ничего не испортилось, для этого нужно сверить интерфейс со сценарием.
5. Допишите сценарий, чтобы кодеры могли его запрограммировать.
Я постоянно применяю эту технику. Только вместо того, чтобы делать пункт 2 самому я всегда прошу кого-то сделать первый набросок интерфейса.
И еще. Ребята, сценарии нужно писать всегда, не зависимо от того как и что вы разрабатываете. Если у вас нет сценария, то у вас не то что хороший интерфейс не получится, вообще не будет понятно получилось ли у вас сделать желаемое или нет, потому что не будет понятно чего вы вообще хотели сделать.
Про замеченные взаимосвязи в методологиях проектирования интерфейсов и техниках разработки кода смотрите также «Рефакторинг, когнетика и дезодорант».
Напомню, что методология разработки программного обеспечения через тестирование (Test Driven Development) состоит в следующей простой концепции:
1. Написать тест для разрабатываемой функции.
2. Сделать так, чтобы все компилировалось (в этот момент тест не проходит).
3. Любыми средствами заставить тест срабатывать.
4. Провести рефакторинг.
5. Еще раз запустить тесты и убедиться, то после рефакторинга ничего не отвалилось.
Посмотрим внимательно на пункт три: «Любыми средствами заставить тест срабатывать.» TDD требует, чтобы мы заставили тест проходить как можно быстрее. Но как этого добиться, если разрабатываемая функция весьма сложная? TDD предлагает элегантный метод - подделать реализацию.
Это значит, что если мы пишем функцию function Sum(A, B: Integer): Integer и тестируем её с помощью теста Assert(Sum(2, 2) = 4), то на третьем этапе разработки по TDD функцию Sum можно реализовать так:
function Sum(A, B: Integer): Integer
begin
Result := 4;
end;
То есть на самом деле ничего не реализовывать, а вернуть такой результат, чтобы тест сработал. Правильная реализация будет написана позже на этапе рефактиринга.
До меня дошло, что подделка реализации может неплохо работать и при проектировании интерфейсов. Более того, я использовал это метод уже множество раз, просто не осознавал это.
Итак. Если вам нужно разработать новый интерфейс, то:
1. Напишите первую часть сценария, где говорится о намерениях пользователя и результатах, которые он хочет увидеть. Например: Управдом хочет узнать кто не заплатил в этом месяце за свет. Это будет тест.
2. С помощью любых интерфейсных решений добейтесь того, чтобы интерфейс мог сделать то, что нужно пользователю. Пусть это будет через жопу, пусть будет закопано в меню, пусть нужно будет прыгать на одной ноге и играть на волынке. Главное - должно работать и давать желаемый результат.
3. Найдете и исправьте все интерфейсные ошибки. Теперь, когда есть хоть какой-то интерфейс найти ошибки и исправить их очень просто.
4. Проверьте, что исправленный интерфейс все еще делает то, что нужно пользователю. После изменений, как после рефакторинга, нужно проверить, что ничего не испортилось, для этого нужно сверить интерфейс со сценарием.
5. Допишите сценарий, чтобы кодеры могли его запрограммировать.
Я постоянно применяю эту технику. Только вместо того, чтобы делать пункт 2 самому я всегда прошу кого-то сделать первый набросок интерфейса.
И еще. Ребята, сценарии нужно писать всегда, не зависимо от того как и что вы разрабатываете. Если у вас нет сценария, то у вас не то что хороший интерфейс не получится, вообще не будет понятно получилось ли у вас сделать желаемое или нет, потому что не будет понятно чего вы вообще хотели сделать.
Про замеченные взаимосвязи в методологиях проектирования интерфейсов и техниках разработки кода смотрите также «Рефакторинг, когнетика и дезодорант».