Чищу картошку как пишется

Когда я вижу, как кто-то учит кого-то языку программирования, то частенько замечаю тенденцию показывать новичкам примитивные примеры в виде ToDo list. Помимо того, что подобные примеры не учат ничему полезному в программировании, они очень однобоки и не позволяют оценить все плюсы и минусы какой-либо среды разработки.

Меня это удручает. Давайте попробуем написать что-нибудь полезное и при этом показать вам, что можно и чего не нужно делать с достаточно новой технологией Microsoft под названием Blazor.

Не так давно мне пришлось помогать детишкам разобраться с программированием. Пацаны были маленькими, но глаза их были полны энтузиазма и постоянно слышался вопрос «Как?» и «Почему?». Кто-то из подопечных притащил в студию пару IoT реле, которые позволяли включать и выключать лампочки по сети. Конечно, для нас, Хабравчан, такая штука не очень интересна, но для подростков было как раз то что надо. Почему бы и нет, подумал я, и мы начали писать всякие реле с таймингами, которые позволяют анимировать гирлянды и всё такое. В конце концов, не хочу вас пугать, но конец года уже близится и скоро нам надо будет украшать ёлки и помещения.

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

Проблемы начались со вторым реле. В нём запросы надо было посылать в виде ASCII строки. А третье реле вообще требовало бинарного ввода на порту. Все программы по миганию гирляндами начали обрастать каким-то нездоровым количеством логики и превращались в костыли.

Было решено реализовать следующую программу:

1. У нас есть список моделей различных реле.
2. В списке мы указываем тип передачи данных и список команд, доступный для каждой модели.
3. Создаём список устройств. Каждое устройство имеет отдельный IP-адрес, имя и название модели.
4. На основе этой информации создаётся строка управления для каждой команды, каждого устройства, которая выглядит следующим образом:

   http://control-center/control/relay-lobby/port-1-turn-on
   http://control-center/control/relay-lobby/port-1-turn-off
   http://control-center/control/relay-lobby/port-2-turn-on
   http://control-center/control/relay-lobby/port-2-turn-off
   http://control-center/control/relay-lobby/port-3-turn-on
   http://control-center/control/relay-lobby/port-3-turn-off
   

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

Ладно, отбираем самых продвинутых учеников и идём писать.

Работать будем с последней версией Blazor для .NET 6.

Создаём пустой проект и идём заниматься проектированием. В принципе, в ТЗ всё достаточно хорошо описано, есть база данных, в ней есть реле, тут всё просто. Для базы данных мы возьмёмся за Entity Framework Core и будем использовать Code-Frist подход (то есть сначала мы пишем код, после чего фреймворк генерирует на основании этого кода базу данных).

База данных

Модель доступна здесь.

public class DataModelContext : DbContext
    {
        public DataModelContext (DbContextOptions<DataModelContext> options)
            : base(options)
        {
        }

        public DbSet<Model> Models { get; set; }
        public DbSet<Device> Devices { get; set; }
        public DbSet<Command> Commands { get; set; }

        protected override void OnModelCreating(ModelBuilder modelBuilder)
        {
            modelBuilder.Entity<Model>().ToTable("Model");
            modelBuilder.Entity<Device>().ToTable("Device");
            modelBuilder.Entity<Command>().ToTable("Command");
        }
    }

    public class Model
    {
        public int ID { get; set; }
        public string Name { get; set; }
        public string Description { get; set; }
        public ICollection<Command> Commands { get; set; }
        public ICollection<Device> Devices { get; set;}
    }

    public class Device
    {
        public int ID { get; set; }
        public string Name { get; set; }
        public string Description { get; set; }
        public string Address { get; set; }
        public int Port { get; set; }

        public int ModelId {get;set;}
        public Model Model {get;set;}

    }


    public class Command
    {
        public int ID { get; set; }
        public string Name { get; set; }
        public string Description { get; set; }
        public CommandType Type { get; set; }
        public string Payload { get; set; }
        public Model Model {get;set;}
    }

    public enum CommandType
    {
        AsciiString,
        UtfString,
        ByteArray,
        Binary,
    }

