Команда проекта: Гродзицкий Николай, Охотников Евгений, Сивко Борис, Суднеко Артур, Томашенко Денис, Шмаков Николай

Прошлое

Очень давнее прошлое

Историю SObjectizer можно начинать с 1995 года, когда в отделе АСУТП Гомельского КБ Системного Программирования собралась команда для разработки объектно-ориентированной SCADA-системы. Этой командой был придуман способ построения приложения из агентов, обменивающихся асинхронными сообщениями. Способ этот был реализован в виде SCADA-системы под названием SCADA Objectizer, где слово Objectizer отражало активное использование ООП.

На разработку первой версии SCADA Objectizer в очень непростых экономических условиях ушло около трех лет. В 1999 году в эксплуатацию была успешно запущена разработанная на SCADA Objectizer система управления производством комбикорма на одном из местных комбинатов хлебопродуктов. К началу 2000 года была сделана вторая, более продвинутая версия SCADA Objectizer.

Две первые версии пытались идти по традиционному пути SCADA-пакетов: было разделение на GUI-пакет конструктора АСУТП и отдельную систему исполнения. К сожалению, сил на развитие системы в таком виде у команды не хватило.

В 2000 году был проведен эксперимент и создана третья версия Objectizer, в которой описание АСУТП создавалось не в GUI-конструкторе, а на специализированном декларативном языке. Это описание транслировалось в C++ код, который компилировался и линковался с системой исполнения. На выходе получался программный модуль, решающий конкретную прикладную задачу. Эксперимент был очень интересным, подтолкнувшим к переосмыслению механизма агентов, пониманию их удобства для разработки распределенных приложений, но …

Но все работы над SCADA Objectizer в КБСП фактически прекратились к концу 2000 года, когда распалась команда, занимавшаяся разработкой SCADA Objectizer. Более подробно история этого периода описана в старой статье в “Компьютерной Газете”.

Давнее прошлое

Новый виток в развитии истории SObjectizer начался в 2001 году, когда двое бывших разработчиков SCADA Objectizer из КБСП оказались в компании “Интервэйл”.

В одной из первых разработок, которую автор статьи выполнял в компании “Интервэйл”, потребовалось реализовать обмен асинхронными сообщениями между несколькими рабочими нитями приложения. Тогда стало очевидно, что идеи агентного подхода могут быть востребованы не только в АСУТП, и что механизм использования агентов и асинхронной передачи сообщений между ними может очень успешно применяться в многопоточных приложениях, в том числе и в распределенных.

Поэтому весной 2002 года появилась новая реализация старых идей под названием SObjectizer-4. Эта версия более-менее активно развивалась с 2002 по 2004 годы, и на ее основе было разработано и запущено в эксплуатацию несколько проектов в компании “Интервэйл”.

В 2005 году стало очевидно, что развитие SObjectizer-4 внутри компании “Интервэйл” замедлилось. Поэтому, после длительных размышлений и сомнений, было принято решение выпустить SObjectizer-4 как проект Open Source. Так, в 2006 году SObjectizer появился на SourceForge под BSD-лицензией, а в журнале RSDN Magazine – большая статья об этом проекте.

Недавнее прошлое

С 2002 года по настоящее время SObjectizer-4 активно применяется в нескольких больших проектах внутри компании “Интервэйл”. Время показало, что в SObjectizer-4 допущено несколько просчетов, которые усложняют его использование и являются серьезными препятствиями к увеличению производительности SObjectizer-4 и построенных на его основе приложений:

В 2010 году стартовали работы по созданию новой версии – SObjectizer-5. Основные работы по созданию SObjectizer-5 были проведены в течении 2010-2011 годов, после чего SObjectizer-5 стал активно использоваться в разработке новых программных модулей, постепенно вытесняя SObjectizer-4. Однако первый публичный релиз SObjectizer-5 состоялся на SourceForge лишь в мае 2013 года после того как SObjectizer-5 в достаточной мере стабилизировался.

Области применения и результаты

Внутри компании “Интервэйл” SObjectizer-4 и SObjectizer-5 применяются в ряде проектов, которые можно охарактеризовать как mission critical.

Самым крупным из них является транспортная платформа для обслуживания SMS- и USSD-трафика. На начало 2013 года данная платформа могла показывать пропускную способность до 1500 SMS в секунду в пиковые периоды и работала под нагрузкой в несколько миллионов SMS/USSD-сообщений в день.

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

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

В последние годы бытует мнение, что C++ не является подходящим инструментом для разработки приложений подобного рода. Однако опыт использования SObjectizer говорит, что это далеко не так. У языка C++ есть свои недостатки, и для каких-то прикладных задач в C++ может просто не оказаться нужных инструментов. Однако, при наличии таковых, разработка нагруженных распределенных приложений на C++ оказывается вовсе не сложной, и с большими проектами могут справиться небольшие команды. Что, собственно, и подтверждалось проектами, которые были выполнены как на SCADA Objectizer, так и на SObjectizer-4 и SObjectizer-5.

Настоящее

Что такое SObjectizer-5

Состав

Под названием SObjectizer-5 скрывается несколько взаимосвязанных разработок. Есть ядро SObjectizer-5 – это проект so_5. Именно so_5 содержит средства для создания агентов и сообщений, а также среду исполнения, которая поддерживает обмен и обработку сообщений агентами.

Над so_5 построены дополнительные библиотеки, их принято называть подпроектами. Эти библиотеки не расширяют понятие агентной модели, но зато существенно упрощают разработку больших распределенных приложений на основе SObjectizer.

Библиотека so_log_2 является тонкой оберткой над ACE Logging и упрощает логирование информации из SObjectizer-агентов.

Библиотека so_5_transport предоставляет набор транспортных агентов, скрывающих специфику работы с TCP/IP-соединениями от прикладных агентов.

Библиотека mbapi_4, используя возможности so_5_transport, дает разработчику еще более высокоуровневый механизм обмена прикладными сообщениями. На основе mbapi_4 разрабатываются распределенные приложения с прозрачным перемещением сообщений через границы процессов и узлов сети. То есть, агенту, отправляющему через mbapi_4 сообщения другому агенту, даже не нужно знать, находится ли получатель в том же самом процессе или же в другом процессе на другом узле сети.

Библитека so_sysconf_4 позволяет размещать фабрики для прикладных агентов в отдельных DLL, а затем строить приложение из этих DLL, как из кубиков в конструкторе LEGO.

В целом, SObjectizer-5 представляет из себя слоеную конструкцию, основа которой – проект so_5, отвечающий лишь за поддержку агентной модели. Этой основы может быть вполне достаточно, например, для разработки мелких утилит или приложений, базисом к которых служат другие фреймворки, такие как Qt или wxWidgets.

Если основы в виде проекта so_5 недостаточно, то можно добавлять к ней дополнительные слои – so_log_2 и so_5_transport. Если и этого недостаточно, то еще и mbapi_4 и/или so_sysconf_4.

Агентная модель

Агентная модель, вокруг которой построен SObjectizer, состоит из нескольких базовых понятий.

Агент – это объект класса, унаследованного от специального базового класса agent_t.

Сообщение – это объект класса, унаследованного от специального базового класса message_t. Сообщения в SObjectizer передаются как динамически созданные объекты. Ответственность за их удаление берет на себя SObjectizer.

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

Почтовый ящик (mbox) – это место, куда сообщения отсылаются и откуда они забираются агентами. Почтовые ящики в SObjectizer позволяют организовать взаимодействие как на основе модели publish-subscribe, так и по принципу peer-to-peer.

Отсылка сообщения может быть сиюминутной (сообщение сразу попадает в mbox) и отложенной (сообщение попадает в mbox только по прошествии указанного времени).

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

Событие – это реакция агента на конкретный тип сообщения в конкретном состоянии. Эта реакция реализуется посредством обработчика события (обычно это метод агента).

Диспетчер – это объект, который отвечает за предоставление агентам рабочего контекста (т.е. рабочей нити), на котором будет запущен обработчик события. В состав SObjectizer входят пять штатных диспетчеров, реализующих разные политики предоставления агентам рабочих контекстов: от самого простого, в котором все агенты работают на контексте одной общей нити, до самого сложного, который использует пул потоков и позволяет выполнять несколько обработчиков событий одного агента параллельно на нескольких нитях. При запуске SObjectizer пользователь может создать произвольное количество диспетчеров, дав каждому из них уникальное имя. А затем привязывать своих агентов к разным диспетчерам в зависимости от того, какой диспетчер наиболее удобен для выполнения работы агента.

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

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

Принцип работы

В общих чертах принцип работы SObjectizer (точнее, его ядра, so_5) довольно прост.

Пользователь запускает среду исполнения SObjectizer (SObjectizer Environment) и регистрирует необходимое количество коопераций с прикладными агентами. При регистрации агенты привязываются к диспетчерам, состав и количество которых так же определяется пользователем.

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

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

На практике все несколько сложнее. Например, при вызове обработчика события, проверяется, а может ли агент вообще обработать это сообщение в своем текущем состоянии. Также SObjectizer следит за тем, в какой момент экземпляр сообщения можно безопасно уничтожить (ведь это объект в динамической памяти, которую нужно освободить, когда этот объект перестает быть нужным). Но общий принцип именно таков.

Несколько слов о синхронном взаимодействии агентов. Синхронность существует только для агента, который инициирует запрос. Этот запрос трансформируется в специальное внутреннее сообщение SObjectizer, и обработчик запроса обрабатывает его как обычное асинхронное сообщение (т.е. через очередь заявок диспетчера). Все это время отправитель запроса “спит” в ожидании ответа, а SObjectizer “будит” его после того, как заявка с запросом будет обработана.

Пример агента

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

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

Агент-прокси имеет два состояния: st_expired, которое означает, что у агента нет актуального значения температуры, и при поступлении запроса нужно заново опрашивать датчик, и st_actual, которое означает, что текущее значение актуально, и его можно сразу отдавать в ответ на запрос.

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

Второе сообщение, msg_data_expired, – это сигнал о том, что с момента прошлого опроса прошла минута, и значение перестало быть актуальным.

Агент-прокси отсылает два сообщения. Первое сообщение, msg_current_data, используется для выдачи текущего значения температуры. Второе сообщение-сигнал, msg_acquire_value, выдается в виде синхронного запроса к агенту-датчику.

 
using namespace so_5;
using namespace so_5::rt;
 
// Запрос текущего значения.
struct msg_get_current_data : public message_t
{
  // Обратный адрес, на который нужно отсылать ответ.
  const mbox_ref_t m_return_mbox;
 
  msg_get_current_data( mbox_ref_t return_mbox )
    : m_return_mbox( std::move(return_mbox) )
  {}
};
 
// Ответное сообщение с текущим значением температуры.
struct msg_current_data : public message_t
{
  float m_value;
 
  msg_current_data( float value ) : m_value(value) {}
};
 
// Сигнал о том, что текущее значение перестало быть актуальным.
struct msg_data_expired : public signal_t {};
 
// Сигнал агенту-датчику о необходимости опросить датчик температуры.
struct msg_acquire_value : public signal_t {};
 
class a_temperature_meter_proxy_t : public agent_t
{
private :
  // Состояния агента.
  const state_t st_expired = so_make_state( "expired" );
  const state_t st_actual = so_make_state( "actual" );
 
  // Адрес агента, отвечающего за взаимодействие с датчиком.
  const mbox_ref_t m_meter_mbox;
 
  // Последнее полученное от датчика значение.
  float m_last_value;
 
public :
  // Конструктор.
  a_temperature_meter_proxt_t(
    // Обязательный параметр SObjectizer Environment, в рамках
    // которого агент будет работать.
    so_environment_t & env,
    // Адрес агента, отвечающего за работу с датчиком.
    mbox_ref_t meter_mbox )
    : agent_t( env )
    , m_meter_mbox( std::move(meter_mbox) )
  {}
 
  // Настройка агента для работы внутри SObjectizer.
  // Вызывается в процессе регистрации агента для того,
  // чтобы агент мог перейти в начальное состояние и
  // настроить свои подписки.
  virtual void so_define_agent() override
  {
    // Изначально агент должен находиться в состоянии expired.
    so_change_state( st_expired );
 
    // Подписка на сообщения.
    // Этот агент реагирует только на сообщения, которые
    // отсылаются в его персональный mbox.
 
    // Реакция на запрос значения, когда у агента нет
    // актуальных данных от датчика.
    so_subscribe( so_direct_mbox() ).in( st_expired )
      .event(
         // Метод, который будет обработчиком события.
         &a_temperature_meter_proxy_t::evt_get_data_from_meter );
 
    // Далее реакция на сообщения, которые агент обрабатывает
    // имея актуальную информацию от датчика.
    so_subscribe( so_direct_mbox() ).in( st_actual )
      // На запрос данных можно просто вернуть текущее значение.
      .event(
         // Обработчик события задается лямбда-функцией,
         // т.к. он настолько прост, что нет смысла
         // заводить отдельный метод.
         [this]( const msg_get_current_data & evt )
         {
           // Сразу отсылаем ответное сообщение.
           evt.m_return_mbox->deliver_message(
             new msg_current_data( m_last_value ) );
         } )
       // На уведомление об истечении времени жизни последнего
       // замера нужно поменять состояние агента.
       .event(
          signal< msg_data_expired >,
          // Опять очень простой обработчик, который
          // может быть представлен лямбда-функцией.
          [this]() { so_change_state( st_expired ); } );
   }
 
   // Обработчик события запроса температуры, когда
   // последнее прочитанное значение уже не актуально.
   void evt_get_data_from_meter( const msg_get_current_data & evt )
   {
     // Получаем текущее значение у реального агента.
     // Ждем ответа не более 10 секунд. Если ответ не поступит,
     // то возникнет исключение, которое обработает SObjectizer.
     m_last_value = m_meter_mbox->get_one< float >()
       .wait_for( std::chrono::seconds( 10 ) )
       .sync_get< msg_acquire_value >();
 
     // Данные у нас есть, переводим агент в состояние
     // наличия актуальной информации.
     so_change_state( st_actual );
 
     // И заказываем отложенное сообщение для того, чтобы
     // вернуться затем в состояние expired.
     so_environment()->single_timer< msg_data_expired >(
       // Сигнал будет доставлен в персональный mbox агента.
       so_direct_mbox(),
       // Через 60 секунд (значение задается в миллисекундах).
       60 * 1000 );
 
     // Текущее значение нужно вернуть получателю.
     evt.m_return_mbox->deliver_message(
       new msg_current_data( m_last_value ) );
   }
};

Сравнение с аналогами

Фреймворков, позволяющих разрабатывать ПО с использованием Actor Model, довольно много (см., например, соответствующий список). Однако, если ограничиться только языком C++, то количество аналогов существенно сокращается. Если добавить сюда еще и то, что за последний год признаки жизни подавало всего три OpenSource фреймворка для C++ (SObjectizer, C++ Actor Framework (CAF) и Theron), то аналогов оказывается не так уж много.

При сравнении нельзя не учитывать один важный фактор: влияние языка Erlang на все, что появилось в этой области в последние 10 лет. Фактически, современные фреймворки, как для C++, так и для других языков программирования, пытаются перенести принципы функционирования Erlang-овских процессов в другие языки программирования. Где-то это получается лучше, где-то хуже. Но в целом клоны Erlang остаются клонами, лишь более-менее приближающимися к оригиналу.

SObjectizer же появился тогда, когда широкой общественности не было известно про Erlang. Это оригинальная разработка, в которой так же, как и в Erlang, происходит обмен сообщениями между сущностями. Но на этом сходство заканчивается. Поэтому главное отличие SObjectizer от аналогов – это то, что SObjectizer не пытается повторить Erlang в C++.

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

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

Далее идут состояния у агентов и упор на асинхронное взаимодействие между агентами. Это приводит к разработке агентов в виде конечных автоматов с наборами состояний и переходами из одного состояния в другое в процессе обработки событий. Для каких-то задач это более удобно, чем работа в стиле Erlang, где можно отослать сообщение другому процессу, а затем синхронно висеть на ожидании ответа. Для каких-то задач, напротив, стиль Erlang более удобен.

Кроме того, очень важен акцент, который делают разработчики аналогичных фреймворков. Так, разработчики CAF и Theron акцентируют внимание на высокой скорости передачи сообщений между агентами и на том, что их основная задача — это выжимание максимальной производительности из современного многоядерного железа. То есть, данные фреймворки в первую очередь позиционируются для parallel computing.

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

Кроме того, SObjectizer находился в реальной повседневной эксплуатации несколько дольше своих C++ аналогов, поэтому, например, разделение на слои (so_5, so_5_transport, mbapi_4, so_sysconf_4) произошло уже довольно давно, тогда как CAF начал движение в этом направлении лишь несколько месяцев назад.

И еще об одном важном отличии: так как SObjectizer никогда не был исследовательским проектом и всегда ориентировался на решение практических задач, при разработке SObjectizer уделялось внимание простоте его использования. Поэтому SObjectizer в меньшей степени использует новые возможности C++11 и менее требователен к уровню поддержки компилятором стандарта C++11 в отличии от, скажем, CAF. Порог вхождения в SObjectizer относительно невысок, в том числе и за счет того, что SObjectizer не требует от программиста отличного знания тонкостей C++. Это неоднократно оправдывало себя на практике, когда новички быстро осваивали SObjectizer и оперативно подключались к разработке больших SObjectizer-проектов.

Текущее состояние

До 2013 года SObjectizer, уже будучи Open Source проектом, все же оставался внутренней разработкой компании “Интервэйл”. Это накладывало свой отпечаток как на приоритеты в развитии SObjectizer, так и на объем ресурсов, которые удавалось выделять на разработку SObjectizer. Но с середины 2013 года SObjectizer развивается как самостоятельный OpenSource-проект.

Сейчас над SObjectizer работает команда из пяти человек. Автор статьи занимается только SObjectizer в режиме full time, остальные члены команды активно помогают. В связи с этим разработка идет в режиме мягкой диктатуры: ответственные решения принимаются лидером разработки, но мнение каждого из членов команды принимается во внимание.

Вся разработка базируется на базе инфраструктуры, предоставляемой ресурсом SourceForge. Исходные тексты – в SVN-репозитории SourceForge. Баг-трекинг, списки задач, дискуссии и документация в Wiki – на сайте SourceForge.

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

Пока все основные усилия команды сконцентрированы на ядре SObjectizer – проекте so_5. Эта часть SObjectizer сейчас развивается наиболее активно. За период с декабря 2013 по август 2014 было выпущено три серьезных обновления so_5, которые существенно расширили функциональность и подняли производительность ядра SObjectizer. Остальные подпроекты лишь слегка адаптировались под новые версии so_5, что было не очень сложно, так как команда разработки очень внимательно и трепетно относится к проблемам сохранения совместимости и минимизации проблем при обновлении SObjectizer.

Работа над очередной версией so_5 обычно строится следующим образом:

Основное внимание при разработке новых версий SObjectizer уделяется двум вещам: тестированию и документированию. По субъективным оценкам, на каждый новый кусок функциональности около 40% времени уходит на проектирование и реализацию, а оставшиеся 60% — это покрытие кода тестами, устранение выявленных при тестировании проблем, разработка демонстрационных примеров и документирование.

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

В некоторых подпроектах, например, so_5_transport и so_sysconf_4 использование юнит-тестирования затруднено, и там активно используются тесты, которые нужно запускать вручную. Это не очень удобно, поэтому есть желание в большей степени автоматизировать процесс тестирования этих проектов. Но для этого пока в должной степени “не дошли руки”.

Будущее

Будущее, к сожалению или к счастью, никому не ведомо, поэтому о том, что случится с SObjectizer в ближайшей или отдаленной перспективе, можно только гадать. Говорить сейчас можно разве что о ближайших планах, которые есть у команды разработки SObjectizer, но что именно из этого получится покажет время.

Итак, после релиза версии 5.4.0 есть планы заняться демо-проектом, который способен продемонстрировать возможности SObjectizer в решении какой-либо практической задачи. Что это будет – вопрос пока открытый. Возможно, клиент для AMQP, возможно, инструмент для работы с MQTT или CoAP, а может быть что-то еще. Выбор еще предстоит сделать, и основным критерием будет наглядность демонстрации возможностей SObjectizer при небольшой трудоемкости.

