17 января в 18:30

IDEA пора закапывать?

В этой статье я хочу поднять тему старения компаний и извечный вопрос: что делать простым пользователям? На примере IDEA. С графиками деградации и загнивания.

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

Данная история началась для меня с того, что на рынке появилась серьезная IDE для моего любимого Python — это PyCharm. В JetBrains, видимо, поняли, что у них хорошо получается делать IDE, а все IDE чем-то похожи, и, в общем, почему бы не захватить этот интересный рынок чуть более чем полностью. Как бы там ни было, в итоге помимо IntelliJ IDEA на свет появилось много замечательных IDE: PhpStorm, PyCharm, RubyMine, WebStorm, AppCode, CLion, DataGrip, Rider — вот скромный список с официального сайта, и, судя по слухам, JetBrains не планирует останавливаться.

Хочу заметить, что я считаю PyCharm не только лучшей, но и в принципе единственной на сегодняшний день вменяемой IDE для Python. И я считаю, что мне очень повезло, что этот продукт появился на свет. Какая радость забыть обо всех костыльных IDE и куцых редакторах, и перейти на PyCharm! Когда всё работает из коробки, это даёт замечательное чувство сосредоточения. Склоняешься над кодом, как старый часовщик, и со всей тщательностью и скрупулёзностью погружаешься в свою задачу. И ничто не отвлекает. И не лень протянуть руку за нужным инструментом, когда всё под рукой.

Пока я занимался своими делами, рос профессионально, компания JetBrains тоже росла, и очень активно. И если «рост» одного человека — это более или менее налаженный и всем понятный процесс, то рост компании — это большой вызов. Превращение маленького сплоченного коллектива в организацию из сотен человек — дело очень рискованное. И, в конце концов, даже если рост проходит успешно, от того маленького коллектива, как правило, практически ничего не остаётся. Компания теряет свою душу. Старые идейные сотрудники устают от однотипных задач и даже частично разбегаются. Новые приходят за высокооплачиваемым местом в стабильной и успешной компании, и на их фоне идейных становится всё меньше. Управлять компанией становится сложно, начинается бюрократизация, стандартизация процессов, и прочее. Новые цели и планки требует привлечения (или выращивания) маркетологов. Начальники всё меньше занимаются разработкой и всё больше менеджментом. Появляются новые амбициозные идеи и проекты, на которые начинают тратить львиную долю самых ценных ресурсов, а старые проекты превращаются в молчаливых грустных лошадок, тянущих всю эту компанию.

Одним из дурных знаков для меня стала смена иконок. Я любил старые иконки, они были очень детально прорисованные и потому хорошо различались зрительно. Но кто-то решил, что сейчас в моде плоские минималистичные иконки. Потом изменилась иконка самой IDE, и мне стало сложно отличить PyCharm от терминала в панели задач. Так в мой инструмент пришел маркетинг, и сделал мою рабочую среду красивее, но менее удобной.

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

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

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

Я не люблю опирать свои выводы на эмоции, и поэтому решил поискать хотя бы немного объективных фактов. Благо, у JetBrains есть замечательный продукт YouTrack, в котором все ходы записаны. А ещё там можно создавать отчеты. Я создал отчёт Resolved vs New/Reopened Rate для продукта PyCharm с фильтром «Type: Bug», и получил вот такой красивый график:



График красив, но в нашем случае совершенно бесполезен. На первый взгляд всё равно: команда работает, баги открываются и закрываются. Но мне кажется, что за этим диким разбросом не видно истинной картины (еще там можно включить режим «Grouped», который немного проясняет, но все еще не убеждает). Эффективность анализа данных напрямую зависит от того, насколько удачно выбран способ представления данных. Чтобы разобраться в этих данных, для начала я импортировал их в LibreOffice.

Незатейливый JS скрипт экспорта данных в формат CSV на случай если вдруг кто-то захочет поиграться со статистикой
// Replace ID in URL.
$.getJSON(
    'https://youtrack.jetbrains.com/rest/current/reports/237-79?fields=reportData,oldData',
    function(data){
        var groups = data.reportData.groups;
        var output = '';
        for (var i = 0; i < groups.length; i++) {
            var el = groups[i];
            output += el.timestamp + ',' + el.positive + ',' + el.negative + '\n';
        }
        console.log(output); 
    }
);


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



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



Вот оно — моё смутное сомнение, материализованное в диаграмме. Количество багов росло всё это время. И их стало аж три тысячи. Если профильтровать тикеты запросом вида Type: Bug State: Open,Submitted,{In Progress}, то их столько и будет: «Found 3009 issues.»

Не надо быть бабой Вангой, чтобы предсказать, что для других IDE этой компании будет примерно такая же картина.

IntelliJ IDEA (удивительно отлаженный и равномерный процесс накопления багов):



RubyMine, PhpStorm, WebStorm ол тугезер:



Есть такая забавная байка, которая гласит примерно следующее: когда проект растёт и обрастает функционалом, количество багов в нём тоже растёт прямо пропорционально количеству функций, и это нормально. Поскольку эта история довольно популярная, я потороплюсь сразу же возразить. Нет, это не нормально по нескольким причинам. Во-первых, недоделанный функционал — плохой функционал. А во-вторых, мы с вами, как программисты, прекрасно понимаем, что добавление новых фич порождает баги не только в новом функционале, но и в старом. И чем больше этих багов накапливается, чем реже делается рефакторинг с целью их тотального искоренения — тем больше проект начинает напоминать «нечто с ручками».

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

Теперь, когда JetBrains стал неприлично большим, согласованность будет стоить гораздо дороже. И если все главные умы компании, устав от рутины IDE-строительства, перестанут придумывать новые способы делать IDE еще лучше, и переключатся на новые интересные и амбициозные проекты, как язык Kotlin, тогда IDEA ждёт неминуемая деградация.

На самом деле, я думаю, появление других IDE на основе IDEA — это было начало конца. Нет, не компании, конечно же. Такой огромный маховик будет крутиться еще долго. Это конец того продукта, о котором компания может честно заявить: «это то, что мы умеем делать хорошо».

Когда производитель переходит от стадии раскрутки к стадии снимания сливок, от былого качества остается лишь брэнд. А что делать нам — простым разработчикам? Снова искать альтернативы? Уходить в монахи вимеры? Или пилить свою IDE с блэкджеком и плагинами? У меня нет ответа на этот вопрос. Надеюсь, он есть у кого-то из читателей.

PS: Большое спасибо разработчикам из JetBrains за их замечательные продукты. Искренне желаю вам успехов в любых начинаниях, и в глубине души всё же надеюсь, что вы найдёте способ привести в порядок текущие проекты.

