Будни нашей лесопилки

Мне довольно часто случается контактировать с коллегами, работающими на самые разные фирмы, причем по всему миру. Неотъемлемой частью таких бесед является (ну как у финских лесорубов - в лесу о бабах, с бабами о лесе) обсуждение того, как устроен техпроцесс в разных конторах. Во-первых, это весьма познавательно, а во-вторых, просто интересно. Расскажу сегодня о том, как организована работа в одном из подразделений разработки ПО у моего клиента - весьма крупной финансовой организации.

1. Второй раз в жизни встречаю действительно стройную, упорядоченную систему документации на Интранет-сервере фирмы. Здесь есть все, начиная от правил заполнения еженедельных почасовок, и заканчивая правилами написания кода на различных языках. Вся информация структурирована, newcomers получают буквальнов первые дни список рекомендованных к прочтению линков, Примерно 90% вопросов, возникающих в процессе работы, снимаются чтением документации, по поводу 10% расскажу чуть позже.

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

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

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

а) есть два плана работы: долговременный и оперативный. Оперативный план разбит на задачи, для каждой задачи назначается два исполнителя - основной и страхующий. Задача основного - сделать работу, страхующего - понимать, чего написал ответственный исполнитель и быть готовым, если что случится, продолжить работу.

б) никакой код невозможно изменить "просто так": разрешение на изменение кода выдается в рамках назначенной разработчику задачи, описание которой содержит, в частности, список тех файлов, которые он может изменить. Кроме того, для каждой задачи менеджером отдела и архитектором системы выдается некий список файлов, которые ты можешь изменить, и уникальный ID, без которого система просто не позволит залить на сервер измененный код.

в) разработчик ответственен за написание тестов к своему коду. Два человека в группе не пишут код вообше: они пишут сценарии для тестирования софта на симуляторе при различных входящих условиях.

г) для каждого изменения назначается коллега, отвечающий за review кода.

д) любое обновление после выхода от разработчиков сначала попадает в отдел тестирования, где до посинения крутится на симуляторе реальных процессов и проходит еще один review кода.

е) весь код всегда идет с сопровождающей документацией: что менял, где менял, зачем менял.

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

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

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

5. После того, как изменение прошло тестеров и симулятор, оно попадает в продакшн, причем делается это не руками программиста, а совершенно другими людьми. Доступ к продакшн-серверу (точнее, группе серверов) имеют только специально назначенные и специально обученные люди, к разработчикам не имеющие никакого отношения.

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

Когда я поинтересовался у шефа разработчиков, пошто так, озвученные цифры сняли все вопросы: 10 минут отказа системы приносят убыток примерно в миллион евро.

Очень интересно организован собственно, процесс работы. Рабочие станции - унифицированные у всех машинки одного производителя. Вся работа, все офисные апликухи, все данные - на сервере, связь - терминальная сессия. На локальных дисках что-либо хранить не то чтобы запрешают, просто смысла нет: когда у моего коллеги накрылся системник, он позвонил в техсаппорт. Через 8 минут на тележке привезли брата-близнеца подохшего системника, с уже подлюченными шлейфами питания, видео и пр. Еще через 2 минуты все было подсоединено, подохший блок увезли на той же тележке, а коллега продолжил работу. Если возникает, к примеру, необходимость пересадить человека на другое место, то все, что от него требуется - это забрать со старого места фотографию любимой тещи и пересесть за другой стол: рабочие места, как я уже говорил, 100% унифицированы, что-то куда-то копировать и перетаскивать просто не надо. Так же на полном автомате решена проблема бэкапа: он происходит централизованно для всех, это не проблема пользователей.

Cоотвественно, в конторе в принципе нет авралов, штурмовшины, закрывания грудями амбразур и пр: в 8 утра (можно раньше) народ уже работает, в 16:30 из отдела сваливает последний человек. Я, например, за неделю знаю о всех совещаниях, на которых мне необходимо быть, и имею детальное представление о том, чем буду заниматься следующие две недели, и достаточно подробное - чем буду заниматься следующий месяц.

Ну вот как-то так. Кому было не сильно интересно - извините.