Параллельно с этим планируется вести работы над следующей версией ядра SObjectizer, so-5.4.1, релиз которой запланирован на конец октября 2014 года, после чего появится возможность вплотную заняться развитием подпроектов SObjectizer, а именно, so_5_transport и mbapi_4.

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

В целом, команде SObjectizer есть чем заняться до конца 2014 года, а в начале 2015 года можно будет подводить первые итоги “свободного плавания” SObjectizer в качестве самостоятельного проекта, и, если к проекту будет интерес со стороны пользователей и сторонних разработчиков, выбирать путь его дальнейшего развития.

У меня есть подборка записей, почерпнутых в учебных классах по осознанности, во время встреч и медитативных посиделок, проходящих в Республике Калифорния.

Сегодня я публикую их в исходном виде. Для меня эти записи достаточно ценны, поэтому я хочу сохранить их навечно в Интернете. Если для этого мне нужно набрать их на клавиатуре и опубликовать, пусть так и будет. Я просто хочу держать их поблизости и предположу, что заложенные в них истины окажутся полезны не только мне.

Есть еще одна причина, по которой я выбрала для публикации это время. Markus Gärtner, автор недавно опубликованной книги “ATDD by Example” и тестировщик интернационализации (i18n) в Amazon, недавно опубликовал статью о заблуждениях в контекстуальном тестировании. Его мысли оказались чрезвычайно близки к искаженному мышлению, что неудивительно, поскольку все мы люди.

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

Итак, приступим:

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

Поляризованное мышление: Обстоятельства могут быть черными или белыми, хорошими или плохими. Либо вы должны быть безупречны, либо вы лажанулись. Нет компромисса.

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

Чтение мыслей: Вы знаете, что люди чувствуют и почему они действуют так или иначе, не интересуясь их мнением на этот счет. В частности, вы способны предсказать, что люди чувствуют по отношению к вам.

Катастрофизация: Вы ожидаете беду. Вы замечаете или слышите проблему и начинаете думать в духе «А что если?»: «А что если случится трагедия? А что если это случится со мной?»

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

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

Иллюзия справедливости: вы чувствуете обиду, потому что вы думаете, что знаете правду, но другие люди с вами не согласятся.

Обвинения: Вы налагаете на других людей ответственность за вашу боль или придерживаетесь другой линии, обвиняя себя во всех проблемах и провалах.

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

Эмоциональные рассуждения: Вы верите в то, что ваши ощущения есть истина в последней инстанции. Если вы чувствуете себя глупым и скучным, то вы обязательно глупый и скучный.

Иллюзия изменений: Вы ожидаете, что другие люди изменятся и подстроятся под вас, если вы на них нажмете или умаслите. Вам нужно изменять людей, потому что ваши надежды на счастье, похоже, полностью зависят от них.

Глобальные ярлыки: Вы обобщаете одно или два свойства в негативное глобальное суждение.

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

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

Источник.

Класс UserPreferences

Класс CFile из первый части статьи продемонстрировал нам, каким образом API, на котором базируется класс, определяет политику распространения исключений данного класса. Там же говорилось о “функциональной совместимости”, которую приходится соблюдать при создании новых классов, использующих некоторый “базовый код”. В первой части в качестве примера рассматривалось создание новой библиотеки. Во второй части полученный опыт будет экстраполирован на создание пользовательского класса.

Для демонстрации, я привлеку на помощь стандартную библиотеку C++ [C++ standard library] (ISO/IEC 14882:2011 раздел 17). В чём очарование стандартной библиотеки? Она присутствует во всех реализациях, а значит универсальна, кросс-платформенна и знакома многим разработчикам.

Из всего множества классов этой библиотеки сейчас нас будут интересовать лишь потоки ввода/вывода [input/output library] (ISO/IEC 14882:2011 раздел 27). Мы рассмотрим, как можно задействовать эти потоки для сохранения/восстановления состояния объектов и обсудим тактику распространения ошибок.

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

 
class UserPreferences
{
public:
    UserPreferences(int intValue, const std::string& stringValue, float floatValue);
private:
   int mIntValue;
   std::string mStringValue;
   float mFloatValue;
};

Мы с вами хотим, чтобы настройки, выбранные пользователем, не теряли свою силу после того, как приложение было закрыто, а затем открыто повторно. И для этого нам понадобится сохранять состояние класса UserPreferences. Как было сказано выше, мы будем делать это с помощью потоков ввода/вывода. Добавим следующие объявления двух глобальных функций:

 
std::ostream& operator<<(std::ostream& out, const UserPreferences& userPreferences);
 
std::istream& operator>> (std::istream& in, UserPreferences& userPreferences);

Это позволит нам в дальнейшем писать код сохранения и восстановления состояния объекта на манер стандартной библиотеки C++.

Так может выглядеть сохранение:

 
void MainApplication::SaveUserPreferences(const UserPreferences& userPreferences)
{
    std::ostringstream out;
    out << userPreferences;
    saveToDisk(out);
}

А так – восстановление:

 
UserPreferences MainApplication::RestoreUserPreferences()
{
    std::string str = readFromDisk();
    std::istringstream in(str);
    UserPreferences userPreferences;
    in >> userPreferences;
    return userPreferences;
}

В свою очередь, реализации методов operator<< и operator>> будут обращаться к публичным методам класса UserPreferences:

 
std::ostream& operator<<(std::ostream& out, const UserPreferences& userPreferences)
{
    userPreferences.Serialize(out);
    return out;
}
 
std::istream& operator>>(std::istream& in, UserPreferences& userPreferences)
{
    userPreferences = UserPreferences::UnSerialize(in);
    return in;
}

Таким образом, вся реальная работа по сохранению объектов будет производиться в методах Serialize и UnSerialize.

Помимо методов Serialize и UnSerialize нам понадобится добавить конструктор по умолчанию [default constructor] – он используется в методе MainApplication::RestoreUserPreferences. Описание класса UserPreferences будет выглядеть следующим образом:

 
class UserPreferences
{
public:
    UserPreferences();
 
    UserPreferences(int intValue, const std::string& stringValue, float floatValue);
 
   void Serialize(std::ostream& out) const;
 
   static UserPreferences UnSerialize(std::istream& in);
private:
   int mIntValue;
   std::string mStringValue;
   float mFloatValue;
};
 
std::ostream& operator<<(std::ostream& out, const UserPreferences& userPreferences);
 
std::istream& operator>>(std::istream& in, UserPreferences& userPreferences);

К описанию класса также необходимо отнести и методы operator<< и operator>>, которые, хотя и описаны вне тела класса, тем не менее являются частью его интерфейса.

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

Для сохранения/чтения состояния объектов с помощью потоков у нас есть возможность выбрать формат сохранения (текстовый или бинарный). У каждого из них есть свои плюсы и минусы. Мы остановимся на текстовом, как более наглядном. При использовании текстового формата нам необходимо выбрать подходящие разделители. Мы возьмём пробел в качестве разделителя для чисел. Это позволит нам при считывании числа полагаться на вызов basic_istream::operator>>, для которого пробел послужит “границей”.

С разделителем для строк чуть сложнее: мы не хотим ограничивать себя сохранением лишь тех строк, в которых не содержатся пробелы. Потому выберем в качестве разделителя нулевой символ (‘\0’) и создадим свой метод – метод Read – для считывания строк.

 
UserPreferences UserPreferences::UnSerialize(std::istream& in)
{
    int intValue;
    in >> intValue;
    in.ignore(); // #1 - символ разделителя всё ещё в потоке - пропускаем его
    std::string stringValue;
    Read(in, stringValue);
    float floatValue;
    in >> floatValue;
    in.ignore(); // #3 - позволяем сохранять в поток другие объекты
    return UserPreferences(intValue, stringValue, floatValue);
}
 
void UserPreferences::Serialize(std::ostream& out) const
{
    out << mIntValue << ' '
        << mStringValue << '\0'
        << mFloatValue << ' '; // #2 - позволяем сохранять в поток другие объекты
}
 
void UserPreferences::Read(std::istream& in, std::string& out)
{
    char c;
    while(in.get(c))
    {
        if(c==0)
        {
            break;
        }
 
        out.push_back(c);
    }
}

В этой нехитрой реализации следует помнить о двух моментах.

