Заметки об американском программировании

Проработав 20 лет в российском программировании и попав по делам в среду американской программистской компании, мне было интересно, конечно, посмотреть, как тут работают. И сравнить. Первые пару месяцев я радовался каждому новому свидетельству того, что в отношении программистской техники я сильнее. Это могло, конечно, относиться только к моей первой команде, но постепенно стало выглядеть как общий закон. Я всегда знал, что я неплохой программист, но чтоб настолько... Не говоря уж о "computer science". Если им, беднягам, нужна была компрессия, шифровка, картография или машгеометрия, они плелись ко мне, сдаваться большевикам... Догадываюсь, впрочем, что и тут есть классные "технари" и "теоретики". Это очевидно из общих соображений, зная, какая тьма всего тут напахана, можно видеть высокий класс во многих текстах, опубликованных в книгах и т.п. Но здесь пока речь пойдет о "типичном" американском программисте.

Так вот, со временем и до меня дошло, что этот "типичный" очень даже является профессионалом, но в другой области, чем я. Не знаю, как эту область назвать, но в ней так же важно уметь поддерживать системы, как и разрабатывать новые программы. Например, типичное занятие - очень быстро разобраться в проблемах клиента по телефону, и найти эффективное решение. Для этого надо, очевидно, знать кучу вещей, смежных к твоей узкой теме и иметь некоторое архитектурное зрение. Жизнь просто другая, и подкидывает "типичному" программисту другие задачи. Количество "просто" пользователей и техническая сложность пейзажа тут совсем-совсем другие.

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

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

Структура управления

Первое, что надо понимать - это что из работающих на фирме лишь 20-30% на ней числятся, это employees - служащие. Остальные - консультанты, они служащие других фирм тут лишь временно, их как-бы сдали внаем. Характерна их высокая текучесть и полная к ним бесцеремонность со стороны основной фирмы. Некомпетентность или просто отсутствие работы - уволен. Консультант тоже не склонен со мной возиться, если я оказался "high maintanance guy". Это не является трагедией, работы всегда полно и если я увидел лучшую возможность или почувствовал что без меня им никак, я так же бесцеремонно потребую деньги на бочку или уйду. Однако люди с рабочей визой, данной на проект, без грин-карты, которых фирма нашла в Индии или Китае и "импортировала", оказываются в бесправном положении, они вынуждены ладить с хозяином любой ценой. Консультант получает более высокую зарплату, чем служащий, даже с вычетом того, что забирает фирма. Часто, если консультант - "хороший парень", т.е. у него высокая самомотивация и очевидно, что его не надо будет погонять, то ему могут предложить перейти в служащие. Это означает падение в заплате, но зато и почти полную безопасность и существенные "бенефиты", 4-х дневная неделя, пенсионный план, отпуск... Фирме это выгодно и руководство часто нажимает, повелевая избавляться от консультантов. Но каждый понимает, что использование консультантов дает свободу в управлении кадрами и повышает гибкость.

Вся работа проводится бригадами. Как и везде, они организованны вокруг "задач", например, по подсистемам или по проектам, или по этапам в проектном цикле (планирование - разработка - тестирование - обслуживание. Сбыт не берем). Или по потокам управленческих данных. Бригада имеет лидера, как правило из служащих. Хотя это начальник, или, скорее, координатор, часто он получает меньше всех в бригаде. Так же часто он уже и не программист. Невозможно кодировать, если надо отвечать на 40 - 100 (и больше!) E-mail в день. В эту ловушку неизбежно и быстро попадает любой "координирующий" человек. Плюс совещания, на которых высший слой менеджеров решает, что надо делать.

Оттуда лидер приносит в клюве свежие ЦУ, собирает совещание команды и начинает планировать. Обсуждение довольно свободное, хотя добиваться консенсуса не требуется. Если нет нависающего крайнего срока, применяется приоритетное планирование, т.е. говорят, что эта задача имеет высший приоритет, когда она стоит - делаем вот эту и т.д. Иногда говорят, - вот ты трать на это работу 2 часа в день. Если крайний срок есть, используется довольно мелочное планирование для каждого по дням и даже часам, хотя контроля за соблюдением я что-то не видел. Если крайний срок горит, все сидят до упора. Действует принцип перегрузки, т.е. все всегда должны быть заняты и "не успевать". Только сильный лидер и только как исключение может допустить несанкционированную деятельность. Почему это так? Высшее звено менеджеров владеет деньгами, вполне реально, у них есть бюджет и они его тратят вполне бесконтрольно, до поры-до времени, пока им не отчитываться. Когда я работаю, я, неважно, служащий или консультант, списываю свое время на те или иные проекты, т.е. на чей-то бюджет, указывая и "вид деятельности", на счет которых есть обширная классификация. ВСЕ время должно быть куда-то списано... Тот менеджер, чей это проект, должен подписаться за мои расходы. Может и не подписаться и лучше до этого не доводить. Где вовлечены деньги, ошибки не допускаются. Дисциплина, дедикейшн, мотивейшн... Страшновато?

Конечно, не все и не всегда происходит так. Сильные специалисты могут выбирать, "чем бы сегодня заняться", к ним имеется длинная очередь задач, на все вкусы... Кому ни спишут, тот рад будет...

Хочу отметить, что высший слой менеджеров технически уже давно "clueless", без понятия, они это сознают и никто не видит в этом недостатка. Их сила (или отсутствие таковой) в связи с заказчиками, от которых приходят деньги, и в видении будущего (чем будем платить людям через два года?). Средний слой, лидеры групп, должны быть технически сильны, им не дают все забыть, посылают подучиваться, этим людям положено знать "как" и "почем", но не "что". Функции не смешиваются, а иначе это быстро приводит к кадровым передвижкам. Редко когда техническое решение навязывают сверху. Если по видимости это происходит, то, значит, решение было навязано заказчиком. Или это значит, что начальник дурачок. И ему скоро конец.