Если вы никогда не видели ничего подобного, то давайте остановимся и подтянем знания. Перед вами — Entity Framework. Это фреймворк, который позволяет ускорить разработку баз данных для приложений, написанных на платформе .NET. Приложения, в частности, написаны на языке C#. В основном потому что для того, чтобы вы могли добраться до данных, вам предложено использовать функцию языка под названием LINQ (Language-integrated query).

Чем всё это хорошо? Тем что вы можете заботиться о своём коде в первую очередь и не париться по поводу базы данных. EF Core позволяет подключить вашу программу к различным базам данных, и вам не нужно будет учить синтаксис. Всё можно сделать в самом языке.

Чем это плохо? EF Core позволяет подключить вашу программу к различным базам данных, и вам не нужно будет учить синтаксис. Всё можно сделать в самом языке. В интернете вы найдёте множество баталий по поводу того, что подобный подход может шибко отразиться на производительности. И действительно, Join в SQL может выглядеть очень красиво и передавать вам в ответ только те данные, которые вы запросили. Если вы напишете кривой запрос на Linq, то вы можете в одну строку увалить целый кластер.

Так что Linq — это палка о двух концах. Чрезвычайно быстрая разработка и прототипирование баз данных должны идти рука об руку с чётким пониманием того, как работает ваш запрос и что происходит на стороне сервера.

Сразу оговорюсь: теперь следовало бы написать бизнес-логику на основе этой базы данных. Но я решил, что делать это будут подопечные, и оставил эту задачу для них (в данном случае бизнес-логика вполне соответствует методам, предложенным самим Entity Framework, и нам ничего дополнительного писать не нужно).

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

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

Frontend

Для тех, кто здесь в первый раз, давайте подтянем теорию. Blazor — это относительно новый фреймворк для создания сайтов, разработанный компанией Microsoft на основе open-source лицензии.

Основной прикол Blazor заключается в том, что всю логику на сайте вы можете написать на C#, без использования Javascript (чем мы здесь и займёмся в показательных целях). Сайт будет скомпилирован в WebAssembly, и вы сможете выложить его на сервер. Для тех, кто никогда не работал с WebAssembly, рекомендую почитать информацию — здесь.

Что это значит для разработчиков? Сайт представляет из себя несколько файлов — пустой HTML, небольшой JavaScript, который будет управлять сайтом, и приличный кусок кода на C#, скомпилированный в WebAssembly файл. Подобная файловая структура не требует никакого специального сервера для работы. Вы можете выложить это всё в открытый доступ на статическом сервере, без какой-либо платформы Microsoft, и всё будет работать.

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

Идея номер один — сайт написан на Blazor и у вас есть отдельный сервер для API, который позволяет дёргать функции удалённо через Web.

Идея номер два — Blazor может и не делать всего этого WebAssembly. Можно скомпилировать ваш код в библиотеку .NET и запускать его, как в старом добром клиент-серверном приложении. Код будет выполняться на сервере, а клиент будет обновлять страницу на экране, отражая изменения.

Именно этим подходом мы и воспользуемся.

Тут надо заметить пару вещей.

В старые добрые времена ASP.NET мы всё делали так — клиент нажимает кнопку на сайте. Весь сайт, представляющий собою форму, отправляется на сервер со всеми данными на экране. Сервер этот сайт обрабатывает, меняет его и выплёвывает обратно на экран. Всё это занимает меньше 10-ти секунд, и все этому рады в 2002 году. Но у нас на дворе 2021, и это нам не подойдёт.

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

Всё намного быстрее и работает за доли секунды. Нам такой подход будет удобнее, и им-то мы и воспользуемся.

Основной плюс Blazor заключается в том, что вам не нужно морочить себя тем, как передавать сообщения с сервера и на сервер. Всё сделано автоматически. Даже если вам захочется переключить своё приложение из Server-Side в Web Assembly, вам всего-то нужно поменять один параметр в конфигах.

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

Backend

Теперь перейдём к Backend, с которым мы будем работать. Как я уже сказал, у нас на руках есть код, который будет брать определённые последовательности символов и передавать их на реле. Этот код будет использовать .NET TCPClient для отправки данных. Обычно таким сайты не занимаются.

