Если попасть молотом по башке врага — ты победил. Если промахнулся — иди учись…

Согласно pairwise.org , есть множество софтинок для этого дела, и от Microsoft (их несколько, не только PICT), и от NASA (уже недоступна, в космос улетела), от Motorola, от IBM, и др.

Некоторые эти программы работают через консоль, другие через GUI, третьи через одно место, и все они, в принципе, делают то же самое, что может сделать один нормальный инженер с карандашом и бумагой, но делают это очень быстро. Главное — подать им на вход грамотный набор данных.

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

Есть и онлайновые сервисы: hexawise, inductive, testcover — смотреть большой обзор, я ими не пользуюсь, предпочитаю консольную Allpairs (скачать бесплатно с джеймсобаховского сайта), бо привык к ней, и она не привязана к одной операционной системе.

Чтобы с ней управляться, нужно сперва уметь управляться с консолью. Ну там, между каталогами переходить, уметь из каталога с тестовыми файлами запускать программу, которая находится в другом каталоге, короче, основные основы управления любым современным кантупиром.

Ведь не может же такого быть, чтобы кто-то занимался тестированием ПО, не понимая, как устроена файловая система, и как организованы файлы на жестком диске, и как управляться со всем этим добром из консоли.

Затем нужно уметь составлять таблицу данных, которая будет обработана Allpairs. В Excel (или в Calc) нужно сделать таблицу с перечислением сущностей и их параметров, затем экспортировать эту таблицу в текстовый файл с разделением столбцов через «TAB». Затем скормить этот текстовый файл Allpairs на обработку.

Непосредственно Allpairs привык использовать так: в каталоге с программой allpairs.exe создаю подкаталог (‘Test’), в который сохраняю текстовые файлы (с таблицами из Excel). В этом же подкаталоге появится и файл с результатами работы allpairs.exe.

Перехожу в этот подкаталог (‘Test’), и уже из него обращаюсь к allpairs.exe, которая находится на одном уровне выше.

Указываю в этом вызове файл, который надо обработать (назвал его input.txt) и приказываю вывести результат работы в файл, который на диске еще не существует (назвал его output.txt).

В Unix алгоритм работы (методология) тот же, но

1. перед вызовом программы обязательно нужно указать ‘perl’,
2. в самом названии программы указывать расширение ‘.exe’ уже нет необходимости,
3. слэши другие.

Нюансы под макой и убунтой (вот, казалось бы): таки надо внятно указать обращение к файлу allpairs.pl:

perl ../allpairs.pl input.txt > output.txt

[…]

Я-то уже понял, что ровно те же самые проблемы есть во всех больших компаниях.

Не могу сказать, чтобы я был несчастлив, и не хочу ни на что жаловаться… но в колледже об этих вещах меня никто не предупреждал.

Итак, поехали.

• Не надейтесь найти в корпорации документацию.

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

  .

• Важно не то, что ты сделал — важно то, что ты продал.

  .

  Можно днями улучшать свой код и править чужие ошибки, но пока это не оказывает никакого влияния на продажи и результат усилий невозможно продать — ваша работа практически ничего не значит. Никого не интересуют ваши правки кода в погоне за его чистотой или стилистическим единством; никого не интересует и решение проблем с архитектурой. На вас даже могут обидеться, если вы будете заниматься подобным. Когда я был студентом, мне не это рассказывали.

  .

• Не всем есть дело до программирования.

  .

  Вы не всегда будете работать с теми, кто нежно любит разработку софта. У большинства людей здесь есть в жизни что-то еще (семья, дети), поэтому стремление написать чистый код чаще всего не входит в их планы. И это нормально. Я научился не ждать энтузиазма от всех и каждого.

  .

• 2-3 часа чистого кодинга в день — это замечательная цифра.

  .

  До того, как я попал на свою работу, я программировал 8-10 часов каждый день, сидя за своими проектами. А в новом окружении у меня едва удается писать код 2 часа кряду. Большую часть своего времени я провожу в попытках понять, как работает чужой некомментированный/недокументированный код, занимаюсь отладкой странного поведения программ и посещаю ежедневные собрания. Все сказанное касается не только меня, поэтому случается, что проходят дни без единого коммита во всей команде. И это тоже нормально.

  .

• Ничего не делать для других взамен — это нормально.

  .

  В своей организации я не встретил ни одного блоггера или разработчика открытого ПО, который бы посвящал часть своего времени любой «отплатой» коммьюнити. Гуглить ответы на Stack Overflow — это с радостью, но свой ответ на вопрос там никто никогда не напишет. Я их понимаю.

  .

• Здесь не слишком осведомлены о том, что происходит во внешнем мире.

  .

  Думаю, все вы каждый день читаете различные новости IT-тематики в блогах, на Reddit или Hacker News. Здесь это не принято. Я был удивлен, когда узнал, что никто из команды Windows Azure никогда не слышал про Heroku или Rackspace — а ведь это их прямые конкуренты. Это приемлемо, не всем же про это стоит знать. (Тут действительно поразительное сходство с Apple, если верить книге Адама Лашински «Inside Apple» — прим. переводчика)

  .

• Суть в том, чтобы делалось дело.

  .

  Если менеджер просит вас о кнопке, которая будет делать то-то и это, то никого не интересует, чего вы там наворотите. Когда запрошенная функция начинает работать, можно считать, что задача выполнена — все остальное можно будет поправить потом. Хотя, честно говоря, сам-то я с этим обещанным «потом» никогда так и не сталкивался. В колледже мне говорили, что качество кода так же важно, как и сам результат его работы. Тут оказалось, что это не так.

  .

• Копипаст кода — это нормально.

  .

  Если кто-то на Github застукает вас за подобным приемом, готовьтесь к расправе в темной подворотне. Тут же я не раз встречал исходники, которые просто копипастились из проекта в проект. Поскольку свое дело они делали (об этом — ниже), никого не интересовало то, что код абсолютно неподдерживаемый.

  .

• Ради скорости дела можно обойтись и без code review.

  .

  Это один из обычаев нашей команды — если ты связался с чужим кодом, то ты должен отправить code review. Обычно же этим никто не занимается, и можно прождать уйму времени, прежде чем кто-то после десятого письма вам ответит.

  .

• Последние версии ПО, ага, как же.

  .

  Далеко не всем нравятся последние версии. 90% моих коллег используют старые версии Office, Windows, Visual Studio и .NET Framework. Есть суеверие, что новые версии напрочь ломают устоявшийся рабочий процесс. Наверное, им руководствуются те, кто до сих пор запускает все свои приложения на Java 1.3 — 1.5. Так я отучился ждать использование последних версий ПО в проектах.

  .

• Ваша специализация не имеет значения.

  .

  Студентов нанимают тысячами и случайно распихивают по командам (которые вы не сможете сменить еще полтора года). Неважно, развлекались ли вы с MongoDB, разрабатывали приложения под iOS, коммитили в Apache, дизайнили интерфейсы или «бутстрапили» свой личный стартап. Вас наняли, чтобы вы сделали то, что вам скажут. Я не ожидал подобного. Здесь слишком сложно найти то место, где можно было бы заниматься тем, что любишь.

  .

• И в заключение.

  .

  Вы работаете на своего менеджера и на его зарплату. Вот об этом мне точно никто раньше не говорил.