OpenQuality.ru

Качество программного обеспечения

Качество программного обеспечения: в главных ролях

Лента  Радар  Блог  Опыт  
Разум  Видео  Заметки  Эпизоды


 

Тише едешь, дальше будешь

Максим Крамаренко | 14.12.2010

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

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

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

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

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

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

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

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

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

- для крупных компаний была важна интеграция с внутренними сервисами (LDAP, SCM и т.п.) и контроль над данными, реализовать это в SaaS довольно сложно.

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

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

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

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

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

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

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

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

1) Требуется не обработка множеств, а навигация по дереву.

2) Права доступа настраиваются для каждого узла дерева.

3) Структура дерева часто меняется.

Первые 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 (например, TrackStudio 4), тестируем, исправляем ошибки. Если мы все сделали, известных ошибок больше нет, сами мы найти ничего не можем, то мы выпускаем бета-версию.

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

3) Если пользователи бета-версий устойчиво (несколько недель) не могут «загрузить» нашу команду – мы выпускаем релиз. Релиз скачивают большее количество пользователей, количество багрепортов опять увеличивается, мы исправляем проблемы и выпускаем минорные версии (4.0.1, 4.0.2 и т.п.)

4) Когда становится очевидно, что исправлением ошибок и мелкими доделками команду занять не получится – мы делаем branch и начинаем разработку следующей версии (например, TrackStudio 5.0). При этом все ошибки продолжают исправляться и в старой, и в новой версии.

5) Когда новая версия нам кажется «готовой» (обычно это занимает несколько лет), мы выпускаем бету и процесс повторяется.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1) Если такое уже где-то было сделано, то нужно посмотреть как это сделано там и сделать тут точно так же.

2) Если есть метод лучше, то старый код нужно тоже исправить.

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

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

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

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

2) У нас клиенты не могут ставить задачи непосредственно программистам. У клиентов вообще нет доступа к трекеру, так как такой подход стимулирует программистов делать «что сказал клиент» и неявно перекладывает ответственность за продукт на клиентов. Обычно задача попадает в трекер, когда становится понятно что именно и как нужно делать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Комментарии (7)

Подход к разработке чем-то напоминает идеологию упомянутого 37signals, только ещё более упрощенную :) В том смысле, что развитие системы идёт неспешно и в том направлении, которые диктуется собственный представлением о продукте. Растянутость релиов во времени этому как раз способствует.

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

В общем, спасибо за интервью и сайту, и Максиму.

Aquary | 17.12.2010 | 6:01 дп. Ответить #

Юрий, и вам спасибо!

Кормчий | 17.12.2010 | 6:05 дп. Ответить #

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

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

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

Крамаренко Максим | 17.12.2010 | 12:53 пп. Ответить #

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

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

Aquary | 17.12.2010 | 2:24 пп. Ответить #

[...] This post was mentioned on Twitter by Yury Udovichenko, Max Vasenkov. Max Vasenkov said: Интервью с создателем TrackStudio Максимом Крамаренко http://t.co/PYXozcs (А заголовок фиговый) http://juick.com/1108531 [...]

Tweets that mention Тише едешь, дальше будешь « OpenQuality.ru | Качество программного обеспечения | Опыт экспертов -- Topsy.com | 17.12.2010 | 6:18 дп. Ответить #

[...] интервью с Максимом Крамаренко – руководителем команды [...]

Максим Крамаренко: “У нас нет своей команды тестировщиков” « QA – грамотно | 01.01.2011 | 9:36 пп. Ответить #

[...] руководитель команды разработчиков TrackStudio, подчеркивает: “У нас нет своей команды тестировщиков. Перед [...]

OpenQuality.ru | Качество программного обеспечения | 01.04.2012 | 11:51 дп. Ответить #

Оставьте комментарий

Required.

(будет спрятан за семью замками)

(будет открыт, если это не спам)

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