Для создания этого контроллера мы воспользуемся технологией ASP.NET Core MVC.

В принципе, сам код MVC предельно прост:

[Microsoft.AspNetCore.Mvc.Route("api/[controller]")]
[ApiController]
public class SendController : Controller
{
    [Inject]
    private IDbContextFactory<DataModelContext> Context { get; set; }

    public SendController(IDbContextFactory<DataModelContext> dmc)
    {
        Context = dmc;
    }
    
    [HttpGet("{Device}/{Command}")]
    public JsonResult Get(string device, string command)
    {
        try
        {

            CommandRunner c = new(Context.CreateDbContext());
            var answer = c.Run(device, command);
            return Json(new { result = "success", device = device, command=command, payload = answer });

        }
        catch (Exception ex)
        {
            return Json(new { result="error", message= ex.Message });
        }
    }
}

Мы просто определяем путь [HttpGet("{Device}/{Command}")]. Если пользователь заходит на сайт по этому адресу, то мы подразумеваем, что первая часть команды будет идентификатором устройства, а вторая часть — идентификатором команды, которую нужно послать.

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

Как вы видите, у нас также есть класс CommandRunner, который как раз и выполняет команды на сервере, отправляя пакеты на устройства. Давайте заглянем в этот класс.

Код CommandRunner.Run достаточно прост:

public string Run(String Device, String Command)
{
    var dev = DbContext.Devices.Include(p => p.Model).ThenInclude(p => p.Commands).First(p => p.Name.ToLower() == Device.ToLower());
    var com = dev.Model.Commands.First(p => p.Name.ToLower() == Command.ToLower());

    var answer = Executor.Say(com.Payload, com.Type, dev.Address, dev.Port);

    return String.Join(", 0x", answer);
}

А код Executor.Say в свою очередь выполняет следующее:

public static Byte[] Say(string What, CommandType Type, string Address, int Port)
{

    Byte[] bt = Type switch
    {
        CommandType.AsciiString => System.Text.Encoding.ASCII.GetBytes(What),
        CommandType.UtfString => System.Text.Encoding.UTF8.GetBytes(What),
        CommandType.Binary => ProcessBinary(What, 8),
        CommandType.ByteArray => ProcessBytes(What),
        _ => Array.Empty<byte>()
    };


    using TcpClient t = new TcpClient(Address, Port);
    var s = t.GetStream();
    s.Write(bt, 0, bt.Length);
    return bt;
}

Здесь мы преобразовываем строку символов в последовательность битов, байтов, ASCII или Unicode символов, в зависимости от того, что принимает на вход наше устройство.

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

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

Итогом этой исследовательской деятельности явились две функции, которые переводят бинарные и байтовые строки в бинарные и байтовые значения:

  static Byte[] ProcessBytes(string What)
        {
            if (What.Length % 2 == 1) What += "0"; //If user sent us uneven byte count
            List<Byte> ret = new(What.Length/2);
            foreach (String ch in What.SplitInParts(2))
            {
                var d1 = Convert.ToByte(ch[0].ToString(), 16);
                var d2 = Convert.ToByte(ch[1].ToString(), 16);
                d1 *= 0x10;
                d1 += d2;
                ret.Add(d1);
            }
            return ret.ToArray();
        }

        static Byte[] ProcessBinary(string What, int WordLength)
        {
            List<Byte> ret = new(What.Length);
            foreach (var ch in What.SplitInParts(WordLength))
            {
                ret.Add(Convert.ToByte(ch, 2));
            }
            return ret.ToArray();

        }

После чего мы просто выплёвываем эту последовательность на адрес устройства и считаем свою задачу выполненной.

Итак, что же нужно знать o MVC фреймворке?

Это уже устоявшаяся технология разработки программного обеспечения от Microsoft. Ею можно пользоваться, не особо опасаясь нарваться на подводные мины (хотя не бойтесь, мин у нас будет достаточно).

Это только присказка, сказка впереди

Итак, у нас есть базовый концепт приложения.

Всё хорошо, вокруг прыгают пони и поют птички. Всё работает.

Ага, как бы не так.

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

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