Первый касается метода basic_istream::operator>>. Этот метод, считав из потока число, оставит в потоке символ-разделитель, прервавший считывание (в нашем случае это пробел). Поэтому нам необходимо пропустить символ-разделитель перед считыванием следующего члена класса (строка #1 в функции UserPreferences::UnSerialize).

Второй момент относится к записи разделителя (опять же, пробела) после записи последнего члена класса – mFloatValue (строка #2 в функции UserPreferences::Serialize). А также к пропуску этого же разделителя при восстановлении состояния объекта (строка #3 в функции UserPreferences::UnSerialize). Мы добавляем данный код для того, чтобы разрешить сохранение в тот же поток других объектов.

Другими словами, класс UserPreferences оставляет потоки ввода и вывода в состоянии, в котором они готовы к повторному использованию. Это позволяет писать следующий код:

 
void MainApplication::Save(const UserPreferences& userPreferences, const ApplicationData& applicationData)
{
    std::ostringstream out;
    out << userPreferences << applicationData;
    saveToDisk(out);
}
 
void MainApplication::Restore()
{
    std::string str = readFromDisk();
    std::istringstream in(str);
    UserPreferences userPreferences;
    ApplicationData applicationData;
    in >> userPreferences >> applicationData;
    // Восстанавливаем состояние приложения с помощью
    // userPreferences и applicationData
}

В скобках замечу, что возможность сохранения нескольких объектов в единственный поток имеет как плюсы, так и минусы. Наряду с удобством записи мы получаем риск потери состояния всех объектов при возникновении ошибки в момент сохранения/восстановления, тогда как при использовании связки “один поток – один объект” мы рискуем только одним объектом.

Возможно, удачным компромиссом будет сохранения в один поток лишь вложенных объектов. Например, будучи составным объектом, класс UserPreferences мог бы сохранять/восстанавливать своё состояние, делегируя операции частям, из которых состоит:

 
void UserPreferences::Serialize(std::ostream& out) const
{
    out << mSubstitution <<
        << mFonts <<
        << mEnvironment;
}
 
UserPreferences UserPreferences::UnSerialize(std::istream& in)
{
    UserPeferences userPreferences;
    in >> userPreferences.mSubstitution
        >> userPreferences.mFonts
        >> userPreferences.mEnvironment;
   return userPreferences;
}

Здесь мы полагаем, что mSubstitution, mFonts и mEnvironment уже не примитивные типы, а дисциплинированные объекты, умеющие сохранять себя сами. Любопытно отметить, что работая с объектами, мы поднимаемся на чуть больший уровень абстракции, и избавляемся от необходимости думать о разделителях.

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

UserPreferences::UserPreferences

Мы ещё не приводили тело конструктора по умолчанию для класса UserPreferences. Давайте это сделаем сейчас:

 
UserPreferences::UserPreferences()
{
}

Оставив тело конструктора пустым, мы позволили компилятору вызвать конструкторы по умолчанию для членов класса mIntValue, mFloatValue и mStringValue. Как следствие, переменные тривиальных типов (mIntValue и mFloatValue) будут инициализированы случайными значениями, а для mStringValue будет вызван конструктор:

 
explicit basic_string(const Allocator& a = Allocator());

Последний и объясняет, почему нам приходится объявлять UserPreferences::UserPreferences без использования пустой спецификации noexcept [noexcept-specification].

 
void method_does_not_throw_exception() noexcept;

Согласно стандарту, конструктор basic_string(const Allocator&) может инициировать любое исключение.

 
allocator(const allocator&) noexcept;

Соберём всё вместе. Ни конструкторы тривиальных типов, ни конструктор копирования std::allocator не приводят к возникновения исключения. Исключение может произойти лишь в конструкторе по умолчанию basic_string (здесь “может” нужно понимать как – “стандарт разрешает”). Вероятно, это исключение будет иметь тип bad_alloc. Больше никаких утверждений сделать нельзя. Зато с большой долей уверенности можно сказать, что в системе должно произойти нечто серьёзное, чтобы конструктор строки по умолчанию инициировал исключение.

С одной стороны результат анализа может показаться неожиданным: безобидный, на первый взгляд, пустой конструктор может генерировать std::bad_alloc, а возможно и исключение неизвестного типа. Но давайте посмотрим на это с другой стороны.

Во-первых, стандарт утверждает, что все исключения, инициированные стандартной библиотекой, должны быть производными от класса std::exception (ISO/IEC 14882:2011 раздел 18.8.1). То есть, класс исключения известен, и при желании мы всегда можем его перехватить.

Во-вторых, что более важно, данный конструктор – это не единственное место в нашем приложении, которое может генерировать “неудобное” исключение. Всё, что от нас потребуется – это корректно перехватить и корректно обработать подобную ошибку.

Вопросу перехвата будет посвящён отдельный раздел, сейчас же мы вернёмся к текущей задаче, а именно – к определению типов исключений, которые могут и/или должны генерировать методы класса UserPreferences.

Итак, мы обнаружили, что конструктор класса по умолчанию, UserPreferences(), может инициировать исключение, принадлежащее классу std::exception либо классу, который является наследником std::exception. Отметим это для себя и перейдём к следующему методу.

UserPreferences::UserPreferences(int intValue, const std::string& stringValue, float floatValue);

 
UserPreferences::UserPreferences(int intValue, const std::string& stringValue, float floatValue) :
    mIntValue(intValue),
    mStringValue(stringValue),
    mFloatValue(floatValue)
{
}

Ничего принципиально нового в этом методе, по сравнению с конструктором по умолчанию, мы не видим. В данном случаем при создании члена класса mStringValue будет вызван метод basic_string(const basic_string& str), который как и basic_string(const Allocator&) допускает генерацию исключений. Поэтому, делаем вывод, что данный метод также инициирует исключение std::exception.

 
UserPreferences::UserPreferences(int intValue, std::string&& stringValue, float floatValue) noexcept;

 
basic_string(basic_string&& str) noexcept;

void UserPreferences::Serialize(std::ostream& out) const

Наконец мы можем перейти от конструкторов с пустым телом к рассмотрению методов, которые действительно что-то делают. Начнём с метода Serialize – приведём тело метода ещё раз:

 
void UserPreferences::Serialize(std::ostream& out) const
{
    out << mIntValue << ' '
        << mStringValue << '\0'
        << mFloatValue << ' ';
}

Реализация данного метода использует три различных метода operator<< для сохранения состояния класса:

 
basic_ostream& basic_ostream::operator<<(int val);
basic_ostream& basic_ostream::operator<<(float val);
basic_ostream& operator<<(basic_ostream& os, const basic_string& str);

Два первых метода являются членами класса basic_ostream, а последний объявлен в пространстве имён std. Нас будет интересовать вопрос: могут ли данные функции генерировать исключения. И если могут, то какому типу будут принадлежать эти исключения.

Первым мы рассмотрим basic_ostream::operator<<(int val). Данный оператор относится к функциям форматированного вывода [formatted output functions], требования к которым описаны в разделе 27.7.3.6 стандарта ISO/IEC 14882:2011. Стандарт достаточно строг в описании, а потому нам достаточно просто предсказать ситуацию, когда данный метод будет инициировать исключение. Для того, чтобы basic_ostream::operator<<(int val) мог генерировать исключение, необходимо чтобы пользователь класса basic_ostream предварительно (т.е. до вызова basic_ostream::operator<<(int val)) сделал вызов basic_ios::exceptions(iostate) с параметром ios_base::badbit и/или ios_base::failbit.

 
void test(std::ostream& out)
{
    out.exceptions(std::ios_base::failbit | std::ios_base::badbit);
    const int temp = 1;
    // Следующая строка может генерировать исключение
    out << temp;
}

Для того, чтобы составить представление о возможных типах исключений, нам понадобится упомянуть о внутреннем классе basic_ostream::sentry (раздел 27.7.3.4 стандарта ISO/IEC 14882:2011). Стандарт обязывает метод basic_ostream::operator<<(int val) начинать свою работу с создания объекта класса basic_ostream::sentry. Это необходимо для выполнения безопасных с точки зрения исключений операций при входе и выходе из функции [exception safe prefix and suffix operations].

Так вот, при создании объекта класса basic_ostream::sentry может быть вызван метод basic_ios::setstate() с параметром ios_base::failbit. Вызов этого метода может генерировать исключение ios_base::failure, если пользователь сделал предварительный вызов basic_ios::exceptions(iostate) с параметром ios_base::failbit.

Кроме этого сценария, стандарт также описывает ситуацию, когда исключение может возникнуть в момент вывода данных методом basic_ostream::operator<<(int val). Если подобное происходит, стандарт обязывает метод basic_ostream::operator<<(int val) перехватить исключение. После того как исключение перехвачено, метод должен проанализировать выражение (basic_ios::exceptions()&ios_base::badbit). Если данное выражение не равно нулю, метод должен позволить дальнейшее распространение исключения. Упомянутое выше выражение будет не равно нулю лишь в том случае, если пользователь сделал предварительный вызов basic_ios::setstate() с параметром ios_base::badbit.

Очевидно, что те же результаты даст нам исследование basic_ostream::operator<<(float val). Что касается basic_ostream::operator<<(basic_ostream& os, const basic_string& str), то хотя он и описан в разделе, посвящённом библиотеке строк (раздел 21.4.8.9), тем не менее, к нему применяются те же требования, как к функциям форматированного вывода (раздел 27.7.3.6.1 стандарта ISO/IEC 14882:2011).

Итак, подведём итог. Все упомянутые выше методы basic_ostream::operator<< могут генерировать исключение. Необходимым условием для этого является предварительный вызов basic_ios::exceptions(iostate) с параметром basic_ios::badbit и/или параметром basic_ios::failbit. Типом исключения будет либо ios_base:: failure либо тип, унаследованный от std::exception (напомню, что это базовый тип для всех исключений, генерируемых стандартной библиотекой).

Таким образом, у нас выбор между двумя реализациями метода Serialize.

В первом случае мы оставляем тело Serialize в виде, приведённом выше. Это позволит клиенту класса UserPreferences принимать решение: желает ли он обрабатывать значение, возвращаемое методом Serialize, либо ему удобней перехватывать исключение, если в процессе вывода случилась ошибка.

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

Сперва обсудим первый вариант реализации Serialize, при котором тело метода остаётся неизменным, и посмотрим на клиентский код. Так может выглядеть код клиента при использовании возвращаемого значения - “возвращаемым” значением в данном случае будет входной (он же выходной) параметр std::ostream:

 
void MainApplication::SaveUserPreferences(const UserPreferences& userPreferences)
{
    std::ostringstream out;
    out << userPreferences;
    // здесь мы используем basic_ios::operator bool()
    // чтобы узнать чем закончилась последняя операция вывода
    if(out)
    {
        saveToDisk(out);
    }
    else
    {
        DisplayError("Failed to save user preferences");
    }
}

А так будет выглядеть код клиента, если ему более по душе перехват исключений – для генерации исключения клиент должен задействовать вызов basic_ios::exceptions():

 
void MainApplication::SaveUserPreferences(const UserPreferences& userPreferences)
{
    std::ostringstream out;
    out.exceptions(std::ios_base::failbit | std::ios_base::badbit);
    // здесь мы полагаемся на генерацию исключения
    // в случае возникновения ошибки вывода
    try
    {
        out << userPreferences;
        saveToDisk(out);
    }
    catch(std::exception&)
    {
        DisplayError("Failed to save user preferences");
    }
}

Теперь рассмотрим альтернативный вариант Serialize, о котором говорилось выше – мы добавим безусловную генерацию исключений при возникновении ошибки:

 
void UserPreferences::Serialize(std::ostream& out) const
{
    const std::ios_base::iostate previousState = out.exceptions();
    out.exceptions(std::ios_base::failbit | std::ios_base::badbit);
    try
    {
        out << mIntValue << ' '
            << mStringValue << '\0'
            << mFloatValue << ' ';
    }
    catch(std::exception&)
    {
        // Мы перехватываем исключение лишь с одной целью -
        // восстановить состояние “реакции на ошибки”
        out.exceptions(previousState);
        throw;
    }
    out.exceptions(previousState);
}

И код клиента для данного варианта Serialize сводится к виду:

 
void MainApplication::SaveUserPreferences(const UserPreferences& userPreferences)
{
    std::ostringstream out;
    // мы исходим из того, что Serialize всегда генерирует исключение в случае ошибки
    try
    {
        out << userPreferences;
        saveToDisk(out);
    }
    catch(std::exception&)
    {
        DisplayError("Failed to save user preferences");
    }
}

Что ж, давайте перечислим все “за и против” обоих подходов и сделаем выводы.

Первый подход – решение о генерации исключения принимает код, вызывающий Serialize

Плюсы:

Минусы:

Второй подход – метод Serialize генерирует исключение, если в процессе вывода случилась ошибка

Плюсы:

Минусы:

Невозможность проигнорировать ошибку может оказаться неоспоримым преимуществом: вероятно, существует сценарий, в котором необработанная ошибка грозит катастрофическими последствиями (к сожалению, в голову не приходит подходящего примера). Но с практической точки зрения первый подход выглядит более привлекательно: он даёт возможность выбора пользователю класса, упрощает кодирование и обеспечивает согласованное поведение operator<<. В реальном проекте, я бы стал руководствоваться именно этими соображениями и остановился на первом (простом) варианте метода Serialize.

Добавлю ещё пару слов к обсуждению данной версии метода Serialize:

 
void UserPreferences::Serialize(std::ostream& out) const
{
    out << mIntValue << ' '
        << mStringValue << '\0'
        << mFloatValue << ' ';
}

Здесь необходимо пояснить, что происходит в этом методе если ошибка случается при выводе очередного значения, скажем, значения – mIntValue. Это тривиально, но позволит нам расставить все точки над i. Будь “включена” генерация исключений, ответ был бы очевиден: неудача во время операции вывода приводит к генерации исключения, и выполнение последующих инструкций в данном методе прекращается. Но поскольку исключения “выключены”, постольку следующим вызовом, после закончившегося неудачей вызова basic_ostream::operator<<(int), будет вызов метода basic_ostream::operator<<(basic_ostream&,char), который в качестве входного параметра получит поток с установленными failbit или badbit. В этом случае, проверив состояние потока и обнаружив, что оно не равно goodbit, метод basic_ostream::operator<< просто вернёт управление в вызываемую функцию. (Это верно для библиотечных методов; разработчик, определяющий собственный operator<< должен позаботиться об этом сам). Что есть благо, поскольку избавляет нас от написания следующего кода:

 
void UserPreferences::Serialize(std::ostream& out) const
{
    out << mIntValue;
    if(out)
    {
        out << ' ';
        if(out)
        {
            out << mStringValue;
            if(out)
            {
                out << '\0';
                if(out)
                {
                    out << mFloatValue;
                    if(out)
                    {
                        out << ' ';
                    }
                }
            }
        }
    }
}

UserPreferences UserPreferences::UnSerialize(std::istream& in)

Ошибка, которая при работе с потоками вывода выглядит как экзотика, в случае потоков ввода становится обычным явлением. При выводе данных ошибки зачастую определяется средой – нехватка памяти, невозможность открытия описателя, нарушения прав доступа и т.п. – и случаются сравнительно редко. При считывании же данных основная причина ошибок – некорректный/неожиданный формат данных и случаются они заметно чаще. Хорошая новость состоит в том, что на реализацию класса UserPereferences данный факт не влияет.

Принцип работы basic_istream::operator>> аналогичен принципу работу basic_ostream::operator<<. То есть, мы можем заставить библиотеку генерировать исключение, сделав предварительный вызов basic_ios::exceptions(iostate). Иначе нам необходимо проверять состояние потока, чтобы выяснить успешно ли закончилась последняя операция.

Так же как и для basic_ostream::operator<< мы можем безопасно вызывать basic_istream::operator>> даже если объект класса basic_istream находится в “плохом” состоянии – вызов basic_istream::operator>> не изменит состояние переменной, в которую мы пытаемся прочитать значение.

Таким образом, мы встаём перед тем же выбором, что и при обсуждении метода Serialize – использовать ли для проверки результа метод basic_ios::operator bool() либо, в случае ошибки, генерировать исключение.

Вариант метода UnSerialize, использующего basic_ios::operator bool() (или “простой” вариант – по аналогии с “простым” вариантом Serialize) будет выглядеть следующим образом:

 
UserPreferences UserPreferences::UnSerialize(std::istream& in)
{
    int intValue;
    in >> intValue;
    in.ignore();
    std::string stringValue;
    Read(in, stringValue);
    float floatValue;
    in >> floatValue;
    in.ignore();
    return UserPreferences(intValue, stringValue, floatValue);
}

Второй вариант – вариант, генерирующий исключение – будет отличаться лишь установкой и восстановлением реакции на ошибки:

 
UserPreferences UserPreferences::UnSerialize(std::istream& in)
{
    const std::ios_base::iostate previousState = in.exceptions();
    in.exceptions(std::ios_base::failbit | std::ios_base::badbit);
    try
    {
        int intValue;
        in >> intValue;
        in.ignore();
        std::string stringValue;
        Read(in, stringValue);
        float floatValue;
        in >> floatValue;
        in.ignore();
        return UserPreferences(intValue, stringValue, floatValue);
    }
    // Мы знаем, что как конструктор класса UserPreferences,
    // так и basic_istream::operator>> могут генерировать лишь
    // исключения унаследованные от std::exception.
    catch (std::exception&)
    {
        in.exceptions(previousState);
        throw;
    }
}

Все соображения, приведённые при обсуждении метода Serialize, остаются верными и для метода UnSerialize, и поэтому мы уже знаем ответ на незаданный ещё вопрос: какой из этих методов нам следует выбрать. Мы должны выбрать ту реализацию, которая соответствует реализации метода Serialize. Для метода Serialize, напомню, мы выбрали реализацию, совместимую с basic_ostream::operator<<. Таким образом, метод UnSerialize должен быть совместим с basic_istream::operator>>. Разработчику, который решился на вариант Serialize, генерирующий исключение, по всей видимости понадобится вариант UnSerialize, который также генерирует исключение.

Для того, чтобы обсуждение было полным, необходимо сказать несколько слов о методе basic_istream::ignore(). Метод относится к группе функций неформатированного ввода [unformatted input functions] (раздел 27.7.2.3 стандарта ISO/IEC 14882:2011). Требования к этой группе слегка отличаются от требований, выдвигаемых к группе функций форматированного ввода [formatted input functions] (раздел 27.7.2.2.1 стандарта ISO/IEC 14882:2011), к которой относится метод basic_istream::operator>>. Но эти отличия не касаются процесса генерации исключений, а потому всё, что мы говорили о методе basic_istream::operator>>, остаётся справедливым и касательно метода basic_istream::ignore().

void UserPreferences::Read(std::istream& in, std::string& out)

Чтобы завершить обсуждение класса, нам осталось взглянуть на метод Read, который отвечает за считывание строк:

 
void UserPreferences::Read(std::istream& in, std::string& out)
{
    char c;
    while(in.get(c))
    {
        if(c==0)
        {
            break;
        }
        out.push_back(c);
    }
}

В этом методе нам встречаются две функции, не обсуждавшихся ранее – это basic_istream::get(char_type& c) и basic_string::push_back(char_type c).

Первый из этих методов также относится к группе функций неформатированного ввода [unformatted input functions], то есть, с точки зрения генерации исключений не отличается от рассмотренного выше basic_istream::ignore(), а потому мы не останавливаемся на его обсуждении. Хотя нужно отметить, что реализация метода Read останется неизменной вне зависимости от выбранного способа распространения ошибок – генерация исключения или анализ возвращаемого значения. Это объясняется тем, что метод Read может быть вызван только из метода UnSerialize, и поэтому возможность или невозможность генерации исключения из метода basic_istream::get(char_type& c) будет определять реализацией UnSerialize.

Что касается метода basic_string::push_back, то помимо ожидаемого std:bad_alloc он может генерировать std::length_error в случае, если длина результирующей строки превышает basic_string::max_size(). Данным аспектом мы управлять не можем, поэтому нам остаётся лишь зафиксировать тот факт, что, в дополнение ко всему выше сказанному, метод Read может генерировать исключения типов std:bad_alloc и std::length_error.

Окончательный вид класса UserPreferences

Давайте посмотрим, что же мы имеем в итоге. Ниже ещё раз приведено описание класса – на этот раз к каждому методу добавлен комментарий.

 
class UserPreferences
{
public:
    // Может генерировать std::exception
    UserPreferences()
 
    // Может генерировать - std::exception
    UserPreferences(int intValue, const std::string& stringValue, float floatValue);
 
    // Метод не генерирует исключений
    void Serialize(std::ostream& out) const;
 
    // Может генерировать std::exception по причине создания объектов типов std::string и UserPreferences
    // Может генерировать std:bad_alloc и std::length_error по причине вызова Read
    static UserPreferences UnSerialize(std::istream& in);
 
private:
    // Может генерировать std:bad_alloc и std::length_error
    static void Read(std::istream& in, std::string& out);
 
private:
    int mIntValue;
    std::string mStringValue;
    float mFloatValue;
};
 
// Метод не генерирует исключений
std::ostream& operator<< (std::ostream& out, const UserPreferences& userPreferences);
 
// Может генерировать std::exception, std:bad_alloc и std::length_error
std::istream& operator>>(std::istream& in, UserPreferences& userPreferences);

Любопытно отметить, что мы пришли к виду класса, в котором информация об ошибках распространяется как посредством генерации исключений, так и через возвращаемые функциями значения (точнее, посредством входных/выходных параметров std::ostream и std::istream).

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

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

Ошибки второго рода можно отнести к ошибкам катастрофическим с точки зрения приложения, от которых клиент класса UserPreferences вряд ли сможет самостоятельно восстановиться. Даже предположив, что клиент класса UserPreferences, перехватив исключения типа std:bad_alloc, попытается для продолжения работы загрузить значение по умолчанию, нет гарантии, что при создании требуемого значения клиент не столкнётся с повторной генерацией того же исключения std:bad_alloc, которое приведёт к аварийному закрытию приложения.

Забегая немного вперёд, скажу, что подобное деление ошибок на те, которые могут быть обработаны неким классом (в данном случае – клиентом класса UserPreferences) и те, которые класс обработать не в состоянии, не является характерной особенностью нашего примера. Оно, скорее, присуще всем системам, составленным из разных уровней абстракций, когда для выполнения некоторого “бизнес-действия” привлекается “низкоуровневая” реализация, а при возникновении ошибки, с которой “работник” справиться не в состоянии, происходит обращение за помощью к вызывающему коду.

Продолжение следует…

Предыдущая часть опубликована здесь.

Алексей, каковы истоки выражения «Not a kernel guy»? Почему именно оно дало название вашему блогу? Что подразумевалось под таким позиционированием?

Полностью эта фраза звучит как «Not a kernel guy in the Windows kernel team», что было, фактически, буквальным изложением той любопытной ситуации, в которой я оказался. В 2006 году я перешел из Копенгагенского центра разработки Microsoft в команду, работавшую над ядром Windows. Это было большой удачей, так как мне всегда нравилось работать с низкоуровневым кодом. В тот момент, однако, мой опыт низкоуровневой разработки был достаточно скромным. Пришлось переучиваться из прикладного разработчика в системного, открывая для себя много нового и интересного по ходу дела. Где-то в этот момент у меня «дозрело» желание завести свой собственный блог. Осталось только придумать название. «Not a kernel guy…» лучше всего отражало тематику блога – я писал о том, что сам недавно узнал, понял и прочувствовал в процессе превращения в тыкву системного разработчика.

Ядро Windows – это святая святых, сердце системы. Как организован техпроцесс низкоуровневой разработки и в чем его особенности по сравнению с прикладной областью?

Гм. Я долго пытался сформулировать что же не так с этой фразой. На первый взгляд, вроде все верно. Ядро – это ключевой компонент любой операционной системы (или, по крайней мере, большинства их них). Кроме того, это довольно сложный компонент, включающий заметное количество нетривиального кода. Но, тем не менее, эта фраза определенно режет мне слух. В этой фразе слишком много эмоций и почти нет фактов. И огромный простор для фантазий о том, как может выглядеть “святая святых” или “сердце системы”. На самом деле все немного проще и совсем по другому. Важных и сложных компонент намного больше, чем пальцев на руках. JIT компилятор .NET, DirectX и драйвера графических адаптеров, подсистема совместимости с предыдущими версиями системы, драйвера файловых систем, гипервизоры и мониторы виртуальных машин, инструменты разработки, сборки и профилирования, тестовая инфраструктура. Ядро – просто еще один элемент в этом списке. Многие из этих компонентов даже не входят в состав системы, но, тем не менее, без них система была бы совсем другой.

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

Скажем, цена ошибки в коде ядра или драйвера выше, чем в прикладном коде, так как первая может “уронить” всю систему, в то время как сфера действия второй ограничена рамками приложения. Чтобы получить успешно работающий у пользователей ядерный код, нужно, чтобы в нем было меньше ошибок, чем в прикладном. Как этого добиться – дело десятое. Понятное дело, будут применяться методики, улучшаюшие качество кода: более разносторонее и формальное тестирование, статический анализ, рецензирование кода, методики, позволяющие улучшить исходный дизайн, формальное доказательство корректности кода и т.д. Выбор конкретных методик зависит от команды, доступного бюджета и прочих обстоятельств.

Да, “святая святых” и “сердце системы” – слишком пафосно и эмоционально. Спасибо, что спустили с небес на землю. Пишут ли системные разработчики псевдокод, создают ли прототипы или сразу же приступают к созданию «боевого» кода?

Системные разработчики делают все то же самое, что и прикладные: пишут псевдокод и рисуют коробочки на доске, создают прототипы, пишут тесты и, бывает, правят “по-живому”. Просто более тщательно. Если же, конечно, они ставят перед собой задачу написать качественный код.

Вопрос о «серьезности». Алексей Пахунов в своем первом проекте и сейчас: что потребовалось изучить/осознать на пути к задачам, которые поручают «серьезным» разработчикам?

Наиболее важными мне кажутся несколько вещей. Во-первых, опыт – в смысле, багаж шишек, набитых как на собственном лбу, так и на лбах коллег. Знания вида “если делать так, то получится эдак”. Наличие опыта позволяет быстрее приходить к верным решениям. В категорию опыта можно отнести и широту кругозора. В какой-то момент становится полезно знать, что происходит в индустрии, какие исследования проводятся в данный момент, текущие тренды и прочее. Такие поверхностные знания помогают быстрее разобраться в новой предметной области, если возникнет такая необходимость.

Во-вторых, важна репутация. Я это хорошо почувствовал при переходе в Google. На новом месте зарабатывать репутацию приходится почти с нуля. Репутация, зачастую, – основной критерий оценки, “сдюжит или нет”. “Стоит ли поручать эту задачу подчиненному? До сих пор он справлялся, каждый раз – со все более сложными задачами. Однозначно стоит!” “Стоит ли тратить время на этот проект? Они уже два раза начинали что-то похожее и бросали на полпути. Пожалуй, не стоит.”

В категорию репутации, вернее, методов её создания, можно отнести умение говорить на одном языке с собеседником. Инженеры, средний менеджмент, менеджеры проектов, шишки из руководства – все разговаривают на собственном диалекте. Бывает забавно наблюдать, как на совещании кто-нибудь из среднего менеджмента “переводит” вице-президенту то, что сказал инженер.

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

И, наконец, нужно дело делать, а не языком трепаться. :-)

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

Про свой подход к созданию приложений ничего внятного, откровенного говоря, сказать не могу. Я просто опираюсь на свой опыт и стараюсь не наступить повторно на одни и те же грабли. Чуть менее успешно, стараюсь не наступать на грабли, ранее разминированные коллегами. Понятно, почему – свои шишки болят больнее. Но, как вы понимаете, суммарный опыт нескольких людей больше чем опыт одного человека. Поэтому, например, следует всегда помнить, что если коллега несет пургу, то это еще не значит, что он не прав. :-)

И, раз мы об этом заговорили, про стиль. Использование единого стиля кодирования в команде/проекте крайне полезно. Единый стиль облегчает чтение и сопровождение кода, уменьшает число ошибок в коде. Особенно если это хорошо продуманный, проверенный практикой стиль кодирования.

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

В связи с этим мне начинают импонировать команды, где эталонный стиль задан “указом сверху”. Кто-то мне рассказывал, что в некоей команде мерилом правильности стиля был стиль, в котором пишет наиболее старший (по должностной иерархии) разработчик. Стиль, наверное, был ужасен, но зато никаких споров. :-)

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

Сможете ли вы рассказать о наиболее значимых ошибках, с которыми вам довелось столкнуться в проектах на тех или иных этапах? Какие выводы из них удалось извлечь?

Расскажу то, что пришло в голову.

Случай первый. Жил-был один проект. Состоял он из двух больших кусков работы: 1) спроектировать и произвести нестандартное железо; 2) модифицировать существующий софт и запустить на этом железе. Обе задачи были сложными и масштабными для имевшихся в наличии ресурсов. Естественным образом сформировались две команды: одна, работающая над аппаратной частью, другая – над программной. В ходе работы возникли проблемы взаимной коммуникации между командами. То программные требования не доходили до ведома проектировщиков железа, то, наоборот, программисты узнавали специфические требования, предъявляемые железом, только когда что-то переставало работать. Поначалу это было похоже на обычные человеческие ошибки. Потом это стало походить на замалчивание информации. Контакты с внешними командами и вендорами тоже страдали похожих же проблем.

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

История вторая. Писал я некое приложение, для которого понадобилось хранить настройки. Причем код должен был быть максимально платформо-независимым. “Ну чё тут думать?”, сказал мой шеф. Пусть будут INI файлы и делов-то. И я написал код для разбора INI файлов. Проблема только, что, как позже выяснилось, тогда я не понимал как, собственно, должны разбираться INI файлы. Взглянув на получившееся, шеф тактично промолчал. Не до того было. А вот мой коллега, которому досталось сопровождение этого кода после моего ухода, говорил пространные речи про рак мозга. Совершенно справедливо, кстати. Мораль: изобретая велосипед, изучи аналоги. Иначе потом будет стыдно.

Еще одна история про то, как я ломал официальную сборку Chrome три раза подряд. Проект, над которым я сейчас работаю, живет в том же самом репозитории, что и Chromium – open source версия Chrome. И собирается вместе с ним же. Понадобилось нам сделать так, чтобы наши файлы архивировались вместе с файлами Chome. Ну что может быть проще, скажете вы? Раз наши файлы уже собираются вместе с Chrome, то достаточно сделать то же самое, что делается для других файлов – добавить в какой-нибудь список “архивируемых” файлов или что-то в этом роде. Единственная закавыка – никакой документации, как это сделать, не существует. Вся документация – это код и комментарии в нем. Совершенно обычная история. Тем более, что есть полнотекстовый поиск по исходному коду.

Я нашел нужный список файлов, добавил наши файлы, тщательно имитируя все то, что делается с остальными файлами. Проверил, что все добавленные файлы собираются как надо. Получил “добро” от владельцев соответствующего скрипта. Результат – официальная ночная сборка не собирается. Оказалось, что официальная сборка собирается немного не так, и наши бинарники просто не были скомпилированы.

Второй заход – исправил официальную сборку, проверил что файлы собираются так, как надо, снова получил “добро”. Естественно, на утро получаю раздраженное письмо: “Can you please test it locally before committing?”. Ну я, собственно, так и сделал, но сборка-то сломана! На этот раз причиной была ошибка в одном из скриптов, которая выползла наружу из-за моих правок.

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

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

Алексей, есть ли какие-то особенности в организации тестирования в Microsoft и Google, на которые вы обратили внимание?

И Microsoft, и Google состоят из отдельных команд, методы и подходы к работе которых могут очень сильно отличаться друг от друга. Скажем, подразделения Bing и Windows в Microsoft выпускают продукты совершенно по-разному. Я могу сравнить то, что видел собственными глазами: как поставлено тестирование Windows в Microsoft и Chrome в Google.

