Saturday, October 16, 2010

Сверху вниз и снизу вверх. Часть IV

Cм. также
Оптимистический и пессимистический взгляд на жизнь
Сверху вниз и снизу вверх. Часть I
Сверху вниз и снизу вверх. Часть II
BFS and DFS - поиск в ширину и глубину Сверху вниз и снизу вверх. Часть III (продолжение)


В этой заметке рассмотрим технику Testing first - сначала тестировать и её связь с основной мыслью серии заметок.

Не вдаваясь в теорию приведу суть этой техники. Суть эта заключается в том, что как только мы хотим приступить к имплиментации некого модуля системы, мы должны остановится и написать сначала для него тест (unit test). Для того чтобы мы могли запустить наш unit test мы пишем по-сути вместо модуля некую заглушку. Затем на каждый вариант input-а мы пишем отдельный test case. После того, как мы покрыли все случаи мы начинаем писать собственно имлиментацию.

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

Давайте, однако, разбираться. Как я писал, есть два способа написания программы - сверху вниз и снизу вверх. Если писать программу "сверху вниз" при котором на каждом этапе мы делаем краткий обзор системы, определяя, но не детализируя любые подсистемы следующего уровня, то, возможно, такой подход имеет смысл. Так как подсистемы не детализированы, то вполне может быть, что наш "модуль" должен быть разделён как указано в пункте б). Также именно по этой причине мы явно не думали о всех возможных input-ах данного модуля, о чём говорит нам пункт а). Однако, по этим причинам значения пункта в) явно переоценено. В процессе написания кода, вдруг выясняется, что тестовое покрытие далеко неполное и должно быть расширено. В этот момент, согласно, методологии, мы должны остановить имплиментацию и вернутся к написанию тестового покрытия (test case). ИМХО, такой interupt требует колоссальных ментальных затрат (по крайней мере у меня).

Второй способ, "снизу вверх". При таком способе мы разбиваем задачу на атомы, затем под-системы первого уровня, которые соединяют атомы, затем подсистемы второго уровня, соединяющие подсистемы первого уровня и т.д. Как я писал, здесь есть два подтип. Первый подтип, как только мы идентифицировали модуль, мы его тут же имлиментируем. Т.к. мы не видим всей картины целиком, то тут все пункты перечисленные выше могут произойти. Однако, ИМХО, гораздо проще вместо подхода tesing first, сделать-таки полный дизайн, как во втором подтипе. В таком случае пункт б) (слишком крупный модуль) не должен произойти. Если он произошёл, значит мы плохо справляемся с работой, так как мы об этом уже думали. То же самое и с пунктом а) (думать о всех случаях). Пункт в) не релевантный, т.к. мы думал о нём на этапе дизайна всей системы, зачем нам дважды делать одну и ту же работу?

Таким образом при написании системы "снизу вверх" использование техники testing first явно не оправдано, нужно просто разработать полный дизайн, а не делать имплиминтацию на месте (если настаивать на последнем варианте, то такая техника имеет смысл). При написании системы "сверху вниз" эта техника "заставляет" нас делать определённые действия, в этом её несомненный плюс. Однако, эффект от его использования явно преувеличен из-за постоянных interupt-ов между имплиментацией и написанием тестового покрытия.

Последнем посте из этой серии:

5. Note first - Сначала писать комментарии.

Продолжение следует.