Идеальный программист. Как стать профессионалом разработки по

7
Приемочное тестирование
Роль профессионального разработчика подразумевает не только
программирование, но и общение. Помните, что принцип «мусор на
входе/ мусор на выходе» применим и к программистам, поэтому
профессиональные программисты следят за тем, чтобы их общение с
другими участниками группы и бизнесменами было точным и
плодотворным.

---

Передача требований
Одним из самых распространенных аспектов общения между
программистами и бизнесом является разработка требований.
Бизнесмены описывают то, что по их мнению им нужно, а
программисты создают то, что по их мнению им описали.
По крайней мере так должно быть. На практике информационный
обмен проходит чрезвычайно сложно, с высоким риском ошибок.
В 1979 году во время работы в Teradyne меня посетил Том,
руководитель отдела установки и обслуживания. Он попросил меня
научить его работать в текстовом редакторе ED-402, чтобы он мог
организовать простую систему обработки заявок на устранение
неисправностей.
ED-402 был коммерческим редактором, написанным для
компьютера M365 – клона PDP-8. Это был очень мощный текстовый
редактор со встроенным языком сценариев, который мы использовали
для разнообразных операций с текстом.
Том не был программистом, но приложение, которое он себе
представлял, было довольно простым. Том полагал, что я быстро научу
его, а он сам напишет приложение. Я по наивности думал то же самое.
В конце концов, язык сценариев представлял собой обычный
макроязык команд редактирования, с простейшими условными и
циклическими конструкциями.
Итак, мы сели за компьютер, и я спросил, что должно делать его
приложение. Том начал с экрана ввода данных. Я показал, как создать
текстовый файл со сценарными командами и как ввести в сценарий
символьное представление команд редактирования. Но когда я
взглянул ему в глаза, ответный взгляд был совершенно пустым. Он не
понял ни единого слова из моего объяснения.
Тогда я впервые встретился с этим явлением. Для меня символьное
представление команд редактирования было простым и естественным:
например, для представления команды Control+B (команда
перемещения курсора в начало текущей строки) в файл сценария
просто включались символы ^B. Но Тому это казалось
бессмысленным: он не мог перейти от редактирования файла к
редактированию файла, который редактировал файл.

---

Том не был глуп. Наверное, он просто понял, что задача намного
более сложная, чем ему казалось изначально, и не захотел тратить свое
время и умственные силы на изучение такой хитроумной концепции,
как использование редактора для управления редактором.
Мало-помалу я начал сам реализовывать приложение Тома, пока
он сидел и наблюдал. Через 20 минут стало ясно, что он уже думает не
о том, как сделать все самому, а о том, как объяснить 
мне
, что именно
ему 
нужно.
На это ушел целый день. Том описывал некоторую возможность, а
я реализовывал ее, пока он наблюдал. Рабочий цикл составлял не
более 5 минут, поэтому ему не нужно было отходить и заниматься чем-
то другим. Он просил меня сделать X, и через 5 минут реализация X
работала.
Часто Том рисовал то, что он хотел, на листке бумаги. Некоторые
из его требований было трудно реализовать средствами ED-402; тогда
я предлагал что-то другое. В конечном итоге мы договаривались до
чего-то, что могло работать, и я реализовывал согласованный вариант.
Но потом мы опробовали его, и Том менял свое решение. Он говорил
что-нибудь вроде: «Да, но это не совсем то, что мне нужно. Давай
попробуем иначе». Час за часом мы пробовали, экспериментировали и
придавали приложению нужную форму. Мы опробовали одно, потом
другое, потом третье. Вскоре мне стало абсолютно ясно, что Том –
скульптор, а я – инструмент в его руках.
В конечном итоге Том получил желаемое приложение, но не имел
ни малейшего понятия о том, как построить следующее приложение
самостоятельно. С другой стороны, я получил важный урок
относительно того, как заказчик определяет свои потребности.
Оказалось, что его представление о функциональности приложения
часто не переживает контакта с компьютером.