В Windows структура команды базируется на тройках: разработчики (Software Development Engineers, SDEs), тестеры (SDEs in Test) и менеджеры проектов (Program Managers, PMs). Численность разработчиков и тестеров примерно равная с перекосом в сторону разработчиков. Задача тестеров состоит в создании такой инфраструктуры автоматического тестирования, чтобы максимально проверить корректность кода. Код должен не только выдавать ожидаемый результат, но и быть быстрым, надежным, совместимым, локализуемым и т.д. Кроме этого, тестовая инфраструктура должна обеспечивать разработчика информативной диагностикой для обнаруженных проблем и давать возможность прогона тестов разработчиком перед тем, как код попадет в репозиторий.

Соответственно, задача разработчиков – написать код, который не только делает то, что нужно, но и позволяет себя проверить с помощью инфраструктуры, созданной тестерами. Сделать это без взаимодействия разработчиков и тестеров нельзя. Или, по крайней мере, сложно. Поэтому обычно разработчики и тестеры совместно работают над созданием новой функциональности. Начиная с написания спецификаций: разработчик пишет design specification, а тестер – test specification. Обе спецификации (на самом деле три – PM-ы пишут functional specification) перекрестно рецензируются и согласовываются. Далее разработчики с тестерами более-менее параллельно пишут код и полируют его до рабочего состояния.

Далее, в разработке Windows интенсивно используются ветки. Новый код сначала попадает в ветку нижнего уровня, а затем постепенно мигрирует выше, попадая со временем в основную ветку. Перед каждой интеграцией изменений в более высокую ветку код должен быть доведен до “зеленого” состояния. За тестерами при этом остается последнее слово – быть интеграции или не быть.

В случае Chrome все сказанное выше про код также верно. Отличие состоит в том, что тестеров гораздо меньше чем разработчиков. Пропорция, на мой взгляд, где-то один тестер к 5-10 разработчикам. Соответственно разработчики обязаны писать тесты сами и всячески тестировать свой код.

Сильный акцент ставится на автоматическое тестирование. Каждый коммит в репозиторий прогоняется через почти все имеющиеся тесты (т.н. commit queue, или CQ – автоматизированная очередь тестов перед коммитом). Часть тестов выполняется перед коммитом, часть (такие как прогон с анализатором памяти и остальные занимающие много времени проверки) – после.

Ветки используются только для release management. Все разработчики, фактически, коммитят код в основную ветку. Стабильность кода при этом обеспечивается тремя вещами. Во-первых, все изменения просматриваются коллегами в обязательном порядке. Во-вторых, значительная часть тестов прогоняется до коммита в репозиторий. В-третьих, коммиты, успешно прошедшие CQ, но сломавшие, тем не менее, сборку или какой-то тест, как правило, сразу откатываются назад. Занимаются этим так называемые “шерифы” – разработчики, назначенные следить за состоянием кода в репозитории. Каждый постоянный разработчик периодически отрабатывает пару дней “шерифом”, а затем возвращается к своим повседневным обязанностям.

Не возьмусь судить, какая из моделей лучше. В каждой есть свои положительные и отрицательные стороны. Наличие отдельной команды тестеров освобождает разработчиков от возни с тестовой инфраструктурой. Скажем, нестабильные тесты меня совсем не волновали, пока я работал над Windows. С другой стороны, обязательное рецензирование всех изменений очень положительно влияет на качество кода. Было бы интересно ввести правило, согласно которому тестер обязательно должен просмотреть коммит разработчика и наоборот. Уверен, что в конечном итоге это улучшило бы взаимодействие тестеров и разработчиков.

Насколько эффективно, на ваш взгляд, вовлечение в техпроцесс выделенных тестировщиков?

Примерное равенство численности разработчиков и тестеров мне кажется очень хорошей идеей. Естественно, если при этом разработчики и тестеры совместно работают над повышением качества кода. Кто-то, наверное, может возразить, что сами разработчики вполне могут справиться с созданием автоматической тестовой инфраструктуры. Мне кажется, однако, что на практике это работает не очень хорошо. Разработчики слишком легко сбиваются на написание кода, откладывая тесты “на потом”. Выделенная QA-команда (даже если набрать её из тех же разработчиков) лучше уже тем, что перед ней стоит другая цель – не написать код, а убедиться в его качестве.

Исходя из вашего опыта, как организовать тестирование продукта наиболее эффективным образом в координатах “время-качество-деньги”?

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

Мне довольно часто приходилось наблюдать (и быть участником) ситуаций, когда умные, казалось бы, люди не понимают того, что создание более качественного кода требует затрат времени и денег. Если хотите использовать TDD “по-взрослому”, приготовьтесь, что половину времени разработчики будут тратить на написание тестов. Да, это означает, что будет написано вдвое меньше фич [features]. (Здесь сторонники TDD дружно потянулись за гнилыми помидорами :-) ). Хотите, чтобы написанные тесты запускались автоматически? Недостаточно купить оборудование. Запаситесь временем на диагностику ошибок, поддержку и сопровождение скриптов, серверов и т.п.

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

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

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

Второй пункт говорит сам за себя. Мониторинг качества разрабатываемого продукта – необходимая составляющая процесса разработки качественного кода. Иначе откуда вы знаете, что вносимые изменения делают ваш продукт лучше (или хуже)? Качество кода – трудно измеримая величина. Не существует единственного параметра, определяющего качество. Лучшие из известных мне решений отслеживают массу параметров: состояние дел в баг-трекере, результаты прогонов тестов, результаты статического анализа кода, статистику баг-репортов, полученных от пользователей и многое другое.

Большая часть создаваемой инфраструктуры должна работать автоматически и на постоянной основе. Понятно, почему – так дешевле, надежней, а полученные результаты – повторяемы (что абсолютно необходимо для мониторинга качества). На данный момент создана масса удобных и полезных инструментов: статические анализаторы кода, динамические валидаторы кода, инструменты для сбора и анализа логов и т.п. Многие из них свободно доступны и бесплатны. Грех не пользоваться ими. Тем не менее, подобные инструменты используются не так широко, как можно было бы ожидать.

Наличие обратной связи. От момента зарождения идеи и до момента, когда продукт попадает к конечному пользователю, код проходит через множество этапов, видоизменяясь по пути. Это сложный процесс. Как показывает практика, даже самые умные люди не могут точно предсказать как покажет себя только что написанный код. Разработчик не может точно предсказать, где тестер найдет ошибку в его коде. Вся продуктовая команда не может точно предсказать, в каких условиях будет работать выпущенный продукт и где именно пользователи столкнутся с проблемами. Налаженная обратная связь позволит оперативно исправить код, “подогнав” его под реальность.

Также очень важно, чтобы обратная связь была проактивной, а не реактивной. Иными словами, тестер должен иметь возможность вносить коррективы в дизайн до написания кода; пользователи должны иметь возможность влиять на дизайн продукта (например, участвуя в тестировании прототипов).

Авралы: как часто они случаются в вашей практике и что обычно является их причиной?

От проекта зависит. Мне, вроде бы, удается пока держать баланс между авралами и нормальной работой. Помимо всего прочего, объем внеурочной работы напрямую зависит от готовности работника взваливать её на свои плечи. Практика показывает, однако, что многие срочные проблемы успешно решаются откладыванием их на завтра. Осталось только научиться уверенно отличать подобные “срочные” проблемы от действительно срочных… :-)

Фундаментальная причина авралов – импровизация. Возьмите любую процедуру, для которой существует контрольный список шагов. Любое отклонение от списка – возможная ошибка. Чем больше допущено отклонений, тем выше вероятность проблем. Тем выше вероятность, что их придется исправлять в срочном порядке. Тоже самое с существующими техпроцессами. Любое отклонение – возможная ошибка. Вы закоммитили код без прогона тестов – ждите поломанной сборки. Новый код не покрыт юнит тестами – значит, он сломается в будущем в самый неподходящий момент. Еще хуже ситуация, когда техпроцесса попросту не существует. Скажем первый выпуск продукта на рынок свежеиспеченной компанией. Сплошная импровизация – большое количество ошибок – непрерывный аврал.

Алексей, в «Вестях с полей» вы пишите: «То ли повезло, то ли менеджеры у меня были хорошие (кстати, хорошие менеджеры были, кроме шуток), то ли игры на самом деле не такие ужасные…». Что характеризует хорошего менеджера и чем он отличается от плохого?

“Нормальный” менеджер по крайней мере не мешает работать. Хороший – помогает. Очень хороший – помогает и не держит зла за допущенные ошибки (но, при этом, указывает на них и помогает не допустить их в будущем).

Каких возможностей вам не хватает в современных языках программирования?

Если в двух словах, то не хватает удобных средств борьбы со сложностью кода и возможности аналитически доказать корректность кода. К первым я бы отнес инструменты, помогающие находить сходные куски кода; диагностику, показывающую, как именно выполнялся код, как он может выполниться в похожих/граничных условиях; инструменты для статического и динамического анализа кода; возможность контролировать разрешённые конструкции языка; возможность расширять язык напрямую, вместо костылей типа перегрузки операторов и шаблонов в C++ и т.д.

К второй группе я бы отнес возможность задать (и гарантировать) условия, в которых должен выполнятся кусок кода (входные данные, определенное количество доступной памяти, немодифицируемость кода и данных, другие потоки не касаются той же памяти и т.п.) и возможность формально доказать корректность куска кода в данных условиях. Ну и на сладкое – возможность “сшить” такие формально доказанные куски кода в одну программу.

Что нового, на ваш взгляд, появится в языках и средах разработки в ближайшие 5-10 лет?

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

Говоря о нынешней моде, я бы добавил мобильные приложения и социальные сети. Продажа Instagram за 1 млрд долларов вскружила голову многим. :) Что вам хотелось бы изменить в индустрии IT?

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

Алексей, большое спасибо за интервью. Пусть сказка на вашем пути хоть иногда становится явью!

Во что обходятся провалы?

Часть перфекционистов в индустрии разработки ПО чрезмерно озабочена провалами, а большинство других не подвергают вдумчивому анализу ценность бесперебойной деятельности. Тем не менее, обычно при тщательной оценке стоимости провала мы видим, что повышение надежности программного обеспечения может принести огромную пользу. В книге “Responding to Significant Software Events” я представляю пять примеров, которые вас убедят.

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

Коммунальное предприятие изменяло алгоритм выставления счетов в соответствии с изменением ставки оплаты труда (эфвемизм коммунальщиков для “повышения тарифов”). Процедура сводилась к корректировке нескольких численных констант в существующей программе биллинга. Незначительная ошибка в одной константе приумножилась миллионами потребителей и вылилась в X долларов, безвозвратно потерянных предприятием. Я говорю “X долларов”, поскольку слышал эту историю от четырех разных клиентов с различными значениями X. Оценка потерь варьировалась от 42 миллионов до 1,1 миллиарда долларов. Учитывая, что такая история произошла с четырьмя моими клиентами, и лишь малая часть коммунальных компаний пользуется моими услугами, я уверен, что на самом деле такие случаи бывали намного чаще.

О следующем случае я узнал из общедоступной прессы, поэтому могу сказать, что речь идет о New York State Lottery. Законодательный орган штата Нью-Йорк разрешил проведение особой лотерии в целях сбора дополнительных средств на одно достойное дело. Поскольку эта лотерея отличалась от обычной лотереи, в программу для печати лотерейных билетов нужно было внести изменения. К счастью, модификация заключалась в изменении одной цифры в существующей программе. Крошечная ошибка привела к печати билетов-дубликатов, а общественное доверие к лотерее было подорвано и сопровождалось убытками, оцениваемыми в пределах между 44 и 55 миллионами долларов.

Другую историю я знаю со стороны, как клиент одной большой брокерской фирмы. Однажды фиктивная строка с 100.000$ была напечатана в сводках 1500000 аккаунтов, и никто не знал причин ее появления. Суммарная стоимость этого провала составила по меньшей мере 2000000 долларов, а причина заключалась в простейших ошибках при программировании на языке COBOL: не очищалась строка в зоне печати.

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

Сценарий Больших Провалов

В каждом из исследованных случаев события развивались согласно универсальному сценарию:

1.   Есть работающая система, которая считается надежной и архиважной

2.   Запрос на быстрое изменение в системе обычно исходит от высокопоставленного лица в организации.

3.   Изменение признается “тривиальным”.

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

5.   Изменение проводится без каких-либо мер предосторожности, типичных для разработки ПО и внедренных в организации (пусть в минимальном объеме).

6.   Изменение проводится непосредственно в системе, выполняющей повседневные операции.

7.   Точечный эффект от изменения невелик, поэтому никто не замечает его сразу.

8.   Этот скромный эффект приумножается многократными операциями и приводит к большим последствиям.

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

9.   Первая реакция руководства – преуменьшить значимость провала, поэтому его последствия ощущаются в некоторой степени дольше и без того неизбежного периода.

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

11.   Руководитель группы понижается в должности до программиста – наверное, вследствие продемонстрированного (не)понимания технических аспектов работы.

12.   Менеджер, который поручил это дело руководителю группы, ускользает в сторону на штабную должность – по-видимому, для развития методик разработки программного обеспечения.

13.   Вышестоящие менеджеры остаются нетронутыми. В конце концов, что они могли сделать?

Первое Правило Предотвращения Провала

Осознав Универсальный Сценарий Гигантских Потерь, вы знаете как поступать в ответ на высказывания такого рода:

Когда вы слышите, как кто-нибудь считает нечто слишком маленьким и недостойным внимания, будьте начеку. Вот Первое Правило Предотвращения Провала:

Нет ничего слишком маленького, чтобы оно было недостойно внимания.

Все может быть иначе

Истории катастроф всегда служат хорошим предметом новостей, но наблюдение за ними может исказить реальность. Если мы рассматриваем только катастрофы в разработке ПО, мы упускаем все организации с эффективным управлением. Но хорошее управление так скучно! Не происходит ничего достойного публикации в прессе. Или почти ничего. К счастью, мы изредка встречаем согревающие душу истории, как, например, публикация в Financial World, рассказывающая о Чарлзе T. Фишере III из NBD Corporation, одном из титулованных CEO восьмидесятых:

“Когда компьютеры Comerica начали извергать ошибочные отчеты своим клиентам, Фишер ввел Контроль Гарантированной Производительности, обещая 10$ за каждую ошибку в месячном отчете клиента NBD. В течение двух месяцев корпорация NBD заявила о 15000 новых клиентов и более чем 32 миллионах долларов в новых аккаунтах.”

История умалчивает о том, что происходило в недрах департамента Информационных Систем, когда его сотрудники осознали, что их CEO Чарлз Т. Фишер III установил стоимость их работы. Я не присутствовал при этом, но могу предположить эффект от осознания того, что каждая непредотвращенная ошибка стоила бы 10$ наличными.

Второе Правило Предотвращения Провала

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

Потеря X долларов всегда является ответственностью управленца, чья финансовая ответственность превышает X долларов.

Осознают ли когда-нибудь другие фирмы, что за незащищенность организации от вероятной потери миллиарда долларов должен отвечать руководитель самого высокого уровня? Программист, который даже не уполномочен позвонить по межгороду, никогда не может быть ответственным за потерю миллиарда долларов. При наличии вероятности потерять миллиард долларов надежное функционирование информационных систем в организации входит в зону ответственности CEO.

Конечно, я не думаю, что Чарлз Т. Фишер III или любой другой CEO приложит руку даже к одной цифре в программе на COBOL. Но я действительно надеюсь, что когда исполнительные директоры осознают ценнность бесперебойной деятельности, они совершат правильные управленческие поступки. И тогда это послание просочится на уровни, в которых можно что-то предпринять по его поводу – наряду с ресурсами для таких действий.

Учиться у других

Другой урок из этих историй: к моменту обнаружения провалов все будет слишком поздно. Будем надеяться, что ваш CEO прочитает о незащищенности в этих учебных примерах, а не в отчете о катастрофе в вашем офисе. Лучше найти способы предотвратить провалы до того как они выйдут из стен офиса.

Вот вопрос на проверку ваших познаний в разработке ПО:

Каков самый ранний, дешевый, легкий и наиболее практичный способ обнаружить провалы?

И вот ответ, который вы, возможно, не ожидали:

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

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

Случаи, подобные описанным выше, встречаются в новостях каждую неделю и оказывают сильное влияние на отношение широкой публики к компьютерам. Но, похоже, они не оказывают никакого влияния на позицию профессионалов в области разработки ПО. Не потому ли, что такие чудовищные потери могут вызывать лишь одну безопасную психологическую реакцию: “У нас это не произойдет, потому что если произойдет, то я потеряю свою работу, а я не могу себе этого позволить, поэтому я не буду об этом думать”?

(По материалам книги Responding to Significant Software Events)
Оригинальная публикация: http://secretsofconsulting.blogspot.com/2011/01/universal-pattern-of-huge-software.html

Ранее мы выделили 32 прощальных послания (post-mortem), в которых предприниматели анализировали причины провала созданных ими стартапов и были столь любезны поделиться уроками, извлеченными из неудач. Многие читатели заинтересовались наиболее типичными причинами краха, которые можно выделить из представленных публикаций.

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

20. Организация компании в неподходящее время

Многие компании, потерпевшие неудачу при старте во время недавнего финансового кризиса и продолжающие испытывать трудности, видят причину угасания своей активности в повышенной негативности рынка. Негативность ударила по инвестиционным фондам (венчурный капитал обвалился в 2009 году) либо по намеченным клиентам, как в случае с компанией Untitled Partners, которая создавала платформу для совместного владения предметами изобразительного искусства. В прощальной заметке основатели компании говорят:

Наш анализ поддерживался статьями в Wall Street Journal и NYT, а также индексом предметов искусства Mei Moses , согласно которому рынок был антициклическим и имел слабую корреляцию с S&P. Но мы не учли величину текущих колебаний и их влияние на дискретный уровень затрат на предметы роскоши в кругу клиентов, которым наш продукт по-прежнему был по карману. Очевидно, мы ошиблись в своей возможности расти на фоне грядущего экономического спада.

19. Неполный рабочий день

Стартапы – нелегкое дело. Еще тяжелее, когда в течение дня вы вовлечены в два разных направления деятельности. Такое заключение прослеживается в нескольких прощальных заметках. Если на основной работе вы заняты полный день, и никто из вас не посвящает все свое время стартапу, вы рискуете перегореть, двигаться недостаточно оперативно и просто не иметь времени на необходимые действия. Кроме того, при наличии другой работы команда рискует действовать с меньшим подъемом, держа в уме наличие других источников дохода. Команда проекта Overto ощутила, что отсутствие хотя бы одного человека, занимающегося проектом полный день, послужило основной причиной неудачи:

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

18. Дислокация, дислокация, дислокация

Дислокация оказалась важной в двух аспектах. Во-первых, должна быть согласованность между концепцией вашего стартапа и местоположением. Грубый пример: если вы создаете инновационное программное обеспечение для торговли на Wall Street, находитесь рядом со своими клиентами для наилучшего взаимодействия с ними. Местоположение также сыграло свою роль в неудачах распределенных команд. Ключевой момент для распределенной команды: найдите эффективные методы коммуникации, иначе отсутствие командной работы и планирования может привести к провалу. Нюансы местоположения назывались в качестве причины неудач в 6% случаев. В своем прощальном письме создатель сервиса микроблоггинга Nouncer рассматривает решение разместиться в Нью-Йорке как фактор, повредивший его компании:

В моем случае в Нью-Йорке не ощущалось нехватки денег, сообщества, достойных сотрудников и умных людей, способных дать хороший совет. Для успеха моего продукта не хватало целевой аудитории – ранних последователей, веб-хакеров, ищущих новую клевую игрушку. Я мог рассчитывать лишь на малое количество людей, встреченных на редких нью-йоркских тусовках, которые подходили под это описание. В Сан-Франциско такие конференции можно было найти каждый день, не говоря уже о неформальных сборищах, где люди “пачкали руки”, играя с программным кодом. Это очень специфичная аудитория, выбор которой был обусловлен моим решением не создавать продукт для широкого круга клиентов.

17. Неспособность привлечь инвесторов