— 15% на все тарифы VDS (кроме тарифа Прогрев) — HABRFIRSTVDS
— 20% на выделенные серверы AMD Ryzen и Intel Core — HABRFIRSTDEDIC.
Доступно до 31 декабря 2021 г.

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

Поехали.

Криптовалюты и майнинг

Минусы: перевод ценнейших невосполнимых ресурсов на вычисления, не несущие НИКАКОЙ пользы. Сама концепция Proof of Work предполагает, что ценным и продаваемым становится не то, что ты сделал полезного, а насколько задолбался, точнее сколько ты вложил, а потом перевёл полезных ресурсов в некий эфемерный контент, который ни для чего кроме как для вычисления ЧСВ не годится. Хранить – опасно (взломы кошельков и бирж, кражи, которые невозможно «откатить»), использовать, как платёжное средство – долго, геморроойно и дорого. В любой золотой лихорадке первые прибыли идут с продажи лопат. В своё время это вроде не сильно повлияло на достаточность лопат для переселенцев на диком Западе для копания картошки, сейчас же дефицит электроники фигачит по всем отраслям, в том числе и из-за того, что значительная часть этого производства уходит на нужды копателей эфемерного золота. Про Грету и её защиту природы от перегрева писать не буду, и так понятно, что потребление электроэнергии гигаваттами ничего хорошего в данном случае не приносит. Как бы вы не относились к теории глобального потепления.

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

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

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

Плоский (акриловый, material …) дизайн интерфейсов

Минусы: когда это явление только появилось, оно смотрелось исключительно весело и прикольно. «Смотрите, пацаны, это не надпись, а, внезапно, кнопка!  Я догадался, а вы нашли?» Но чем дальше эта зараза, насаждаемая яблочными и не только хипстерами, стала проникать в жизнь, тем хуже становилась юзабельность привычных уже программ и девайсов. Ну, хорошо, на компьютере я провёл мышкой и выцепил момент, когда она, пролетая над элементом, временно мигнула формой курсора. «О, это можно нажать!» Но когда я стою с планшетом или мобилой, а ещё хуже перед банкоматом, гадать «методом тыкания» становится иногда очень даже рискованно.  Но попробуй сказать хоть слово в защиту скевоморфизма в интерфейсах, от ярлыка даже не Бумера, а динозавра будет очень тяжело откреститься. 

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

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

Итого: осудить и высмеять всем миром. Ввести требование чтобы действия не маскировались и были очевидными.  Оставить на задворках для каких-нибудь сект свободных художников.

Похмыкали, привыкли и фиг с ними? Ок, теперь перейдём к вопросу потяжелее.

Стартапы (особенно ИТ стартапы) и экономика стартапов

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