PPS: Понимаю, вопрос дискуссионный, и наверняка найдется много людей, несогласных с моим мнением. С кармой я уже попрощался ) И всё же, надеюсь на конструктивные комментарии.
raacer @raacer
карма
106,0
рейтинг 4,0
Самое читаемое Разработка

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

  • 0
    • 0
      Следует сначала создать отчет: https://youtrack.jetbrains.com/reports/resolveRate/create
      а затем заменить ID отчета (237-79) на свой.
      • 0

        У меня никак не получается сделать отчет на такой большой рендж. Может поделитесь сырыми данными?

        • +1
          На какой продукт?
          Я делал вот так

          • 0

            На Idea, попробую добавить фильтрацию по типу.

            • +1

              Окей, помогло.


              http://imgur.com/a/X3EmI


              Так вот, репортили всегда больше чем фиксили :)

              • 0
                Не знаю почему, но у меня картинка получается более размазанная.
                Ну в общем о том и речь, что репортов больше.
                • 0
                  Можно предположить что там есть и дубликаты, не воспроизводимые или просто никем не обработанные, но на самом деле исправленные баги.
                  Вопрос к тестировщикам из JetBrains.
                  • 0
                    Можно предполагать всё что угодно, но факт остается фактом: среди этих задач есть серьезные проблемы, которые не исправляются годами.
  • +37
    У вас в посте уже все написано: дейтвительно, в любом живом и развивающемся проекте количество багов и фича реквестов растет пропорционально размеру кодовой базы. Вот если их количество вдруг начинает уменьшаться — пиши пропало, проект исчерпывает себя.

    В любом количественном анализе важно не только цифры посчитать, но и правильно интерпретировать. С этим у вас явные проблемы. Вы пытаетесь рационализировать то, что давно известно эмпирически. История про растущее количество багов — эмпирическая, а не рациональная. В этом причина вашей ошибки.
    • +5
      количество багов и фича реквестов растет пропорционально размеру кодовой базы. Вот если их количество вдруг начинает уменьшаться — пиши пропало, проект исчерпывает себя.
      Я считал только баги. Фича реквесты не считал.
      • 0
        Окей, это не очень важно, на самом деле. Суть в том, что я с вами не согласен методически.

        Но вброс годный, да :)
        • +55
          Для меня очень важно. 3000 багов, и среди них те, которые мешают мне работать, висят годами. А кому из разработчиков мешали старые иконки — мне совершенно не ясно. Они могли мешать только маркетологам.
          И это не методика, это просто число, чтобы заценить масштаб трагедии :) Меня лично больше беспокоит не количество, а то, что эти баги мешают работать.
          • +7

            Судя по графику в IDEA 16k багов.


            Не могу вспомнить хоть одно issue, которое мне сегодня мешало бы работать и я его ощущал на себе :)

            • +4
              Я много таких помню.
              Часть очень быстро закрывалась (несколько дней для тестовых билдов), часть бала незначительными, но длительными и популярными (например, FTP keep alive) и часть (фичи) решалась плагинами.

              Я однозначно могу сказать, что проект становится лучше. Несмотря на множественные баги.
              Количество сил ограничено, и они грамотно разделяют их между багами и фичами.
              • +2

                Я тоже репорчу баги (когда есть EAP — использую EAP) и их закрывают. Я скорее о том, что лично для меня нету критических багов, которые мешают работе, я наоборот жду когда запилят мои фича реквесты.


                @raacer давай-те ваш список багов, которые мешают жить. Будем ставить пальцы в youtrack ;)

                • +12
                  Мне что, надо каждый раз плакаться на Хабре, чтобы мои баги позакрывали? :)

                  Спасибо большое за Ваш энтузиазм и стремление помочь. Я ценю Ваше предложение. Я также вполне ожидал, что мнение многих людей не совпадёт с моим в целом либо в деталях. Тем не менее, я не думаю, что та проблема, которую вижу и испытываю я, может быть закрыта несколькими исправлениями. Я рассматриваю баги как индикатор производственных проблем. И я думаю, что если эти проблемы не устранить, баги всё равно будут возникать снова и снова. Я бы проголосовал за то, чтобы в компании на какое-то время заморозили разработку новых фич и занялись исправлением ошибок и, самое главное, рефакторингом кода и/или производственного процесса (в зависимости от того, что является причиной всех этих багов).
                  • +1
                    Я бы проголосовал за то, чтобы в компании на какое-то время заморозили разработку новых фич и занялись исправлением ошибок и, самое главное, рефакторингом кода и/или производственного процесса

                    Этого, конечно, не будет, т.к. одни только багфиксы по платной подписке — это чересчур. Отдел маркетинга будет в шоке, да и пользователи, которых сейчас всё устраивает, тоже. Так что в лучшем случае больший процент времени на эти вещи смогут выделить.

                    • +10
                      Я думал они именно поэтому подписку сделали. Продукты и так крутые, а если выкатить релиз с багфиксами народ не поймет зачем покупать новую версию если и так ок.
                      А по подписке оно как-то норм.
                      • +1
                        Так, на сколько я помню, звучит официальная версия — та, которую хотят слышать покупатели. На деле же по количеству новых фич и багов я бы не сказал, что они там занимаются полировкой.
                      • 0
                        Подписку сделали, чтобы получить больше денег.
                  • 0
                    Рефакторинг — бесконечный процесс.
                    Да, давайте им займемся.
                    • +3
                      Это сарказм? Ну, давайте никогда не заниматься рефакторингом, раз Вы так считаете.
            • +4
              в Resharper каждый день достает глючный Ctrl+1/Ctrl+Shift+1
              причем им я пользуюсь куда чаще чем какими то сложными рефакторингами.
              • +2

                ctrl+shift+backspace туда же

              • 0
                Alert123 а что конкретно с ним достает? на это есть тикет?
                • +1
                  наверное есть, в саппорт я писал давно еще, в новых релизах так ничего и не изменилось.
                  запомненное место просто пропадает при редактировании/copy/paste кода в этой области (простой кейс: запомнили место 1 и место 2, в месте 1 сделали Cut для части кода, перешли в место 2 и сделали Paste, вернуться в 1 больше нельзя). Да и значёк закладки сбоку не отображается если строка пустая.
                  • –1
                    и в Idea кнопки Back/Forward с тулбара в какой то из версий пропали. Скролишь код мышью, изучаешь, нажимаешь Ctrl+LeftClick чтобы перейти к определению функции — а обратно вернуться нельзя, вы бы эти Back/Forward в углу рядом с поиском добавили.
                    • +1
                      Crtl+Alt+Left/Right
                      • 0
                        это надо знать, бросать мышь и тянуться в клавиатуре. Можно и в главном меню покопаться и найти. Но если есть переход с помощью чисто мыши то и возврат должен быть так же интуитивен.
                    • 0

                      возьмите и добавьте сами

                    • +6

                      Куда пропали?
                      По-прежнему на месте:


                      • 0
                        только сейчас нашел где этот тулбар включается. Раньше потыкал на главном меню и оставшихся кнопках — там в контекстном меню нет ничего, с тех пор считал что насовсем убрали.
                        • +1
                          Кнопки-то нашлись, но осадок неприятный остался :-D
                          • 0
                            неудобство работы с настройкой «по умолчанию» — на мой взгляд такой же баг, тем более раньше было — а потом пропало.
                            • 0
                              Ну не скажите. Одно дело, когда задумка неудачная, и совсем другое дело, когда то, что задумали, не работает так, как задумали. И то, и другое — важные проблемы, но причины их возникновения немного разные.
                            • +5

                              То что убрали тулбар — исключительно верный ход. Больше места должно быть для кода, ничего не должно отвлекать. На это нужна была смелость, потому что все привыкли за 30 лет видеть иконки undo, redo, cut, copy, paste, но при этом никогда, НИКОГДА на них не кликают. Тут JetBrains молодцы.

                              • 0
                                (del)
                              • –4
                                Если лично ВЫ никогда, НИКОГДА на них не кликаете, то это не означает, что оставшиеся 99,9999% пользователей их тоже не используют.

                                JetBrains был основан всего 16 лет назад и не мог IDEA выпускать как вы выразились уже 30 лет. Значит вы говорите об классическом UI текстовых редакторов, в обучении работы которым на курсах и в самоучителях всегда делается акцент на работу с мышкой (шорткаты для гиков, которые читают справку).

                                Лично я, когда ем во время работы бутер или яблоко, то тоже вместо комбинаций клавиш могу прощелкивать мышкой. И еще знаю очень, ОЧЕНЬ много людей (преимущественно старшее поколение), которые используют в своих офисных пакетах исключительно кнопки тулбаров, а наличие шорткатов считают от лукавого. Но я же не буду из этого выводить псевдостатистику, что все, ВСЕ пользователи используют исключительно тулбар и компания IDE своим решением сознательно мешает продуктивной работе программистов ;-)
                              • –1
                                Для «не отвлекать» есть Distraction Free Mode, а сокрытие тулбара — не более, чем следование моде на минимализм.
                    • 0

                      В меню View нужно включить тулбар (не помню, как оно точно называется, IDEA нет под рукой). После установки идеи — первая вещь, которую делаю, как раз из-за этих кнопочек.

          • +18
            А кому из разработчиков мешали старые иконки — мне совершенно не ясно.

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


            И это не методика, это просто число

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

            • +6
              Я такой разработчик. Надеюсь, что JetBrains продолжит и дальше улучшать иконки
              Я и не смотрю, конечно, давно все убрал, но новые разработчики пугаются.
              То есть иконки стали настолько хороши, что Вы их убрали совсем?
              А почему новые разработчики пугаются модных современных иконок?
              Вот он, маркетинг в чистом виде.
              Вы неверно поняли мой посыл. Я имел в виду, что число не доказывает корреляцию между ростом ошибок и усложнением моей работы. Такое доказательство потребует целой научной работы. Поэтому приведенное число не является методикой оценки глючности продукта. Проводить параллели я предлагаю самостоятельно.
              • 0
                Вы их убрали совсем

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

              • 0
                А почему новые разработчики пугаются модных современных иконок?

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


                число не доказывает корреляцию между ростом ошибок и усложнением моей работы

                Тогда зачем оно вообще в топике и о чем топик вообще? Если проблема в том, что вам субъективно стало неудобнее работать, так бы и написали. Зачем было делать вид, что хотите доказать корреляцию, графики строить? Я и говорю — маркетинг.

                • +2
                  Вы знаете. Вашу речь про иконки(их убирание) не понял и я.
                  Как-будто из ваших предложений убрали некоторые части.
                  Я догадываюсь, что вы убрали старые иконки, а когда вышли новые, то их добавили?

                  Топик дискуссионный и не подразумевает доказательств.
          • +4
            Толчком к измнению иконок было появление Райдера. Нужно было решение, которое не будет чужеродным ни для пользователей Visual Studio, ни для тех, кто уже пользуется средами на платформе IntelliJ.
            • 0
              Ничего, что новый визуальный ряд начали разрабатывать в начале 2014 года, когда о райдере только начинали думать?
              • +1
                Мысль о том, что в IntelliJ нужны новые иконки появилась позже, чем новый дизайн JetBrains. Конечно, это связанные вещи, я сказал о том, что послужило толчком к этому.
            • +1
              Это же и есть маркетинг. На функциональность это мало влияет.
              • +3
                Отделять визуальную составляющую от функциональности — ошибка. В любом продукте важно не только то, что он умеет, а ещё и то — легко ли этим пользоваться или легко ли отыскать нужную функциональность. Юзабилити, прости господи. А это неразрывно связано с тем, как что выглядит.
                • +1
                  Я подозреваю, что в данном случае речь не о юзабилити, а об эстетичности и привлекательности, что, как ни странно, оказывает большее влияние на прибыль, чем количество незакрытых багов. Даже для IDE.
                  • 0
                    Нет, именно юзабилити. Если кнопка явно отражает зачем она нужна без необходимости задерживаться на ней, чтобы получить подсказку, это именно удобство, а не эстетика.
                    • 0
                      А при чем это к «решению, которое не будет чужеродным для пользователей Visual Studio»? В этой ветке обсуждается другая гипотеза. И я высказывал своё понимание сути конкретной гипотезы про «нечужеродность». А Вы — о юзабилити…
                      • 0
                        Я к тому, что люди привыкли к примеру, к зеленой стрелке, которая чаще всего означает «build». Если в проекте поменяли иную иконку на такую, то это вопрос удобства, а не красоты.
                        • 0
                          Я с вами согласен. Только я говорю о сильном изменении стиля иконок, а не о цвете.
                • +3

                  Видимо именно из-за улучшившегося юзабилити баг IDEA-162686 не остался незамеченным пользователями, а набрал уже более сотни голосов и комментариев.


                  И что же видят пользователи в ответ?
                  Надуманные обоснования того, зачем это сделано и незавуалированное желание спустить всё на тормозах с прямыми призывами отозвать свой голос.

          • +6

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

            • 0
              Можете ссылку на плагин дать, не получилось найти? Очень тяжело с новыми, сине-серые тона на темном фоне я плохо различаю.
                • 0
                  Кстати, это не те иконки, которые были раньше, еще до того, как иконки стали постоянно меняться.
                  • +1

                    можно скачать архивную версию IDEA и по аналогии создать "Icon Pack 2014" например.

                    • 0
                      Ок, как там говорят… ждём ебилдов? :)
                      Я просто обратил внимание, что речь совсем не о об этих новых синеньких иконках, а как раз о тех желтых, которые предлагаются в плагине. То есть это событие произошло намного раньше.
          • +18

            Вы же не предлагаете людей, которые рисуют иконки, пересадить на исправление багов? Будет только хуже, уверяю. Это разные люди, они несовместимы :-)

            • –2
              за деньги людей, которые согласовывают/меняют/утверждают иконки можно нанять хоть сколько-то программистов, которые действительно сделают продукт лучше.
              • +3

                Денег хватает и так у JetBrains. А количество не всегда переходит в качество.

            • +1
              Мне больше волнует то, какие задачи в приоритете у начальства, и в каком направлении думают начальники.
              • +1

                Большинство задач — это инициатива снизу. По крайней мере в IDEA Core, насчёт PyCharm не знаю.

          • 0
            не очень понятна цель статьи на самом деле. и мало примеров действительно критичных багов
            • 0
              Цель — обсудить проблему и возможные решения того, что продукты портятся.
      • +4

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


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

        • +1

          Вы намекаете, что эти тысячи тикетов никто из разработчиков даже не прочитал? Если хоть кто-то хоть раз прочитал, то тип тикета точно актуален, это меняется за секунду.

          • +2

            в какой-то момент их становится столько, что реально включается внутренний фильтр на прочтение каждого тикета. В какой-то из версий YouTrack даже добавили признак "Triaged".
            И да, старые и неактуальные баги тоже закрываются, если заметят что он уже исправлен как-то. Лично сам несколько таких "закрыл" просто прокомментировав что баг уже не воспроизводится

            • +1
              в какой-то момент их становится столько

              Столько — это сколько? Я ж не говорю, что их все надо ежедневно перечитывать… а за день новых тикетов вряд ли появляется столько, что невозможно успеть пробежаться по ним и статусы расставить.


              старые и неактуальные баги тоже закрываются, если заметят что он уже исправлен как-то

              Такое бывает. Но это не относится к теме неверных типов у тикетов.

          • 0

            Почему вы решили, что тот, кто читает новые тикеты, первым делом меняет их тип? Не такое уж это и важное поле.

            • 0
              Если разработчикам не важно, фича это или баг (в чём я не уверен, но это возможно, да), то это только усугубляет проблему.
            • +1

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

              • +1

                Я вполне могу поверить, что вы так делаете первым делом. Но это отнюдь не означает, что все остальные так делают.

                • +1

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

        • +1
          Вы можете привести пример тикетов у JetBrains, в которых забыли исправить тип? Если Ваше предположение об их большом количестве верно, то, наверно, для Вас не составит труда найти несколько таких тикетов.
          • +4

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


            • Recognize NTFS junctions — если NTFS junctions никогда до этого не поддерживались, я считаю, что их поддержка — новая фича.
            • Analyze->InspectCode doesn't find a relatively simple singleton — инспекция ищет определённые виды синглтонов по их внешнему виду. Поддержать новый вид — это фича, а не баг.
            • Integration tests are not renamed when the class is renamed — при переименовании класса Foo идея предлагает заодно переименовать FooTest, но не предлагает переименовать FooIT. Определённо поддержка нового суффикса — это фича. Маленькая, косметическая, но всё же фича.
            • Propose to change access level for method reference — есть инспекция, но к ней нет квик-фикса. Сделать новый квик-фикс — однозначно фича. Хотя кому-то может показаться, что отсутствие квик-фикса — баг.
            • No completion inside lambda when instance of contains lambda — внутри expression-лямбд после выражения instanceof не удавалось воспользоваться code completion с учётом знания об уточнённом типе переменной. Кто-то может подумать, что раз что-то работает вне лямбд, то отсутствие этого в лямбдах однозначно бага. Однако это новая фича языка, которая весьма нетривиальна во многих аспектах (в том числе для полноценного вывода типов в недописанной лямбде), поэтому поддержка чего-то внутри лямбд, что работало вовне (а внутри лямбд не приводило к ошибкам, не ломало код а просто не работало), скорее фича, чем бага.
            • 0
              что для кастомера бага, для разработчиков может быть фичей

              Вот с этим я категорически не согласен. Когда у пользователя что-то не работает или работает не так, как ожидается, то это баг, реже enhancement или usability problem, но не фича.
              Фича — это когда добавляется функциональная возможность, которой раньше вообще не было (с точки зрения пользователя), а не улучшение работы существующих возможностей.

              • +3

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


                Многие люди (и я в том числе) считают синонимами слова feature и enhancement применительно к issue type. К примеру, в JetBrains YouTrack вообще нет Enhancement, а в OpenJDK JIRA есть enhancement, но нет feature. Словоблудие это всё, работать надо, а не классифицировать задачи по коробочкам.

              • 0
                > Вот с этим я категорически не согласен.

                Если баги в JetBrains сортируете не вы — вряд ли ваше мнение учтут
                • 0

                  А его и не обязательно как-то специально учитывать… судя по примерам lany, у тех, кто сортирует баги в JetBrains, мнение просто совпадает с моим :-)

    • +2
      Тут, извините, как в старой шутке из книги «Физики шутят»: «Хорошо, Смит, эффект вы обнаружили, теперь попытайтесь найти причину» под картинкой со взорвавшейся установкой.
      Эффект обнаружен — широкоиспользуемая IDE становится все более глючной. Ладно, мы поставили точку, сказали, мол, это естественно и все такое, ведь проект развивается. Делать-то что с этим?
      • +1

        А вы считаете, что проблема только в сфере IDE и остальной софт с каждым релизом становится все быстрее и стабильнее?

        • +2
          Везде по-разному.
          Например, у нас принято иметь три ветки: стабильная, RC и DEV. В стабильную идут только исправления, в RC — только исправления и незначительные улучшения, в DEV — все, что угодно. Стабильная ветка — да, с каждым релизом становится все быстрее и стабильнее. У клиентов — стабильная, RC и DEV получают только те, с кем это предварительно оговорено, те, кто участвуют в предварительном реальном тестровании.
          • 0

            Ну так и у JetBrains есть EAP.

            • +1
              В последнее время я стараюсь не устанавливать обновления PyCharm сразу после нового мажорного релиза, а дожидаюсь следующего минорного. Делаю так, потому что надоело участвовать в этой EAP, на которую я не подписывался.
              • 0

                EAP это не совсем то, на что вы подписывались. К вам по подписке приходят релизы. На EAP надо именно отдельно подписываться.

                • +5
                  Я шучу. Имею в виду, что мажорные релизы похожи на EAP.
                  • +5
                    Имею в виду, что мажорные релизы похожи на EAP.

                    Тут я с Вами согласен, но абсолютно с точки зрения наоборот: когда я пользовался EAP года 4 назад, это была именно EAP и для работы не годилась, падало, брыкалось, что только ни делало, лишь бы не работать. Сейчас же я сижу исключительно на EAP сборках и они очень редко валятся с критическими ошибками.


                    Касательно статьи в целом — плюс за поднятие темы, но минус за рассмотрение проблемы с эмоциональной точки зрения "вы меня задолбали, я ухожу, вот вам гневное письмо". Как активный репОртер, я знаю, что есть баги, которые не являются критическими (low priority) или воспроизводимыми (вроде и важный, но проявляется при куче совпадений у одного человека. Все об этом вроде знают, но сделать ничего не могут). Так же есть баги, которые уже давно устарели (здесь проблема разбора ютрака, а не фикса багов, также проблема того что репортеры зачастую не комментят баг как "May be closed as obsolete/unreproducible" и такие баги (хотя по факту уже давно ими не являющиеся) висят годами и никому не мешают, приорити не растёт, в списке вверх не поднимается).
                    Так же, как выше заметили, кол-во пользователей растёт, кол-во репортов растёт. И это не значит что багов стало больше, часть из них старые, но ранее не зарепорченные. Плюс к этому зоопарк плагинов, поддержка новых фреймворков в ядре как плюс к увеличению разных комбинаций для выявления бага в уже (может быть, лет как 6 назад) написанном коде.


                    Но да, частично (очень незначительно) я с вами и согласен, поскольку есть баги, которые мешают жить, но, почему-то, только вам. Например я пользуюсь сплит-видом без тулбаров и табов, и не всегда точно помню, который файл открыт рядом. Уже давно прошу просто показывать имя файла в углу, как, например, https://jsfiddle.net/ делает. Но я отчётливо понимаю, что так IDE пользуется крайне мало людей, и ещё меньше из них способны и имеют желание зайти на ютрак и оставить схожую просьбу/поставить +1 моей просьбе. Оно так и висит 2.5 года.
                    Я так понимаю, что практические единственный способ что-то исправить/улучшить если запрос крайне непопулярный — это PR в open source CE. Ещё можно на форуме у них поспрошать, может через разбор бага (или её важность) до разработчиков не дошла.


                    UPD: Ну конечно же ещё есть такой фактор как правильно оформленные баги. "У меня тут что-то не работает" фиксится крайне редко.

                    • 0
                      Тут я с Вами согласен, но абсолютно с точки зрения наоборот: когда я пользовался EAP
                      Очень радует, что EAP релизы стали стабильнее. Но меня волнует стабильность мажорных релизов, которые я просто боюсь устанавливать, т.к. глюки и ошибки сильно выбивают меня из колеи и мешают делать работу.
                      «вы меня задолбали, я ухожу, вот вам гневное письмо»
                      А я не говорил, что я срочно куда-то ухожу :) Я просто поднял тему. Уходить или нет — я еще не решил. За анализ мне никто не платил, так что хватит с меня эмоций. Заниматься анализом прежде всего в интересах самой JetBrains, и я уверен, они им занимаются. Может быть этот пост будет поводом для них поанализировать еще чего-нибудь. А всё то, чем мы тут занимаемся — это, в основном, чистой воды предположения.

                      Уже давно прошу просто показывать имя файла в углу
                      Это не баг. Важно, конечно, но совсем не баг.
                      • +1
                        Это не баг. Важно, конечно, но совсем не баг.

                        Да, конечно, тут я неправильно выразился. Для этого у них есть отдельный тип Usability Problem. Что обычно приравнивается по важности к багам или около того.

      • +6
        Эффект обнаружен — широкоиспользуемая IDE становится все более глючной.
        На самом деле утвержение спорное. Аргументацию автора статьи очень трудно назвать исчерпывающей.
        • +3
          А в статье нет аргументаций. Есть только мнение и немножечко фактов, которые, все же, надо еще сопоставлять и переваривать. Статья адресована тем, кто так или иначе сталкивается с этими проблемами. А кто не сталкивается — тех нет смысла в чем-то убеждать, пусть себе радуются на здоровье. Наверное, стоило об этом написать в самой статье.
    • +7
      Как-то я слушал главного по разработке Visual Studio, когда он приезжал в Россию, так вот он хвастался графиками убывающего кол-ва багов в каждой версии vs, при том довольно неплохо убывающего.
      • 0
        Значит они работают над архитектурой и качеством кода — рост числа багов это сигнал о проблемах с архитектурой и/или качеством кода.
        • +2

          Только не стоит забывать, что после "Значит они работают над архитектурой и качеством кода" есть ", а не над фичами".

          • +14
            А мне вот нравится такой подход. Пусть сначала позаботятся о существующих основных фичах, сделают всё надёжным и стабильным, а потом уже выдумывают тысячу пятьсот дополнительных фич на все случаи жизни.
            • +3

              полировать до блеска можно вечно не созидая при этом ничего более

              • +5
                К чему эти крайности?
                • –1
                  А как вы поняли что это крайность?
                  В том идея что линия за которой крайность у всех разная. Просто у вас (пользователя, у которого нет тысячи сотрудников, которые хотят ЗП) линия очень близко к полной стабильности, а у них (надо и фичами юзеров приманивать) дальше.
                  • 0
                    А как вы поняли что это крайность?
                    Вечность — это бесконечное количество времени. Больше уже некуда. Чем Вам не крайность?
                    Просто у вас (пользователя, у которого нет тысячи сотрудников, которые хотят ЗП)
                    Ну да, у каждого свои проблемы: у кого суп жидкий, у кого бриллианты мелкие. Ну и что теперь? Пусть разработчики напишут статью о том, как их задолбали недовольные пользователи вроде меня :) Заодно расскажут свою версию, почему багов становится больше.
          • 0
            ну логично — пока старые фичи не стали стабильно работать нечего за новые браться, тем более что новые фичи это шлифовка — самое главное давно сделано и важнее чтобы оно надёжно работало
            • 0
              >> самое главное давно сделано и важнее чтобы оно надёжно работало
              Это вы, наверное, про vi?
    • +7
      Это не говоря уже о том, что количество зафиксированных багов != количеству багов в коде. Пользовательская база растет — фиксируется больше багов. В конце концов, не все баги раздражают настолько, чтобы их репортить.
      А еще мне интересно, отсеивались ли дубликаты.
      • 0

        Вроде как по стейту только брались Open, Submitted, In Progress.

        • +2

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

          • +1
            помеченные дубликаты не могли попасть по этим состояниям.

            Конечно не могли, есть state=Duplicate и то, что он является Resolved по сути, это уже второстепенно, а то что он уже не Open, Submitted, In Progress — определяет попадёт он в выборку или нет. Если по стейтам не фильтровать, а просто брать по типу, то тогда попадают. В общем-то в основном этим и объясняются некоторые пики зарепорчено/зарезолвено. Было пару больших проблем в истории с кучей дубликатов.

    • +3
      в любом живом и развивающемся проекте количество багов и фича реквестов растет пропорционально размеру кодовой базы


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

      А что надо пофиксить в методике?
      Мне пока приходит в голову:


      • Defect density вместо общего количества (вопрос, как вычислить какую-то метрику размера при закрытом коде)
      • Добавить какую-то классификацию по серьезности багов
      • 0

        IDEA Community открыта, весь код PyCharm Community в неё входит, считайте на здоровье. Думаю, картина для закрытой части принципиально отличаться не будет.

  • +10

    Кидайтесь камнями, но я, не смотря на мою любовь (убывающую, правда) к IDEA, искренне верю в будущее Language Servers.


    Когда IDE будут меряться рендером шрифтов, отзывчивостью и удобством (мне например очень понравился VS Code), а работу по анализу сорцов будут делать IDE независимые language server-а (как это у Haxe сделано например).


    Имхо это прекрасное будущее разработки тулинга. У IDEA сейчас прекрасный анализ кода. Это заставляет открывать её вместо VS Code когда надо сделать рефакторинг. Но поправить пару строчек — проще открыть Atom, Code, Vim, Nano, etc…


    И тут я вижу два сценария — IDEA начнёт поддерживать LS, либо IDEA останется аутсайдером, но имхо мотивации контрибьютить в LS гораздо больше, чем в IDEA.

    • 0
      1. Если вдруг, когда-то, появится LS для Java лучший чем в IDEA, IDEA просто возьмет его себе. Уже сейчас можно включить LS для TypeScript.
      2. IDEA это не только LS, это еще 100500 фич и интеграций.
      3. Отзывчивость vs code и atom субъективно хуже чем IDEA. У IDEA есть "проблема" со временем старта. Из шела очень удобно делать idea file, и редактировать прямо в IDEA.
      • +5
        Если вдруг, когда-то, появится LS для Java лучший чем в IDEA, IDEA просто возьмет его себе. Уже сейчас можно включить LS для TypeScript.

        Уже есть рабочий вариант (на основе Eclipse JDT), который используется в плагине к VS Code от RedHat.


        Отзывчивость vs code и atom субъективно хуже чем IDEA.

        Ладно атом, этот ещё тот тормоз, а что не так с отзывчивостью у VS Code? С самых ранних версий очень шустро работал.


        Из шела очень удобно делать idea file, и редактировать прямо в IDEA.

        "code file", или "code ." чтобы открыть целую папку в VS Code.

        • +3
          Уже есть рабочий вариант (на основе Eclipse JDT), который используется в плагине к VS Code от RedHat.

          А, так он на JDT? Там постоянно нестыковки со спецификацией Java. Их, конечно, чинять, но не так быстро, как хотелось бы. Идеевский аналайзер джава-кода, на мой взгляд, точнее соответствует спецификации. Ну и рефакторингов/фиксов в JDT просто в сто раз меньше, чем в IDEA.

          • 0
            Ну и рефакторингов/фиксов в JDT
            А вот это тоже может быть следствием чего угодно.
      • +1
        1. Уже делают. Не с нуля. Вопрос времени, я думаю.
        2. Для этого в LS есть понятие "Client". Тот, кто рисует результат анализа и позволяет его редактировать. И я хотел бы иметь возможность выбора, да.
        3. Это простите как? Что тогда вы понимаете под отзывчивостью? Я просто очень известный в узких кругах неудачный юзер IDEA где у меня всё тормозит. Когда 200-300ms от нажатия кнопки до появление символа при редактировании Kotlin исходников например — это отзывчиво или нет?
        • +4

          Они собираются значительно ускорить отзывчивость редактора в новых релизах, сделали так называемый Zero latency typing.


          Скрытый текст
          • +7
            Интересно. Из картинки выходит, что IDEA сейчас самая тормознутая из всех.
            • +6

              Да, это чувствуется не иллюзорно. :)
              Я долго привыкал. Что-то не так, какой-то дискомфорт, а что именно сразу не ясно, потом понимаешь, что дело в отзывчивости редактора.

              • +2
                Попробуйте отключить spell-checker, иногда неиллюзорно помогает с отзывчивостью
                • +1

                  Всегда первым делом его отключаю. Немного помогает, но задержка всё равно есть.

          • 0
            • +1

              Так то да, но в PyCharm 2017.1 EAP уже завезли, значит и на всех остальных IDE появится с новыми релизами.

          • 0

            Довольно странное решение сравнивать IDE c редакторами текста.

            • 0

              Ну, они именно сам редактор текста сравнивают, причем именно latency самого редактора, а не всяких там автодополнений и прочих наворотов.

        • +2

          вот ещё, на тему отзывчивости IDEA:
          https://gyazo.com/9895e2bbeb933a6ede7841bfb97b2153


          Никогда такого не видел в Atom или VS Code, даже на огромных проектах

        • +2
          Когда 200-300ms от нажатия кнопки до появление символа при редактировании Kotlin исходников например — это отзывчиво или нет?

          1. Попробуйте по-отключать всё, что покажется ненужным, в разделе Inspections.
            Отключение Spelling здорово помогало.


          2. Еще есть параметры для Autopopup в Code completion, и Autoreparse в Editor/General. Их лучше увеличить, чтобы не мешались при редактировании.
        • +1
          1. и 2. Пока LS не показывает удивительных результатов(на примере TS) — он тормознутее чем то что есть в IDE. Имо, в будущем, в первую очередь это будет востребовано в языках которые не сильно популярны, и где делать поддержку для каждой IDE невозможно.


          2. Никогда такого не было и вот опять https://drive.google.com/file/d/0B90geJfEOzlzWWoza1N3SDFuMzg/view?usp=sharing

          Когда 200-300ms от нажатия кнопки до появление символа при редактировании Kotlin исходников например — это отзывчиво или нет?

          Вот именно эти 200-300 мс я ощущаю в vs code, стоило только у нему добавить пяток плагинов. Атом такой с самого начала. Можно поискать достаточно старый пост, где делали обзор именно скорости ввода символов. Скорость показывания подсказок с IDEA сравнивать бессмысленно, разве что если в IDEA включить power-save mode.

        • +1
          3. Про отзывчивость частично согласен. Иногда IDEA начинает выдавать заметный latency при наборе текста, причём замечаю это всё чаще и чаще последнее время. Но в «нормальном» режиме (80% времени на вскидку) latency набора текста гораздо меньше, чем в Atom/VSCode. Иными словами: IDEA либо мгновенно отрисовывает буквы, либо тормозит, существенно раздражая. Atom/VSCode имеют стабильный и заметный latency, не приятный сначала, но потом привыкаешь.
        • +1
          Когда 200-300ms от нажатия кнопки до появление символа при редактировании Kotlin исходников например — это отзывчиво или нет?

          Странно что про scala плагин никто не пишет. Отзывчивость там секундами, а иногда и десятками секунд, измеряется.
    • +2
      отзывчивостью и удобством

      проще открыть Atom, Code

      Надеюсь не наступит таких времён, когда браузеры заменят нормальные редакторы кода, делая вид, что они отзывчивые и быстрые.
      • +1
        atom и VS code работают поверх браузерного движка
    • +2

      Как заработать на Language Servers?
      Подозреваю, что количество желающих заплатить за удобную IDE несколько больше, чем количество желающих прикупить лицензию на LS в надежде, что IDE станет работать лучше.
      Нет денег — нет будущего.

      • +2
        Куда нести donation на language server для связки perl+sql+javascript+html в одном коде, и чтобы всё это корректно распознавалось и работало в vim?
  • 0
    Хочу заметить, что я считаю PyCharm не только лучшей, но и в принципе единственной на сегодняшний день вменяемой IDE для Python


    emacs + spacemacs, не холивора ради. Нет чудо-интерфейса, зато работает из коробки и очень даже хорошо.
    Да, я в курсе что уже 2017й. Но пока не нашел что PyCharm может а Emacs нет (в плане ежедневной работы со сложными Python проектами).
    ЗЫ: это все ИМХО, на вкус и цвет…
    • +5
      Спасибо.
      А он может трёхколоночное сравнение версий из git? аннотации из git? переход на определение унаследованного метода?
      • +3
        Да, может, magit называется
      • +2
        Все есть, звать magit

        Вот пара скринов:
        — Трехколоночными диффами не пользуюсь. вот 2
        — Аннотации, репо это не оч активно, для иллюстрации достаточно

        По поводу перехода — есть, входит в слой python (layers в spacemacs) Мышкой не кликнешь (emacs же) но M+.(точка) делает дело. Ходит по родителям и поддерживает virtualenv.
    • +11
      Попробовал я emacs + spacemacs, порог входа гораздо выше, что-бы открыть и поредактировать заняло минуты и гугления. Поиска файлов нет (issue с 2015 года), открыл python файл, нет ни автокомплита ни перехода к определению. Хотел поставить jedi для автокомплита, но его нет в списке предложенных модулей, ok, нагуглил как подключить список, установил jedi, но автокомплита все ещё нет, то ли нужно жать магические кнопки, то ли надо запустить jedi сервер, то ли конфигурировать его надо. Вообщем чем дальше тем глубже в лес, а результата нет.
      А Idea — запустил и работает.
      • 0
        Не спорю, Idea проще если начинать совсем с «пустого листа».
        Если же есть опыт vim — то у spacemacs все не так уж и плохо :) + spacemacs очень активно развивается, сейчас все проще, добавляешь python в layers и он сам все поставит (включая anaconda mode) который и дает и отличный автокомплит и все плюшки.
        По поводу поиска файлов — есть helm (включен по дефолту) который ищет файлы в проекте по типу quick search в atom.

        И да. Это все нужно найти и прочитать. Порой не хочется тратить время.
        • 0
          Что-то я не понял… В имакс добавили эмуляцию вима??
          • +3
            Evil Mode. Шорткаты из вима, все остальное из emacs. Больше ненужно ломать мизинец.
          • 0

            Добавили, только есть проблемы с поддержкой переключения языков, с работой в минибуффере и с совместимостью с другими плагинами. Но того, что есть, уже достаточно для того, чтобы переключиться с вима на имакс, да :)

    • +4

      У Emacs очень большой порог вхождения. Чтобы настроить окружение для разработки на Emacs, надо потратить месяцы, а то и годы. И это непрекращающийся процесс. Постоянно что-то меняется, что-то начинает конфликтовать, и т.д. и т.п. Надо читать тонны документации, хорошо знать elisp. И с большими сложными проектами все равно все будет подглючивать, тормозить, не будет так удобно. Например, Idea не поперхнувшись слопает огромные сложные HTML с inline CSS и Javascript. Все раскрасит и весь код поймет. Для Emacs это святой грааль — что-то абсолютно недостижимое. Да даже просто распарсить сложный проект на Javascript, чтобы получить нормальную навигацию и автодополнение, по-моему, нереально. На больших проектах там все время что-то внутри этого elisp'а ломается, перестает работать, или работает неправильно.


      С Python чуть получше, но до уровня PyCharm не дотягивает значительно.


      Справедливости ради, в последний раз пользовался Emacs очень давно. Но уверен, что ничего не поменялось.

      • +1
        Согласен что у Emacs ооочень большой порог вхождения, поэтому стоит +spacemacs. ;)
        • 0
          Вы меня прямо таки заинтриговали. Лет 10 назад пользовался emacs, но надоело его настраивать: любой плагин был сырым и недоделанным, все приходилось допиливать. Неужели сейчас всё изменилось?
          • 0
            Гляньте http://spacemacs.org

            Ну и мой конфиг, по большому счету все стандартно, только модули да пара визуальных настроек:
            • 0
              Уже посмотрел. Но там не указано, придётся ли допиливать все плагины напильником :)
              • +1
                Ну об этом нигде не пишут :) PyCharm тоже не говорит что поддержка flake8 — дело не простое :)

                По моему опыту: пилить ничего не нужно, совсем. Указанный конфиг — все что я переношу на новую систему, плагины все из melpa/elpa и ставятся spacemacs автоматом.
                Из неприятного — иногда складывается впечатление что управляешь космическим кораблем, слишком уж много настроек, но если в них не лезть — все ок. Конфиг открывал раз 10 за 2 года, а вот emacs мануал… раз в неделю — точно ;)
                • 0
                  Похоже, пришло время снова пощупать emacs ) Вот еще дождусь приезда новой клавы — будет как раз в тему ;)
                  Vortex POK3R RGB

                  • +4
                    Теперь понятно, почеиу вам иконки не понравились
                    • 0
                      Нет, это не связано с цветастой подсветкой на фотографии.
                  • +2
                    Мне после 10 лет пользования обычным емаксом spacemacs не понравился. Его слои очень глючные и очень специфичные, а по сути просто компоновка уже имеющихся плагинов из melpa, которые авторы скомпоновали по своему усмотрению. И если вы захотите что-то поправить, то вам нужно будет разбираться еще и со слоями. А вы захотите. Вообще на мой взгляд слои для perl, js и php сделаны по принципу «чтобы было» и «давайте соберем все плагины какие есть».

                    Если вы привыкли к IDEA, въехали во все ее фичи за годы, то на emacs вы уже не перелезете, слишком высоа планка и слишком много возни с инструментами. В emacs вы сможете продуктивно работать с проектами любой сложности, но делать это придется абсолютно по-другому нежели в IDE, активно используя внешние инструменты.
                    • +2

                      Я бы сказал так: Emacs — это редактор текста. Да, расширяемый, да, мощный. Но это редактор. Причем, очевидно, что какие-то детали реализации препятствуют превращению его в IDE или еще более удобный редактор.


                      Например, подсветка синтаксиса в нем реализована так, что для каких-то языков почти невозможно сделать Emacs mode с быстрой и корректной подсветкой (Javascript, смесь языков в одном буфере). Например, Idea может подсветить и дать редактировать строку в Python проекте как SQL запрос. Для Emacs — недостижимая мечта. Детали его внутренней реализации препятствуют интерпретации буфера более чем одним способом. Какие-то костыли есть, но они работают из рук вон плохо.


                      Idea еще работает с проектом как с единым целым. Например, если в шаблон проекта на Django я передаю экземпляр класса, то Idea уже умеет это понять, и автодополнение полей класса работает при редактировании шаблона. Для Emacs это — недостижимая планка. Ну, может быть какой-нибудь энтузиаст сделает это в следующие 10 лет. Только надо будет потратить неделю на настройку, затем тратить три дня каждый раз на подстройку под каждый проект, и все будет подглючивать и работать чуточку не так, как надо. И еще, через 10 лет, в тренде будут уже другие технологии.

                      • +1
                        Например, Idea может подсветить и дать редактировать строку в Python проекте как SQL запрос. Для Emacs — недостижимая мечта.

                        В org-mode можно делать в тексте вставки кода и работать внутри них, используя режим для языка, на котором написан этот код. Уже вот сегодня.


                        Например, если в шаблон проекта на Django я передаю экземпляр класса, то Idea уже умеет это понять, и автодополнение полей класса работает при редактировании шаблона. Для Emacs это — недостижимая планка.

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

                        • +3

                          Теоретически все так. Практически, к тому моменту, когда я забросил Emacs, пилилась много лет такая вещь, как поддержка HTML с inline CSS и Javascript для Emacs. Так вот, это не работало нормально.


                          Нет ничего недостижимого, Emacs очень расширяемый. Но почему-то не выходит ни у кого. PyCharm из коробки подхватывает любой мой проект. Будь там virtualenv или buildout, Django или еще что-то. Практически не надо ничего настраивать. Сразу все начинает работать максимально корректно. Можно ткнуть мышкой в instance.frobnicate() и моментально перейти в определение метода frobnicate, даже если он определен в яйце, установленном где-то buildout'ом в виде zip.


                          Не спорю, что теоретически всего этого возможно добиться в Emacs. Но с какого-то момента желание заниматься собственно проектом пересиливает желание заниматься подстройкой и борьбой с багами в Emacs.

                      • +1
                        Вы во многом правы. Но это не мешает мне годами заниматься коммерческой разработкой в emacs. Потому что я нахожу этот инструмент удобным и приятным в работе, даже после того как перепробовал несколько разных IDE.

                        Я бы сказал так: Emacs — это редактор текста. Да, расширяемый, да, мощный. Но это редактор. Причем, очевидно, что какие-то детали реализации препятствуют превращению его в IDE или еще более удобный редактор.


                        Именно, это редактор, и поэтому я не требую от него многого. К IDE у меня ожидания весьма завышеные — поэтому когда в емаксе что-то работает в 90% случаев это нормально, но когда в IDE все работает в 95% случаев, то это на лично мой взгляд того не стоит.

                        Например, подсветка синтаксиса в нем реализована так, что для каких-то языков почти невозможно сделать Emacs mode с быстрой и корректной подсветкой (Javascript, смесь языков в одном буфере). Например, Idea может подсветить и дать редактировать строку в Python проекте как SQL запрос. Для Emacs — недостижимая мечта. Детали его внутренней реализации препятствуют интерпретации буфера более чем одним способом. Какие-то костыли есть, но они работают из рук вон плохо.


                        Верно. Для таких случаев я использую narrow-mode(временно обрезает буфер до выделенного фрагмента) и в нем меняю режим. Сейчас правда уже появился web-mode, который вполне терпимо переваривает кашу html/php/js.

                        Idea еще работает с проектом как с единым целым.


                        В emacs есть projectile. Чисто для справки — просто удобная вещь.

                        Например, если в шаблон проекта на Django я передаю экземпляр класса, то Idea уже умеет это понять, и автодополнение полей класса работает при редактировании шаблона. Для Emacs это — недостижимая планка.


                        Автодополнения нет, и скорее всего не будет никогда на том уровне что есть хотя бы в eclipse. Проблема в том, что если реализовать в emacs все то что нужно для автодополнения на таком уровне, то и тормозить оно будет как eclipse. А зачем нам еще один eclipse написанный на медленном elisp, когда у нас есть замечательный emacs?

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


                        Когда на одном проекте можно сидеть годами, тогда настройка под проект в принципе оправдана.

                        И еще, через 10 лет, в тренде будут уже другие технологии.


                        К сожалению даже плагины для IDE допиливают годами до вменяемого состояния. Я уже не говорю про не сильно популярные языки. Перлу 30 лет в обед, IDEA больше 10 лет, а плагин для нее для поддержки языка существует буквально пару лет.

                        В целом же недостатки описанные вами абсолютно справедливы, но во-первых они не всегда критичны, а во-вторых даже не всегда недостатки. Ну и специфика работы бывает разная — для многих людей IDE и правда будет наиболее рациональным выбором с точки зрения эффективности и затрат времени.
                        • +3

                          Выскажу резюме своего опыта. Я очень любил Emacs и пользовался им более 10 лет. Скорее даже ближе к 14-15.


                          В какой-то момент мне понадобилось срочно поработать с запутанным проектом на Javascript, где было очень сложно разобраться без возможностей Idea по парсингу Javascript. Даже синтаксис у меня в Emacs подсвечивался плохо.


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


                          До этого я тоже был противником IDE и очень любил Emacs. Даже пописывал на elisp, к сожалению, исходники своих творений, видимо утерял, хотя у кого-то они могли остаться. Это было еще до GitHub.


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


                          До PyCharm ради интереса пробовал различные IDE: Eclipse с плагином (забыл его название), NetBeans, Wing — это все тогда даже рядом не стояло по возможностям и удобству. Поэтому всегда возвращался к Emacs. Но вот PyCharm перевернул ситуацию, потому что очень хорошо сделан.

                          • 0
                            Очень интересный опыт, спасибо.
                            У меня все наоборот:
                            Долгие годы «прыгал» vim, Eclipse, TextMate, Vanilla Emacs, даже PyCharm (года 3-4 назад), но потом попался spacemacs. Пропала большая часть геморроя с настройками и плугинами, все просто работает.
                            Есть пара нюансов:
                            — часто приходится работать с файлами на других машинах (рабочая среда у одного из проектов в облаке) и тут PyCharm туговат;
                            — также приходится работать на «слабом» железе (хромбуки, mbair 2011) у которого не очень то хотелось отдавать много памяти IDE;
                            — многоязычность. Python, Erlang, C, yaml(не то чтобы язык), HTML, JS, CSS. К счастью последние 3 мало, но вот с первыми 4мя у emacs проблем нет;
                            — может я и Control Freak, но все чаще замечаю что коллеги с PyCharm нередко «забивают» на архитектурные решения, оправдывая мол «ну в PyCharm же видно будет»

                            И да коллеги шутят что олдфаг на имаксе и каждый раз спрашивают «а имакс так может?» но пока ответ «может» — я и думать не думаю переходить.
                            Вот такая история.
                            • 0
                              может я и Control Freak, но все чаще замечаю что коллеги с PyCharm нередко «забивают» на архитектурные решения, оправдывая мол «ну в PyCharm же видно будет»
                              Ничо се… Я вот задумался, что PyСharm толкает меня на то, чтобы я не использовал «import as». А тут такое заявление об архитектуре, то есть зависимость от IDE проявляется не только в мелочах.
                              Приведите пожалуйста пример, на какие архитектурные решения PyCharm позволяет забивать?

                              И да коллеги шутят что олдфаг на имаксе и каждый раз спрашивают «а имакс так может?» но пока ответ «может»
                              И это до сих пор никого не натолкнуло попробовать Emacs? Наверное, тяжело учить кнопки и отвыкать от мыши? )
                              • +1
                                Не то чтобы я PyCharm винил в чем-то, к редактору это отношения мало имеет, это все человеческие недочеты, но «import as»ы, модули в 1к строк и черт знает как названные переменные и методы проскакивают все чаще и чаще. Просто IDE (PyCharm в данном случае) делает работу с этим ужасом проще, вот люди и расслабляются.

                                А вот пробовать emacs никто не хочет, ибо все убежденны что emacs ничего не может и он для задротов. Я и не агитирую, дело личное.
                            • +1

                              Кстати, после перехода на PyCharm я установил IdeaVim и перешел на Vim. То есть, когда мне надо написать простой скрипт, или поправить конфиг, делаю это в Vim.


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


                              После перехода на Vim (и IdeaVIM) почти все симптомы туннельного синдрома прошли. Хотя IdeaVIM первые годы был довольно глючным, ну и переучиваться с клавиатурных сочетаний Emacs, которые у меня уже в подкорке за 10+ лет отложились, было непросто. Думаю, я за 7 лет намного хуже Vim изучил, чем помню Emacs. :( Уже нет ни времени, ни мотивации так глубоко вникать, как когда-то с Emacs.

                              • 0
                                Да, IdeaVim выручает. Только мне непонятно, как под ним пользоваться фичами самого редактора, которые висят на шорткатах, не работающих с включенным IdeaVim.
                      • +1
                        Я бы сказал так: Emacs — это редактор текста. Да, расширяемый, да, мощный.
                        Глупости. Всем известно, что Emacs — это хорошая операционная система, и единственное, чего в нём не хватает — это хорошего редактора.
                        • 0
                          Точнее, не хватало. Теперь в нём есть vim! :-D
                    • 0
                      Вообще на мой взгляд слои для perl, js и php сделаны по принципу «чтобы было» и «давайте соберем все плагины какие есть».
                      Почему Вам так кажется?
  • +1

    Да я даже не знаю. Во-первых, на тему ценовой политики. Продукты JetBrains имеют Early Access Program, в рамках которой вы можете использовать их продукты полностью бесплатно, в дополнение к этому ещё и имея самые последние фичи и апдейты. Да, там могут быть баги, но ничего супир-дупир критичного я лично не заметил, как раз на днях установил себе текущий последний EAP-билд PhpStorm. И честно обалдел от того, какая удобная IDE стала после того как я последний раз её открывал (где-то пол года или год назад).


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


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

    • +1
      EAP живут 30 дней и после релиза новые версии выходят спустя 3, а то и более месяцев. Раньше использовал WebStorm, потом решил не продлевать подписку после смены лицензионной политики, пробовал atom, brackets, но остановился на vscode.
      • 0

        Сейчас это не так. ЕАПы 2017.1 уже появились (IDEA Ultimate ещё в декабре), а релизы 2016.3 были в ноябре. Почти не было дырки.

        • +1
          Один простой пример — поддержка codestyle в Rider. Первые issues на эту тему заведены практически год назад и добивались новыми в трекере, а воз и ныне там. Пользоваться без этой поддержки невозможно в принципе, если стиль в чем-то не совпадает с дефолтным. Новые сборки выпускают реже чем раз в 3 месяца. Зачем такой ущерб нужен?
          Почти не было дырки.

          Так «почти» или не было? Ничего не поменялось значит. Раз была, то это уже шоустопер для:
          вы можете использовать их продукты полностью бесплатно, в дополнение к этому ещё и имея самые последние фичи и апдейты.
          • 0

            Ну если для вас 500 долларов в год (или сколько там лицензия стоит) такие большие деньги, значит ваше время не так ценно и устроить себе отпуск на пару недель, пока еапа нет, ничего не стоит.

            • +1
              А теперь читаем эту ветку полностью, про бесплатность не я говорил — это цитата.
              • –2

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

                • +1
                  Меня не устраивало то, что я получаю за деньги, пусть и копейки. Скорость апдейта ужасающа — для мира js пара месяцев — это много. Но js у меня только на сервере, на фронте C# (gamedev), причем под osx (основная платформа уже 4 года). Я ждал rider на замену xamarin studio, но все как-то никак. А теперь и от webstorm отказался — лицензия действующая, а не пользуюсь (и не собираюсь продлять) — перехожу на более быстро обновляющиеся и поддерживающиеся коммунити вещи. Бесплатность — это просто бонус и отсутствие неприятного послевкусия.
          • +5
            Новые сборки выпускают реже чем раз в 3 месяца

            Это не совсем так: начиная с приватного EAP новые билды выходят не реже, чем раз в месяц.
            Первые issues на эту тему заведены практически год назад и добивались новыми в трекере, а воз и ныне там.

            Поддержка Code Style настроек появилась в прошлом EAP билде (https://www.jetbrains.com/rider/download/).
            • 0
              Попробовал — неплохо. Правда оно без остановки валит эксепшнами и пытается отправить их хозяину. Когда ориентировочно можно ожидать редактирования Code inspections (в плане нейминга переменных с разными модификаторами доступа)? То, что игнорируется версия целевого FW (например, FW3.5) и оно настаивает на nullable expressions и прочем треше из последних версий языка (и отключить это можно только по очереди отключая правила через quick fix, ибо другого способа нет) — это так и задумано?
              • +2
                Без остановки — это образно, или правда с открытия, и на любое действие? Если Вам будет не очень жалко, присылайте нам эксепшены посмотреть, пожалуйста.

                Для редактирования Code Style настроек для нейминга скорее всего еще не сделали UI, в качестве временного решения могу предложить настроить все как нужно в ReSharper, и Rider'у скормить. Либо подождать, пока мы протащим недостающие настройки. К сожалению, по срокам для нейминига сориентировать пока не могу, но работа в этом направлении ведется постоянно.

                Что касается версии Target Framework, какая версия тулсета установлена у вас, и какая выбрана в Settings > Build, Execution, Deployment > Toolset и что на эту тему говорится в .csproj? У нас была схожая проблема, но казалось, что ее победили.

                • 0
                  Без остановки — это каждые 5-10 минут. Отправил последнюю запись в логе:
                  Error Report: Created new issue DEXP-163500
                  osx 10.12.2
                  mono --version
                  Mono JIT compiler version 4.8.0 (mono-4.8.0-branch/f5fbc32 Mon Nov 14 14:10:00 EST 2016)
                  
                  dotnet --version
                  1.0.0-preview2-1-003177
                  

                  Но я не использовал запуск / отладку и тп — просто открыл старый проект (solution / csproj которого были сгенерированы unity3d 5.5.0 с TargetFrameworkVersion=v3.5) и начал его рефакторить.
                  • 0
                    Язык зависит не от того какой у вас выбран фреймворк, а от того, какой компилятор будет использоватся при билде. Укажите в настройках мсбилд постарее и свежие фичи последних шарпов отключатся. Или в настройках проекта явно укажите какой язык вы хотите использовать в нем — эта настройка добавит строчку ... в файл проекта и райдер также все это поймет и адаптирует инспекции =)
                    • 0
                      Для этого предназначена опция в проекте:
                      <TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
                      

                      Почему остальные IDE понимают, что нельзя использовать фичи языка выше, чем указанный целевой FW, а Rider такой особенный? Мне нужно получить на выходе валидный для целевого FW код (исходники), а не конечную MSIL-сборку, которую подхачит последний компилятор с разворачиванием сахара в правильные инструкции. Этот код потом подхватывается кастомным моно древней версии и собирается под себя.
                      • 0
                        Потому что никто не мешает скомпилировать data?.Text под .net 3.5 последним компилятором…
                        Покажите плиз фичи из других ИДЕ зависящие от версии шарпа и учитывающие эту пропертю проекта, буду очень признателен.
                        • 0
                          Прочитайте еще раз, что я написал: мне не нужна msil-сборка, которую прокатили распоследним компилятором и получили валидный бинарник под FW3.5, мне нужен исходный код, который сможет быть собран / выполнен древним рантаймом, который нельзя обновить / заменить. Нужен исходный код, не внешний бинарник. По поводу других IDE — возможно не так выразился: они не настолько умные (можно даже сказать тупые), чтобы везде толкать предложения по апдейту исходников под последний компилятор. В моем случае — это плюс, меньше информационного шума в среде разработки.
                          • 0
                            Enterprise, JAVA… выбираю версию в IDEA, под какой я хочу юзать JDK, выбираю саму версию JDK (прошу заметить, это разные вещи). И все «как нужно». Т.е. как раз то, о чем говорите и вы.

                            Т.о. я могу сделать вывод, что JAVA-код и тяжелые многолетние проекты под данной ИДЕ писать «вполне можно как».

                            P.S. Пояснения для тех, кто вне JAVA-World: мы выбираем сначала версию компилятора (и языка программирования), затем выбираем то «поколение» под которое хотим писать код. Т.о. я могу выбрать последнюю версию ЯП на сегодня (JDK v8.x) и затем выбрать поколение целевое. И писать на уровне JDK v6.x
                            • 0
                              <TargetFrameworkVersion>v4.6.1</TargetFrameworkVersion>

                              В .csproj файле как раз и означает за language level.


                              Runtime под которым будет запускаться указывается в файле app.config ключ <supportedRuntime version="v1.1.4322" />


                              Так что жалоба обоснована. Это действительно баг.
                              Но как по мне в EAP можно и забить. Вот в релизе уже должно быть пофикшено 100%

                          • +1
                            Я так и не понял почему вы не можете в настройках проекта выбрать ту «древнюю» версию мсбилда и соответственно компилятора, которая вам нужна. А не использовать последнюю, которая установлена на вашей машине и подетектилась по умолчанию ИДЕ.
                            • –1
                              Я так и не понял почему вы не можете в настройках проекта выбрать ту «древнюю» версию мсбилда и соответственно компилятора, которая вам нужна.

                              Вы предлагаете наставить несколько версий mono, включая целевую (еще неизвестно, есть ли они в виде готовых пакетов или нужно собирать из сорцов под osx) только ради того, чтобы в вашей IDE пропали навязчивые предложения все писать под C#6? Жестковато как-то.
                              • +1
                                Я предлагаю открыть либо
                                — настройки тулсета и выбрать там другой мсбилд меньшей версии
                                — настройки проекта и выбрать там нужный уровень шарпа

                                И я НЕ понимаю почему
                                — почему если не устраивает дефолтное поведение ИДЕ нельзя открыть один диалог и поменять 1 настройку чтобы было хорошо. Почему дефолтное поведение выбрано именно такое я попробовал объяснить, но видимо сдаюсь =)
                            • +1
                              Только сейчас заметил что хабр съел кусок моего комментария выше. За уровень шарпа в csproj отвечает тег LangVersion, который меняется в настройках проекта.
                              supportedRuntime в appconfig видимо тоже на это влияет.
                              А вот TargetFrameworkVersion с языком не сильно связны… Например в C# 6.0 есть только одна завязка на таргет фреймворк и связана она с фабрикой для интерполяционных строк. Все остальные фичи прекрасно компилируются и работают при меньших версиях таргет фреймворка =)
                              • –3

                                Не представляю где вы нашли LangVersion.
                                У меня в Vs2015u3 ни в свойствах проекта, ни в самом csproj файле такого нет...


                                Если в RiderIDE есть такой параметр — это сугубо самодеятельность JetBrains.

                                • 0

                                  Нет, все таки есть тег.

                                  • +1
                                    Вы так и не ответили на мой вопрос… Но переубеждать вас дальше у меня нет желания =)
  • +5
    Надо ещё на приоритеты смотреть. Сколько из накопленных дефектов Immediate и High?
    Накопление Minor дефектов — это нормально. На них часто все забивают.
    • 0
      Приоритет бага, который откровенно тормозит мою работу, не вселяет в меня оптимизма. Надо еще смотреть на то, кто эти приоритеты расставляет, и чем он руководствуется. Я смотрю прежде всего на свой опыт работы с IDE. А статистика — это просто для объективности, и чтобы не быть голословным.
      • +2

        Не все баги на вашем графике тормозят вашу работу.

        • +1
          Да, их там на всех хватит.
          • +13

            Вы определитесь, или это "крик души", или это статистически обоснованное утверждение.
            Если первое, то достаточно просто поругаться на IDEA, и не надо даже пытаться никаких графиков рисовать. Если второе, то комментарии "на всех хватит" — бесполезны. Надо показывать статистику по 1. качеству расставления приоритетов, 2. количеству не закрытых багов высоких приоритетов.

    • 0
      Не только приоритеты, есть еще голосование, тоже можно было учесть, насколько процесс направлен на то, что лучше большему числу пользователей.
  • +9
    Статья о том, что не бывает идеального ПО. И о том, что в ПО бывают баги и их кол-во растёт от роста популярности. Оно и так понятно. Остальное, типа плохого влияния денег на качество продукта — не только притянуто за уши, но и вообще странно звучит.

    з.ы. Для питона пользуюсь как раз eclipse+pydev, вроде нормально всё, чего ужасного. Всё работает — и стат. анализ и дебагер и редактор там гибкий довольно, что ещё надо то.
    • +1
      Вы считаете, что деньги не влиют на продукт? Когда руководящее лицо в интервью сообщает, что Kotlin решили делать статически типизированным, потому что это тулинг, IDE и деньги — это я за уши притянул что-то?

      Я не против, что компания зарабатывает деньги — она для того и существует. Но это факт, и это оказывает влияние. Как и то, что в случае чего я просто проголосую своими деньгами.
      • +3
        Вы считаете, что деньги не влиют на продукт?
        Я считаю, что деньги влияют на продукт в лучшую сторону. Не вижу ни одной причины быть по другому и не припомню ни одного примера, чтобы вливание денег в продукт его попортило. Зато множество обратных примеров есть.

        Потому я был готов, например, к тому что на мой комментарий ответят «ну сравнили eclipse pydev и pycharm, вот pycharm в нём вот то и вот это». Я бы даже спорить не стал, а только напомнил о том, что неплохо бы цены сравнить. И «цены» тут не про конечного пользователя (знаю я и про бесплатные варианты), а именно про «коммерческость» продукта. Даже тут были куча тредов про то, как и чем жава тулзы от JetBrains лучше эклипсовских (я и тем и тем пользовался, на самом деле тут есть о чём поспорить, но больше вкусовщина). С другой стороны, и программисты большинства компонентов эклипса не лаптем щи хлебают, там свои спонсоры и весьма серьёзные. Без этого где был бы эклипс? Сомневаюсь что где-либо, даже в таком нелицеприятном упоминании вашего поста. Хотя тот же pydev на донате, и при этом весьма юзабелен.
        Когда руководящее лицо в интервью сообщает, что Kotlin решили делать статически типизированным, потому что это тулинг, IDE и деньги — это я за уши притянул что-то?
        Про ситуацию с kotlin особо не в курсе, потому оценить причём тут деньги не могу. Но считаю пусть лучше продукт развивается, становится статически типизированным, пусть тулинг иде и деньги, чем гордо загибается. Потому возможно и притянули, да.
        • 0
          Я Вам — про одно, Вы мне — про другое.

          Вы говорите о влиянии заработанных денег. Заработанные деньги — это следствие курса на деньги. Я говорю о влиянии курса на деньги на направление и способ развития проекта. Фичи, на которых зарабатывают деньги — это не всегда, и часто совсем не те фичи, которые помогут мне сделать мою работу быстрее.

          Пример — всё те же многострадальные иконки. Их «улучшили» для того, чтобы захватить больше рынка. В качестве результата пришли деньги. Но, поверьте, деньги зарабатываются не для того, чтобы сделать продукт лучше, а наоборот: продукт делается лучше для того, чтобы заработать деньги. И вот это «лучше» подразумевает прежде всего продаваемость, а не эффективность самого продукта. Если он хорошо продаётся с багами — его будут продавать с багами. Часть денег пускают на реинвестирование — грубо говоря, на новые иконки. А другую часть — на то, что хочется. И это далеко не обязательно исправление ошибок, и особенно, если это не делает основную кассу.
          • +2
            Вы говорите о влиянии заработанных денег. Заработанные деньги — это следствие курса на деньги. Я говорю о влиянии курса на деньги на направление и способ развития проекта.
            Но, поверьте, деньги зарабатываются не для того, чтобы сделать продукт лучше, а наоборот: продукт делается лучше для того, чтобы заработать деньги.
            Это всё жонглирование логическими посылками. Коммерческой компании приходится держать курс на деньги, чтобы заработать денег, иначе она перестаёт существовать или становится неэффективной. А заработать денег нужно, чтобы были ресурсы развивать продукт. Он же делается в любом случае «лучше» по вашим словам, ну так и славно. Сомневаюсь, что вы знаете всю коммерческую подноготную конкретно компании jetbrains, например. Вам просто не нравятся иконки или что-то там ещё итд итп. Можно, как вы сказали, в таком случае просто проголосовать рублём и уйти на другую систему, а это ПО пойдёт дальше так или иначе развиваться и зарабатывать деньги (что, ОЧЕВИДНО, является основной целью как компании jetbrains, так и программистов в ней). «Не нравится» — дело обычное, пользователи нашей системы, например, тоже иногда сетуют что чего-то не нравится (возможно, иногда даже справедливо). Прислушиваться — это правильно, но как сказал Г.Форд, «если бы я слушал чего хотят люди, они до сих пор ездили бы на телегах».
            • 0
              Ну, Вы всё верно написали, и я о том же говорю. Ну не нравится мне что-то — что с того? Компания будет идти своим путём. Для такой большой компании моё мнение вряд ли имеет решающее значение, если вообще имеет хоть какое-то, и в этом нет ничего предосудительного. Это всё — очевидные истины, достаточные для понимания того, что я лично мало влияю на глобальное положение вещей, и мне надо либо смириться, либо искать другие способы решения своих задач. В этом и состоит вопрос: что делать?
    • +1

      Я с идеей почти не стыкался, зато постоянно пользуюсь другим их продуктом — решарпером. По моим скромным наблюдениям в том самом релизе в котором ввели новую лицензионную политику наступил феерический п… провал.
      Огромные куски функционала отваливаются напрочь (юнит тесты? да кому они вообще нужны, не критично), производительность падает временами ниже плинтуса (настолько что студия с ООМ валилась, но это тоже не критично), все время какие-то феерические косяки (нерабочий инсталлятор? Ну и ладно, не критично, главное — релиз есть, как его установить — дело десятое).
      Впервые за много лет релизы по качеству скатились до уровня былых ЕАР, нужен доброволец который проверит что очередным "релизом" вообще возможно пользоваться и только после этого все апдейтятся.
      Связи этого непотребства с ростом популярности не вижу в упор.

  • +28
    IDEA пора закапывать?

    Нет. Только истеричных белок с такими заголовками.
    • +1
      Багов прибавилось это я тоже заметил, местами подсветка кода пропадает ( в новых шаблонах ES6 в длинном шаблоне подсветка отключается ), анализ хрень выдает и тд.
      Но все баги что мне попадались абсолютно не критичны и активно правятся.
      Пока другим IDE до IDEA 3 года на оленях по Сибири.
      Надеюсь так же будет и дальше и они не потеряют высокое качество своих IDE.

      А вот с иконками абсолютно поддерживаю новые иконки адское дермище!
      Решил эту проблему вот этим плагином IDEA 2016.2 Icon Pack.
  • +1

    Не скажу, что баги вылазят с заметной частотой и парочку, которые я репортил они закрыли довольно оперативно.
    Однако, пользуясь IDEA примерно с 2012 года (сначала Intellij, потом PyCharm и Android Studio) на одном и том же ноутбуке, замечаю что работать становится всё более некомфортно.


    Сейчас, даже с большинством выключенных инспекций и плагинов загрузка CPU и скорость запуска хуже, чем были пару лет назад. Это очень печалит, потому что хоть PyCharm и предоставляет множество фич, но при этом среда перестаёт быть удобной для работы.
    После выхода VS Code перешёл, в основном, на него. Хоть это и Electron, но в целом скорость работы куда выше, чем у IDEA. Единственный существенный минус — алгоритмы работы автодополнения. Но в целом работать со среднемелкими проектами удобнее.

    • +3
      загрузка CPU и скорость запуска хуже, чем были пару лет назад

      Вот уж на что не жаловался, так это на загрузку CPU. А почему запуск настолько критичен? Он же один раз запускается и дальше просто работает.
      • +2

        Вы же понимаете, что оборудование у всех разное, и в данном случае сравнение "на моём компьютере всё работает хорошо" — не корректно?
        Конечно, достаточно мощное железо позволяет не замечать разницы в производительности довольно долгое время.


        А почему запуск настолько критичен?

        Это неудобно, когда есть мелкие проекты, над которыми не работаешь постоянно. Бывает, хочется что-то быстро поправить, но при этом не хочется отказываться от автодополнения, дебага, удобной работы с VCS. Да, можно поправить в редакторе, но зачем, если IDE запускается быстро?


        Для интереса сейчас открыл небольшой Pet-project в vs code, затем в pycharm. В первом случае полный запуск — 7 секунд, во втором — около минуты.

        • 0
          Согласен. Я иногда делаю быстрые правки в vim, потому что лень открывать проект в PyCharm, хоть он у меня и довольно быстро работает.
        • +1
          Если IDE запущенно, то открыть другой проект в новом окне гораздо быстрее, чем полный запуск. Так у меня старт идеи занимает 3 минуты, открыть проект в новом окне 18 секунд.
      • 0
        Я работаю с несколькими проектами одновнеменно
        • +2
          … и у меня бывает открыто 10+ разных окон IDE (PHPStorm). Так вот через пару дней комп (i5, 16Gb RAM, SSD) начинает безбожно глючить. Сегодня, например, отвалилась подсветка синтаксиса.
          • +1
            Вообще-то это сложно назвать работой.
            10+ проектов одновременно…
            • –1
              Ну у меня не 10, конечно, открыто. Но пять — точно. Никто ж не говорит, что между ними обязательно нужно скакать со скоростью 100 раз в сутки. Месяц назад открыл проект и свернул. Зачем его закрывать? Может еще через месяц приду что-то туда дописать. А может завтра код на ревью скинут.
              • +9
                Вот через месяц я его и открою снова.

                А держать 5 активных в которые не заглядывал в течении дня…
                Это сравни тому как оставлять кучку мусора посреди комнаты — потом когда-то домету…
                • +1

                  А ещё это похоже на 50+ вкладок в Хроме "потом посмотрю" и "а почему у меня Хром тормозит?".

                  • 0
                    Кстати, в Chrome очень помог OneTab. Вроде и не теряешь открытые вкладки, но они и не мешают, болтаясь там годами :)
                  • 0
                    Похоже, только не тормозит )
              • +1
                Месяц назад открыл проект и свернул
                Я так не могу. Через 2-3 дня вынужден перезагружаться.
            • +1
              микросервисы :-(
              • 0
                Мне просто любопытно: а они у Вас связаны как-то между собой тематически? В PyCharm ведь можно открывать несколько проектов в одном окне.
                • 0
                  Тематически связаны. Но в PHPStorm раньше (если не ошибаюсь) была возможность либо открыть проект в новом окне, либо в текущем (заменив проект в текущем окне). Сейчас появилась возможность открывать в одном окне несколько проектов, но там есть какие-то ограничения по настройкам (часть настроек будет общая). Но надо будет попробовать, может будет лучше. К. т. проекты есть на разных языках (PHP, JS)
          • +2

            Попробуйте сделать один многомодульный проект, а не 10 отдельных проектов. Вам будет гораздо удобнее и IDE тоже будет гораздо удобнее.

            • 0
              Не всегда так получается. У меня часть сервисов, например, на erlang-е (они все собраны в один проект, с которым я работаю из IDEA). Часть сервисов на Ruby (сам Б-г велел использовать rubymine, а плагин для erlang в rubymine работает через джеппу). Отдельный проект ansible, который чисто по логике должен быть отделен от всего остального. Ну и так далее.
              • 0

                Дело в неудачных названиях project и module. Мыслите, что project — это workspace, а module — это project. Тогда будет легче.

      • +1

        На работе несколько лет юзаем Phpstorm — для, собственно, PHP, и для Perl через плагин Camelcade. В последнее время часто происходят лаги (как в Perl, так и в PHP) при наборе текста. CPU при этом сильно скачет вверх на процессе Java. Думал, что проблема в Linux-версии IDE (моя рабочая станция — Ubuntu) либо в плагине для Perl. Однако, у другого разработчика с рабочей станцией на Windows та же история. Вот и думаем — то ли плагин лагает (даже на проектах без использования Perl), то ли IDE. Тут ещё один нюанс: мне приходится постоянно держать открытыми 7-8 проектов, среди которых есть легаси с тысячами файлов (как Perl, так и PHP). У другого разработчика ситуация похожая. Возможно, дело ещё и в количестве файлов. Eclipse на этих проектах тупо вис. В целом, лаги при наборе текста — не очень приятное явление, но пока что удобство и функциональность сильно перевешивают.

        • +1
          Пробовали увеличисть ограничение оперативки в настройках?
          • 0

            По умолчанию при каждом мажорном обновлении правлю *.vmoptions: xmx2048m, xms256m. Дефолтных настроек изначально было мало. Если верить индикатору памяти в IDE, проблем с памятью нет. При лагах потребление памяти ощутимо не скачет, скачет CPU. В старой статье от 2006 года утверждается, что слишком высокие значения этих параметров могут приводить к подвисаниям из-за сборки мусора. С другой стороны, в 2015 исследователь сборки мусора в IDEA задавал ещё более высокие значения. Наверное, надо бы провести собственное исследование, но тут загвоздка: дома нет проблемы, на работе нет времени.

        • +1
          А Вы не могли бы записать CPU snapshot и отправить нам? С включенными сторонними плагинами и без них.
          • 0

            Когда и если будет окно для этого (и разрешение начальства) — с удовольствием.


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

  • –11

    image

  • –9
    Однажды JetBrains победил Eclipse
    Когда это было? Лично я для Java пока лучше Eclipse ничего не нашёл.
    • 0
      • –1
        А при чём тут статистика поисковика? Другое дело, если б тут был график соотношения юзеров по этим IDE.
        • +4
          В интервью кто-то из JetBrains сравнивал количество фич, людей и т.д. Не помню где читал. Типа Eclipse был такой страшный монстр, который всё захавает, а сейчас оказался далеко позади. В целом похоже на правду, что IDEA обогнала Eclipse по всем показателям. Хотя, именно на Java я не программирую.
          • 0
            Мне вот пару лет назад на некоторое время пришлось погрузиться в Java и попробовать по паре месяцев поюзать и Eclipse и IDEA. Я не смогу привести конкретного сравнения, т.к. было не так уж и не давно, только ощущения. И вот по ним — мне в IDEA было комфортнее работать, чем в Eclipse.
      • 0
        Согласен… В эклипсе более чем всего достаточно… Какой смылс переходить на IDEA что-бы сэконоимить хотябы 1% времени рабочего дня? ;)
        Ерунда…
        Я вообще хардкорно пользуюсь ИДЕ в по 1,2 часа в хорошие дни. Редко больше 4-ех ито это наверное по поводу кода все предельно ясно и например что-то from scratch пишется и опыт за плечами… Но как часто это? С микросервисами навверное чаще ;)
        Но остальное время это дискуссии, чтение, поиск, обдумывание…
        IDE новичков чаще волнует…
        • +6
          IDE новичков чаще волнует…

          Зависит от специфики работы. Некоторым вообще целыми днями приходится копаться в чужом коде, а не дискуссировать и обдумывать. Им без IDE — вообще никуда.
        • –2
          Мне захотелось глаза по стенке размазать от вашего комментария, но все же: экономия 1% рабочего дня(8*60/100~=5 минут) даёт для компании из 10 средних разработчиков (100к/мес) экономию в 50*20/60=18 часов в месяц, около 10к.
          А сколько у нас разработчиков? Тысяч 300, думаю, наберется.
          • 0
            Сегодня мелькнула цифра в 18 млн разработчиков.
            • –2
              Спасибо.
              Итого экономия 1% времени позволит бизнесу экономить 18млн рублей в месяц.
              • +1
                В масштабах чего?
          • +1
            Думаю нужно считать не от 8 часов, а от того времени, когда вы действительно проводите в IDE.
            Я вот врятли больше 2 часов код пишу, остальное время это доки, спеки, общение, митинги и т.д.
            Да и теже самые 5 минут можно считать погрешностью, я думаю мы больше времени тратим когда с коллегами холиварим.
          • 0
            Дружище, вы не внимательно прочитали
            — 1% со знаком вопроса в конце… Предпологающий что вы должны были или согласиться с этим или высказать предположнеи об этом.
            Я личнио не верю даже в этот процент.
            Так же с низу я привел вам примерно время о том сколько действительно средний девелопер проводит над вбиванием кода в IDE. надо отталкиваться от это-го…

            Далее гораздо важнее комбинация Девелопер+ IDE Х чем просто IDE.

            Когда я начал яву Eclipse было лучшим что есть… Мой опыт на яве >15 лет. Я работал в различных проектах, на различных фирмах и командах, как консультант и как внутренний сотрудник.
            С нубами и с гениальными хакерами… Никто из опытных программеров не жаловался на то что ему мешает программировать Eclipse.. Помню один сумащедший опроект где я торчал на работе у клиента с 8 до 21:00 иногда до 23:00 ночи…
            Это было в 2013-ом. Тогда перелопатил десятки тысяч строк легаси и к сожалений нашего нового но не очень хорошего кода колег- новичков… Нубы были с IDEA, потому что они уже с ней социализировалось…
            Но писать код хороший или хотябы быстрее им это никак не помогало… Это не говорит что IDEA хуже эклипса… Вовсе нет!
            Я даже верю им и вам всем, что она в чем-то лучше…
            Меня уже пару раз пытались пересадить, на нее… Я тыкал пару дней, но в конце я так и не понимал в чем это лучше чем мой Эклипс (который я умею настраивать и затачивать) и зачем мне перучивать шорткаты… И не заметил что-бы мне это что-то с эконимило…

            На данный момент я ДевОпс у нас на фирме примерно 20% с IDEA — они не пишут ни на сикунду быстрее, скорее наоборот, но перестали заниматься бэшингом еклипс потому-что поняли что преимущества у них особого нет… им просто нравится красный молоток с длинной рукояткой, а другим нравится тот что потяжелей с короткой ручко. Но оба они хороши…
            И наверняка если б я только сейчас вышел с универа я бы начал с IDEA.

            Я заикнулся пор ДевОпс, тоесть работаю со скриптами… Много было в последнее вреймя Ansible, Terraform, Puppet. Да еще в веб ушел с TypeScript и вот для этих целей мне понадобился совсем другой молоток. И я нашел прекрасным Visual Studio Code от микрософта — очень понравилась для таких вещей и да теперь у меня две дежурные IDE ;)
          • +3

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

        • 0

          Раз десять при разных обстоятельствах пытался использовать Eclipse (на Linux). И для проектов на PHP/Perl (легаси с большим количеством файлов) — Eclipse вис, фатально крашился (без бубна уже запуститься не мог). И для создания диаграм UML — примерно та же история, только менее агрессивно. А реалии, увы, такие, что надо работать, а не познавать Eclipse-дзен.

          • 0
            1,5 года eclipseпод xubuntu. Наблюдаю небольшой провал в скорости работы (иногда небольшие задержки) по сравнению с виндовой версией.
            Но в целом вполне… Проблем с явой никаких которые можно было свести к eclipse. Но возможно ноут надо будет обновить — ему лет 7, хотя пока пофиг.
        • +4
          Удобная IDE дает совсем не экономию времени на нажатие клавиш, а меньшее количество отвлечений на рутину. Когда можешь сделать что-то одним хоткеем, вместо возни мышью, выполнением рутинных действий, или даже написанием однострочников в консоли, в результате меньше отвлекаешься от основной задачи, не теряешь ее контекст (который может быть довольно сложным), не выпадаешь из потока. В результате возрастает общая эффективность, но насколько — практически невозможно измерить, зависит от решаемых задач и самого программиста.
          • 0
            но насколько — практически невозможно измерить, зависит от решаемых задач и самого программиста.

            В том то и дело…
            Eclipse вполне можно без мыши работать как и в IDEA. Но на практике редко встретишь тех кто может это полностью без мыши в одной из них…
      • 0
        2011 год — год перехода на 4-ю версию, глючную и забагованную.
      • 0
        Я не специалист в Google Trends, Но вы сравниваете Eclipse (Software) и IDEA (Search term). Если переключить с Search term на Software, то картинка кардинально поменяется. Даже, если Eclipse переключить в Search term, то там не 2011 будет.
        • 0
          Подскажите, как в запросе «IDEA» переключиться на Software?
          • 0
            Как вариант кликнуть на квадратик IDEA и выбрать «IntelliJ IDEA». Для тех кому кажется, что это слишком узкое понятие я описал и второй вариант — переключить Eclipse в Search term. Правда тогда, возможно, вы будете сравнивать «U.S. Department of Education» c «Eclipse | Board Game»
            • 0
              Поэтому тот вариант показался мне лучшим. «Idea» — слишком общее слово, чтобы его часто гуглили просто так без сочетания с другими словами, и я подозреваю, что в большинстве случаев это всё же software.
              • –1
                Ну «Eclipse», тоже не узкоспециализированный термин :) А что касается «чего люди ищут», то можно открыть анонимную закладку и попробовать поискать «IDEA» и «Eclipse» — получите некий усредненный вариант — довольно грубо, но представление даёт. Например, можно сравнить какое место занимает IntelliJ IDEA и какое Eclipse IDE.
    • +2

      Например, вот одно из мнений 5-летней давности:
      https://habrahabr.ru/post/112749/

      • +2
        Мнение от человека, который тех, кто пишет на Eclipse, называет «несерьёзным Java-программистами»?
        • +1

          Его позиция хотя бы выглядит убедительно и я с ним согласен в одном:


          Главная вещь, отличающая IDEA — она понимает контекст.

          На 2012 год IDEA было объективно "умнее" Eclipse в плане "понимания" кода. Дальше можно спорить сколько угодно, но это бессмысленно. Что там сейчас происходит я не слежу, может Eclipse уже сильно продвинулся в этом плане.

          • +1
            Отнюдь. Баги Eclipse заставили свитчнуться почти год уж как на IDEA.
            За это время кое-как к Eclipse Neon починили автокомплит в лямбдах и то не полностью…
            Годами чинили, чинили и не вычинили.
            Новых фич не заметил…
            Dark theme все так же вызывает смех и недоумение.

            Один из контрибьюторов Eclipse CDT взялся писать Eclipse Two на Electron:
            http://jug.ru/2017/01/eclipse-two/

            Но IDEA тоже поглюкивает, конечно, просто это не так мешает пока.
    • 0
      Мне интересно, почему NetBeans никто не берет в рассмотрение(в контексте Java). Настолько непопулярен? В свое время у эклипса достало постоянное выедание памяти и какие-то бэкграунд процессы, которые повисают и остановить их нельзя. Лечится тока убиванием эклипса и новым стартом. Перешел на IntelliJ IDEA, все было супер, но с какой-то мажорной версии на некоторых операциях стал поттупливать, причем много операций из повседневной работы. Решил ради интереса попробовать NetBeans — все необходимые тулы из коробки, не нужно отдельными плагинами(которые отдельно от основного продукта поддерживаются и с новой версией надо ждать обновления) качать, как для эклипса и работает шустро.
      • +1

        Да, непопулярен. Не больше пары процентов рынка.

  • –7

    Использую SublimeText 3 и как-то всё ровно. Atom медленнее просто.

    • +6

      Саблайм и Атом для больших проектов — это немного не то как-бы) IDE не зря придумали всё-таки.

      • –19

        А большой проект это сколько?
        Имхо, IDE несколько расслабляет. Разработчики забывают даже базовое API, полагаясь на автодополнение, никто не придумывает архитектуру, ведь есть же меню рефакторинг...

        • +22

          Зачем разработчикам помнить "базовое API"? И что есть "базовое"? Особенно в наши то времена со всеми этими 100500 модными фрэймворками и библиотеками. Всего всё равно не запомните, полезете в документацию. Предлагаете постоянно переключать внимание и забивать голову всем этим вместо погружения в предметную область? Заодно развивать навыки машинистки, набивая километры символов?


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

        • +10

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

        • +5

          Сократ выражал аналогичные опасения по отношению к распространению письменности: https://youtu.be/XNIHBEBsoKg?t=24


          [writing] will introduce forgetfulness into the soul of those who learn it: they will not practice using their memory because they will put their trust in writing, which is external and depends on signs that belong to others, instead of trying to remember from the inside, completely on their own.

          Источник


          Перевод

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

          • –1

            И он, в принципе, оказался прав :-)
            Но хуже даже не забывчивость, а то, что бумага всё стерпит. Но это уже из Цицерона..

      • +2
        IDE придумали не зря, конечно, но и без IDE можно жить и писать, правда проект должен быть грамотно структурирован. Надо не забывать, что средняя продуктивность редко переваливает за 200 строк в день, которые можно написать в редакторах по типу Sublime при небольшом поддержке автодополнения, поиска по файлам, быстрому открытию файлов, главное, структура проекта и ориентация в ней.
        Дебаг, профилировщик, можно использовать отдельные тулы по необходимости.
        • +1

          В этом и дело, что например когда надо делать красивую архитектуру из групп классов, использовать этот самый саблайм или атом — дело это будет тяжким и длительным, и скорее всего вы просто сами обленитесь и сделаете всё по-минимуму, сэкономите на doc-блоках, забьёте не интерфейсы и абстрактные классы (потому что лень будет всё это писать)… Когда в PhpStorm уже всё для вас готово, все нужные use'ы подставляются вверху автоматически, геттеры-сеттеры добавляются без проблем, неймспейсы классам пишутся сразу корректные… Ну и так далее.


          В общем, в итоге ты просто "рисуешь" архитектуру своего проекта вместе со своей IDE, вместо того чтобы писать каждое слово вручную, как если бы это происходило в случаях в Sublime или Atom. Я уже давно слез с обычных текстовых редакторов, пусть к ним и можно установить различные плагины, немного расширяющие базовый набор возможностей — всё равно это совершенно не тот уровень, он не сравним с современными IDE для разработки. Ещё раз напишу) Не зря их придумали.

          • 0
            А я постоянно исправляю импорты, которые подставляет PyCharm, потому что он часто ломает структуру импортов и сваливает всё в непонятную кучу ) Казалось бы: фича есть, а пользоваться ей у меня не выходит.
            • +1

              Ну это я уже не знаю что у вас там, простите, но представьте: у меня никаких проблем с этим нет ни в Netbeans при работе над PHP проектами, ни в PhpStorm. Возможно дело вообще в Питоне, который не даёт такой же строгости при работе с пакетами и не позволяет однозначно указать нужные модули при импортировании (это только предположение, я не знаю питон). В общем, в PHP лично у меня таких проблем не было. Всё импортируется как надо, а когда существует выбор — IDE спрашивает меня о том, с каким конкретно неймспейсом нужно связать класс.

              • 0

                У меня таких проблем нет ни в idea, ни в pycharm. Плюс есть сортировка импортов, что там, что там.

      • +1

        У ST3 своя экосистема плагинов. Тот же CodeIntel снимает кучу вопросов, не говоря уже про Emmet.


        Просто попробуйте и удивитесь.

        • +3

          :) Да знаю я про подобные плагины. Только они реализуют примерно 10% из всех функций, которые реализованы и сгруппированы в нормальной IDE типа Netbeans или PhpStorm.


          Давайте посмотрим внимательно на то, что даёт нам энтот самый CodeIntel:


          • переход к нужному файлу и строке
          • автозавершение импортов
          • подсказки при вызове функций

          И это всё?


          Как насчёт возможности изменить название любого класса сразу во всём проекте?
          Как насчёт быстрого редактирования любой переменной во всём файле?
          Автогенерация геттеров и сеттеров для переменных класса?
          Интеллектуальная коррекция всех use-директив во всём файле?
          Быстрая навигация по всем сущностям файла (переменным, методам класса, и т.д.) в отдельном окошечке?
          Авто форматирование кода?
          Автоматическое удаление лишних пробелов из файла при сохранении?
          Инструмент для разрешения конфликтов при объединении своего кода с чужими коммитами?
          Готовые шаблоны для новых классов, интерфейсов, трейтов?
          Авто-подстановка неймспейса?
          Подсветка неиспользующихся или использующихся некорректно переменных в методах?
          Авто-генерация doc-блоков?


          Можно и дальше продолжать. Есть ещё целая гора тонкостей. Всё что я выше написал — есть из коробки в Netbeans и PhpStorm. Чтобы добиться подобной широты функций на Atom'е или на Sublime Text, придётся найти, установить и настроить целую кучу плагинов. И я не уверен, что вы найдёте всё что я перечислил. И я не уверен, что он