Пост о том как не надо вести разработку фреймворков, и о том, почему жизненный цикл программного обеспечения это не пустые слова, особенно, если на вас полагаются миллионы разработчиков по всему миру. Далее следует критика подхода к разработке платформы .NET Core, и, тесно связанного с ним фреймворка, ASP.NET Core.



История версий .NET Core (шутка с просторов Интернета):


* Alpha
* Beta
* RC1
* 2RC 2Furious
* RC: Tokyo Drift
* RC4: The Big RC
* 7
* RC8

Предыстория


vNext — кодовое имя для нового поколения ASP.NET, которое использовалось довольно продолжительное время, пока фреймворк не получил порядковый номер и не стал называться ASP.NET 5 (позже известный как ASP.NET Core). Если до этого развитие ASP.NET шло планомерно, в основном, без проблем с обратной совместимостью, то новая версия стала настоящей революцией. По сути это новый фреймворк. Одной из целей тотального переписывания было достижение модульности, что, в том числе, позволило отвязать .NET от платформы Windows. Это потом послужило поводом для череды громких анонсов о поддержке Linux и OS X.


Надо сказать, что новый фреймворк получился очень приятным: канул в лету монструозный System.Web, а MVC и Web API части слились в одно целое. Кроме того, рантайм и библиотеки были разбиты на мелкие части (типичная инсталляция веб-приложения вместе со всеми зависимостями теперь занимала меньше 50 мегабайт, против прежних 500 МБ полной версии .NET Framework). Поддержка Linux — вообще отдельный разговор. Официальный образ для Docker, запуск приложений в два клика на серверах любого облачного хостинг провайдера — то о чем, до этого .NET программистам можно было только мечтать.


Но не всё было гладко. Новая платформа получилась несовместимой не только на уровне ASP.NET, изменился сам .NET Framework. По сути, появилось два независимых направления: CoreCLR и "старый" .NET версии 4.x. Портирование между этими фреймворками оказалось нетривиальной задачей для большого числа библиотек, авторы которых, естественно, стали выражать свое недовольство. Но, по большому счету, Microsoft тогда легко отделался — люди пошумели немного, и успокоились. В качестве тренировки воображения, можно представить себе реки крови, которые потекли бы в случае, если помимо основной версии Java появилась бы какая-нибудь несовместимая SuperDuperJava. В случае .NET же, разработчики скорее радовались новым возможностям, чем противились изменениям, хотя и недовольства тоже было много.



Как бы там не было, факт в том, что .NET теперь находится в ситуации, подобной той, что имела место быть с Python 2.x и 3.x. А еще ведь есть WinRT, Mono, Unity и Xamarin, которые тоже не отличаются стопроцентной совместимостью...


Release Candidate


Если вы нормальный человек, и не прибыли на Землю с одной из планет системы Альфа Центавра, то, скорее всего, после единицы у вас идут числа 2 и 3, после альфа версии идет бета, а после Release Candidate следует финальный релиз, ну или RTM.


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


В нормальном мире, когда проект подходит к стадии Release Candidate, сообщество ожидает стабильности. "Это слишком скучно" — наверное, так подумали в Microsoft. Оказалось, что самое интересное еще было впереди. Внезапно, самые большие изменения в истории нового фреймворка случились когда версия получила приставку RC. Первым признаком грядущего пожара стал project.json, а точнее его замена на старый добрый MSBuild. Если быть честным, то это изменение само по себе не является катастрофой. Однако, именно project.json был флагманом "нового" .NET. Посмотрите презентации с многочисленных конференций — пиар машина завлекала хипстеров из мира Go и, о боже, Node.js именно такими вещами. Кроме того, ужасный тайминг — как можно называть что-либо Release Candidate, когда впереди предстоит смена системы сборки для всего фреймворка?



Дальше — больше. ASP.NET Community Standup — канал на YouTube, где разработчики в еженедельных выпусках рассказывают про новый ASP.NET и процесс его разработки. Стэндап, до этого стабильно выходивший раз в неделю, неожиданно замолкает на месяц. Последняя публикация называется "Do we have dates?", что очень символично. Разработчики фреймворка, до этого активные пользователи твиттера, начинают осторожничать, не ввязываются в дискуссии. Остальной же твиттер бурлит от негодования. Все теряются в догадках. Создается впечатление, что те, кто делал этот проект, теперь сами не в курсе о том, что происходит. Из догадок сообщества — пришли "взрослые ребята", которые дали нагоняй "наигравшимся вдоволь детишкам" и взяли всё под свой контроль.


Смешались в кучу кони, люди, WebAssembly


О том, какой раздрай творится в мире .NET можно судить по всплывшим в сети скриншотам обсуждения будущего платформы внутри Microsoft. В то время, как ASP.NET находится в подвешенном состоянии, разработчики обсуждают странные темы вроде поддержки компиляции в WebAssembly. Скорее всего, .NET Core, в его текущем виде неудобен некоторым отделам Microsoft (вроде Xamarin) из-за своей несовместимости. Одна часть Microsoft не совсем довольна тем, что сделала другая. Как Лебедь, Рак, и Щука, каждый тянет на себя. В результате — топтание на месте и странное молчание.



