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

в 15:30, , рубрики: IDE, idea, jetbrains, pycharm, Программирование

В этой статье я хочу поднять тему старения компаний и извечный вопрос: что делать простым пользователям? На примере 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», и получил вот такой красивый график:

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

График красив, но в нашем случае совершенно бесполезен. На первый взгляд всё равно: команда работает, баги открываются и закрываются. Но мне кажется, что за этим диким разбросом не видно истинной картины (еще там можно включить режим «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); 
    }
);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PPS: Понимаю, вопрос дискуссионный, и наверняка найдется много людей, несогласных с моим мнением. С кармой я уже попрощался ) И всё же, надеюсь на конструктивные комментарии.

Автор: raacer

Источник


  1. Steel:

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

  2. Simba:

    Да-аа, неслабо стало там на хабре. Спасибо на наблюдение, Steel!

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js