— Антон, чем вы занимаетесь в области Java-разработки?— Последние шесть лет я работаю в компании ZeroTurnaround, и по долгу службы занимаюсь любимым делом – разработкой инструментов для Java-разработчиков. Наш известный продукт – JRebel для Java-разработчиков, и наш второй крупный продукт – это XRebel, тоже для Java-разработчиков, но больше для тех, кто занимается веб-разработкой. Я занимался первые три года JRebel, и последние три года участвую в создании XRebel.
О средах разработки
— Популярность IDEA растёт, и я с удивлением обнаружил, что по данным опроса, проводившегося на сайте вашей компании, она в этом году обогнала Eclipse.
Позиции различных IDE среди опрошенных на сайте zeroturnaround.com
— Стоит признать: любой опросник врет. Это статистика, а как известно, «есть ложь, есть большая ложь и есть статистика». Среди тех, кто отвечал на этот опросник, IDEA – самая популярная IDE, но это не значит, что она самая популярная среди всех Java-разработчиков. Если мы посмотрим статистику среди пользователей JRebel, то Eclipse все равно будет ведущим IDE, с вполне уверенным перевесом — доля Eclipse — более 60%.
На самом деле интересно не то, какая сейчас доля пользователей у IDEA, а то, как эта доля изменялась. Мы проводим эти опросники не первый раз, и все время показатели популярности растут для IDEA и падают для Eclipse. А для NetBeans они всегда очень маргинальны. Не то, чтобы 10% можно было считать маргинальным, но все-таки они достаточно низкие, с чем, конечно же, команда NetBeans очень не согласна. Они считают, что такие вещи вообще никак нельзя изучать через опросники. Но это всем интересно все равно, и все это всегда будут делать.
Мы видим тренд, что IDEA растет. И мне кажется, это связано с тем, что IntelliJ IDEA и компания JetBrains решили поменять стратегию выпуска новых версий. Чаще выходят апдейты, чаще выходят баг-фиксы, постоянно можно видеть «ранние релизы».
И когда какой-то продукт достаточно активно развивается, это привлекает разработчиков. Мы как дети, мы любим все новенькое. И чем мощнее инструмент, тем мы его больше хотим. Несмотря на то, что нам, например, 95% мощности этого инструмента, может быть, даже никогда не нужны будут.
Мне кажется, что один из больших плюсов IDEA в том, что её разрабатывает одна компания, с единым взглядом на то, как это должно выглядеть, как должен выглядеть продукт. У Eclipse я этого не наблюдаю. Там не наблюдается единой «линии партии», скажем так. И поэтому некоторые куски являются когерентными, а некоторые совершенно, как будто бы «ad hoc» в системе. Я не говорю, что в IDEA такого нет – в IDEA тоже местами есть беда, но она исправляется, когда сообщество начинает возмущаться: «Ребята, как же так, у вас коммерческое IDE». И там быстро-быстро стараются загладить эти шероховатости. В Eclipse, к сожалению, я этого не наблюдал.
Eclipse до сих пор – community-проект, даже несмотря на то, что за ним есть большие силы. Он следует своей довольно консервативной стратегии выпуска новых версий. К тому же, несколько лет назад были довольно большие проблемы с релизами, были, насколько я знаю, проблемы с производительностью и стабильностью. Но это случается у многих продуктов. И у IDEA был период, когда релизы были не очень хорошие, и у NetBeans тоже.
Единственный большой контрибьютор в Eclipse, который радеет за «единую линию» – это, мне кажется, Red Hat со своим дистрибутивом JBoss Developer Studio. Они стараются собрать такой дистрибутив, который ты поставил и который работает. И они являются таким «моторчиком» для Eclipse, чтобы улучшить его. Очень много последних улучшений в Eclipse связано именно с Red Hat.
— По существу, как вам кажется, программист на IDEA работает производительнее, чем в Eclipse? Вот вы будете по IDEA делать доклад. Наверняка вы в обеих IDE работали.
— Да, я работал последние двенадцать лет, с 2004 года, в IDEA. Eclipse я пользовался и контрибьютил в нее с 2006-го по 2008-й, и как-то еще немножко периодически использовал. Но по долгу службы мы делаем плагины для IDE. Наш продукт встраивается как плагин, и я как раз и занимался разработкой плагинов. Поэтому я все IDE последние несколько лет довольно активно использовал. Даже наблюдал, сколько у меня стояло разных версий Eclipse – порядка десяти штук.
— Но по большей части вы работали именно в IDEA? Тогда ясно, что для вас работа в ней производительнее, вы к ней привыкли.
— Да, во-первых, конечно, это дело привычки. Но помимо этого, я считаю, что для каждой задачи надо иметь свой инструмент, который вы хорошо знаете, и которым можно взять и сделать все, что угодно. Для каких-то вещей в разработке в Java мне было бы удобнее использовать NetBeans – я бы взял NetBeans для этой задачи. Для какой-то задачи мне было бы эффективнее использовать Eclipse – я бы взял Eclipse.
Для меня в IDE самая продуктивная часть – это навигация и система шорткатов. Очень часто люди ищут какую-то логику в системе шорткатов. Логики никакой нет, никогда. Мне, например, задавали вопрос: «Какая логика в таком-то шорткате в IDEA?» Неправильно так спрашивать, потому что, если смотреть, где какие шорткаты, везде можно увидеть какие-то странности. Почему Ctrl+H является поиском в Eclipse? Где здесь логика? Непонятно.
— Шорткаты, как аккорды – запоминаются мышечной памятью.
— Да, тут надо запоминать спинным мозгом, мышечной памятью и так далее. И тут главное, чтобы то, что ты хочешь сделать, ты мог бы сделать сейчас, и как можно больше out-of-the-box, не настраивая, не кастомизируя систему.
Тут как выбор между Mac или Gentoo Linux: или мы настраиваем всё под себя, или же мы берем и сразу едем, садимся в «Феррари» и шпарим сто километров в час.
Если человек может это с каким-то инструментом себе обеспечить, то он молодец. И тут уже не важно, IDEA или Eclipse. Я для себя это нашел в IDEA. Кто-то, может быть, найдет для себя это в Eclipse.
О системах контроля версий
— Вечный повод для «священных войн» программистов – это выбор системы контроля версий. Хочу поделиться своей историей. Когда-то давно наша компания сделала ставку на SVN, и теперь у нас много сотрудников (большинство из них — не Java-программисты или вовсе не программисты) обучены эффективной работе с SVN, многим трюкам и особенностям. А в последнее время мы видим, что Git всех разгромил по популярности. И часто возникают «продвинутые молодые специалисты», которые приходят и говорят: «Что же это вы до сих пор на Subversion? Вы устарели! Вы не в тренде! Как так?»
Популярность систем контроля версий
— В нашей компании по историческим причинам мы не используем Git во многих проектах. Есть команды, которые захотели перейти на Git – они перешли. Но у нас основное количество проектов и самые основные проекты содержатся в ещё менее популярной среде, чем SVN – это Mercurial.
Получили бы мы какие-то преимущества от перехода на Git или нет?
В своё время мы приглашали из GitHub тренеров, чтобы они провели нам тренинг по Git, для того чтобы мы решили, стоит нам переходить на Git или нет. И после этого дневного интенсива мы потом сели, подумали и поняли, что учитывая то, как мы работаем, от перехода на Git нам легче не стало бы. А для получения преимуществ от Git нам нужно было бы поменять свою работу.
Если ваш способ работы (делание бранчей, вот эти все вещи) подходит под вашу систему контроля версий и она это поддерживает, то это хорошо. Если мы берем инструмент, который позволяет кучу всяких классных вещей делать, а используем его все равно как SVN, то толку с этого мало.
Относительно популярности Git — тут работает вот какой момент, мне кажется: разработчики любят что-то очень мощное. Даже если эта мощность вся не нужна, мы хотим, чтобы оно было у нас под рукой – этот тесак. Даже пулемет, уже не тесак. SVN – это тесак, мы коммитили туда, и нас всё устраивало. Потом мы взяли Git-пулемёт и начали опять туда так же, как в SVN, коммитить. И тогда возникает вопрос: а зачем все эти вещи?
— Да, если не умеешь хорошо играть, зачем тебе хороший музыкальный инструмент?
— Ну да. Я, честно говоря, не видел никогда для себя смысла очень сильно уделять время Git. Но сегодня, конечно, если меня кто-то спросит, какие инструменты разработчик должен знать, то в первую очередь я назову всё равно Git.
— Не обусловлен ли успех Git популярностью сервиса GitHub?
— Да, конечно, GitHub – он самый популярный, из-за него, мне кажется, популярен и Git. А во-вторых, тут работает зависть. «Я хочу тоже такое же, как у моего соседа, потому что у него мощно». И популярность Git тоже этим обусловлена.
— Многие апологеты Git напирают на децентрализацию. Я им отвечаю, что у нас SVN на три сервера реплицируется, у нас достаточно децентрализации.
— Ну, это разная децентрализация! Тут как раз, если у тебя децентрализованная команда, если у тебя все время разные проекты, разные прерывающиеся разработки и так далее, бранчи как раз являются силой Git. Если мы говорим о бранчах в SVN – это все-таки рудимент.
— Но это начинает работать, только когда очень большая команда и очень большой проект. А когда это в рамках небольшой компании, достаточно централизованной, то тут преимущества Git не дает?
— Тогда нет, конечно. Если маленькая команда, и если мы еще к тому же стараемся не делать много бранчей, или, например, всё разрабатываем только в одной основной ветке с так называемыми feature-флагами — тут преимущества Git теряются. Особенно, если маленькая команда.
О средствах автоматизации сборки
— Несколько угрожающе сейчас, если посмотреть на графики, для Maven выглядит рост популярности Gradle. Gradle, по-моему, повсюду, многие про него говорят. Стоит ли задуматься пользователю Maven о переходе на Gradle?
Популярность средств автоматизации сборки
— На эту тему мы делали замечательный доклад на прошлой конференции «JPoint» в этом году, с Барухом jbaruch Садогурским и Евгением Борисовым. Там у нас был эпический баттл – Maven, Gradle и SBT. Ну SBT там к слову, а в основном Maven и Gradle. И там в конце доклада Барух очень хорошо резюмировал, что для огромного количества проектов и сценариев Maven хватит за глаза. И Maven, благодаря своей «негибкости» так называемой — нельзя просто взять, всунуть руки и поправить логику билда — он как раз вот этим и берет. Он консервативный, стабильный, люди знают, как его «варить». Соответственно, он будет держаться на уровне 70%. И он держится, и мне кажется, что это не сильно изменяется. Это в том опроснике, может быть, как-то играют цифры.
— Gradle растет и отъедает у Maven его долю.
— Ну да. Но основные энтерпрайзные проекты все равно будут сидеть на Maven. В сторону Gradle будут смотреть, наверное, старые проекты, которые написаны еще на Ant, если их продолжат развивать в той логике.
— В логике императивного, а не декларативного подхода к сборке?
— Да-да. Для этого Gradle является вполне неплохим вариантом. Но у Gradle есть своя проблема: там очень легко написать «макароны». Многие эти «макароны» объясняют тем, что язык сборки, Groovy, не статический, типизированный.
Если в Gradle появится когда-нибудь ключик «Enterprise Mode, On!», который будет запрещать любые скрипты внутри build-файла, я думаю, это будет его первый шаг в enterprise-мир. В принципе, многие так считают. И Барух так считает, и я с ним согласен.
Мне кажется, что Maven – это все равно solid, это стандарт де-факто. Его должен знать каждый.
Gradle – это для тех, у кого действительно требования по сборке выходят за рамки. Gradle, мне кажется, не просто инструмент для сборки, он немножко более, он – инструмент для автоматизации, делать что-то большее, чем просто сборку. Он взял все хорошее из Maven, добавил Groovy, и мы теперь имеем такой мощный инструмент. Опять же, его популярность еще обусловлена тем, что он мощный. Мы опять возвращаемся к тому аргументу, что разработчики очень хотят мощность, даже не всегда, когда она нужна. И я уверен, что многие берут Gradle сейчас для каких-то новых проектов там, где он не дает никакого плюса по сравнению с Maven.
Я думаю, это какая-то инерция, к которой мы привыкли. Мы привыкли, что нам надо все время улучшаться.
— Но нам, разработчикам, все равно всегда надо улучшаться, у нас профессия такая.
— Может быть, нам надо просто остановиться и улучшаться в том, что мы уже имеем и что мы уже умеем, а не хватать новые фреймворки, инструменты и так далее. У нас есть хорошие инструменты, которые мы могли бы максимально освоить, и вышибать из них максимальную эффективность, из того, что у нас есть. А мы, не дойдя, не выжав хотя бы 90% и этих инструментов, уже кидаемся на новый инструмент, только потому, что кто-то сказал, что это более в тренде, более блестящее и более интересное.
— Ну и последний вопрос, с чем вы выступите на конференции Joker 2016?
— У меня два доклада на конференции – один про Java байт-код, и второй про эффективное использование IDEA.
Если вам интересно, что на Joker 2016 будет про инструменты, то вот вам полезные ссылки на уже утверждённые доклады:
- Кирилл Толкачев «Релиз-менеджмент с помощью Gradle»
- Martin Toshev «Spring RabbitMQ»
- Владимир Цукур «Путь от CRUD к Hypermedia API с Spring»
- Алексей Зиновьев «Что Spark грядущий нам готовит?»
- Владимир Красильщик «Vert.x: Красавица и Чудовище»
Комментарии (69)
MacIn
11.08.2016 18:38Очень порадовал трезвый взгляд на Git.
n43jl
11.08.2016 21:21+4Незнаю, мне он не очень показался трезвым. Сам использую только svn на работе и только git дома. Что svn лучше git на маленьких проектах — у меня противоположное мнение. В SVN же не нравится, что комит должен быть готовой фичей, и соответственно не всегда может быть маленьким (в гите ты можешь делать сколько угодно маленькие коммиты и пушить готовую фичу).
Иногда у меня нет доступа к SVN серверу (потому что к примеру нет интернета под боком), я сижу и думаю о том, что git давно решил эту проблему. Также если охото поэксперементировать, если SVN — то ничего не сделаешь, бренч создавать из пушки по слонам, в итоге работаешь вообще без контроля версий — в гит нет такой проблемы, комить локально сколько влезет.
Вообщем локальные коммиты делают гит для меня намного привлекательнее чем SVN.MacIn
11.08.2016 22:28-1Что svn лучше git на маленьких проектах — у меня противоположное мнение.
Не столько лучше, сколько адекватнее маленькому проекту. Если команда маленькая и разработка централизована, идеология центрального репозитория подходит лучше. В таких случаях убеждать кого-либо в том, что распределенный контроль версий лучше потому что он распределенный — все равно что утверждать, что зеленая машина лучше желтой, потому что она зеленая.
В SVN же не нравится, что комит должен быть готовой фичей, и соответственно не всегда может быть маленьким (в гите ты можешь делать сколько угодно маленькие коммиты и пушить готовую фичу).
Извините, я не понял этой фразы. Вы имеете в виду, что вы не можете закоммитить что-либо, что сломает билд? В принципе, верно. Но. Если изменение даже не компилируется, надо ли вообще стремиться его класть куда-либо? В конце концов никто не мешает иметь свою базу/ветку, если вы боитесь за сохранность данных на диске и т.п. Если оно не ломает билд, почему вы не можете его закоммитить в транк, который все равно никому не виден, кроме коллег?
Иногда у меня нет доступа к SVN серверу (потому что к примеру нет интернета под боком), я сижу и думаю о том, что git давно решил эту проблему.
Стоп-стоп-стоп, с этого места подробнее. Какую именно проблему? Если вам нужны последние изменения кого-либо из коллег, вам все равно нужен доступ к сети, какой бы СКВ ни была. А иначе СКВ вам нужна лишь для собственных коммитов, что важно только если вы будете переключаться между задачами (в противном случае весь «коммит» это Ctrl+S). Чего в отсутствие сети все равно сделать нельзя, раз трекер недоступен. Да и, например, у нас «производственный процесс» требует постоянного присутствия — либо IP телефон, либо скайп. Так что либо сеть есть, либо ты не работаешь.
Разные команды — разные потребности — разные принципы работы. Вполне есть ситуации, когда Git реально просто не нужен.
PS вполне рабочая комбинация SVN и Git локально.n43jl
11.08.2016 23:40+1Для маленьких проектов и разных вкусов — впринципе согласен, но SVN навязывает центральный репозиторий. git — же дает право выбора — хочешь центральный, хочешь локальный + центральный и каждый разработчик может выбрать сам для себя. Я работаю в маленькой команде и они используют SVN — а я хочу иметь возможность коммитить локально :)
Вы имеете в виду, что вы не можете закоммитить что-либо, что сломает билд?
Зачем сразу ломать :) На моей работе случается с регулярностью в несколько дней. Билды у нас делает QA Engineer, он говорит: «Хочу собрать билд». Разработчик: «Ой я делаю фичу — уже сделал коммит, подожди 30мин пока я закончу». Билд накатывается на демо-сервер, и что-то незаконченное там — не смерть, но сервер могут демонстрировать клиенту, там не должно быть меню на которое ты кликаешь и ничего не происходит. Я всегда, когда это слышу — «подожди пока я закомичу» — вспоминаю Git.
Стоп-стоп-стоп, с этого места подробнее.
По поводу svn update or git pull без интернета — это понятно. Я о другом — git позволяет не менять привычек независимо от того есть у вас интернет или нет — вы продолжаете разбивать задание на маленькие кусочки, и делать маленькие коммиты, коммиты — это как история проекта, вы можете откатиться к предыдущему комиту, сделать бренч для фичи — интернет не нужен. Это не тоже самое, что и ctlr+s, это намного могущественнее :) Но вы правы, что не всем это нужно — это больше зависит от стиля и привычек.
Разные команды — разные потребности — разные принципы работы. Вполне есть ситуации, когда Git реально просто не нужен.
Согласен, но после использования git, при использовании SVN я часто ощущаю, что мне не хватает гибкости git.
А когда я использую git локально вместе с SVN я думаю, что один из них лишний — лучше либо менять свои привычки, либо переходить на git. Проблема SVN — он заставляет менять привычки, и то, что в лучшую сторону — это очень спорно. Git же позволяет работать в своем стиле локально независимо от всего, а пушить на центральный репозиторий в том стиле который хочет команда.
aragaer
12.08.2016 11:36Как однажды кто-то сказал в каком-то чате, git svn это более удобный клиент svn, чем просто svn.
MacIn
12.08.2016 13:34Я работаю в маленькой команде и они используют SVN — а я хочу иметь возможность коммитить локально :)
У нас используется гит локально, но случаи, когда он нужен — перечесть по пальцам за годы.
Зачем сразу ломать :) На моей работе случается с регулярностью в несколько дней. Билды у нас делает QA Engineer, он говорит: «Хочу собрать билд». Разработчик: «Ой я делаю фичу — уже сделал коммит, подожди 30мин пока я закончу». Билд накатывается на демо-сервер, и что-то незаконченное там — не смерть, но сервер могут демонстрировать клиенту, там не должно быть меню на которое ты кликаешь и ничего не происходит. Я всегда, когда это слышу — «подожди пока я закомичу» — вспоминаю Git.
Ну вот видите, я же говорю — команды и принципы разные, и есть случаи, когда гит не нужен. Нет, минусят, чудаки.
У нас билд делается автоматизировано с юнит тестированием несколько раз в сутки, так что явный слом виден сразу, а «логический» никого не волнует — это же Dev ветка. В релизные ветки изменения мёрджаться только после QA на Dev ветке. Поэтому репозиторий можно собрать любому в любой момент, через интернет-портал и ни разу не было «подожди, ща доделаю».
Я о другом — git позволяет не менять привычек независимо от того есть у вас интернет или нет — вы продолжаете разбивать задание на маленькие кусочки, и делать маленькие коммиты, коммиты — это как история проекта, вы можете откатиться к предыдущему комиту, сделать бренч для фичи — интернет не нужен.
У нас просто другой принцип работы: изначально фича разбивается на части, на разные «таски»/«тикеты», каждый из которых — законченная часть, между которыми ты не скачешь. Это планирование дисциплинирует, помогает декомпозировать задачу.
Это не тоже самое, что и ctlr+s, это намного могущественнее :) Но вы правы, что не всем это нужно — это больше зависит от стиля и привычек.
Вот я о том и говорю — в нашей команде (судя по тому, что я читаю от оппонентов) по-другому построена работа. Случаев, когда Git был бы нужен локально за годы работы я могу вспомнить 2 или 3. У нас не бывает такого, что ты пилишь фичу и тебе нужно срочно пофиксить что-то в этом же модуле, вот прямо вчера надо пофиксить. Благодаря хорошо поставленному QA и «живому тестированию» на малых клиентах у нас не бывает ситуаций, когда надо сидеть и по ночам что-то пилить. Или переключаться с фич на фиксы. Плюс к тому под-команды организованы так, что в каждой группе люди примерно одного уровня и каждый может работать с каждой частью системы. Да, есть «свои» области, но что-то срочное может сделать другой. Например, пока я пилю фичу, мой коллега может сделать фикс и попросить сделать ревью на всякий случай. Для этого нужен только дифф, чтобы посмотреть, что он написал.
Такого, чтобы было нужно срочно прервать разработку и фиксить тот же модуль, за годы работы было 2-3 случая, я без проблем обошелся простым копированием в tmp папку и обратно. Отпуска, или неравномерная загруженность. Но это — исключения.
Проблема SVN — он заставляет менять привычки, и то, что в лучшую сторону — это очень спорно
Это если ваши привычки изначально гитовые. В нашем случае все наоборот.
MacIn
12.08.2016 13:50Два дополнения вслед:
1) Ни демо, ни установка клиенту никогда не идет из dev репозитория, только из стабильного/RC, поэтому каждодневные коммиты никак те ветки не ломают
2) Про «не надо ломать привычки» — Git стал массовым относительно недавно, если сравнивать с централизованными СКВ. Так что это вопрос открытый: переход в какую сторону заставляет менять привычки.
asm0dey
12.08.2016 08:41+2Если моя большая фича состоит из нескольких более маленьких фич и я хочу закоммитить каждую маленькую фичу, а запушить только большую — то в свне без сервера я так не смогу, а в гите — смогу. Коммиты должны быть атомарными, максимально дроблёными для того чтобы можно было bisect'ом понять, какой именно из них привнёс проблему.
MacIn
12.08.2016 13:16я хочу закоммитить каждую маленькую фичу, а запушить только большую — то в свне без сервера я так не смогу, а в гите — смогу.
Коммитится в центральный репозиторий каждая малая часть, хоть каждый день по нескольку раз (ведь мы разрабатываем одну часть, доводим до какой-то точки и потом переключаемся на другую). В чем проблема коммитить все изменения, не ломающие билд, в dev ветку?asm0dey
13.08.2016 07:32Так мы ж вроде обсуждали ситуацию когда центральный репозиторий недоступен?
MacIn
13.08.2016 18:45В разных командах по-разному. Я не могу начать работу без сети — не могу отметить начало рабочего дня. Да и для того, чтобы начать работать над другой фичей, перед чем нужно скинуть файлы в репозиторий, мне нужен доступ к трекеру, где собственно записано, что надо делать. Есть сеть — есть репозиторий, есть список тикетов.
Да и начать можно с того, работают ли вообще в конторе N люди удаленно?
У всех по-разному.asm0dey
13.08.2016 18:56А, ну я часто работаю из дома и мне нет никакой потребности иметь доступ к серверу гита чтобы начать полноценно работать. У меня часто бывает достаточно много задач, я прекрасно могу их форкать от мастера и мёрджить обратно без всякого доступа к сети. В офисе мне надо будет сделать просто pull --rebase и push.
MacIn
13.08.2016 21:56Я тоже работаю из дома, но мне по-любому надо отметить рабочее время, так что сеть — must have так или иначе.
asm0dey
13.08.2016 21:57Ну да, у вас специфический рабочий процесс. У нас время вроде никто не считает, считают выполнение задачи в срок.
MacIn
13.08.2016 21:59Зато сверхурочные и т.п. легко оплатить, потому что время учтено.
asm0dey
13.08.2016 23:09На прошлой работе у меня тоже были сверхурочные. Просто писал сколько времени лишнего отработал. Но в общем-то я никаких претензий к вам не имею — каждый использует те инструменты, которые ему нравятся и подходят.
avost
13.08.2016 07:23Для этого придуманы ветки. Комитьте в фичеветку, а в вашем пожелании слово пуш замените на мёрдж ;)
asm0dey
13.08.2016 07:32Так мы ж вроде обсуждали ситуацию когда центральный репозиторий недоступен?
avost
13.08.2016 08:21А, ну для этого есть же всякие hgoversvn или как там их называют. Когда на прежней работе один чистый чекаут занимал 40 минут это было спасением.
asm0dey
13.08.2016 08:28Собственно, в SVN всего две проблемы — сложные мёрджи из-за отсутствия трекинга файлов и переименований, а так же наличие центрального сервера без доступа к которому нельзя сделать несоклько коммитов
MacIn
13.08.2016 18:44сложные мёрджи из-за отсутствия трекинга файлов и переименований
Переименования отслеживаются в SVN
а так же наличие центрального сервера без доступа к которому нельзя сделать несоклько коммитов
Зачем? Нет, серьезно — как часто вам приходится работать без сети?asm0dey
13.08.2016 18:54Ну доступа к закрытому корпоративному серверу из дома у меня нет примерно никогда. Потому что он мне не нужен.
Про переименования — круто, не знал что уже сделали (но я правда очень давно ушёл с свн). А мёрдж в транк ветки второго поколения тоже уже нормально выполняется?MacIn
13.08.2016 21:58А мёрдж в транк ветки второго поколения
Не совсем понимаю, что имеется в виду.asm0dey
13.08.2016 23:11Мы бранчуемся от транка в ветку user-story-1. А от неё бранчуемся ещё раз в ветку user-story-1-new. А теперь хотим смёрджить user-story-1-new прямо в транк. Нормально отработает?
VolCh
12.08.2016 06:15+1Централизованной разработка бывает крайне редко, в подавляющем большинстве случаев (если исключить команду из одного человека) она ведётся распределённой.
MacIn
12.08.2016 13:13Мне кажется, мы вкладываем в «централизованный» разный смысл.
VolCh
12.08.2016 15:11Я — все исходники, ресурсы и т. п., хранятся на серверах, там же и правятся, на локальных машинах если и есть что только копии ссервера бинарников и т. п., с сервера на локальную машину разработчика происходит только пулл, если вообще происходит.
MacIn
12.08.2016 15:23Я имею в виду именно центральный репозиторий, из которого происходит автосборка и деплой. У каждого полная копия того, с чем он работает, в локалке.
leventov
11.08.2016 18:54— Но это начинает работать, только когда очень большая команда и очень большой проект. А когда это в рамках небольшой компании, достаточно централизованной, то тут преимущества Git не дает?
— Тогда нет, конечно. Если маленькая команда, и если мы еще к тому же стараемся не делать много бранчей, или, например, всё разрабатываем только в одной основной ветке с так называемыми feature-флагами — тут преимущества Git теряются. Особенно, если маленькая команда.
Не согласен. Как раз для маленькой команды (в предельном случае — один человек) Git/Mercurial гораздо удобнее тяжеловесного SVN. А главное премущество SVN как раз существенно на больших проектах — можно работать с поддеревьями
Shamov
11.08.2016 21:23+1Вообще само противопоставление ложно. Git и SVN — это не две взаимоисключающие альтернативы. У нас на работе вообще TFS в качестве хранилища кода. Однако ничто не мешает мне использовать Git локально, а в основное хранилище коммитить только после того, как успешно смержу новый код с чужими изменениями внутри своего репозитория.
leventov
11.08.2016 21:32То есть вы считаете, что неполноценность (неудобность) TFS без локального Git — это нормально и так и должно быть? Какие преимущества дает TFS?
Shamov
11.08.2016 22:45TFS используется только потому, что в нём одновременно есть ещё и система тикетов, и какие-то чисто менеджерские инструменты для анализа того, на что уходит время. Но если отвечать на поставленный вопрос, то… да, я считаю, что неполноценность TFS — это нормально. В том смысле, что это неизбежно. Это один из законов Джона Галла: «Любая система по мере роста постепенно утрачивает основные функции.» Другими словами, TFS нельзя ни починить, ни заменить равным по функциональному охвату аналогом, который был бы лучше. Можно лишь как-то компенсировать отдельные его недостатки при помощи других систем.
gvsmirnov
11.08.2016 21:27+1Вообще слабо представляю, как можно разрабатывать в основной ветке и спокойно спать, разве что если релизить раз в месяц.
Есть две фичи: одну делать две недели, другую одну неделю. Как зарелизить вторую фичу через неделю и быть уверенным, что work in progress первой фичи ничего не сломает? При использовании feature branches — легко. Но если коммитить открыто и смело и прямо в trunk, то будет тяжеловато.
Случайно поставил минус комментарию, сорян
antonarhipov
11.08.2016 21:38Если «фичи» делать отключаемыми, то теоретически должно и с одним trunk-ом всё получиться.
gvsmirnov
12.08.2016 00:36+1Ага. Нужен очень надёжный механизм включения/ выключения :) Это, конечно, и для других целей полезно будет. Но нельзя же все изменения делать отключаемыми? Сложный багфикс, например, может занять несколько дней и в промежутке система может быть в разбитом состоянии. Или крупная переделка в некоторых частях сразу.
А какие популярные и железобетонные подходы к отключению фич ты пробовал?antonarhipov
12.08.2016 01:19+1Не, только про «фичи» разговор, не про бакфиксы. А фичи стандартно — через конфигурацию, какая бы она не была. Переменные окружения, например. Железобетонно работает если фича достаточно изолирована.
А вообще, если подумать, что мешает это же и к багфиксам применить? Наверное, ничто не мешает.
MacIn
11.08.2016 22:32А в чем проблема? Все коммитится в транк, фичи, прошедшие QA, мёрджатся в релизные ветки. Что именно вы считаете «тяжеловатым»?
n43jl
12.08.2016 00:07+1Также с 1 единственным trunk-ом и pull request-ами фич слышал о таком workflow: замержить pullrequest может только другой разработчик, который должен сначала сделать code review. Вообще, эта идея мне очень понравилась:
1) code review само по себе отлично и мне кажется может сильно поднять общий уровень команды и качество кода
2) решает проблему совместного владения кодом
3) взгляд со стороны может помочь выявить ошибки до merge pull requestMacIn
12.08.2016 15:32У нас workflow при работе с SVN построен так:
1) В транк (дев ветка) может коммитить любой что угодно, что не ломает компиляцию и юнит тесты (ну и то что не ломает фнукционал явно)
2) Транк — только для разработчиков, клиенты его никак не видят, на их работу ничто не влияет
2.5) Если код сложный и ты не уверен, запрашиваешь у коллеги ревью по номеру тикета, в котором записаны все твои коммиты
3) Когда нужно заdeployить что-то клиенту, сначала конкретная сборка (по номеру) из транка тестируется QA, они дают добро на мёрдж в RC ветку
4) Из dev в rc мерджатся конкретные коммиты для этой функции
5) rc конкретной версии тестируется QA как на эту фичу, так и на основной функционал (периодически)
6) Прошедшая все проверки rc версия штампуется как стабильная и может быть установлена клиенту или на демо-сервер.
Естественно, в случае, если все сработало и код не отправлен на доработку.
gvsmirnov
12.08.2016 00:38+2А из транка нужные фичи как выбираются? Cherry picking? А всякие svn-ы так умеют, или нужно вручную конкретные файлы переносить? А если две фичи один и тот же файл изменяют? А если команда больше и фич в разработке много?
MacIn
12.08.2016 15:22А из транка нужные фичи как выбираются? Cherry picking?
По revision, если одни куском или по номеру таска, что проще.
А всякие svn-ы так умеют, или нужно вручную конкретные файлы переносить?
И так и так можно. Можно… ща выгвоворю… смёрджить фичу в другой бранч целиком. А можно руками (иногда приходится руками, в силу разницы между ветками, тут никто не поможет, никакая СКВ).
А если две фичи один и тот же файл изменяют? А если команда больше и фич в разработке много?
Конфликт, ресолв, пересобрать, проверить, мердж.gvsmirnov
12.08.2016 17:58То есть в svn можно отдельно взятые ревизии перетащить из транка в релизную ветку? В целом, спасибо за информацию. У меня от svn только воспоминания баттхёрта, но я им никогда и не учился правильно пользоваться :)
MacIn
12.08.2016 18:24Тут есть, например:
https://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-merge.html
Merging a Range of Revisions секция
antonarhipov
11.08.2016 21:40А чем SVN тяжеловесен?
leventov
11.08.2016 21:48Как минимум, необходимостью иметь и админить свой сервер. Гугл-код закрыли, остался только вроде помоечный sourceforge из публичных и бесплатных, которые поддерживают svn? И то не знаю, как там с приватными репами. Для Git есть Bitbucket, Gitlab. Завел проект за 5 минут и вперед.
@gvsmirnov выше написал, почему он не располагает к мелким коммитам, бранчам c экспериментами, активной параллельной работе в нескольких направлениях. Это то, что нужно в начале проекта.
antonarhipov
11.08.2016 22:00+1Погугли, «svn hosting». То, что несколько популярных сервисов не предоставляют поддержку svn не делают его автоматически тяжеловесным :)
n43jl
11.08.2016 22:00+4К примеру, созданием веток. Я бы может быть и смерился с тем, что SVN для ветки все копирует и весить она может очень много по сравнению с git. Больше всего мне не нравится, что в SVN нельзя создавать ветки локально, коммитить локально, и решать позже — хочешь ли ты чтобы это попало в центральный репозиторий или тебе нужно еще что-то закончить или вообще этому не место в центральном репозитории.
antonarhipov
11.08.2016 22:11А и ещё, в Git ведь тоже можно с поддеревьями работать. Не знаю, на сколько хорошо это работает, но команда такая имеется.
leventov
11.08.2016 22:27Я имел ввиду в первую очередь скачивание и пуш только поддерева, с которым работаешь. Натыкался на это. Но оказывается уже есть: http://stackoverflow.com/questions/600079/how-do-i-clone-a-subdirectory-only-of-a-git-repository, и довольно давно.
dim_s
11.08.2016 21:49+1Gradle мощный, но порог вхождения у него такой же как у maven'a, если не проще, можно не использовать всю мощь. Если инструмент просто настроить и просто с ним работать, а вся его остальная мощность тебе не нужна, но вдруг понадобиться? Что выбрать? Вот и выбирают gradle, еще все проекты для Android крутятся вокруг gradle.
Git уже давно пережил стадию «моды», но многим до сих пор кажется что это мода.antonarhipov
11.08.2016 22:05вся его остальная мощность тебе не нужна, но вдруг понадобиться?
Всё так. Точно так же мы склонные усложнять дизайн раньше времени, потому что «а вдруг понадобится? а вдруг надо будет расширять и вводить новые возможности» В результате имеем излишние абстракции и усложнения там где их могло бы не быть. Философская тема.
еще все проекты для Android крутятся вокруг gradle
Тут всё таки другая причина. Для Android Gralde стандарт не потому, что разработчики так захотели, а потому, что производитель так решил.
vektory79
12.08.2016 11:12+1Ну тут очень тонкий момент. И намой взгляд нужно смотреть в том ключе, а мешают ли те функции, которые на данный момент являются избыточными?
В случае с SVN/Git — у гита есть практически всё, что есть у SVN, но и много всего другого тоже. При этом наличие дополнительных возможносте практически никак не влияет, если его использовать как SVN. Как бы дико это не звучало. Но если понадобится, если команда дозреет, то можно просто начать использовать.
В случае с Gradle/Maven — все несколько сложнее. Да Gradle в целом функциональнее. Но это функциональность в ряде случаев может явно сыграть в минус и это ничем нельзя (пока) компенсировать.
К чему это я? А к тому, что я часто встречаю аналогичную аргументацию, мол сейчас не нужно, по этому будем использовать другое. А на практике оказывается, что когда дополнительная функциональность понадобилась — то уже поздно. Собственно, тот факт, что понадобились продвинутые функции уже и означает, что поздно. Нештатная ситуация — вот она, а средст для её разрешения нету.
Из личного опыта: у нас изначально использовался Mercurial. Хотя на первых этапах использование было в стиле SVN. Но когда понадобилось — никаких проблем.
При этом мы изначально взяли Maven. И до сих пор на нём. Но когда вылазят нестандартные ситуации, то начинается адъ и Израиль с Ant вставками. А иногда и до JavaScript вставок через Ant вставки дело доходит. Но и мигрировать на Gradle не можем т.к. энтерпрайз, много больших команд и нету полного доверия между разработчиками (привет вашему докладу с Барухом).
Так что не всё так однозначно и надо подходить к вопросу вдумчиво и осторожно.
sshikov
13.08.2016 20:55Но когда вылазят нестандартные ситуации, то начинается адъ и Израиль с Ant вставками.
Это, простите чисто ваши особенности. Тот же groovy вполне доступен из сборки maven, и очень давно был. gaven наверное уже лет 8 существует. И он поверьте, не менее гибкий в конечном счете, чем gradle — может быть просто слегка другой.
j_wayne
12.08.2016 07:34По поводу IDEA vs Eclipse. Работал в Eclipse более 10 лет. В этом году перешел на IDEA по трем причинам (в порядке убывания веса): месяцами не чинящиеся баги, в частности с лямбдами, невменяемый автокомплит (когда вместо своих классов сначала показываются одноименные классы из дремучих дебрей JDK), ужасная dark theme.
mikhailian
Недавно, когда я заикнулся в одной большой конторе о том, что пора использовать JRebel, на меня посмотрели, как на осла:
— «Попробуй тестовую версию, но только не давай рабочих контактов. Потом будешь полгода отмазываться от их липкого маркетинга».
Не поймите меня превратно, вопрос был не в деньгах, просто с теми людишками команде не хотелось больше связываться.
23derevo
antonarhipov тут ваш маркетинг назвали земляным червяком!
antonarhipov
Вполне нормальная, человеческая реакция. А разработчики, как правило, очень чувствительны к такому проявлению внимания.
Shamov
Не такой уж он и липкий. Мне какой-то Шон написал всего два письма. В первом спросил, удалось ли мне всё установить и настроить. Во втором интересовался тем, пробую ли я чисто для себя или для всей команды. На каждое я ответил всего парой предложений и он отлип…
real_ales
Липкий маркетинг я получил от coverity, когда мне писали несколько раз и потом звонили из Ирландии(?) и просили соединить меня с моим руководителем, чтобы показать ему (раз уж я не могу принять такого решения) все преимущества полной версии продукта.
23derevo
какая жесть
gvsmirnov
Довольно распространённая техника у enterprise продажников. Даже мы что-то такое пробовали.
Потом в дурку забраПотом поняли, что продавать систему мониторинга нужно не через инженеров, и совсем поменяли стратегию.jbaruch
Сейлзы это, а не маркетинг. Сейлзы. И да, это как джава и дажавскрипт, звучит похоже, но совсем не то.
asm0dey
Один мой друг сказал что на определённом уровне начинаем продавать мы все. Главное дойти до этого уровня :)