Что дальше? Можно сделать несколько предположений о будущем .NET исходя из обсуждений в официальном канале Slack: Mscorlib и AppDomains скорее всего возвращаются в своем первоначальном виде, что ставит под вопрос модульность всего фреймворка, и, вообще, необходимость первоначальной затеи. Взамен — некоторое подмножество API, доступное и совместимое на всех платформах начиная с ASP.NET и заканчивая Unity и Xamarin. Это достаточно большие изменения. По новым срокам — абсолютная неопределенность.


Вывод


Несмотря на блестящую работу, проделанную командой разработки, отсутствие полной картины в глазах менеджмента привело к тому, что большое количество разработчиков сделали ставку на платформу, которая никогда не будет выпущена в её текущем виде. Можно долго спорить на счет того, было ли правильным решение поделить платформу на две ветки, но думать на эту тему нужно было гораздо раньше. Разворот на 180 градусов в стадии RC это худшее из того, что можно было придумать. Release Candidate это, вполне себе, устоявшийся термин, который предполагает некие обязательства, которые неплохо было бы выполнять.

Поделиться с друзьями
-->

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


  1. centur
    30.05.2016 06:49
    +11

    Ох уж эти паникеры, что в твиттере изнылись, что на хабре. Вообще так в любом bleeding edge — someone's eyes should bleed.


    Побуду КО:
    Если вы начали делать ставку в продакшене (или хотя бы в проектах которые должны выйти в этом году) на Core — вы ССЗБ.
    Если вы поверили что такой массивный re-write сложной платформы не обойдется без отставаний и лаж в датах — или вы очень неопытны или см ССЗБ.
    Майкрософт конечно тоже хороши — выпустить RC и поломать все в RC2. Но такое случается, как и случаются перевранные даты. К этому индустрия как-то привыкла… А вот лететь на bleeding edge — это все оттого, что все как-то разом забыли о поломанных совместимостях и сильно расслабились, надеясь что agile всех спасет.


    1. x2bool
      30.05.2016 07:13
      +6

      Лично я бы не взял на себя ответственность делать новый проект на ASP.NET Core. Но многие решили всё же делать. Но это ладно. Авторы многих популярных библиотек вынуждены следить за .NET Core с самого его рождения, т.к. сообщество ожидает от них поддержки новой платформы. Основной источник недовольства это именно лидеры opensource сообщества. И я их понимаю.


      Я не против, пускай ломают, экспериментируют. Но назовите это "альфа версия", и никто плохого слова не скажет.


      1. centur
        30.05.2016 08:28
        +1

        Ага, первый RC был неудачной идей, хотя они вроде и GoLive лицензий с ним не давали...


        1. masterL
          30.05.2016 11:29
          +4

          Давали

          Go Live!
          Starting with the RC1, we are including a “Go Live” license. This license allows you to deploy an application written with ASP.NET 5 RC1 to a production environment and utilize Microsoft Support. The duration of this license for the RC1 last until the next release candidate or the completed release of ASP.NET 5 (called an RTM release) that is currently scheduled for Q1 2016. This license also covers running ASP.NET on Windows, Linux, and OSX.


          1. centur
            30.05.2016 13:18
            +2

            Точно… Я сначала прочитал это как goLive на ASP.NET, но в блоге на мсдн упомянуты Go Live и на core.
            Там конечно есть аккуратная такая оговорка, что со следующим RC ваша Go Live превращается в тыкву


            The duration of this license for the RC1 last until the next release candidate or the completed release of ASP.NET 5 (called an RTM release) that is currently scheduled for Q1 2016.


  1. Alex_GDI
    30.05.2016 07:16
    -5

    прочитал заголовок, фух померещилось.


  1. 0xffaa
    30.05.2016 07:42
    +12

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


    1. x2bool
      30.05.2016 07:56

      Да, но если нужно вернуть mscorlib, и при этом потеряется модульность фреймворка, то я не совсем понимаю необходимость всех изменений, сделали бы тогда .NET Framework 4.7.x. К тому же, если доделывать его еще 2 года, то в сумме получится ~4 года, что очень большой срок по современным меркам.


      1. 0xffaa
        30.05.2016 08:15
        +3

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

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

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


        1. Veikedo
          30.05.2016 09:15
          +2

          Дело не только в экономии места, но и в скорости поставки/независимости разработки/заменяемости компонентов


          1. x2bool
            30.05.2016 12:39
            -2

            И при использовании Docker никто не захочет дополнительно ставить 0.5 GB.


  1. kekekeks
    30.05.2016 10:22
    +5

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

    На уровне исходников же совместимость они не так уж и сильно ломают, тут есть проект, который я со времён beta4 на новом ASP.NET-е веду, на апгрейды до новых версий было потрачено в сумме часа два.


    1. PsyHaSTe
      01.06.2016 19:28
      +1

      Ну не знаю, потратил целый день пытаясь перенести с RC1 на RC2, так и не получилось — если раньше dnx сам генерировал для сборок все нужные файлики, то в RC2 нельзя просто взять и среференсить «csproj». Речь о «dnx452» в данном контексте, на котором все работает (но прибитый к винде, насколько я понимаю), а новый кроссплатформенный начинает кричать, что неможет зарезолвить депенденси. А учитывая, что по крайней мере датаконтракты нужны, получается фигня…


  1. mtt
    30.05.2016 10:47

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


  1. lumini
    30.05.2016 10:47

    Я вот уже давно привык, что первые версии майкрософтовских продуктов — очень странные и корявые, а к (традиционно) третьему выпуску — все становится очень даже вкусно. NET до 2.0 был мягко говоря неидеальным. MVC опять же до третьей версии — тоже кривоват. RC1 -> RC2 -> релиз Core как раз третья «большая версия», так что по логике он должен быть хорошим :)

    Пока смущает, что после создания в студии дефолтного проекта RC2 еще минут пять машина пыхтит доустанавливая нугеты. Я бы предпочел раз в пару месяцев обновлять на серверах большой .NET с багофиксами и малыми изменениями (типа как 4.6 и 4.6.1), чем терпеть тонны пакетов в каждом мизерном проектике.


    1. kekekeks
      30.05.2016 11:48
      +1

      Вообще говоря нугет пакеты теперь лежат в %USERPROFILE%/.dnx/packages и не выкачиваются каждый раз по новой.


  1. alexcl
    30.05.2016 11:27
    +3

    Третий день переводим Catlight на .Net Core RC2. Сюрпризов много, официальная документация не покрывает и половины изменений, которые нужно сделать. Самой полезной инструкцией по миграции оказался этот пост — Converting an ASP.NET Core RC1 Project to RC2

    Но уже видно что RC2 заметно лучше — получается чистый publish без сотни лишних файлов и нормально можно выбрать runtime.


    1. x2bool
      30.05.2016 11:29
      -3

      Ага, и это еще цветочки, самое интересное всё еще впереди.


  1. correy
    30.05.2016 11:29
    +2

    Согласен с большинством: паника, по-моему, преждвеременна. Стоит немного подождать.


  1. ZOXEXIVO
    30.05.2016 12:13
    +2

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


    1. correy
      30.05.2016 12:47

      Это свойство человека :)


  1. szKarlen
    30.05.2016 12:38

    Еще на конференции Build 2016 рассказали планы по .NET Standard. Кстати, RC2 тулинг для VSCode уже показывает NETStandard1.5 профиль для запуска проектов.

    Если опустить разницу в доступности публичных API между версиям, то .NET Core RC2 спокойно подтягивает весьма сложные библиотеки. Кстати в RC2 уже идут патчи для RyuJIT, доступные в апдейтах .NET 4.6.


  1. szKarlen
    30.05.2016 12:46
    +1

    p.s.

    планы по WebAssembly и т.п.: экспериментируют со многими вещами, в том числе и LLVM.
    Даже был компилятор в JS.

    Но это никоим образом не влияет на корпоративный план (т.е. менеджмента, а не разработчиков), что только подтверждают изменения project.json и т.д.


    1. KvanTTT
      30.05.2016 13:22
      +1

      Таких трансляторов вообще большое количество: C#, F#, .NET related languages. Причем некоторые совсем неплохого качества, судя по описанию.


      1. szKarlen
        30.05.2016 14:47
        +1

        вот-вот! просто в статье это подается как что-то ужасное. хотя, business as usual.


  1. dotnetdonik
    30.05.2016 14:18
    +4

    Какая разница ASP.NET разработчику как грузиться mscorlib api, это уже меняли несколько раз и никого это не волновало, пока кто-то об этом не написал в твиттере.
    Вопрос с заменой project.json также выглядит раздутым интернет тролями, поэтому сейчас все на него ведутся.

    Куда более неожиданным было появление NET CLI, отказ от DNX и отсутствие достаточно длительное время Tools для нормальной работы с новым рантаймом. Но этого никто не замечал, так как в интернете никто не бурлил, хотя трудностей это добавляло куда более.


  1. sshikov
    30.05.2016 19:48
    +2

    В качестве тренировки воображения, можно представить себе реки крови, которые потекли бы в случае, если помимо основной версии Java появилась бы какая-нибудь несовместимая SuperDuperJava.


    Вам бы поработать на IBM Java (где нет классов sun.*), и под Далвик для Андроид… )))


  1. StealthDogg
    03.06.2016 08:45
    +2

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


    1. x2bool
      03.06.2016 10:46
      +1

      Релиз, конечно же, будет. Но не в текущем виде, и, теперь, неизвестно когда.


      1. StealthDogg
        03.06.2016 19:41
        +1

        Ок, давайте по порядку тогда
        1) По поводу «текущего вида»: это RC2. Считать текущим видом RC1 после 17 мая неправильно. Более того, с января (как я помню) разработчики рассказывали про грядущие изменения. И для кого это произошло внезапно — ну ССЗБ. Более того еще есть и open source на GitHub.

        2) По поводу «неизвестно когда»: разработчики обещали RC2 в мае, RTM в конце июня. Первую часть обещания они сдержали. Ждем вторую.