Эту причину можно было счесть родственницей причины №20 (организация компании в неподходящее время), если бы не группа основателей стартапов, откровенно заявивших о неспособности привлечь инвесторов как причине заката своей деятельности. Если у вас нет денег для реализации идеи, пересмотрите состояние рынка и свои подходы.

16. Вытеснение на второй план

Вопреки банальным утверждениям, согласно которым стартапам не следует уделять внимание конкуренции, в реальности происходит так: как только свежая идея получает одобрение рынка, на сцене появляется много соперников. И хотя навязчивые мысли о конкуренции не прибавляют здоровья, ее игнорирование привело к неудаче 10% стартапов. Marc Hedlund, руководитель Wesabe (сервис для управления персональными финансами) рассказал об этом в своих прощальных заметках:

В Mint был худший метод агрегации данных, а в Wesabe требовалось значительно больше усилий для работы в системе. При выборе между ними клиентам оказалось намного легче и удобнее работать в Mint, и положительный опыт накопился довольно быстро. Все, что я упомянул – независимость от одного провайдера ресурсов, сохранение конфиденциальности пользователей, помощь клиентам в изменении их финансовой жизни в лучшую сторону – все это замечательные, разумные вещи, и мы к ним стремились. Но ни одна из них не имеет значения, если с продуктом труднее работать, потому что большинство людей просто не заботятся о том, чтобы извлечь прибыль в долгосрочной перспективе, если доступна краткосрочная.

15. Выгорание

Основателям стартапов нечасто удается соблюдать баланс работы и личной жизни, поэтому риск сгорания высок. Способность при необходимости урезать свои расходы и перенаправить усилия при попадании в тупик оказалась важным фактором в достижении успеха и предотвращении выгорания – наряду с наличием крепкой, разноплановой и целеустремленной команды, в которой можно разделить ответственность. Выгорание было названо причиной краха в более чем 12% случаев. В прощальных заметках один из основателей сервиса Diffle рассматривает последствия выгорания и говорит о том, что оно не закончилось с закрытием стартапа и продолжалось в течение некоторого времени:

14. Потеря фокуса: распыление

Отвлечение на “а что если” было множество раз названо в качестве фактора, способствовавшего провалу. Важно запустить на рынок одну вещь и сфокусироваться на одном продукте, иначе вы рискуете остаться с большим количеством почти готовых продуктов, которые не представляют ценности для вас или ваших клиентов. В последней заметке о проекте Kiko его основатель Mahesh Piddshetti пишет:

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

13. Разногласия с инвесторами/cooснователями

Разлад с сооснователем стал одним из наиболее фатальных факторов для компаний. Сооснователь Bricabox рекомендует: “Когда сооснователь покидает компанию (как в случае со мной), вам уже нанесен сокрушительный удар. Не усугубляйте ситуацию бременем заботы о капитале компании, оставшейся на ваших руках (инвесторам не понравится, что второй акционер отсутствует – даже если он уже не имеет никакого отношения к компании). Поэтому наилучший вариант в такой ситуации – длинный-длинный срок ограничения на обращение акций для всех ключевых сооснователей.”

Но напряженность не ограничена командой основателей. Когда ухудшаются отношения с инвестором, все довольно быстро идет под откос, что доказывает случай с ArsDigita. Инвесторы и основатели разошлись во взглядах на светлое будущее компании, и в конце концов инвесторы привели компанию к краху. В своих финальных заметках Phillip Greenspun, один из основателей компании, ярко и откровенно говорит о том, что происходит, когда инвесторы и управляющая команда стартапа находятся в разладе:

12. Недооценка круга общения

Мы часто слышим, как организаторы стартапов сокрушаются о нехватке деловых контактов. Нас удивило, что в качестве одной из основных причин неудачи предприниматели называют неэффективное использование собственной сети общения. Об этом говорится в 16% прощальных заметок. Чему учит нас этот факт? Если у вас есть сеть общения (она есть у каждого), будьте осмотрительны с этим ресурсом, но ни в коем случае не забывайте о нем.

11. Вопросы ценообразования

В ценообразовании одна часть наука и десять частей искусство. И это темное искусство, судя по большому количеству стартапов, которые потерпели неудачу и выставляли слишком большую или слишком маленькую цену за продукт. К примеру, один предприниматель сказал: “Потребовалось немало ключевых цепочек с покупкой за 50 центов и продажей за 1,25$, чтобы оплатить телефонные счета”. Основатель EventVue заметил, что их смертельной стратегической ошибкой было “следование модели продаж в корпоративном секторе с каждый раз новой маленькой ценой”.

10. Продукт, недружественный пользователю

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

9. Запоздалый отказ от убыточного пути

Одним из чрезмерно используемых стартаповских словосочетаний в 2010 году было «ключевые предположения модели» (Pivot), но среди причин краха довольно часто назывался недостаточно быстрый отказ от плохого продукта, плохого сотрудника, плохого решения и т.п. Остановки или приверженность плохой идее – не лучший способ распределить ресурсы. И это не просто идеи. Если вы принимаете неверное решение по найму сотрудника, совершите корректирующий поступок (эвфемизм для его увольнения) – и чем раньше, тем лучше. Как только вы увидите, что ваш продукт не пользуется спросом на рынке, подумайте о необходимых изменениях. Инерция и упертость, ограничивающие рост и возможность изменить модель бизнеса, назывались среди причин неудач в одном случае из пяти.

8. Нехватка страсти и специфических знаний

В мире рождается много хороших идей, но создатели угасших стартапов считают остутствие интереса к выбранной области и нехватку специфических знаний ключевыми причинами провала вне зависимости от того, насколько идея хороша. Сооснователь Untitled Partners заявил: “Я недооценил важность взаимосвязи между нашими корпоративными и личными интересами”. Нехватка страсти как причина краха фигурирует в 18,8% случаев. В своем последнем обращении основатели NewsTilt откровенно говорили об отсутствии интереса к выбранной отрасли:

7. Выпуск продукта в неподходящее время

Если вы выпускаете продукт слишком рано, пользователи могут сбросить его со счетов как недостаточно хороший. Если первое впечатление пользователей было отрицательным, вернуть их назад будет трудно. Если вы выпускаете продукт слишком поздно, вы можете упустить благоприятное стечение обстоятельств. “Здесь требуется баланс. Если речь идет о мегапопулярном веб-сайте, от которого зависят пользователи, скажем, Ebay или Mint.com, то его недоступность может обернуться катастрофой. Но если речь идет о сайте, подобном Twitter, то простой могут счесть шуткой. Знайте свой сайт, не затягивайте до бесконечности его выход на рынок. Но если он критически важен для пользователей, обеспечьте надежность его работы». Как сказал Reid Hoffman, “Если вы не испытываете определенных трудностей при запуске версии 1.0 своего продукта, вы выпустили его слишком поздно”. Неподходящее время выхода продукта было названо причиной краха в более чем 20% случаев.

6. У меня есть продукт, теперь мне нужна бизнес-модель

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

5. Деньги кончились

Деньги и время заканчиваются и требуют разумного отношения. Задача правильного расходования средств зачастую оказывалась неразрешимой, и ее неверное решение называлось причиной краха угасших стартапов. Стоит ли потратить существенную сумму единовременно для придания импульса продукту или лучше разрабатывать его постепенно? Непросто найти правильное соотношение. Команда YouCastr обозначила денежные проблемы в качестве причины провала, но в то же время подчеркнула существование других причин для закрытия проекта вопреки возможности попытаться найти дополнительные деньги:

Единственная важная причина, по которой мы закрываем проект – у нас кончились деньги. Несмотря на ЧРЕЗВЫЧАЙНО бережливое управление компанией, наличие выручки и готовность держаться до конца, у нас не было денег для продолжения работы. Следующие несколько причин могут пролить больше света на наше решение закрыться вместо того чтобы найти другой источник денежных средств.

4. Слабый маркетинг

Понимание целевой аудитории, знание способов заполучить внимание пользователей и умение в конце концов превратить их в клиентов – одни из наиболее важных навыков в успешном бизнесе. Тем не менее, в 30% провалов неэффективный маркетинг стал главной причиной неудачи. Зачастую неспособность заниматься маркетингом была отличительной чертой основателей. Им нравилось писать код и строить продукт, но у них отсутствовала тяга к продвижению продукта. Ребята в проекте Devver подчеркнули крайнюю важность заполучить кого-нибудь, кто любит создавать и находить каналы дистрибуции, развивать деловые связи.

3. Неподходящая команда

Наличие разноплановой команды с взаимодополняющими навыками часто выдвигалось в качестве критически важной составляющей успеха стартапа. В прощальных записках зачастую слышались стенания вида “вот если бы у нас был CTO с самого начала” или “основатель, которому бы нравилось заниматься деловыми вопросами”. В некоторых случаях команда основателей желала более глубокого контроля действий друг друга и достижения баланса. Как заметил основатель Nouncers, “Теперь мне ясно, что базовой проблемой было отсутствие партнера, который мог меня сбалансировать, а также тщательно анализировать принимаемые деловые и технические решения”. Основатель Wesabe также отмечает, что решения, касаемые деятельности предприятия, он упорно принимал в одиночку и потому в неудаче Wesabe не может обвинить никого кроме себя. Нехватка умений в команде называлась в качестве причины провала почти в каждом третьем случае.

2. Решение интересной задачи вместо нацеливания на потребности рынка

Выбор интересной задачи вместо решения задачи, соответствующей требованиям рынка, часто назывался в качестве причины неудачи. Конечно, вы можете создать приложение и посмотреть, что с ним будет, но лучше заранее знать потребности рынка. “Компании должны браться за проблемы рынка, а не за технические задачи”, утверждает основатель BricaBox. Одной из основных причин провала BricaBox было стремление решить техническую задачу: “Здорово уступать своим желаниям, но лучше всего если ваши желания находят отклик на широком рынке. Если вы хотите решить техническую проблему, соберите группу и создайте проект с открытым кодом”.

1. Негибкость и отсутствие активного внимания к отзывам клиентов

Игнорирование своих пользователей – проверенный способ прийти к неудаче. Несмотря на очевидность этого постулата, отказ от него назывался первейшей причиной краха. Узость взглядов и пренебрежение отзывами пользователей – это фатальные упущения для большинства стартапов. Например, основатель компании eCrowds, создавшей систему управления веб-контентом, отметил: “Мы потратили слишком много времени, создавая систему для себя и не получая обратной связи от потенциальных клиентов. Легко оказаться в ситуации с ограниченным полем зрения. Я рекомендую не затягивать больше чем на два-три месяца получение объективного мнения потенциальных клиентов”.

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

Оригинальная публикация: http://www.chubbybrain.com/blog/top-reasons-startups-fail-analyzing-startup-failure-post-mortem/

Технология DTrace и подходящие инструменты для ее использования появились в 2005 году, но, несмотря на это, DTrace еще малоизвестна в широких кругах разработчиков и сисадминов. Это тем более удивительно, что за пять с половиной лет, прошедших с выхода системы Solaris 10, в которой она впервые появилась, так и не было придумано более совершенной технологии наблюдения за операционной системой и приложениями.

DTrace была разработана в компании Sun Microsystems, и открытый код всех ее компонентов был опубликован в том же 2005 году. С тех пор DTrace была перенесена в Mac OS X, QNX и FreeBSD, и появилась также во всех дистрибутивах, унаследовавших код ядра Solaris: Belenix, Korona, Nexenta, OpenIndiana и Milax. Разумеется, в Solaris технология DTrace тоже осталась и даже развилась – датчиков стало больше. В настоящее время DTrace доступна в самой свежей версии Solaris 11 Express, равно как и в Solaris 10.

По сравнению с другими средствами сбора информации о системе и отладки приложений, DTrace обладает рядом уникальных свойств:

Основным компонентом DTrace является модуль ядра, обеспечивающий функционирование подсистемы DTrace, а основным инструментом – приложение dtrace, которое воспринимает скрипты, написанные на языке D, созданном специально для работы с DTrace. В этой заметке мы не будем вдаваться в детали реализации DTrace; тем, кто в них заинтересован, я могу посоветовать найти их описание в Google, а также в главах 27 и 28 второго издания книги «Операционная система Solaris», написанной мной в соавторстве с Евгением Ильиным в 2009 году. Кроме того, наблюдение, профилирование и трассировка работы приложений с помощью DTrace подробно рассмотрены в одной из лекций по курсу «Системное администрирование ОС Solaris 10».

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

Однажды на конференции OSDevCon в Дрездене Чад Минхир (Chad Mynhier) вел мастер-класс по DTrace. Интерес к нему был огромный, и вот почему. Чад работает в компании Forsythe, зарабатывающей миллионы долларов в месяц на оптимизации банковских приложений. Как-то раз у одного из заказчиков он триумфально ускорил работу приложения в тысячу раз, заодно побив рекорд скорости зарабатывания гонорара.

Дело в том, что одно из основных банковских приложений, функциональность которого вполне удовлетворяла всех раньше, стало работать значительно медленнее с ростом нагрузки. Так как банк планировал еще больший рост нагрузки, опасное замедление становилось неприемлемым. Анализ приложения с помощью DTrace вначале не выявил ничего особенного, однако распределение функций по частоте вызовов показалось Чаду настораживающим: чаще всех вызывалась функция gettimeofday(), возвращающая текущее системное время. При работе с базами данных в вызове этой функции нет ничего подозрительного, так как в БД часто записывается время, в которое произошла транзакция, но эта функция отчего-то доминировала в вызовах… С помощью DTrace было локализовано место в приложении, где эта функция вызывалась чаще всего. Оказалось, что по недосмотру разработчика она вызывалась в цикле, который, как назло, тоже был задействован почти в каждой операции приложения.

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

Cкрипт, выдающий количество функций, написать легко. В качестве затравки рассмотрим несколько вариантов, а затем перейдем к синтаксису скриптов. Например, вот такой скрипт выдает количество вызовов любых функций при работе программы ls (вначале на экран будет выдан результат ее работы, а потом – список функций с количеством вызовов для каждой в порядке возрастания):

pfexec dtrace -n 'pid$target:::entry {@funсtions[probefunc]=count();}' -c ls

А вот таким скриптом можно посчитать количество функций, вызванных конкретным процессом с PID=2355; для получения результата надо прервать выполнение скрипта с помощью Ctrl-C:

pfexec dtrace -n 'pid2355:::entry {@funсtions[probefunc]=count();}'

А вот так можно посчитать количество системных вызовов в том же процессе:

pfexec dtrace -n 'syscall:::entry /pid==2355/ {@funсtions[probefunc]=count();}'

Итак, в скриптах на языке D всегда используется следующий синтаксис:

провайдер:модуль:функция:датчик
/условие/
{
действия
}

Провайдер – это модуль ядра или модуль приложения, обеспечивающий регистрацию своих датчиков DTrace в системе. Например, провайдер syscall регистрирует датчики, расположенные в системных вызовах, провайдер mysql – датчики, встроенные в сервер MySQL.

Модуль – это название модуля или библиотеки, например, libc.

Функция – имя функции, датчик в которой нам интересен, например, fopen.

Датчик – название датчика (во многих случаях датчик называется entry или return).

Условие задает ситуацию, когда следует выполнить действие при срабатывании датчика. Например, надо выполнить его только тогда, когда датчик сработал в приложении top. Тогда условие выглядит так:

 /execname == top/

Действия – это то, что обеспечивает сбор информации и вывод ее на экран. Из примеров ниже будет ясно, какими они бывают.

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

