Электронные таблицы SocialCalc

Глава 19 из книги "Архитектура приложений с открытым исходным кодом", том 1.

Оригинал: SocialCalc, глава из книги "The Architecture of Open Source Applications" том 1.
Автор: Audrey Tang, перевод: Н.Ромоданов

19.8. Усвоенные уроки

Мы выпустили SocialCalc 1.0 19 октября 2009 года в 30-летнюю годовщину первого выпуска VisiCalc. Опыт сотрудничества с коллегами в Socialtext под руководством Дэна Бриклина был очень ценен для меня, и я хотел бы поделиться некоторыми уроками, которые я за это время усвоил.

19.8.1. Главный конструктор с ясным видением

В работе [Bro10] Фред Брукс (Fred Brooks) утверждает, что если мы ориентируемся на стройную концепцию архитектуры, обсуждения при создании сложных систем должны быть более прямыми, а не выводится из других решений. По словам Брукса, формулировку такую единой архитектурно целостную концепцию лучше всего отдать на откуп одному человеку:

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

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

19.8.2. Wiki для сообщества, работающего с проектом

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

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

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

19.8.3. Объединяем разные часовые пояса

Когда Давид Хейнемейер Ханссон (David Heinemeier Hansson), создатель Ruby on Rails, первый раз попал в команду 37signals, он как-то заметил о пользе распределенных команд: «Семь часовых поясов между Копенгагеном и Чикаго фактически означали, что мы могли делать очень много с небольшими перерывами». Это также оказалось верным, когда при разработке SocialCalc Тайбэй и Пало-Альто были разделены девятью часовыми поясами.

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

19.8.4. Оптимизация для удовольствия

В 2006 году в своем докладе для конференции CONISLI [Tan06], я изложил в форме нескольких заметок свой собственный опыт руководства распределенной командой, реализующей язык Perl 6,. Среди них - «всегда иметь план», «снисходительность ведет к вседозволенности», «избегать тупиков», «искать идеи, а не консенсус» и «предлагать эскиз идеи вместе с кодом», которые особенно актуальны для небольших распределенных команд.

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

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

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

19.8.5. Управление разработкой с использованием «описаний - проверок»

До прихода в Socialtext, как можно видеть по спецификациям Perl 6 [7], в которых мы добавляли официальные наборы тестов к спецификациям языка, я выступал за подход «чередования тестов со спецификациями»,. Впрочем, еще были Кен Пьер (Ken Pier) и Мэтт Хюссер, Heusser, команда аналитиков SocialCalc, которая действительно открыла мне глаза на то, как можно перейти на следующий уровень, преобразовав тесты в исполняемые спецификации.

В главе 16 в [GR09] Мэтт разъяснил наш процесс разработки с использованием подхода «описание - проверка» следующим образом:

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

В начале «описания» владелец продукта делает добросовестную первую попытку создать приемо-сдаточную проверку, которая будет расширеная разработчиками и тестерами перед тем, как кто-нибудь из разработчиков напишет какую-нибудь сточку кода.

Такие «описания - проверки» затем преобразовываются в wiki-тесты, табличный язык спецификаций, предложенный Уордом Каннингеммом во фреймворке FIT [8] и позволяющий управлять фреймворками автоматического тестирования, например, Test::WWW::Mechanize [9] и Test::WWW::Selenium [10].

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

19.8.6. Открытый исходный код с лицензией CPAL

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

В Socialtext для SocialCalc была создана лицензия Common Public Attribution License [11]. Лицензия CPAL, разработанная на основе лицензии Mozilla Public License, предназначена для того, чтобы позволить автору исходного текста требовать от пользователя исходного текста отображать информацию о себе в пользовательском интерфейсе производных программ, а также имеет пункт, касающийся использования в сети, в котором требуется в производной программе в случае, если она используется в сети в качестве сервиса, указывать те же самые условия распространения, что и в исходной лицензии.

После одобрения лицензии в Open Source Initiative [12] и в Free Software Foundation [13], мы обнаружили, что такие известные сайты, как Facebook [14] и Reddit [15], решили выпустить исходный код своей платформы под лицензией CPAL, что очень обнадеживает.

Поскольку лицензия CPAL является лицензией «weak copyleft» (т. е. с весьма слабыми ограничениями — прм.пер.), разработчики могут свободно комбинировать ее с либо бесплатным, либо с проприетарным программным обеспечением, и единственное, что нужно, это создать собственную модификацию SocialCalc. Это позволило различным сообществам адаптировать SocialCalc и сделали его еще более мощным.

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

Примечания

---

Далее: К началу статьи

---

---