20 мая 2012 г.

Тестирование и документирование

Я уже давно хожу с этой мыслью — решил про нее написать, и освободить в голове место для новых мыслей :)

Помимо основной задачи — проверять корректность работы и описывать работу приложения — у тестирования и документирования есть еще одна очень важная функция. Эта функция — давать разработчику возможность посмотреть на свой код, на свою архитектуру, с альтернативных точек зрения. Мне кажется, эту функцию часто недооценивают (если вообще про нее помнят) — а между тем она, кажется, очень важна. Может быть, иногда важнее основной. Я уверен, что хорошую архитектуру вообще невозможно создать без того, чтобы в процессе работы над ней смотреть на нее с 2-3-4 разных точек зрения.

Вот в ТРИЗ есть такой "оператор РВС" (размер-время-стомость) — психологический прием, помогающий взглянуть на решаемую задачу с нескольких непривычных точек зрения. Я бы его так и называл — оператор сдвига точки зрения :) Часто он помогает увидеть возможность для очень сильного решения. Вот кажется, что тестирование и документирование могут выполнять роль такого "оператора сдвига точки зрения" в разработке (хотя, собственно, сам РВС вполне можно использовать тоже).

Когда я пишу тесты — я смотрю на свою архитектуру с точки зрения ее использования вне текущего приложения. Это позволяет мне выбрать такую абстракцию, которая будет действительно re-usable в разных контекстах — а не только в том, для которого я ее сейчас создаю. Когда я пишу документацию — я смотрю на свою архитектуру с точки зрения человека со стороны, не принимавшего участия в разработке, не имеющего доступа к ее истории. Это заставляет меня, в частности, подвергать сомнению какие-то "исторически сложившиеся" вещи — действительно ли системе все еще нужна эта история?

В этом смысле тесты работают даже если их никто не запускает. А документация работает, даже если ее потом никто и не читает :)

Почему про это полезно помнить? Ну, лично мне это позволяет точнее отвечать на вопрос "зачем я пишу эти тесты/эту документацию". Т.е. если я пишу тесты только для того, чтобы проверить соответствие реализации и контракта — это одно. А если я пишу их в том числе и для того, чтобы понять, насколько мой компонент удобен и логичен в использовании — это уже немного больше. КПД таких тестов больше, они больше дают. Так же и с документацией.

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

3 комментария:

  1. А ты что, сначала пишешь код, а потом уже тесты с документацией?

    ОтветитьУдалить
  2. Еще круче -- я вообще не пишу ни тестов, ни документации. Я пишу идеальный код -- он не нуждается ни в том, ни в другом.

    Вообще-то, я и код частенько не пишу -- я пишу статьи про то, как его надо писать ;)

    ОтветитьУдалить
  3. yo dawg, i heard you liked articles, so i wrote an article on how to write articles about writing articles

    ОтветитьУдалить