Как это на самом деле. За очень редкими исключениями. Цинично, и по существу. Хитрый финансист, не желающий, свой, не сильно праведно заработанный капитал вкладывать  «в долгую», организовывает структуру, которая рекламируется, как фабрика стартапов. Суть её работы: вы приходите с любой хернёй, которая может никому и не нужна, показываете, как это можно впарить обывателю-дураку, верящему в чудо/банкиру недоумку/спекулянту на таких же недоумках. Набираете рабов, которые за призрачную морковку на горизонте с надписью «доля в прибыли» в кратчайшие сроки и в адских условиях кодят/пилят/паяют неведомую фигню. Если это кодинг, то обязательно нужны все внешние карго-культовые атрибуты типа Аджайла/Скрама, и портрета Джобса во всю стену, закрывающего дыры и отвалившуюся штукатурку.  Обязателен внешний антураж в виде выступлений на технологических конференциях для таких же рабов, которые в результате начинают думать, что прогрессивные стартаперы это они и есть, а не тот ушлый манагер, который их продал организатору фабрики стартапов. Т.к. рабы далеко не безграмотны и чаще всего реально владеют определенными технологиями, им всегда есть о чем поговорить.  Плюс спонсором этого шоу обычно является тот самый владелец фабрики. В силу закона больших чисел 99% таких стартаперских затей проваливаются, не успев сделать вообще ничего, но неплохо собрав денег, в том числе и со сторонних инвесторов-лохов «в рост и перспективу». Часть на каком-то этапе обязательно палится на откровенном кидалове инвесторов, тогда это объявляется, как очищение святых прогрессивных рядов от недобросовестных конкурентов. Если сварганенная фигня может быть хоть как-то применена на практике, компанию начинают судорожно и с массой подтасовок готовить к продаже на бирже, что торжественно обзывается «выходом на IPO», и как-то до сих пор прокатывает с массой пустышек. Они же, при стабильно убыточной работе, становятся далее предметом торга и дальнейших спекуляций для тех, кого не пустили «в нефть/металлы». В плюсе: организатор фабрики, наёмный или добровольный погонщик рабов, кстати, часто искренне считающий себя инноватором, изобретателем и идеологом этого конкретного стартапа. В минусе – все остальные. Что на выходе: сгоревшие разработчики, которые вполне могли принести реальную пользу, работая в другом нормальном месте, создавая хоть что-то ценное. Отвратительного качества продукты и сервисы, к которым по-хорошему нужно сразу прикладывать многомиллионные иски за несоответствие заявленным качествам, но толератно-тактичное общество это жрёт, приговаривая «мы за прогресс, надо потерпеть, дальше будет лучше, но не сразу». Самое плохое: стиль работы на выгорание становится примером для многих работодателей (вот, они же смогли?) и, что ещё хуже, возводится в культ: «только так работают профессионалы». Для нормальных профи на своём месте становится упрёком: вы не горите на работе. Колоссальный отток капиталов, которые могли финансировать длинные ценные проекты в эту короткую спекулятивную кухню. Кончится это наверняка пузырём, как в своё время доткомы. Второй существенный минус: появляется желание поиграть в стартап. Как у бизнеса, который хочет казаться прогрессивным, финансируя неведомо что, так и у не прибитых никуда разрабов и затейников с менеджерской хваткой. Пока пилится продукт зарплаты могут быть очень даже неплохими. На выходе в лучшем случае велосипед среднего качества, в обычном – «не взлетело, это был риск, закрываем».

Итого: пора заканчивать толерантно относиться к обману потребителя и инвестора и перестать воспевать «феномен стартапов». Это просто создание ещё одного рынка пустышек, которое добром не кончится.

Методология разработки AGILE.  Продуктовый подход в инсорсе

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

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

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

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

У работника по найму в разработке на окладе всегда есть периоды, когда загрузка падает до минимальной. У более-менее людей с совестью (ого, совесть в 21-м веке) это вызывает некоторый дискомфорт. Деньги идут, отдачи нет. У людей, которые не сильно профессиональны, но существенно менее совестливы такие периоды вызывают дискомфорт тоже, но по другой причине. Появляется страх сокращения, а идти особо и некуда, т.к. квалификация невысока. Естественное разделение. Вот оно откуда.. Ушлые менеджеры, которые чаще всего совестью не обременены, нашли выход, как убрать дискомфорт и угрозу своему существованию и как снять напряжение у оставшихся, не сбежавших «специалистов». В инсорсе в результате нехитрых манипуляций сознанием Заказчика, т.е. владельца компании, тоже вводится и насаждается понятие Продукта. Бинго! Вместо выполнения конечной задачи с конечными сроками теперь можно бесконечно долго пилить одно и тоже, навешивая не всегда нужную функциональность, меняя технологии (все сейчас в контейнерах и на S3, нам тоже критически важно туда и именно сейчас, кто опоздал, тот проиграл!). Бизнесу не надо показывать окончательные сроки, боль дедлайна размазывается на мелкие боли. Защищать стоимость Проекта не надо. Проекта же нет. Главная задача этого подхода: исчезновение даты окончания разработки и передачи результата в эксплуатацию. Как-нибудь сами, навсегда. Разработка становится вечной, зарплата всегда оправдана. Выгода вторичная: баги и косяки всегда имеют обоснование: мы пилили фичу срочно, в следующем спринте исправим. Минусы: разработка ведётся оставшимися ресурсами, которые приняли такую ситуацию, как должное. Многим их них стыдно, но они никогда в этом не признаются: «Это же мэйнстрим, все так работают, мы прогрессивные Скрумщики, а не какие-то замшелые ватерфоллисты.» Бизнес видит, что концов уже не найти, остальные коллеги по несчастью смирились тоже, управленческий строй поддерживает всячески миф о прогрессивности и эффективности Продуктового подхода. Гибкие методологии разработки тут подходят идеально, их распиаренная популярность великолепно закрывает вопрос совестью и сомнения у того, кто это банкет транжирства оплачивает. На выходе: стоимость владения такими инструментами в разы, иногда на порядки выше, чем покупка немодного готового адаптированного решения. Инструмент (Продукт) никогда не работает так, как это нужно заказчику, эффективность низкая, а значит и себестоимость того, чем бизнес это безобразие оплачивает тоже растёт.

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