Простой пример того, как я использую DTrace в повседневной жизни: после переноса пользовательских настроек с одного компьютера на другой система на не захотела работать с принтером, как раньше. Было ясно, что какой-то из файлов настроек отчего-то не скопирован. Но какой именно? Их же сотни… Банальные /etc/printers и /etc/lp/* были проверены и разгадки не дали. Тогда пришлось задействовать DTrace. Простой скрипт дает возможность заглянуть в недра программы lpstat (наиболее безвредная программа из тех, что работает с принтером) и посмотреть, какие файлы она пытается открыть:

lpstat -s
scheduler is running
system default printer: eaqvap21
aqvap21: unknown printer
aqvap21: unknown printer

Чтобы запустить программу и подсунуть ее PID скрипту на DTrace надо использовать ключ -c :

dtrace -n 'pid$target::fopen:entry {printf("%s",copyinstr(arg0));}' -c "lpstat -s"

dtrace: description 'pid$target::fopen:entry ' matched 1 probe
scheduler is running
system default printer: eaqvap21
aqvap21: unknown printer
aqvap21: unknown printer
dtrace: pid 11156 has exited
CPU     ID                    FUNCTION:NAME
 0  59882                      fopen:entry /etc/default/init
 0  59882                      fopen:entry /etc/lp/ppd/eaqvap21.ppd
 0  59882                      fopen:entry /export/home/filip/.printers
 0  59882                      fopen:entry /export/home/filip/.printers
 0  59882                      fopen:entry /export/home/filip/.printers
 0  59882                      fopen:entry /etc/printers.conf
 0  59882                      fopen:entry /export/home/filip/.printers
 0  59882                      fopen:entry /etc/printers.conf
 1  59882                      fopen:entry /etc/nsswitch.conf
 1  59882                      fopen:entry /export/home/filip/.printers
 1  59882                      fopen:entry /export/home/filip/.printers
 1  59882                      fopen:entry /etc/printers.conf

Вот и все: я забыл, что надо почистить файл .printers в домашнем каталоге:

rm /export/home/filip/.printers

Готово! Все работает на ура!

Замечание: подсовывать PID программы скрипту надо потому, что провайдер pid требует указания PID изучаемого с помощью DTrace процесса, а знакомый нам всем вызов fopen как раз относится к этому провайдеру DTrace.

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

pfexec dtrace -n 'syscall::open*:entry {printf("%s\n",copyinstr(arg0));}'

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

Наконец, для тех, кто отлаживает веб-приложения, может пригодиться скрипт, который вылавливает SQL-операторы из сервера БД перед тем, как сервер их запустит. Это позволяет выяснить, какие именно операторы исполняются; такая информация поможет, если кажется, что скрипт, работающий с БД, все делает верно, а база данных возвращает неожиданный результат: может оказаться, что либо SQL-выражение формируется неверно, либо соединние происходит не с той базой данных, что надо, либо какой-то параметр передается СУБД без должного оформления (например, без кавычек или с лишними кавычками).

Вот этот скрипт:

#!/usr/sbin/dtrace -s
#pragma D option quiet
dtrace:::BEGIN
{
  printf("%-20s %-20s %-40s %-9s\n", "Who", "Database", "Query", "Time(ms)");
}
mysql*:::query-start
{
  self->query = copyinstr(arg0);
  self->connid = arg1;
  self->db    = copyinstr(arg2);
  self->who   = strjoin(copyinstr(arg3),strjoin("@",copyinstr(arg4)));
  self->querystart = timestamp;
}
 
mysql*:::query-done
{
  printf("%-20s %-20s %-40s %-9d\n",self->who,self->db,self->query,
         (timestamp - self->querystart) / 1000000);
}

Запустив его, можно наблюдать картину работы сервера (осторожно! там может быть очень много информации, если сервер сильно нагружен запросами!):

$ pfexec ./mysql.d
Who                  Database             Query                                    Time(ms)
root@localhost       data                 SELECT DATABASE()                        0
root@localhost       test                 show tables                              0
root@localhost       test                 SELECT DATABASE()                        0
root@localhost       mysql                select * from users                      0
root@localhost       mysql                select * from host                       0

C помощью измерения времени между срабатываниями датчиков query-start и query-done вычисляется время исполнения SQL-оператора, и DTrace позволяет строить графики распределения времени исполнения по операторам. Так можно найти те обращения к базе данных, которые отнимают много времени при выполнении конкретных приложений. Большое преимущество DTrace в том, что все эти измерения можно производить в условиях реальной нагрузки на сервер, так как накладные расходы на работу самого DTrace минимальны и не будут мешать работе сервера.

Замечание: время выполнения запросов меньше 1 ms, а в скрипте выполняется целочисленное деление, поэтому результат получается 0. Можно считать в микросекундах, а не в миллисекундах, тогда будет какое-то небольшое значение.

Из приведенных примеров видно, что датчики DTrace расставлены в системе и приложениях Solaris повсюду. Изучить, какие аргументы, связанные с датчиками, можно использовать так, как показано выше, можно в документации по системе (man) и в документации по конкретным приложениям (например, по серверу MySQL на сайте mysql.com).

Значительно больше примеров скриптов для dtrace можно найти в следующих источниках:

Тем, кто захочет попробовать DTrace на практике, важно помнить, что для использования dtrace надо обладать правами администратора системы; обычному пользователю dtrace недоступна из соображений безопасности.

Статья рассматривает вопросы, относящиеся к обработке исключительных ситуаций [exception handling] в языках, поддерживающих соответствующий механизм. В статье обсуждаются наиболее распространённые проблемы, с которыми сталкивается разработчик, применяя обработку исключений, а также возможные способы решения этих проблем. Основной акцент в статье делается на примерах и прецедентах использования исключений. Статья предназначена для разработчиков, знакомых с объектно-ориентированными языками и будет полезна при освоении этих языков.

Основные примеры в статье приведены на C++.

Введение

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

Понятия “ошибка” и “исключение” в статье, в основном, рассматриваются как синонимы. Везде, где не оговорено особо, фразу “функция генерирует исключение” можно трактовать, как “функция возвращает ошибку”, и наоборот. Либо, переиначив, функция извещает об ошибке, генерируя исключение.

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

Под термин “исключительная ситуация” не подводится теоретической базы – ситуация считается “исключительной”, если таковой её считает разработчик.

Помимо этих понятий, в статье широко используется термин “компонент”. Термин следует трактовать в самом широком смысле – он может ссылаться на класс, подсистему, программный продукт и т.п.

1 Стратегия

Мы будем исходить из того, что язык позволяет нам генерировать и перехватывать исключения. Это необходимо и, в принципе, достаточно для реализации единого – последовательного и согласованного – подхода к обработке ошибок, о котором говорилось выше. Утверждение вытекает из уверенности в том, что подход реализуем, в рамках одного проекта, поддерживаемого одним человеком.

Посмотрим, жизнеспособна ли идея, если речь идёт о промышленном применении.

Для того, чтобы решение выглядело чем-то большим, нежели совет “пишите хороший код”, начнём со списка вопросов, которые встают перед разработчиком в момент обработки ошибочной ситуации:

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

1.1 Когда следует генерировать исключения

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

Два фактора влияют на выбор того или иного способа:

Первый не зависит от разработчика и, порой, не оставляет ему выбора, заставляя использовать традиционные методы оповещения об ошибках. Тогда как второй определятся прецедентами использования [use cases] разрабатываемого компонента.
Ниже мы подробно рассмотрим оба фактора.

1.1.1 Внешние ограничения

Начнём с рассмотрения внешних ограничений. Подобные ограничения актуальны для языка C++, но подчас их приходится учитывать и для языков, для которых работа с исключениями является “врождённым” свойством. Вот основные случаи, в которых нам приходится использовать традиционные способы оповещения об ошибках.

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

 
LRESULT CALLBACK MyCallbackMethod(API_STRUCTURE*);
 
void DoSomething()
{
    API_STRUCTURE s = { 0 };
    try
    {
        API_Method(&s, MyCallbackMethod );
    }
    catch(const MyError&)
    {
        // #1
        Another_API_Method(&s );
    }
}
 
LRESULT CALLBACK MyCallbackMethod(API_STRUCTURE*)
{
    throw MyError( );
}

1.1.2 Выбери меня

Теперь, предположив, что внешние ограничения отсутствуют, давайте рассмотрим, что может повлиять на наше решение – воспользоваться исключением или вернуть из метода значение?

Обсуждение полезно будет провести на примере небольшого класса. Подобное обсуждение даст нам возможность поставить “правильные” вопросы, задав которые мы в значительной мере приблизимся к решению. Начнём с рассмотрения примера совместно используемого кода (для краткости назовём такой код “библиотечным”). Это позволит нам в дальнейшем упростить обсуждение “обычного” небиблиотечного кода.

1.1.2.1 Создание библиотеки

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

Как правило, в отсутствии внешних ограничений, разработчик волен сам выбирать способ оповещения об ошибках. Рассмотрим факторы, которые могут повлиять на этот выбор:

1.1.2.1.1 Функционально совместимый код

Под функциональной совместимостью здесь следует понимать совместимость создаваемого совместно используемого кода с базовым кодом, на котором построена библиотека (если таковой имеется) или кодом, который она призвана заместить.

Одним из примеров функционально совместимой библиотеки может послужить набор классов, обеспечивающих тонкую (а иногда и не очень тонкую) обёртку вокруг функций API. Здесь уместно вспомнить Windows Template Library (WTL).

Другой пример – дополнение или расширение хорошо известной библиотеки. Здесь знакомой иллюстрацией может быть библиотека boost.

В случаях, подобным упомянутым выше, наилучшей стратегией является соблюдение “принципа наименьшего удивления” [principle of least astonishment] [principle of least surprise] (E.S. Raymond, The Art of Unix Programming, 1.6.10 Rule of Least Surprise). Сейчас мы ведём речь лишь об обработке исключений, но, в общем случае, этот подход хорошо работает и при реализации библиотеки в целом.

Класс CFile

В качестве примера обратимся к классу, который работает с описателем файла – объектом ядра операционной системы Windows. И попытаемся на этом примере проиллюстрировать условия, которые могут повлиять на выбор определённой стратегии распространения ошибок.
Объявив класс в некотором пространстве имён, для того чтобы минимизировать конфликты с другими классами “файл”, в дальнейшем будем опускать это пространство имён. Выдвинем основное требование к данному классу – облегчить, насколько возможно, жизнь разработчикам-пользователям данного класса.

Первое, что мы можем потребовать от класса – это взять на себя скучную работу по закрытию описателя объекта ядра. Всё, что нам понадобится – это пара функций: конструктор-деструктор.

 
// пространство имён опущено
class CFile
{
public:
    explicit CFile(HANDLE h);
    ~CFile();
    operator HANDLE() const;
private:
    CFile(const CFile&) throw();
    CFile& operator=(const CFile&) throw();
private:
    HANDLE m_h;
};

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

CFile::operator HANDLE()

Выше я немного слукавил. Сказав, что нам понадобится лишь пара функций – конструктор и деструктор, я, на самом деле, описал в классе 5 методов. Закрытые конструктор копирования [copy constructor] и оператор присваивания [assignment operator] мы ещё обсудим. Начнём же мы, пожалуй, с метода CFile::operator HANDLE().

Поскольку в классе не определено ни одной функции, через которую можно оперировать с описателем, нам понадобился метод CFile::operator HANDLE(). Метод позволит нам свободно передавать объект CFile в функции, ожидающие описатель. Также это позволит расширять класс постепенно, без необходимости реализовывать все аналоги функций API в момент создания класса.

С функцией CFile::operator HANDLE() дело обстоит проще всего. Имея приведённое выше описание класса, можно предположить, что функция не должна генерировать исключение.

 
inline
CFile::operator HANDLE() const throw()
{
    return m_h;
}

И это действительно так, поскольку единственное место, где m_h может быть присвоено недействительное значение – это конструктор класса. И потому выглядит разумно, что именно этот метод (конструктор) должен нести ответственность за то, чтобы генерировать исключение (если будет выбран этот путь распространения ошибок).

Либо, давая более развёрнутое пояснение, предположим, что в конструктор класса было передано недействительное значение описателя ядра. В этом случае конструктор может как возбудить исключительную ситуацию, так и инициализировать член класса m_h недействительным значением. Но какой бы из вариантов ни был выбран при реализации конструктора, это не должно повлиять на реализацию метода CFile::operator HANDLE() и вот почему:

Таким образом метод CFile::operator HANDLE() может быть написан так, как если бы приватный член m_h был проинициализирован должным образом.

CFile::~CFile()

Перейдём к рассмотрению деструктора. Наверное, не ошибусь, сказав, что нас приучили не инициировать исключение в деструкторе и с подозрением смотреть на классы, практикующие данный подход.

Деструктор класс CFile, не генерирующий искючений, мог бы выглядеть следующим образом:

 
#ifdef _DEBUG
inline
BOOL Verify(BOOL b) throw()
{
    if( !b )
    {
        DWORD nErr = ::GetLastError( ); nErr;
        ::DebugBreak( );
    }
    return b;
}
#else
inline
BOOL Verify(BOOL b) throw() { return b; }
#endif // _DEBUG
 
inline
CFile::~CFile() throw()
{
    Verify( ::CloseHandle( m_h ) );
}

Тем не менее, мы отвлечёмся на время от общей рекомендации не генерировать исключение в теле деструктора и внимательно рассмотрим причины, по которым не стоит этого делать.

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

Причина первая – в конструктор CFile был передан недействительный описатель. В этом случае нам необходимо повторить ту же цепь рассуждений, что мы провели для метода CFile::operator HANDLE() и прийти к выводу, что если исключение и должно возникнуть, то в конструкторе CFile:CFile, но никак не в деструкторе CFile::~CFile.

Причина вторая. Объект CFile был создан с использованием действительного описателя, но ::CloseHandle, тем не менее, вернул ошибку (например, по причине нарушения прав доступа). В этом случае следует руководствоваться следующим практическим соображением – выполнение кода деструктора означает, что переменная покидает область видимости, и в большинстве случаев не имеет значения, успешно или неуспешно завершился вызов ::CloseHandle. Безусловно, нельзя полагаться на то, что всех разработчиков устроит подобное поведение (о тех, кому важны результаты закрытия описателя мы поговорим ниже). Нельзя, также, рассчитывать на то, что код, который будет исполняться в случае ошибки в отладочной версии приложения, исправит ситуацию.

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

 
inline
CFile::~CFile() throw(CFileError)
{
    if( Verify( ::CloseHandle( m_h ) ) )
        return;
    if( std::uncaught_exception( ) )
        return;
    const DWORD nErr = ::GetLastError( );
    throw CFileError( nErr );
}

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

Проверка результата вызова std::uncaught_exception() необходима: она защищает код от попытки вызвать повторную генерацию исключения в процессе раскрутки стека, когда исключение уже существует. Если же позволить повторную генерацию, это будет считаться ошибкой механизма обработки исключений (ISO/IEC 14882:2003 раздел 15.5.1) и, по умолчанию, будет вызвана функция std::terminate(), которая, в свою очередь, по умолчанию, вызовет std::abort().

Нельзя назвать это и самым изящным способом оповещения об ошибке. Корень неоднозначности кроется в том, что в общем случае невозможно определить, можно ли проигнорировать одно исключение ради обработки другого. Именно поэтому стандарт настоятельно не рекомендует генерировать исключения в деструкторе объекта (ISO/IEC 14882:2003 раздел 15.2.3).

Таким образом, можно утверждать, что отсутствует основная предпосылка для использования исключения в деструкторе – повышение надёжности кода путём своевременного оповещения об ошибке. Или, другими словами, поскольку существует ситуация, при возникновении которой ошибка не может быть донесена до пользователя, постольку необходим другой, надёжный способ донести ошибку.

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

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

CFile::CFile(HANDLE h)

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

Рассматривая конструктор, невозможно сослаться на то, что обработка ошибки должна вестись где-то в другом месте (как в случае с CFile::operator HANDLE()). Также нельзя привести пример неоднозначного, или вводящего в заблуждение кода (как в случае с деструктором).

Таким образом мы стоим перед выбором:

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

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

Плюсом первого подхода видится единственный пункт:

try
{
    CFile file( ::CreateFile( /*...*/ ) );
}
catch(const CFileError& e)
{
}

Плюсов у второго подхода, как видится, больше:

Следующий пример поможет проиллюстрировать проблему, описанную в двух последних пунктах.

bool CMyClass::Foo()
{
    HANDLE h = ::CreateFile( /*...*/ );        // #1 CFile file( ::CreateFile )
 
    ToDoSomethingUnrelatedWithCreatedFile( );  // #2, эта строка
                                               // выполняется всегда
    if( INVALID_HANDLE_VALUE == h )
        return false;
    bool bRet = ToDoSomethingWithCreatedFile( h );
    ::CloseHandle( h );
    return bRet;
}

