OpenQuality.ru

Максим Крамаренко руководит командой разработки TrackStudio – иерархической системы управления задачами, которую внедрили сотни клиентов в 33 странах мира. История продукта, извлеченные уроки, техпроцесс – русло нашей сегодняшней беседы.

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

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

На тот момент трекеры в виде сервисов были 2-х типов:

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

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

Основных проблем было две:

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

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

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

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

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

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

Главная техническая сложность – реляционные СУБД довольно плохо работают с ситуации, когда

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

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

Если бы мы начали сейчас писать TrackStudio, то наверняка использовали бы какую-нибудь NoSQL СУБД.

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

Нашим самым большим открытием в первые годы работы над проектом было то, что стандарты де-факто гораздо важнее, чем официальные стандарты. Аналитика сильно преувеличивает важность и популярность дорогих коммерческих продуктов (ORACLE, DB2, WebLogic и т.п.).

Самый важный урок: не нужно ориентироваться на официальную статистику популярности платформ, серверов БД и приложений. Поддержка MySQL может сказаться на продажах больше, чем поддержка ORACLE и DB2 вместе взятых.

Самый необычный пользователь: чем он запомнился?

Это был директор городского парка, бывший программист, который использовал SaaS-версию TrackStudio для задач вроде «Нужно покрасить скамейку».

Самый тяжелый пользователь?

Клиент из Австрии, который очень плохо понимал и писал по-английски. За несколько месяцев он написал более 600 писем с вопросами.

Как вы отлаживаете код? Что представляет собой техпроцесс работы над продуктом?

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

С организационной точки зрения исправление багов для нас стоит на первом месте, обычно мы не выпускаем продукт с известными багами. Это не значит, что в TrackStudio нет глюков (конечно, есть), но найденные глюки обычно исправляются уже в следующей минорной версии. Для версии 3.5 таких минорных версий было 77, для 4.0 – уже 9. Образцом для подражания для меня является OS/2 2.1, для которой было выпущено больше 100 fixpack-ов.

Причем мы стараемся не столько найти больше глюков, сколько ускорить устранение найденных. Со временем такой подход позволяет значительно увеличить надежность приложения: если сразу после выпуска TrackStudio 3.5 пользователи присылали 6-8 багрепортов в неделю, то через несколько лет мы стали получать 1 багрепорт в 3-6 месяцев.

Наш процесс разработки выглядит примерно так:

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

Маленькая команда и большой продукт: каким образом осуществляется тестирование TrackStudio и его саппорт?

У нас нет своей команды тестировщиков. Перед выпуском бета-версии мы инсталлируем новую версию системы на свой сервер и активно используем несколько недель. Параллельно разработчики занимаются тестированием с применением средств покрытия кода (code coverage), мы устраиваем соревнования «кто быстрее достигнет заданного уровня покрытия».

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

Особенность нашей ситуации в том, что

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

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

ТDD и автотесты: оправданы ли они в работе над TrackStudio?

Нет, автоматические тесты не применяем. Пробовали, но ничего хорошего из этого не вышло. Причины такие:

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

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

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

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

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

Кроме того, при таком подходе code review происходит автоматически.

Есть ли у вас внутренний Coding Style (документ или «устное» коллективное знание, которое определяет принятый стиль кодирования)? Сможете ли вы привести примеры хорошего и плохого стиля?

В TrackStudio довольно редко приходится делать что-то совершенно новое, в основном происходит улучшение и переписывание старого кода. Мы стараемся придерживаться следующих правил:

Что касается форматирования, то никаких особых требований нет, используем «стандартное» форматирование средствами IDE.

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

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

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

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

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

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

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

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

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

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

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

Что вам хотелось бы изменить в развитии IT?

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

Например, одной из наиболее популярных СУБД сейчас является MySQL. За счет простоты первых версий эта СУБД выиграла у PostgreSQL, а инновации последних лет заключались в реализации функциональности, которая была сделана конкурентами много лет назад.

HTML/CSS стали популярными именно за счет своей простоты, на многие проблемы технологии изначально просто закрыли глаза, в итоге интенсивное «допиливание» этих инструментов продолжается до сих пор, а web-разработка стала неоправданно сложным делом.

Тенденции последнего времени скорее не ослабляют, а усиливают этот эффект. Agile-практики фокусируются на получении мгновенного результата в ущерб архитектуре. Считается, что наличие тестов позволит относительно безболезненно поменять архитектуру системы потом, но это далеко не всегда получается. В популярной книге Getting Real от 37signals также предлагается сфокусироваться на решении простых проблем, оставив сложные на потом.

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

Максим, большое спасибо за интервью. Успехов вам, системе TrackStudio и вашим клиентам вне зависимости от конъюнктуры в IT!