И последнее на сегодня, DevOps-ерское безумие

Плюсы: иногда это работает. Как великолепно описано в книге «корпорация Феникс» работать с мудаками нельзя. Если на стороне разработки сидят ленивые ортодоксальные ботаны, которым нормально ввалить в файловую структуру миллион файлов: «а что такого, код же красивый», а на стороне инфраструктуры сидят динозавры, накатывающие ось на железо, да ещё и вручную через GUI, то явно что-то идёт не так.

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

Минусы. Это не то, что в жизни.  Сейчас мне скажут, что это же и есть DevOps! В книге всё же расписано, и непрерывное тестирование, и непрерывная доставка изменений, и подготовка сред выполнения, как кода самими разработчиками. Все разбираются досконально во всём, все такие лапочки, что только порадоваться можно. А когда задолбало покупать серваки стойками, то все дружно ушли в облако и настало счастье. Фигак и занавес.

Так вот это оптимистичное описание ничего общего не имеет с реальной жизнью и с тем, что нынче называют DevOps подходом. На практике обычно появляется кучка (или один-два) разрабов, которые узнали, что «DevOps-ам много платят» и они решили по верхам (иногда и глубоко) пройтись по модным темам, типа K8S, Helm, Terraform. Даже ничего не понимая, и не считая нужным понимать, что базы не в воздухе размещены и живут, а на дисках, не по воздуху приходят, а по сети, не в вакуум, а на вычислительную ноду, которая будь хоть сто раз вложенно виртуализирована, один чёрт работает на процессоре с какой-то своей специфичной архитектурой и особенностями. Что тупо добавить памяти не всегда приводит к росту скорости. (Про NUMA они наверняка вообще никогда не слышали.)

Эти «девопсы» начинают неплохо, пока всё живёт по-старому, на настроенной специалистами платформе, потом потихоньку начинают городить дичь, перестают быть вменяемыми при общении с другими профессионалами и в случае неизбежных факапов всегда находят на что свалить сорванный SLA. На тяжёлое наследие легаси, разумеется. И старое железо, от которого пора избавиться..

В чем же проблема? А она в том, что нельзя любого «многостаночника» автоматически называть девопосом, на девопса нельзя выучиться «с нуля». Должен быть багаж и опыт за спиной, и желательно не узко прикладной.  Нельзя такому «девопсу» отдавать безраздельную власть над проектом и уж тем более над инфраструктурой. Специалисты сетевики, как ни странно, очень даже нужны. Как и системные инженеры, и DBA со знанием особенностей СУБД. Надо перестать платить конские деньги просто за знание модных технологий и стеков, начать считать TCO и понимать, что подход «смасштабируемся, если что, горизонтально» чаще всего изначально неправильный. В общем, тут не столько про вред DevOps, а про вред модных шарлатанов. И недобросовестную эксплуатацию модного термина. Но так недалеко и до того, что рациональные вещи скоро тоже будут хейтить только за то, про них какой-то реальный  адекватный DevOps положительно высказался.

Итого: не надо «всё в девопс». Чаще всего вам это не нужно, либо не по карману. А то, что по карману не является тем, чем названо.

Ну и самое последнее, про «все в облака!». Хоть здесь наконец-то мировой разум немного пришёл в себя, вывесил лозунг «Cloud repatriation!» и пошёл верным путём, в гибриды.

А что Вы считаете вредным и требующим адекватной и справедливой реакции общества?

Добра всем, жить своим умом, разума и процветания!