Предположим, что в приведённом выше коде мы заменили вызов функции ::CreateFile() (строка #1) созданием объекта типа CFile, который генерирует исключение в конструкторе.

В этому случае, функция CMyClass::ToDoSomethingUnrelatedWithCreatedFile() (строка #2) будет вызвана лишь в случае успешного открытия файла, что, в свою очередь, может неявным образом изменить результат действия функции CMyClass::Foo(). Данный код, безусловно, является результатом небрежного программирования, но, к сожалению, в “смешанном” коде могут встречаться подобные примеры.

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

Подведём итог. Плюсы второго подхода можно кратко сформулировать следующим образом – класс не навязывает обработку исключений. Подобное поведение хорошо согласуется с тем, что класс представляется ничем иным, как объектной заменой обычному описателю. Объект CFile может использоваться в любом месте, где может использоваться HANDLE, попутно предоставляя удобный сервис, которым славится объектный подход. И потому окончательный выбор будет сделан в пользу версии, не генерирующей исключений – класс CFile будет содержать конструктор CFile::CFile(HANDLE h) с пустой спецификацией throw().

CFile::CFile(const CFile&) и CFile& CFile::operator =(const &)

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

Оба метода объявлены как закрытые и с пустой спецификацией throw(). Таким образом, мы подразумеваем, что:

Подобное объявление сделано по одной причине – у данных функций отсутствует реализация, поэтому они не могут быть вызваны, и, следовательно, они не могут инициировать исключение. А реализация, в свою очередь, у них отсутствует, потому что мы хотим избавиться от вопроса о том, что должно происходить при копировании объекта типа CFile. Данный вопрос не представляется тривиальным – как разработчики класса мы могли бы использовать любую из перечисленных ниже возможностей:

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

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

Если подвести итог, то определение класса теперь выглядит следующим образом (все функции объявлены с пустой спецификацией throw()).

 
class CFile
{
public:
    explicit CFile(HANDLE h) throw();
    ~CFile() throw();
    operator HANDLE() const throw();
private:
    CFile(const CFile&) throw();
    CFile& operator =(const CFile&) throw();
private:
    HANDLE m_h;
};

Семейство классов

Конкретную задачу закрытия описателя можно решить гораздо более простым и элегантным способом – определив шаблонный класс, единственная задача которого – вызвать определённую функцию в своём деструкторе. Создание выделенного класса для объекта ядра может быть оправдано лишь в том случае, если класс предоставляет дополнительный сервис по сравнению с сервисом, что предоставляет пара “описатель и шаблон, закрывающий описатель”.

Потому, если речь идёт о промышленном применении, то данная реализация выглядит несколько наивно. Очевидно, что она определяет политику распространения ошибок ключевыми функциями класса внутри реализации данного класса. Как только возникнет необходимость определить класс, обладающей подобной семантикой для другого объекта ядра, нам понадобится повторить всю цепь рассуждений. Или воспользоваться распространённым инструментом разработчиков – механизмом “copy-paste”. По-видимому, наиболее перспективным решением для долгосрочных проектов было бы решение, параметризующее политику распространения исключений (в статье мы данное решение рассматривать не будем).

CFile::Create(/*…*/)

Заговорив о дополнительных сервисах, давайте оценим, как добавление новой функциональности повлияет на существующую стратегию распространения ошибок. Также интересно понаблюдать за тем, какие изменения придётся вносить в уже описанные функции.

Для начала, для уменьшения количества кода, необходимого для открытия файла, добавим в класс функцию CFile::Create().

 
class CFile
{
public:
    // новые методы
    CFile() throw();
    HANDLE Create(LPCTSTR lpFileName,
        DWORD dwDesiredAccess,
        DWORD dwShareMode,
        LPSECURITY_ATTRIBUTES lpSecurityAttributes = 0,
        DWORD dwCreationDisposition = CREATE_ALWAYS,
        DWORD dwFlagsAndAttributes = FILE_ATTRIBUTE_NORMAL,
        HANDLE hTemplateFile = 0) throw();
    // объявления “старых” методов остались без изменений
};
 
inline
CFile::CFile() throw() : m_h( INVALID_HANDLE_VALUE ) {}
 
inline
HANDLE CFile::Create(LPCTSTR lpFileName,
                     DWORD dwDesiredAccess,
                     DWORD dwShareMode,
                     LPSECURITY_ATTRIBUTES lpSecurityAttributes/* = 0*/,
                     DWORD dwCreationDisposition/* = CREATE_ALWAYS*/,
                     DWORD dwFlagsAndAttributes/* = FILE_ATTRIBUTE_NORMAL*/,
                     HANDLE hTemplateFile/* = 0*/) throw()
{
    assert( INVALID_HANDLE_VALUE == m_h );
    return m_h = ::CreateFile( lpFileName, dwDesiredAccess, dwShareMode,
        lpSecurityAttributes, dwCreationDisposition, dwFlagsAndAttributes,
        hTemplateFile );
}

Заметим, что добавление функции CFile::Create() заставляет нас добавить конструктор CFile::CFile() (к которому мы ещё вернёмся).

Из приведённого выше описания видно, что CFile::Create() объявлена с пустой спецификацией throw(). Обсудим это решение. Фактически, выбор в пользу распространения ошибок традиционным способом для всех функций класса был уже сделан при обсуждении конструктора. Описав функцию CFile::Create() как генерирующую исключение, мы оставили бы пользователя с несогласованным описанием класса:

 
HANDLE h = ::CreateFile( “file1.dat”, /*...*/ );
CFile file1( h );                                 // CFile::CFile(HANDLE h)
                                                  // не генерирует исключений
CFile file2;
File2.Create( “file2.dat”, /*...*/ );             // предположим, что
                                                  // CFile::Create()
                                                  // может инициировать
                                                  // исключительную ситуацию

В данном случае семантически эквивалентный код даёт разный результат и демонстрирует указанную неоднозначность. Предположив, что приведённый выше код присутствует в одной функции, будет трудно обосновать перед конечным пользователем класса разницу в поведении.

CFile::CFile()

Как было отмечено выше, добавление функции CFile::Create() приводит к необходимости описать конструктор по умолчанию [default constructor]. Это, в свою очередь, приводит к тому, что приватный член класса получает инициализирующее значение, которое остальные функции могли и не ожидать. В общем случае, добавление (или изменение) инициализирующего значения приватного члена приводит к пересмотру и, возможно, модификации всех функций, использующих этот член класса. В данном случае, член m_h инициализируется значением INVALID_HANDLE_VALUE, что необходимо приводит к изменению реализации деструктора. После модификации он должен выглядеть примерно так:

 
CFile::~CFile() throw()
{
    if( INVALID_HANDLE_VALUE == m_h )
        return;
    Verify( ::CloseHandle( m_h ) );
}

До введения конструктора умолчания предполагалось, что приватный член m_h не может получить значения INVALID_HANDLE_VALUE иначе, как по невнимательности пользователя класса. Теперь же это значение становится разрешённым в контексте объявления конструктора по умолчанию. Более тщательный, можно даже сказать “маниакальный”, подход подразумевает добавление ещё одного члена класса, который указывал бы на то, был ли член m_h инициализирован в результате вызова конструктора по умолчанию, либо был изменён внутри какой-либо другой функции. Это дало бы нам возможность в деструкторе провести различие между разрушением переменной, созданной конструктором по умолчанию, и неверно инициализированной переменной (имеющей то же значение INVALID_HANDLE_VALUE).

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

Можно заметить, что после добавления конструктора по умолчанию, нет необходимости модифицировать функцию CFile::operator HANDLE(). Причины здесь те же, что приводились и раньше при обсуждении этой функции.

CFile::Close()

Вернёмся к нуждам тех, кому необходимо знать о неуспешном закрытии описателя объекта ядра “файл”. Для них необходимо ввести явную операцию, закрывающую описатель. И класс теперь будет выглядеть так (код деструктора продублирован для сравнения).

 
class CFile
{
public:
    // новый метод
    BOOL Close() throw();
    // объявления “старых” методов остались без изменений
};
 
CFile::~CFile() throw()
{
    if( INVALID_HANDLE_VALUE == m_h )
        return;
    Verify( ::CloseHandle( m_h ) );
}
 
BOOL CFile::Close() throw()
{
    // #1
    // if( INVALID_HANDLE_VALUE == m_h )
    //     return true;
    assert( INVALID_HANDLE_VALUE != m_h );
    BOOL bRes = ::CloseHandle( m_h );
    Verify( bRes );
    if( bRes )
        m_h = INVALID_HANDLE_VALUE;
    return bRes;
}

Обратите внимание, что следует противостоять искушению объединить “общий” код в деструкторе и в функции CFile::Close. Задача деструктора – попытаться закрыть описатель и позволить дальнейшее исполнение. Задача явного вызова CFile::Close – закрыть описатель и сигнализировать об ошибке, если закрытие прошло неуспешно. Отсутствие проверки на допустимость описателя при входе в функцию CFile::Close() – отнюдь не оплошность. Разработчик, который не поленился и пожелал явно закрыть файл, либо занимался оптимизацией (освобождение ресурса до выхода из области видимости), либо для него важен результат закрытия. В этом смысле не должно быть никакой разницы между вызовом CFile::Close() и непосредственным вызовом ::CloseHandle().

Если бы мы проверяли значение описателя при входе в функцию CFile::Close() (раскомментировав две сточки, ниже #1), пользователь мог бы наблюдать разницу в побочных эффектах. А именно, вызов CFile::Close(), для неинициализированного объекта, не модифицировал бы значение, которое возвращает ::GetLastError(), а вызов ::CloseHandle() с тем же неинициализированным объектом в качестве параметра заносил бы в thread local storage (TLS) значение 6 (The handle is invalid).

Общие замечания

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

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

Общая “проблема” подобных библиотек-обёрток состоит в том, что в подавляющем количестве случаев, они будут служить чисто утилитарной цели – уменьшение объёма кода в одной конкретной функции (классе, компоненте). И у библиотеки будет гораздо больше шансов быть повторно используемой, если пользователю не придётся изучать её структуру и сопоставлять поведение библиотеки с поведением “чистых” функций API. Генерация исключения и, соответственно, его перехват, могут рассматриваться как попытка навязать дополнительную и, возможно, ненужную пользователю работу.

Продолжение…

Вступление

В рамках любого проекта особняком стоит управление конфигурацией продукта (Software Configuration Management, SCM). С одной стороны, такое управление есть, с другой стороны, немалая часть разработчиков не выделяет его как отдельную «дисциплину». Иными словами, управление незримо присутствует и в то же время не существует. Между тем, практики SCM используются повсеместно. Иногда сообща, иногда разрозненно, но – используются. Присутствует ли SCM в вашем проекте? Попробуем предотвратить метания на тему «да или нет» и перечислим основные направления деятельности под общим названием «Управление конфигурацией продукта». К этому списку мы будем возвращаться на протяжении всей статьи.

Знакомые слова, не правда ли? Пусть вас не вводит в заблуждение слово «продукт». Продукт – это не только дистрибутив, за который компания-разработчик получит деньги. Это любой артефакт, создаваемый командой на всём протяжении жизненного цикла продукта. Файл с исходниками, документ со спецификацией требований, тесты, бинарники для установки у клиента – всё это продукты. А под конфигурацией понимается набор версий, то есть, “срез” состояния всего продукта.

В общем и целом, главное назначение SCM – это управление изменениями, поступающими в проект, забота о качестве приложений. При чём здесь качество? Если перечисленные функции свести воедино, то образуется «подложка», фундамент, лежащий под всеми видами деятельности проекта. Соответственно, если он будет непрочным, здание проекта рухнет. Хорошо, если фундамент просядет где-нибудь в начале строительства, когда мы не приступали к возведению стен. А если мы уже людей туда заселяем? Вот и получается, что обеспечить качество продукта без продуманной организации техпроцесса не получится.

Выбор инструмента

Как и в любом процессе, здесь важны две равновеликие составляющие – методики работы и инструменты для поддержки этих методик. Одно без другого не имеет смысла.

Скажем, многие разработчики стоят перед выбором: «Какую систему контроля версий использовать – git или Mercurial?» При детальном рассмотрении выясняется, что речь идёт о команде, в которой распределённая модель работы просто не нужна. К примеру, условия работы с кодом диктуют постоянную синхронизацию результатов работы между всей командой. Или же команда продолжает покупать лицензии на Perforce, хотя его использование выродилось в линейное складирование версий, без ветвления.

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

В общем, выбор порой надуман, особенно на первых этапах работы. Однако чаще всего бывает обратная ситуация – внедрение методик и инструментов просто не поспевает за потребностями.

При выборе инструментов и политик, а также правильного времени их внедрения, уместна аналогия с кессонной болезнью – эффектом, который возникает при слишком быстром подъеме на поверхность с большой глубины. Из-за быстрой смены давления из крови и тканей ныряльщика начинают выделяться мелкие пузырьки газов, обычно в них растворённых. Это приводит к серьезным последствиям для всего организма. То есть, всплыть получится, однако человек рискует просто погибнуть. Известны только два решения – постепенный многочасовой подъем или быстрый подъём с последующей акклиматизацией на поверхности, но уже в барокамере. Поскольку обычные проекты не избалованы бюджетом для покупки “барокамер”, будем рассматривать только первый рецепт.

Предположим, некоторый проект с серверной и клиентской частями начинается «на коленке», в глубине гаража или квартиры основателя проекта. Выбираются простые инструменты: багтрекером (bug tracker) служит лист в Excel, контроль версий реализован в традиционном Subversion, сборка проекта идёт простым нажатием кнопки в любимой среде разработки, а дистрибутив выдается в виде архива или заливается на сервер по FTP. Проходит время, проект зреет, появляются новые люди. Листик в Excel ещё удается расшарить по сетке, SVN (Subversion) пока хорошо справляется с коммитами (commit) в транк (trunk, по умолчанию – главная ветка в Subversion), ветки пока не нужны. Поскольку продукт теперь собирается под 2-3 разные операционные системы (клиентура растёт), приходится использовать пару разных сред разработки и на каждой новой машине тратить немало времени на настройку всех библиотек. Да и сама компиляция и линковка теперь – задача непростая, каждый раз вылазят специфичные для среды ошибки. При наличии нескольких человек трудно понять, кто и когда залил на сервер новый релиз и кто готовит инсталляционный пакет для клиентов. Проблемы пока решаются, ибо команда всё ещё невелика, и все находятся рядом. Однако давление уже изменяется: проект “всплывает”, последствия начального выбора процессов и инструментов скоро начнут «пузыриться».

Первый пузырёк появляется в системах контроля версий и багтрекинга. Всё чаще люди начинают непродуктивно тратить время на коммит новой версии на транк – ведь приходится по 2-3 раза делать update перед очередным коммитом. Классическая ситуация: три человека меняют один файл, первый делает commit, второй и третий, прежде чем сделать то же самое, вынуждены делать update. Далее кто-то из них двоих делает свой коммит, в результате чего третий вынужден опять упражняться в слиянии (merge) исходников. Начинается использование веток: сначала робко, для больших подсистем, потом всё чаще. При этом кто-то продолжает скидывать дельту (изменения в рабочем продукте) прямо в транк – ведь единой договорённости об использовании веток пока нет. Всё чаще возникают конфликты слияния, потеря дельты – сказывается разница в подходах между участниками команды. Всё больше ошибок при компиляции и тестировании появляется из-за несогласованности внесения изменений – слабо контролировалось вхождение новой дельты (новой функциональности или багфиксов). Листик Excel разросся, стало сложно управлять поступающими запросами, уже непонятно, кто за какие изменения отвечает. К примеру, кто-то решил вместе с очередным багфиксом сделать рефакторинг и «размазать» его на 4 последовательных коммита. Разумеется, это переплелось с плановыми изменениями – в итоге билд поломан, пытаемся выяснить, на каком основании что было сделано. Иными словами, “пузырёк” появляется там, где происходит наибольшая активность, а стало быть – наибольший перепад давлений.

Следующий пузырь появляется при сборке проекта и работе с настройками среды. Разные среды, компиляторы, настройки окружения – всё чаще появляются специфичные ошибки компиляции и линковки. Да тут ещё и одна из сторонних библиотек поменялась – всем разработчикам нужно ее установить и проверить на совместимость с их модулями. При этом текущая стабильная версия системы (она стоит у заказчика), использующая предыдущую версию библиотеки, требует сопровождения. А значит, приходится её переустанавливать и менять ключи компиляции каждый раз, когда делаются багфиксы. А если учесть, что теперь клиенту, работающую под Windows, надо устанавливать новую dll и регистрировать дополнительный COM-объект, становится понятен нервный смех того, кто делает инсталляционные пакеты. И вот уже очередной перепад давлений – политики и инструменты для сборки проекта и управления рабочей средой просто не справляются. Под словом “политика” (policy) в этом контексте обычно понимают свод договорённостей, правил и используемых практик, которые принимаются всей командой.

Худо-бедно, учась на своих ошибках, сменили часть инструментария (в первую очередь, систему отслеживания запросов), договорились о правильном взаимодействии при работе с ветками, написали скрипты для запуска отстройки, начали использовать CMake для поддержания кроссплатформенности. Но продукт не стоит на месте, он растёт, а значит продолжает увеличиваться перепад давлений. Вот уже к работе подключилась удаленная команда тестировщиков. Возникла необходимость разделения прав в системе отслеживания ошибок, нужны новые способы быстрой настройки рабочего окружения, надо куда-то и в каком-то порядке выкладывать релизы для прогона тестов разной интенсивности и глубины. И снова “пузыри”…

В нашем примере очень показательно и естественно добавление удаленной команды разработчиков. Это большое испытание для всего проекта, не говоря уже о его SCM-инфраструктуре. Надо решить вопрос распределенной работы с исходниками, понять кто, где и в какой момент интегрирует изменения, выпускает очередной релиз, куда его положить, как отдать на тесты и получить их результаты для дальнейшего закрытия «тикетов». В общем, очередной “подъём наверх” ставит всё новые задачи с точки зрения организации инфраструктуры. И редко кто бывает к ним заранее готов – всё меняется под нужны момента и редко кто заранее планирует все изменения.

Однако, предугадать это безобразие вполне возможно. Главное – нужно понимать, что все используемые инструменты и практики между собой увязаны, хотя и ортогональны друг другу. Всё как в физике – есть векторы сил, которые действуют в разных направлениях и с разной величиной, однако при сложении получается конкретный вектор, который направлен вперёд. Напомним, что есть 6 основных направлений работы (рассмотрены выше), с которыми совершенно точно предстоит столкнуться. Предупреждён – значит вооружён.

Нельзя отвергать и использование “барокамеры”, а именно – единовременных вложений ресурсов и времени на улучшение инфраструктуры. В этом случае команда целенаправленно вкладывается в то, чтобы улучшить свою работу. На это требуются деньги, однако результат можно получить относительно безболезненно и, если постараться, то быстро. Поэтому можно считать подобное решение альтернативой “постепенному подъёму”.

На что ориентироваться при выборе инструмента? Итак, начался проект. Первое, с чем придётся столкнуться ещё до начала написания кода – запросы на изменения. Это пункт 1 в списке, рассмотренном в начале статьи. Даже когда единственным рабочим продуктом будет спецификация требований, её разработчикам уже нужен инструмент для отслеживания всего того, что происходит с требованиями, какие правки в них вносятся и зачем. Что уж говорить об исходном коде. Отслеживать изменения нужно научиться сразу – и научиться делать это качественно. Так что не экономим ресурсы, а постоянно оцениваем: хватает ли нам системы трекинга изменений и хватит ли на ближайшие пару месяцев.

Тут возникает проблема выбора, ведь система bug- или task-трекинга – это один из любимейших велосипедов программистов. За такие системы берутся многие, при этом доводят до презентабельного вида – сотни, и наибольшей популярностью пользуются десятки систем – от простых todo lists с галочками до сложных и безумно больших и гибких систем управления проектами. К слову сказать, разделение между bug-, task- и issue-tracking достаточно условно, однако task-трекеры ориентированы на более широкую аудиторию, не только разработчиков. Здесь очень велик риск внедрить одно, а через несколько месяцев захотеть уже сильно другое. Поэтому надо или быть заранее готовым сменить через год-два систему трекинга, или каким-то образом предвидеть направление роста команды и выбрать именно то, что не помешает маленькой команде и поможет – команде большой.

Не стоит забывать и о политиках использования. Ведь можно бесконтрольно плодить и закрывать запросы на изменения, а можно создать рабочую группу (change control board, группа контроля за изменениями), которая будет вести работу по приоритезации и отслеживанию выполнения этих запросов.

На данный момент мои фавориты – Redmine, eTraxis, Basecamp – каждый для своих классов задач. Basecamp, по сути, это сильно расширенный todo list. eTraxis – гибкая система трекинга чего угодно. В нём открытый код, и я, участвуя в его внедрении на крупном проекте, даже написал несколько улучшений и исправлений кода. Вообще, очень гибкая штука – горячо рекомендую. Ну а на Redmine смотрите, если нужна целая система управления проектами – для этих глобальных целей он хорошо подходит.

Следующий по значимости класс систем – контроль версий. Это пункт 2 в нашем списке SCM-задач. Такая система также выбирается в самом начале, поскольку рабочие продукты начинают появляться практически с первого дня работы. Тут ситуация отличается от систем трекинга. С одной стороны, инструментов не так много. Из бесплатных (open source) систем лидируют Subversion (SVN), git, Mercurial, среди платных – MS TFS, Perforce, IBM Rational ClearCase (и его потомки). Небольшой выбор компенсируется тем, что этими инструментами можно пользоваться по-разному. Можно использовать один и тот же SVN годами, однако в начале проекта работать только на транке, а уже через год вырастить увесистое дерево веток и меток. Так что с этим классом инструментов просто необходимо периодически пересматривать политики и практики их использования. При этом ничто не является догмой – вы можете сейчас активно ветвиться, а потом постепенно перейти к системе непрерывной интеграции (continuous integration), исповедующей частую интеграцию на транке. К примеру, немало копий, поломано при обсуждении того, как надо ветвиться (и надо ли вообще). Или священная война последних 3-4 лет – какие системы лучше, централизованные или распределенные. Что тут сказать, надо исходить из потребностей. Моя слабость – это IBM Rational ClearCase, но только не UCM, а его базовый функционал. Мощнейшая штука, несправедливо загубленная маркетологами IBM. Кстати, не так давно появился неплохой продукт PlasticSCM, одновременно имеющий распределённую природу и частично использующий идеологию ClearCase. С интересом слежу за его развитием.

Следующую немаловажную нишу занимают системы поддержки построения продуктов – это третий пункт нашего “хит-парада”. Ниша эта небольшая, однако без неё многие проекты немыслимы. Сюда входят как системы для описания кроссплатформенной компиляции и линковки (CMake), так и системы полного цикла сборки (Maven, ant). Общая цель – сделать построение продукта как можно более прозрачным. Зачастую такие системы специфичны для конкретного языка или технологии, а их выбор приходится на более поздние этапы развития проекта. Чаще всего их начинают внедрять когда ресурсы ручной сборки уже выработаны. Однако правильные архитекторы и СМ-инженеры думают о них уже в самом начале проекта :)

Это же описание справедливо и для систем управления рабочим окружением, выпуском и развертыванием продуктов. В нашем списке они выделены под пунктами 4, 5 и 6, однако потребность в них возникает практически в одно и то же время. Зачастую продукт сильно эволюционирует до того как доходит очередь до этого класса систем. Это правильно – только реальные потребности покажут, что и когда надо внедрять для подобных задач. Мало научиться строить продукт – надо его правильно выдать пользователям (в том числе, тестировщикам), убедиться, что при использовании или тестировании будет всё настроено так, как задумывалось разработчиком, и нам не будут лететь сообщения об одних и тех же ошибках каждый раз после выхода нового релиза. Подобные инструменты эволюционируют обособленно и, как правило, по времени ближе к середине проекта, когда есть уже что показать тестировщикам. Обычно же начинают с того, что просто выкладывают бинарники в расшаренную папку в сети, приложив release notes, где описано, какие изменения внесены и как настраивать окружение. Тем и ограничиваются долгое время.

Несколько слов о литературе по SCM. Книг на русском языке практически нет. Есть масса онлайн-материалов по конкретным инструментам, много HowTo, руководств, но не книг. Обзор имеющейся литературы можно найти здесь.

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

Типичные ошибки и заблуждения

Первая типичная ошибка – не использовать контроль версий. Лечится быстро, но болезненно. Без контроля живут до первой ошибки, которую не смогли поправить откатом к предыдущей работающей версии системы. Никакие бэкапы не сравнятся с системой контроля версий.

Аналогичная ситуация – отслеживание запросов на изменение. Кто-то ограничивается перепиской по email, и долгое время тем и счаслив. Лечится не очень быстро. Скачок происходит, когда количество обозримых задач и контроль за их исполнением просто не умещается в голове, а поиск по почте мало помогает. Вот тогда и начинаются поиски подходящей системы. Впрочем, тут появляется другая ошибка – как я уже писал, начинают писать что-то своё, тогда как готового – просто навалом. Но тут уж трудно кого-то в чём-то убедить.

Ещё одно заблуждение (скорее, позиция в священной войне), состоит в том, что распределённая модель может полностью заменить модель централизованную. Рискую навлечь на себя гнев апологетов git и Mercurial, однако считаю, что это далеко не так. Будучи активистом антиброуновского движения :), полагаю, что централизованная модель может и даже должна использоваться в проектах, имеющих жёсткую иерархию работы с изменениями. Перед глазами собственный пример. Я имел удовольствие работать в крупном проекте, распределённом между странами и часовыми поясами. У нас, бывало, проходила не одна неделя, прежде чем изменения попадали от разработчика в продукт, отгруженный “наружу”. При этом участники команды должны были иметь возможность смотреть изменения от любого разработчика вне зависимости от его местонахождения, времени суток и доступности его копии изменений. У нас использовался ClearCase с надстройкой Multisite, позволявшей централизованным хранилищам в локальных командах реплицировать между собой все нужные изменения. Таким образом я, находясь в России или США, мог видеть код, написанный в Индии или Италии – он становился доступным в течение получаса (максимум). С децентрализованной моделью это было бы трудно.

К заблуждениям отнесу и уже упоминавшийся отказ от использования веток. Я не имею виду непрерывную интеграцию, которая принципиально строится на использовании единой ветки для разработки – есть аргументы как “за”, так и “против” этого метода. Речь идет о непонимании механизма работы. Кто-то считает, что наличие веток отнимает кучу дискового пространства – это неверно, так как внутреннее представление большинства систем достаточно оптимально и там, как правило, хранятся только изменения, но никак не полная копия исходников для каждой ветки. Кого-то пугает процесс слияния изменений после окончания работы на ветке. Страх этот идёт отчасти из-за того, что в самой популярной на сегодняшней день системе контроля версий – Subversion – ветвление и слияние действительно сделаны… скажем так, не совсем хорошо :) В других системах это делается значительно проще, так что страхи пора забывать.

Кстати, встречал упоминания о том, что кто-то просто удаляет ветки после того, как дельта использована для интеграции, и ветка уже не нужна. Объясняется это какими-то полурелигиозными сображениями вида “она будет мешать” или “она же занимает место”. Система контроля версий изначально создана для того, чтобы хранить все версии, сколько бы их не было – под это ветки “заточены”. Нередки случаи, когда вернуться к старым изменениям приходится и через пару месяцев. Если база разрастается совсем уж до неприличия и тормозит всю работу, можно слить старые изменения в архив, но ни в коем случае их не удалять.

Нельзя не сказать и о метках – незаслуженно мало используемой возможности систем контроля версий. Метки позволяют работать с именованными версиями. Например, интегратор проекта слил воедино все изменения пары команд, которые параллельно работали над изменениями, получил тот срез, который можно считать стабильным. Он вешает на него метку, и теперь любой участник команды может взять этот срез путём извлечения одной-единственной метки. Чем это отличается от обычного номера ревизии? Тем, что метку могут “перевесить”, если вдруг выяснится, что произошел сбой и стабильной считается уже другая ревизия. Кроме того, не во всех системах контроля есть наборы изменений (changesets), и для них метки – это единственный способ каким-либо образом идентифицировать конфигурацию без перечисления всех версий всех элементов. В общем и целом, метки – полезная штука, от которой не надо отказываться.