Психологический климат в бригадах зависит от людей, естественно, но как мне кажется, здесь преобладает деловое отношение с ориентацией на результат. В острых ситуациях люди стараются сдерживаться, даже если есть все основания взорваться. Взорвался - удар по репутации, особенно лидера. Замечания не делаются публично, по той же причине.

В целом, есть впечатление механистичной рациональности, холода. Отчасти оно сглаживается социальными средствами - юмором, обязательностью, подчеркиванием уважения к чужому мнению и т.д. Кроме того, деньги тоже отчасти смягчают, зарплаты высокие и это позволяет почувствовать определенную "привилегированность". Система выглядит умней людей.

Техника управления и поддержки разработок

Первое, что надо знать - все по email. Ничего не говорится только устно, все подкрепляется почтой. Телефон только для оперативной информации и поддержки, распоряжения по нему не даются. Значение этого очевидно, вся история остается. Почтовый пакет позволяет многое, можно сортировать сообщения по ящикам, искать, перенаправлять, рассылать по спискам. Можно послать такое сообщение, что стереть его будет нельзя - выглядит как угроза и делается редко. Нормальный разработчик получает 10-30 сообщений в день, менеджеры получают сотни.

Другая похожая система - time table. Это мой календарь, в который некоторые люди (секретарша) имеют право (я им его дал) заносить пометки о будущих событиях, типа совещаний, семинаров, крайних сроков и т.д. В любое время я, заглянув туда, получаю представление о своем ближайшем будущем.

Второе, что надо знать - это PVCS. Роль этого простенького пакета очень велика и людей, которые его (или чего-то эквивалентного) не знают, в Америке нет. Или не будет. PVCS - это Program Version Control System, система управления версиями. Это база данных исходных текстов (теоретически, любых файлов), расположенная на ЛАНовском сервере, откуда можно Взять текст и куда его можно Положить. Если я просто взял текст, я получаю его самую недавнюю копию в виде файла, защищенного от изменений (этот режим можно изменить вручную локально, тогда возникнет путаница). Но я могу также взять текст, Заперев его, тогда он будет доступен для изменений, но никто больше запереть его не может. Изменив "запертый" мною текст, я могу положить его обратно, при этом система запросит комментарий, а что я сделал?, и присвоит тексту следующую версию. В любой момент можно получить всю историю изменений и любую из предшествующих версий. Можно пометить коллекцию текстов меткой.

Главное назначение PVCS - избежать ситуации, когда разные программисты меняют разные части одного и того же текста. И связать любое изменение с его автором (что делается автоматически, путем запоминания ЛАНовского позывного автора вместе с образованием новой версии) и с некой причиной (что делается через комментарий). Все комментарии также автоматически добавляются в текст как стандартные Си-комментарии. У нас PVCS работает в тесной связи с MAKEpom: если есть проект в мейкере, я могу использовать его, чтобы вытащить все последние версии всех файлов в проекте и все h-файлы, кроме того, можно узнать, а из каких текстов был скомпилирован данный модуль. Чтобы сгенерировать полный набор текстов для какого-то модуля, достаточно сказать "gen имяМодуля". Важное свойство пакета - можно узнать, какие файлы кем заперты. Если мне пора сгенерировать версию, очень полезно знать, над чем еще работают и кто... В целом, это отличный организующий центр.

Третья важная черта, связана с помешательством на тестировании и использовании bound checker"s и других средств проверки качества кода. Для тех кто не знает: bound checker - это нечто вроде отладчика, который ловит выходы за границы массивов, взятую и неотданную (или наоборот) память, а также, что важнее под Windows, системные ресурсы, не те аргументы в вызовах системных функций, копирование с перекрытием и т.д. На некоторых фирмах ОБЯЗАТЕЛЬНО иметь чистый протокол bchkw при сдаче модуля. На нашей не так, все бы остановилось... Люди анализируют статистику ошибок по модулям и бригадам (но, правда, не по разработчикам, это не коллегиально), цикломатическую сложность программ, и пр. и все это выливается в решения типа "на что теперь важнее тратить деньги".

Гипертрофия и мания тестирования

Как вы относитесь к такой идее: каждому программисту дать двух контролеров качества? Именно так дела и обстоят. Где не два, там полтора точно. Каждое изменение, естественно, приводит к полному перетестированию всей системы (т.е. проверяют, а работает ли то, что уже работало), тут это почему-то называют регрессионным тестированием. Если добавлено новое качество, его, естественно, проверяют тоже. Изменения сперва накапливают (некая сумма изменений, которую надо протестировать, и есть "версия", с точки зрения контролера). Просто так, вне версии, ничего изменить в полевом софтвере не дадут. Основой являются таблицы, где написано, что должна делать система в том или ином случае и перебраны все существенно разные варианты ввода. Одним из вариантов "ввода", например, является выключение питания... В общем, тестеры (это простая работа, не требующая образования) работают в 2 смены и в выходные, их количество увеличивается, и это тенденция поучительная. Не все ладно в Датском королевстве... Интересно также постоянное ощущение полупритушенного конфликта между тестерами и разработчиками. Разработчики тоже тестируют свои системы и компоненты. Мы, например, используем робот-тестер - отличный пакет QA-Partner фирмы Segue. Он позволяет запомнить мои, пользователя, действия в виде скрипта, программы на Си-подобном языке. Далее я вставляю в нее циклы, выделяю общие функции и пожалуйста, робот готов.

Знаете ли Вы, что Instance, экземпляр объекта в объектно-ориентированном программировании - это конкретный объект из набора объектов данного класса. Все экземпляры одного класса имеют одинаковый набор операций.