Pull to refresh

Comments 22

Успехов, успехов, успехов jetBrains-у.
Они лучшие.
Среда разработки этой компании — одна из лучших, что я использовал. Жаль на жителей СНГ нет скидок или подарочных сертификатов :(
удаче ребята, успехов! ждем таких же качественных продуктов и в дальшейшем… Один только Resharper чего стоит, без него студия не студия :)
Было бы интересно послушать поподробнее их мысли насчёт collaboration тулов для разработки документации и т.п. Очень, очень актуальная тема.
UFO landed and left these words here
Чумовой подкаст :) Дмитрий интересные вещи толкал. Вот так вот послушаешь его так и понимаешь что надо на всю продукцию JB переходить. Addiction detected :}
Я в последнее время все больше думаю что бардак в разработке это хорошо, если это правильно организованный бардак. А всякие скрамы и аджайлы это чистый маркетинг.

Эх, не люблю я термин Рефакторинг (наверно детская травма), но в последнее время в него намешали всякого, да и обычно менеджмент не любит таких слов.

А какой интересно процент обнаружения (распределения по источникам) ошибок у JetBrains? Сколько ошибок находятся при помощи unit-тестов?

А кто у вас пишет функциональные тесты? Обычные разработчики? Какое покрытие? Много ли у вас тестов приходится поддерживать при изменениях (например архитектуры)?
Тесты у нас обычно находят ошибки класса «разломали чего-то в процессе переделки». В штуках их, конечно, намного меньше, чем багрепортов от пользователей и наших собственных тестеров, но важность их часто бывает сильно больше. Но много и ложных срабатываний — тестов, которые падают потому, что плохо написаны, а не потому, что в продукте что-то сломалось.

Функциональные тесты пишут обычные разработчики; мы пытались привлекать к этому тестеров, но как-то не очень пошло. Покрытие — вот сейчас посмотрел, показометр показывает 45%, но мы на эту цифру смотрим редко и целенаправленным её увеличением не занимаемся. Вносить осмысленные изменения в тесты при переделках архитектуры приходится очень редко, что нас весьма радует.
И что вы делаете с «ложными срабатываниями»? Бывает что тесты просто идут «под нож»? Просто я работал в одной компании, где было принято просто удалять неправильные тесты, без переделывания.

А почему тестеры не смогли писать функциональные тесты? Интересно ваше мнение :)

Кстати, а какое у вас соотношение тестировщиков к разработчикам?
Удалять тесты у нас не принято; удаляем только в том случае, если они тестируют вообще непонятно что, или если после переделки от того, что они тестируют, ничего узнаваемого не осталось. Стараемся чинить. Если чинить не получается — муваем в специальную группу «тесты, про которые мы знаем, что они иногда падают», в которой они продолжают иногда падать, пока кому-нибудь не станет не лень разобраться.

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

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

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

Кстати, вы в подкасте упоминали о том, что уже некоторое время в компании используете git и не совсем довольны результатами. Расскажите, пожалуйста, о сложностях, которые появились при переходе на него.
Официальная поддержка Mercurial (на базе hg4idea-luciad плюс куча наших фиксов и доделок) будет в IDEA 10.

Сложности с git вытекают в первую очередь из того, что он версионирует репозиторий целиком, поэтому даже для того, чтобы запушить один маленький файлик, нужно иметь up to date версию всего репозитория. Если запушить нужно срочно (например, компиляцию починить), а в это время 30 коллег пушат в тот же репозиторий какие-то свои change'и — апдейтиться часто приходится по нескольку раз. При этом кода дофига, и каждый апдейт может занимать минуты (особенно под Windows).
Отличная новость! Если ещё появится возможность, в графическом виде, апдейтиться к определённому changeset'у в графе и мерджить ветки между собой, то цены такому плагину не будет.

А сколько, в среднем, ведётся параллельных веток при разработке и как организован процесс мерджа? Мерджите в конце 2х-3х недельной итерации в основную ветку разработки или процесс организован иначе?
Про графический интерфейс пока не обещаем. Для git'а мы кое-что сделали, но оно пока не шарится с другими VCS.

Итераций как таковых у нас нету. Локальные бранчи используются на усмотрение разработчиков — если кому надо, он сам себе заводит, а кому не надо, тот прямо в мастер всё фигачит. Плюс, конечно, есть параллельная ветка (иногда две) на предыдущий major release, куда каждый свои фиксы переносит через git cherry-pick, или сразу после исправления проблемы, или потом по мере необходимости.
У вас не бывает ситуаций, когда какой-то вечерний push в мастер заламывает что-то очень важное, работа встаёт, и автор этого push'а будет доступен только с утра? :) Не совсем понятно, почему не используете несколько веток-«песочниц» под каждую разрабатываемую фичу, которые мерджатся с мастером только в конце разработки, т.е. когда новый локально смердженный с мастером код пройдёт интеграционное тестирование.
Это связано с тем, что хочется как можно раньше локализовать возникающие интеграционные проблемы или из-за CI сервера, который не удобно настраивать для прогона тестов и инспекций под каждый создаваемый branch?

Ещё интересно, какое сейчас количество changeset'ов в git репозитарии и сколько по времени этот репозитарий клонируется на локальную машину? Мы сталкиваемся с тем, что время клонирования всего mercurial репозитария довольно быстро растёт и месяца через 3, вполне возможна ситуация, когда клонирование репозитария с master сервера (в локальной сети) будет больше 20 минут.
Если кто-то что-то совсем сломал, его коммит можно просто откатить — с этим справится любой другой программист. :) Это бывает, но не настолько часто, чтобы ради этого менять процесс и сильно усложнять всем жизнь.

Серверные бранчи для фич мы не используем потому, что не видим в этом необходимости. :) У нас вообще редко бывает такое, что девелопер долго (несколько недель) делает какую-то большую фичу в существующем коде. Активный девеломпент идёт либо в плагинах (которые нет смысла выносить в отдельные бранчи — и так никому не мешает), либо в виде кучи мелких изменений в разных местах.

Changeset'ов в репозитории дохрена и более — мы когда переходили на git, засосали туда всю историю из perforce и subversion, то есть все коммиты с начала 2005 года. Клонирование занимает, наверное, час-полтора, но это как раз не особенно напрягает: это приходится делать один раз в начале работы, один раз при создании бранча для новой версии, и тогда, когда совсем всё сломалось.

Дмитрий, спасибо за ответы :) JetBrains'у успехов!
>что он версионирует репозиторий целиком, поэтому даже для того, чтобы запушить один маленький файлик, нужно иметь up to date версию всего репозитория.

это для одного бранча, я правильно понимаю?
иначе как же тогда живут огромные репы типа линуксового ядра?
Да, это per branch. Репы типа линуксового ядра живут совсем по-другому: там для каждого репозитория есть очень мало человек, которые туда push'ат, а сборка всего в кучу делается через явный ручной pull из кучи разных репозиториев в мастер-репозиторий Линуса.
Я ждал, что Голодный задаст вопросы насчет перехода IDEA в оупенсорс. Получили какую-то видимую пользу? Есть посторонние комиттеры? Довольны ли вообще результатом?
Я уже слышал ответ
и потому даже не подумал задать такой вопрос +)
Only those users with full accounts are able to leave comments. Log in, please.