Будущее SCM

Судя по англоязычным публикациям, будущее за системами класса Application Lifecycle Management (ALM). Это инструменты, соединяющие в себе функции контроля версий, поддержки билда, и, самое главное, сбора требований, отслеживания запросов на изменения, поддержки тестирования и оценки его результатов. Этакие швейцарские ножи. Уже сейчас существует некоторое количество таких продуктов. К примеру, Microsoft Team Foundation Server (MS TFS) – думаю, он в представлениях не нуждается. Чуть менее известно семейство IBM Rational Team Concert, в частности IBM Rational Jazz. Судя по описаниям и отзывам, команда IBM критически перетрясла разработки прошлых лет и оставила самое лучшее. Также на слуху AccuRev и Neuma.

Заметьте, все решения платные. Единственная альтернатива, которая приходит в голову – это сборка воедино бесплатных решений с открытым кодом. Многие системы багтрекинга имеют возможность интеграции с системами контроля версий. В общем, есть все предпосылки для объединения, однако, как правило, дальше объединения трекеров и контроля версий дело не заходит. Полные интегрированные системы если и существуют, то, как правило, это результат работы отдельных компаний или коллективов: и дальше внутреннего использования они не выходят. Думаю, здесь мы ещё увидим немало интересного.

Максим, сможете ли вы выделить факторы, которые влияют на успех/провал разработки и внедрения любого продукта (вне зависимости от его предметной области)?

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

Помимо рисков огромное влияние оказывает мотивация участников процесса. В случае отдельной незаинтересованности (неважно с чьей стороны – заказчика или исполнителя) велика вероятность краха проекта.

Каким образом методология работы позволяет учитывать риски?

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

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

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

Что нужно учесть с момента первого разговора с заказчиком (внешним или внутренним) и до выхода продукта в свет?

Ну, первый разговор – самый главный, на нем обе стороны определяют, смогут ли они сотрудничать или лучше не надо. Очень много проектов провалилось только потому, что заказчику не понравился исполнитель или наоборот, но решили все-таки попробовать. Если на первой, второй и последующих встречах есть хоть единое сомнение в надежности делового партнера, такие сомнения лучше разрешить в ближайшее время, желательно – в тот же миг. Потом это, как правило, обходится много дороже.

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

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

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

Как происходит разработка приложения после того как техзадание согласовано с заказчиком? Пишите ли вы псевдокод, создаете ли прототипы или сразу же приступаете к реализации «боевой» системы?

Это обычно зависит от количества имеющихся наработок и/или готовых решений, которые применяются в проекте. Если количество разработки незначительно относительно настройки уже имеющегося кода, можно сразу в бой. Если же система требует значительных усилий по разработке, пишется «с нуля» или в дальнейшем может серьезно видоизмениться, то первым этапом обязательно будет продумывание архитектуры, затем прототипирование (отдельно – пользовательского интерфейса, отдельно – программных механизмов), затем можно приступать к реализации.

В разрезе создания большой системы: какой стиль разработки – нисходящий или восходящий – вы предпочитаете и почему?

Для любой большой системы интуитивно кажется, что нисходящий стиль лучше и правильнее. Однако в реальной жизни идеализация очень часто наступает на «надо завтра что-то показать и это не диаграмма классов». Поэтому очень часто приходится комбинировать, например, реализацию интерфейса пользователя с продумыванием архитектуры всего проекта. Сказать, что это плохо, однозначно нельзя – полученные отзывы по интерфейсу могут внести коррективы и в архитектуру, и в последовательность взаимодействия элементов.

Тут надо упомянуть, что разные языки по-разному способствуют тому или иному стилю. Например, в ОО-языках можно писать боевой код прямо сразу, рассчитывая потом распихать его по классам и произвести улучшения – допустим, вводя дополнительные абстракции. Функциональные и декларативные языки, на мой взгляд, предполагают, что разработка будет строиться в основном «сверху вниз».

Максим, какая из реализованных систем была наиболее интересной и технически сложной? Сможете ли вы описать ее жизненный путь с точки зрения выбора архитектуры и средств разработки?

Обычно при ответе на такой вопрос я подробно рассказываю о проекте создания системы управления театральными подъемами, но в данный момент, думаю, это не самый сложный проект. Хотя и не самый простой.

Но в этот раз, пожалуй, имеет смысл упомянуть более свежий проект – систему учета взаимодействия с клиентами в рамках одного из направлений деятельности компании, в которой я сейчас работаю. Проект создания CRM-системы (возможно, это слишком громкое название, но короче и точнее термина подобрать сложно) примечателен тем, что успешно работает и продолжает развиваться, при этом будучи выполненным в рамках абсолютно неправильного процесса: не было ни ТЗ, ни фиксированных сроков, ни фиксирования пожеланий и требований, ни долгих споров на тему того, как должна выглядеть грядущая победа над энтропией. Это давало мне, по сути, основному разработчику системы, простор для фантазии.

Изначально наша компания – это типичный представитель малого бизнеса, численность которого не превышает 40 человек. При этом по направлению, которое подлежало частичной автоматизации, работала примерно половина сотрудников компании. Процедура была формализована, пользователи предоставляли в организацию бланки-заявки, в которых описаны типовые действия, требуемые к выполнению в соответствии с договором. Заявка перемещалась между отделами, так же выполняющими вполне регламентные процедуры. Но одно дело, когда клиентов десять и поток заявок относительно небольшой. Совсем другое – когда клиентов за тысячу, а появление шквала заявок носит весьма нерегулярный, подчас лавинообразный характер. В этих случаях были нередки потери заявок, невыполнения обязательств, ошибки в работе и, как следствие, конфликты между сотрудниками. Поэтому возникла вполне очевидная необходимость в информационной системе, которая позволяла бы:

Изначально задача была поставлена в виде «нам нужна база по клиентам с отслеживанием сроков исполнения». Вооруженный ею, а так же кратким описанием процесса, я попытался продумать интерфейс системы. Поскольку единственное ограничение от внутреннего заказчика состояло в том, что система должна быть веб-приложением, доступным из любой точки с интернетом, в качестве инструмента был выбран комплект LAMP, в рамках которого у меня был большой опыт и неплохое количество наработок. Была еще идея реализовать все в рамках Google Apps, но этот вариант был отвергнут, поскольку я не знал Python, а мой коллега, хоть и знал, никогда не работал с Google Apps API. В свете этого разработка могла значительно затянуться, а нужно было, как всегда, «еще вчера». Поэтому выбор инструмента был определен, на вооружение взята типовая архитектура веб-приложения (которой я придерживался уже несколько лет при реализации подобного рода проектов), а я занялся проектированием пользовательского интерфейса.

Пользовательский интерфейс во всех приложениях является бичем разработчика. Как ни странно, но почти во всех встречающихся мне задачах (в т.ч. и в задаче с театральными подъемами), на интерфейс, его реализация и связанные с ним вещи занимали до 75-80% времени проекта. Поэтому при создании приложений необходимо уделять максимальное внимание простоте и удобству пользовательского интерфейса. Это в дальнейшем сократит как нервы пользователя, так и временные затраты разработчика. Предполагалось, что в системе будет веб-интерефейс, основанный на HTML4 совместно с применением библиотеки jQuery. В качестве шаблонизатора использовалась технология XSLT: бэкэнд генерировал XML с данными, на который затем одевался XSL-шаблон, который мог быть разным в зависимости от условий, например, предназначены ли данные для передачи на сторону клиента посредством AJAX или же, наоборот, должны быть отправлены на печать.

После проектирования интерфейса была спроектирована и реализована базовая структура БД, в которой предполагалось хранить основные сущности. Второстепенные были добавлены позднее. Как правило, это оказывались всякого рода справочники и шаблоны.

Затем в течение порядка трех-четырех месяцев был реализован основной функционал. Поначалу он представлял собой базу данных по клиентам и смежным сущностям плюс систему назначения и отслеживания задач. В таком виде система и была пущена в бой. Однако последующие два месяца эксплуатации выявили нежелание сотрудников работать в рамках системы. Основой по-прежнему оставались бумажные заявки, а конфликты продолжали возникать. В свете этого было решено модифицировать систему, приведя ее к более привычному для участников процесса виду – в CRM была встроена сущность «Заявки», каждое внесение которой порождало сверку с уже имеющимися данными по клиенту (для исключения операторских ошибок), а так же инициировало последовательное выполнение задач согласно бизнес-процессу со всеми вытекающими бонусами.

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

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

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

О, баги! :) Вообще с возрастом начинаешь замечать, что есть много различных типов багов.

Первый – синтаксический, когда программист ошибается в названии оператора или забывает поставить разделитель. Это неизбежное зло – программисту как оператору свойственно ошибаться при вводе текста, и тут обычно только незамыленный взгляд способен найти ошибку (ну и вменяемое сообщение о ней от компилятора/интерпретатора).

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

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

Первая история произошла как раз при внедрении системы управления театральными подъемами. По заданию требовалось, чтобы запуск двигателей подъемов контролировался не только сенсорным экраном, но и отдельными кнопками, вмонтированными в пульт, плюс присутствовала индикация в виде загорающегося светодиода над нажатой кнопкой. А это означало, что мне в процессе работы надо опрашивать дополнительный контроллер и посылать ему команды на индикацию. Собрали прототип, я протестировал программу – все работает. На следующий день время теста на конечном оборудовании. Включаем… и получаем цветомузыку – светодиоды горят произвольно – вне какой-либо зависимости от нажимаемых кнопок. Вот захотелось так и все. В панике перепроверяю код: все правильно, но такое дурацкое поведение не исчезает. Коллеги хмурят брови и просят проверить еще раз. После обеда.

Разумеется, весь обед голова забита только вопросом «Какого … ?». Возвращаемся. И тут в голову приходит глупая идея – за этот проект мы уже несколько раз наступали в электрические наводки на информационные линии, а с учетом того, что силовые щиты тоже рядом… в общем, прошу коллег заменить кабель от компьютера до контроллера на экранированный. Заменяем. Все начинает работать как и работало на тестовом пульте. Выдыхаю, перехожу к следующему этапу.

Вторая история случилась совсем недавно. Я разрабатывал простенький веб-видеочат, для создания клиентской части использовал открытый Flex вместо традиционного Adobe Flash, а, поскольку знания платформы были недостаточно глубоки, всячески подглядывал в размещенный в сети код и исходники, идущие вместе с сервером для RTMP-трансляций erlyvideo. Чат в итоге был реализован и даже работал, но при тестировании обнаружился очень странный эффект – при ожидаемом поведении в браузерах ОС Windows и Mac OS X ответственный за вещание Flash-элемент категорически отказывался работать в Linux, даже не выдавая предупреждения на захват камеры. Попытки неоднократно переписать код, консультации с опытными Flex-разработчиками, один из которых и был автором того кода, на базе которого я строил тот элемент, не увенчались успехом. Окончательно разочаровавшись во всех испытываемых средствах я полез как можно глубже в документацию. Оказалось, что выдача окошка предупреждения безопасности – это свойство исключительно Flash-плагина, Air-приложения же сразу обломаются. Запустив отладку, я обнаружил – да, действительно, обламывается. Но у меня было не Air-приложение! Сразу пришло на ум, что, возможно, это указывается в параметрах компиляции. Прошерстив все параметры и вдоволь ими наигравшись до такой степени, что даже работающая компиляция перестала функционировать, я сдался, решив проверить последний шанс. Дело в том, что для Linux есть альфа-версия Flex Builder-а, продукта Adobe для удобной работы с Flex-ом. Создав на удачу в нем проект, я скопировал туда прошедший неоднократную переделку код и запустил. Каково было мое удивление, что все заработало! Появилась панель безопасности, заработал захват видео-потока с камеры. А вместе с удивлением пришло и озарение. Я начал проверять, как ролик вставляется в страницу и опасения подтвердились – библиотека jQuery SWFObject откровенно халтурила, пытаясь вставить Flash-элементы в Linux как и на других платформах через тег object, в то время как правильно это делать через тег embed (что и делает оригинальный SWFObject, который занял вакантное место библиотеки для встраивания). В результате чего браузер трактовал ролик как встроенное Air-приложение и применял соответствующую настройку безопасности. Для проигрывания было все равно, а вот с захватом и трансляцией получилось неудобно. В результате, стыдно признаться, но на этот вполне тривиальный баг я потратил почти неделю времени, правда, неполных рабочих дней, потому как делалось это параллельно остальным задачам.

Мораль обоих историй проста – «баги коварны» и «никому нельзя верить». :)

Максим, есть три базовых сценария приемочных испытаний: проверку системы осуществляет разработчик, выделенный тестировщик или вменяемый заказчик. При создании каких приложений/систем оптимален тот или иной сценарий? Исходя из вашего опыта, как организовать тестирование продукта наиболее эффективным образом в координатах “время-качество-деньги”?

Для выбора из предложенных варинтов, на мой взгляд, главное – представлять стоимость сбоя и отказа.

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

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

Каковы признаки плохого кода? Можете ли вы привести примеры?

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

Технические ошибки на проекте можно подразделить на следующие:

• Неправильный выбор платформы

Здесь, скорее всего, будет все плохо: начиная от архитектуры и заканчивая локальными фрагментами кода, все будет сосредоточено на героическое преодоление нюансов разработки под выбранную платформу. В результате этого скорее всего получится дорогой в разработке и поддержке, но абсолютно неэффективный продукт. К счастью, в наши дни подобные ошибки встречаются все реже и реже. Наиболее абсурдный пример подобного решения – написание интернет-форума на Си в виде CGI-приложения (зачем, когда есть такие языки, как Python, Ruby, PHP, явно больше подходящие для веб-разработки).

• Ошибки архитектуры

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

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

Также сюда можно отнести проблемы неравномерности кода, когда существует множество мелких файлов, являющихся промежуточными звеньями, а основная бизнес-логика сосредоточена в отдельном большом файле, что часто приводит к возникновению т.н. «спагетти-кода» (о нем поговорим далее). Стыдно признаться, но именно такую ошибку совершил и я, посчитав, что выделение каждой функции в отдельный файл будет хорошим решением. Правда, несколько проектов с последующими внесениями изменений заставили меня передумать на этот счет, поэтому как именно модификации потребовали значительных телодвижений по обеспечению инфраструктуры, нежели написанию самого кода.

• Неряшливое кодирование

Под неряшливым кодированием я обычно подразумеваю два явления – несоблюдение стиля кодирования и спагетти-код.

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

Спагетти-код – это код, в котором встречаются фрагменты, написанные как в разном стиле, так и с разными подходами к разработке. Такое обычно бывает когда над проектом успело поработать несколько разработчиков, причем некоторые из них внедряли не свои разработки, а код третьих товарищей. В результате получается каша, в которой очень сложно понять, какая строчка за что отвечает, какие части значащие, а какие инфраструктурные. Как следствие, с каждой итерацией вносить изменения в этот код становится все сложнее и сложнее, в умах разработчиков все чаще возникают пролетарские идеи о рефакторинге или «все взять и переписать». Стоит отметить, что бороться со спагетти-кодом (иное название – «лоскутное одеяло») весьма сложно как на архитектурном, так и на организационном уровне.

• Незнание алгоритмов и/или принципов функционирования инструмента

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

• Недостаточная или излишняя документация

Тут обычно вспоминают классическую фразу «Документация как секс – когда она плохая, это все же лучше, чем ничего». На деле можно столкнутся как с очень плохой документацией (крайний случай – когда она откровенно лжива), так и с излишне хорошей, когда на метод из четырех строк приходится 20 строк описания.

Как сделать код более читабельным? Как обеспечить возможность его легкого изменения в будущем?

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

Попробую со своей дилетантской стороны предположить, что наиболее читабельный код – это код, которого мало. В результате идеальный код – код, которого нет. Но, поскольку на данном этапе развития технологий к идеалу можно только стремиться, то следует предположить, что код, содержащий меньшее число строк и есть лучший. К сожалению, тут вскрывается другой неприятный факт: чтобы читать и изменять код с минимальным числом строк, нужно обладать хорошей компетенцией в программировании и в языке, в частности. Получается, что «количество ума на Земле постоянное, а население растет».

Если кратко, советы для достижения читабельного кода, думаю, можно свести к следующим:

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

• Используйте стили написания кода, такой проще читать.

• Как минимум, подписывайте назначение функций/методов (особенно если их назначение неочевидно из названия) и коммиты в систему контроля версий.

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

• Помните: возможно ваш код будете читать вы сами (лет через пять и бить себя по голове при этом), а возможно – психопат-убийца-маньяк. И не факт, что он не найдет, где вы живете. («Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.» – Martin Golding)

Максим, каковы признаки хорошего кода?

Их не так много:

На самом деле все гораздо проще:

Наверное такой код можно назвать хорошим кодом. Беда в том, что если пункт один можно обеспечить тестированием, а пункт три – грамотным проектированием и репроектированием, то пункт два исключительно субъективен. На практике хороший код написать с первого раза практически малореально. Хорошим получается код четвертой, пятой и последующих итераций (об этом писал Ф.Брукс в своей эпической книге «Мифический человеко-месяц»).

Табу для разработчика: каких ошибок не стоит допускать при создании программных продуктов?

При создании программных продуктов не нужно допускать двух ошибок:

К сожалению, программная инженерия сейчас все еще многогранна и сложна. Программисту приходится учитывать множество факторов (нет, фазы Луны уже учитывать необязательно) и нюансов в своей повседневной работе, поэтому вполне нормально, что вся картина будет выпадать из поля зрения. Конечно, говорят, что можно расширять сознание при помощи LSD и аналогичных веществ, но, боюсь, это порочная и не несущая в конечном итоге значимой прибыли практика.

Самое большое зло в разработке – делать «тяп-ляп», мол, потом перепишем все правильно. Практика показывает, что все временное старается существовать как можно дольше, а с наколеночными решениями рано или поздно приходится иметь дело. Другая крайность – «кризис перепроектирования» – не менее ужасна: архитектор не может остановится на конкретном инструменте и пробует все вокруг для получения сферического идеального решения в вакууме.

Каковы, на ваш взгляд, наиболее важные навыки для эффективного программиста?

Наиболее важные навыки эффективного программиста:

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

Можно ли после этого спокойно спать? :)

Можно. Такие маньяки водятся только в телевизионных сериалах. :)

Максим, каких возможностей вам не хватает в современных языках программирования?

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

Другое дело, что объем знаний для освоения любого из языков программирования на сегодняшний день требует предварительной подготовки, а само изучение языка, если брать доскональную работу, а не поверхностное чтение справочника с последующим ввязыванием в бой, тоже занимает достаточно много времени. Исключения есть (например, Эрланг учится весьма быстро), но их мало. А помимо языков существуют дополнительные инструменты, практики, методики построения приложений… В результате сложность разработки растет геометрически и под грузом данных разработчику порой сложно написать просто и изящно, как это было бы в случае, если бы не было излишних нагромождений. С другой стороны, отказаться от всего наследия было бы тоже неразумно. Требования к функционалу систем растут, и в этом свете было бы неправильно изобретать велосипед, когда можно подключить огромную подсистему парой строчек, не затратив на это значительных усилий, времени и, что немаловажно, денег заказчика. Се ля ви.

Что нового, на ваш взгляд, появится в языках и средах разработки?

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

В то же время на уровне генерации машинного кода, наоборот, произойдет интеграция всех платформ и систем под знамя LLVM, т.е. исходный и/или промежуточный код (CIL, байткод JVM) будут транслироваться в представление LLVM, а только затем – в бинарный код целевой платформы. Это упростит переносимость продуктов, позволяя модернизировать интерфейсы в зависимости от конечного устройства, оставляя код бизнес-логики неизменным. Впрочем, это весьма оптимистичный прогноз.

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

Максим, что вам хотелось бы изменить в развитии IT?

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

Максим, спасибо за интервью. Хочется пожелать вам новых интересных проектов, развивающихся эволюционным, а не революционным путем! :)