F

Почему ты не Powershell?

$Path=C:\users\test\folder$Trimer=$Path.Split(\)[$Path.Split(\).Count-1]$Path.Trim($Trimer)

Не такой уж и умный компилятор

let splitPath inputObject: string =    let q = inputObject.Split(System.IO.Path.DirectorySeparatorChar)     q

let splitPath inputObject: string =    let mutable inputObject : string = inputObject    let q = inputObject.Split(System.IO.Path.DirectorySeparatorChar)     q

LInq

Нет ++

F#, ну зачем?

Printf, printfn, нейминг

Out-HostInputstring -Newline

Napespaces и ленивый Open

||>, <|, почему не | ?

(1,2)||>someFunction

1|>someFunction

printfn%s(stringValue)

printfn%s<|stringValue

Почему ты не F#?

Some, None

  let dictionary = Dictionary<string, string> ()       let getFromDictionary key =        match dictionary.TryGetValue (key) with        | true, value -> Some (value)        | false, _ -> None

Discriminated union aka алгебраические типы

type ValidInput =    | Txt of string    | Ini of string type InvalidInput =    | WrongFormat    | FileDoesNotExists    | FileIsEmpty    | OtherBadFile type Input =    | ValidInput of ValidInput    | InvalidInput of InvalidInput

let input = testInputObject request match input with| ValidInput (x) -> invokeAction x | InvalidInput (x) -> writeReject x 

Непробиваемый дизайн языка

• Нет return. Вернуть значение из функции можно только в конце после отработки всей логики.
• Нет if без else. Потому, что if без else обычно применяется там, где будет возвращен null.
• Type of Value. В F# всегда возвращается либо тип, либо значение какого-то типа, но никогда не Null.

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

Имутабельность по умолчанию

DDD

let getUserType key =    let user = getFromDatabase key    if user.HaveWings = true then "Parrot"    else "Cat"

let getUserType key =    let user = getFromDatabase key    if user.HaveWings = true then "Parrot"    else "Cat"

let splitPath inputObject =     let mutable inputObject : string = inputObject    let stringArray = inputObject.Split(System.IO.Path.DirectorySeparatorChar)       let mutable outString = ""    for i in stringArray do        outString <- i      let chararray = outString |> Seq.toList |> List.rev    for c in chararray do        inputObject <- inputObject.TrimEnd(c)     printfn "%s" inputObject splitPath @"C:\users\test\folder"

Смотрите мой подкаст

Подводный камень #1: Async не работает асинхронно

  async Task WorkThenWait()  {      Thread.Sleep(1000);      Console.WriteLine("work");      await Task.Delay(1000);  }   void Demo()   {      var child = WorkThenWait();      Console.WriteLine("started");      child.Wait();      Console.WriteLine("completed");  }

Соответствующий код F#

let workThenWait() =     Thread.Sleep(1000)    printfn "work done"    async { do! Async.Sleep(1000) } let demo() =     let work = workThenWait() |> Async.StartAsTask    printfn "started"    work.Wait()    printfn "completed"  

let workThenWait() = async{     Thread.Sleep(1000)    printfn "work done"    do! Async.Sleep(1000) }  

Подводный камень #2: Игнорирование результатов

async Task Handler() {   Console.WriteLine("Before");   Task.Delay(1000);   Console.WriteLine("After");} 

Соответствующий код F#

let handler() = async{    printfn "Before"    Async.Sleep(1000)    printfn "After" } 

warning FS0020: This expression should have type unit, but has type Asyncunit. Use ignore to discard the result of the expression, or let to bind the result to a name.

предупреждение FS0020: Это выражение должно иметь тип unit, но имеет тип Asyncunit. Используйте, ignore, чтобы отбросить результат выражения или let, чтобы связать результат с именем.

let handler() = async {   printfn "Before"   do! Async.Sleep(1000)   printfn "After" } 

Подводный камень #3: Асинхронные методы, которые возвращают void

async void ThrowExceptionAsync() {    throw new InvalidOperationException();}public void CallThrowExceptionAsync() {    try     {        ThrowExceptionAsync();    }     catch (Exception)     {        Console.WriteLine("Failed");    }} 

Соответствующий код F#

let throwExceptionAsync() = async {    raise <| new InvalidOperationException()  }let callThrowExceptionAsync() =   try     throwExceptionAsync()     |> Async.Start   with e ->     printfn "Failed"

Подводный камень #4: Асинхронные лямбда-функции, которые возвращают void

Parallel.For(0, 10, async i => {    await Task.Delay(1000);});

Соответствующий код F#

Parallel.For(0, 10, fun i -> async {  do! Async.Sleep(1000) })

error FS0041: No overloads match for method For. The available overloads are shown below (or in the Error List window).

ошибка FS0041: не найдены перегрузки для метода For. Доступные перегрузки показаны ниже (или в окне списка ошибок).

Parallel.For(0, 10, fun i -> Async.Start(async {  do! Async.Sleep(1000) }))

Подводный камень #5: Вложенность задач

Console.WriteLine("Before");await Task.Factory.StartNew(    async () => { await Task.Delay(1000); });Console.WriteLine("After");

async {  do! Task.Factory.StartNew(fun () -> async {     do! Async.Sleep(1000) }) |> Async.AwaitTask }

error FS0001: This expression was expected to have type Asyncunit but here has type unit

ошибка FS0001: Ожидается выражение типа Asyncunit, присутствует тип unit

Подводный камень #6: Асинхронность не работает

async Task FooAsync() {    await Task.Delay(1000);}void Handler() {    FooAsync().Wait();}

let fooAsync() = async {    do! Async.Sleep(1000) }let handler() =     fooAsync() |> Async.RunSynchronously

Резюме

Я много раз слышал, как программисты смеются над тиммейтами, которые написали медленный код. Резкие, самодовольные фразы в стиле "этот болван четыре раза пробежался по коллекции, хотя можно было один", и тому подобное. Когда слышишь такое, сразу думаешь ну тут все по делу, зачем делать лишние итерации? Почему нельзя изучить пару элементарных вещей, вроде принципов работы LINQ выражений в C#, и писать нормальный код? Ты смеешься над некомпетентными тупицами до тех пор, пока смеяться не начнут над тобой. И можете мне поверить никакие знания в программировании не спасут вас от ситуации, когда вы по незнанию зафигачили квадратичный алгоритм вместо линейного.

Я не знаю, смеялся ли кто-то над моим кодом, но я точно уверен не раз и не два я писал решение, которое было в сто раз медленнее, чем могло бы быть. Но в этих случаях я сознательно писал неоптимально. Например в C# есть цикл for, и есть метод коллекции Select (в других япах он чаще называется map). Цикл быстрее, но я считаю функциональный подход более эстетичным и использую его. Я знаю, что данных мало, тут не будет ботлнека, и пишу код, который по-моему красивей, читабельней и потому лучше. Таких решений при разработке очень много и я выбираю писать производительный код только когда точно знаю, что иначе просадки станут проблемой.

Есть очень много разрабов, которые делают по-другому, и искренне считают, что такие как я дерьмовые инженеры. У меня есть друг, опытный разраб высокого класса, который на днях выпнул человека с собеса, потому что тот предоставил медленное решение. Задача была реализовать специфичный LINQ метод. В C# эти методы следует делать ленивыми через итераторы и yeild а парень просто зафигачил новый список, и стал пихать в него значения, чем сломал ленивость. На больших срезах данных это может создать крупные и главное неожиданные просадки в производительности, достаточные, чтобы на доске завелся баг. По большому счету, тут дело даже не в снижении производительности, а в перемещении ботлнека в неожиданное место не самая приятная хрень.

Я бы никогда не поставил крест на разработчике из-за такого, потому что сам не заморачиваюсь с yield, пока данных не становится по-настоящему много. С новым листом сделать интуитивно проще, принципы работы LINQ я хорошо понимаю. У меня нет задачи писать какой-то совершенный, абсолютно отказоустойчивый код заранее, и даже тогда, когда мне оптимизация ничего не стоит, я не всегда её применю. И я такой не один. В майкрософтской доке по LINQ пример добавления своего метода предложен именно с новым списком потому что у создателя примера были дела поважнее, чем возиться с итераторами.

Мы позвали в подкаст Андрея Акиньшина человека, который действительно разбирается в производительности. Создатель BenchmarkDotNet, автор книги Pro .NET Benchmarking, топовый докладчик на темы производительности, поведения рантайма и бенчмаркинга в дотнете, и просто очень, очень, очень крутой инженер. Мой друг, который прогнал человека с собеса слепой котеночек в вопросах перформанса по сравнению с ним.

Знаете, что нам сказал Андрей? Что эстетика важнее производительности, пока у тебя нет ботлнеков.

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

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

И эти спичечники считают, что они крутые парни, а все остальные вшивые говноделы. Мне есть что им сказать. Если ты взял for вместо select, хотя оба варианта нас устраивают по скорости, то почему ты тогда остановился на этом? Какой ещё C#, братан, C# это медленно. Давай возьмем C++. А лучше ассемблер. Нет, стоп, ассемблер неоптимален давай сразу фигачить машинные коды. Эстетика, поддерживаемость, читабельность это же все херня собачья. Важно, чтобы все четыре элемента связного списка были выведены на экран наиболее быстрым способом.

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

Хорошо, когда скорость и красивость не противоречат друг другу. Если по условиям задачи тебе больше подходит Queue, а не List взять очередь будет и эстетичнее, и производительнее. Но люди, которым совершенно не интересно быстродействие, никогда об этом не узнают. Вы легко отличите их шарповый код там везде будут листы.

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

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

За примерами далеко ходить не надо достаточно просто посмотреть на современных фронтендеров. Большая часть из них, когда увидят "производительность, C#, LINQ" захлопнут эту статью, и не дочитают до этого места. Так что теперь мы можем поговорить, что у них нет никакой инженерной культуры. Они делают самые тормозные вещи в мире вроде всяких электронов у них в языке из коробки всего два вида коллекций они про другие и знать не знают. Их инструменты для билдов и управления пакетами работают так медленно, что после ввода "yarn start" можно смело идти смотреть сериал. Итоговые файлы, которые получаются после компиляции весят раз в сто больше, чем должны были. Создается эффект снежного кома. Как теперь не переучивай их, какую культуру не прививай с большинством проблем фронтенд инфраструктуры особо ничего и не сделаешь если только не переписать её с нуля.

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

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

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

Смотрите мой подкаст

Несколько недель назад вышел .NET 5. На сайте Microsoft можно найти подробный анонс со всеми изменениями, но главный вопрос для меня, как для разработчика и что с того? Что мне с выхода пятого дотнета, как я могу его использовать, есть ли смысл переходить на новую версию прямо сейчас? На эти вопросы я постараюсь ответить дальше.

Перфоманс

Изменения в перфомансе это самая заметная часть релиза. О них много писали на сайте Microsoft и рассказывали на .NET Conf. Давайте посмотрим внимательнее и определимся, где, насколько и за счет чего выросла производительность.

Измерения перфоманса с этого скрина основаны на бенчмарках от TechEmpower. Здесь Microsoft сравнивают результаты замеров производительности .NET 3.1 с ожидаемыми значениями для .NET 5. Стоит заметить, что это именно ожидаемые значения реальных результатов от TechEmpower пока не было. Однако уже эти результаты выглядят впечатляюще ускорение на 38 процентов для Plaintext, на 42 для Json и на 20 процентов в категории Fortunes (пояснения по разным типам бенчмарков вы можете найти в вики TechEmpower).

Помимо результатов бенчмарков от TechEmpower, Microsoft также рассказывает и о других улучшениях. Например, сериализация JSON стала работать на 20% быстрее, а сериализация больших коллекций и массивов ускорилась аж в три раза.

Также замеры производительности делал автор библиотеки Fusion Александр Якунин. В двух статьях на Medium он сначала измерил, насколько ускорилась работа демок его библиотеки (от 20 до 105 процентов), а затем проверил пятый .NET на нескольких синтетических бенчмарках и также получил некоторое ускорение.

За счет чего это происходит? В первую очередь, благодаря изменениям в GC, которые привели к уменьшению количества аллокаций и ускорению сборки мусора. Кстати, все эти изменения осуществляются одновременно с переписыванием GC на C#, а значит его код становится куда доступнее, понятнее и безопаснее. Подробности можно почитать в статье от Microsoft.

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

Изменения в JSON сериализации выглядят особенно впечатляюще. Только посмотрите на результаты бенчмарка по сериализации больших массивов!

private MemoryStream _stream = new MemoryStream();private DateTime[] _array = Enumerable.Range(0, 1000).Select(_ => DateTime.UtcNow).ToArray();[Benchmark]public Task LargeArray(){    _stream.Position = 0;    return JsonSerializer.SerializeAsync(_stream, _array);}

Коротко пятый дотнет сильно вырос в производительности и это важнейшая часть нового релиза. Большинство стандартных веб-приложений могут ожидать прирост производительности на 20% и выше, а отдельные приложения могут и вовсе ускориться в несколько раз.

Языковое

Вместе с .NET 5 вышла и девятая версия C#. Официальную страничку с изменениями вы можете найти на сайте Microsoft, но давайте попробуем разобраться что именно здесь стоит внимания?

Самое заметное изменение это record-типы, позволяющие избавиться от бойлерплейта при написании DTO. Записи это иммутабельные ссылочные типы с простым и коротким объявлением. В них по умолчанию определены методы Equals, HashCode, Copy, Clone, PrintMembers и ToString разумеется, все они используют значения полей типа для выполнения операций. То есть Equals корректно сравнивает две записи по значениям, а не по ссылке.

Также записи поддерживают синтаксис копирования с изменением значений полей через with, например:

var person = new Person { FirstName = "Mads", LastName = "Nielsen" };var otherPerson = person with { LastName = "Torgersen" };

Больше о применении записей вы можете почитать в блоге Владимира Хорикова и в публикации от Konrad Kokosa.

Другое важное изменение это обновленный pattern matching. Теперь паттерны могут настраиваться по типам и операторам сравнения, причем несколько разных сравнений вы можете объединять через логические операторы. Например:

DeliveryTruck t when t.GrossWeightClass switch {    < 3000 => 10.00m - 2.00m,    >= 3000 and <= 5000 => 10.00m,    > 5000 => 10.00m + 5.00m}

Остальные изменения не столь заметны они касаются верхнеуровневых программ (возможность писать короткие программы без базового класса и функции main), упрощенного синтаксиса для new (без указания типа), init-only сеттеров и прочего.

Последние изменения в новом C#, которые хотелось бы упомянуть это расширенная поддержка для source generators. Этот функционал позволяет генерировать код при компиляции проекта и зачастую очень удобен для авторов библиотек. В новом релизе работу с генераторами кода сделали чуть проще, расширив функционал partial классов (с них сняли некоторые из старых ограничений) и добавив инициализаторы модулей (методы, которые вызываются до первого доступа к любому полю/методу модуля).
Хороший пример работы с генераторами кода вы можете найти в этой статье на Medium.

Отдельно стоит рассказать про F# 5. В новой версии языка добавилась масса классных возможностей для скриптов (например, директива для подключения nuget пакетов), slicing для более удобной работы с данными, а также улучшилась работа с quotation expressions и computation expressions. А еще сильно улучшился интероп с C# и перфоманс. Словом, новый релиз выглядит интересно и делает F# потенциально полезнее в продакшене. Полное описание всех изменений можно найти на сайте Microsoft.

Коротко язык оброс разнообразным сахаром. Самое заметное изменение в C# 9 это записи, но едва ли оно само по себе стоит обновления. С другой стороны, если вы будете обновлять версию дотнета по каким-то другим причинам, то у вас появится новый функционал, делающий язык чуть более мощным. Мелочь, а приятно.

Прочее

Помимо глобальных улучшений платформы Microsoft также неплохо поработали над отдельными библиотеками.

Например, в новой версии дотнета сильно улучшилась поддержка десктопа. WinForms и WPF наконец-то получили все преимущества .NET Core классный перфоманс, упаковка всего приложения в один .exe, работа без установленного на машине дотнета и и нет, не кроссплатформенность. Все это работает только под Windows.

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

С кроссплатформенностью все осталось по-прежнему. Релиз MAUI перенесли на .NET 6, а других решений для кроссплатформенного десктопа Microsoft пока не предлагает. Так что продолжаем использользовать Авалонию (или можно обратить свое внимание на Uno Platform перспективно выглядящий фреймворк для разработки на все и сразу).

Еще больше улучшений появилось для фулстек веб-разработки с использованием Blazor. Главное из них это улучшения производительности Microsoft обещают, что WebAssembly версия Blazor ускорится аж в три раза. Одной из основных причин такого роста производительности стал пререндер на стороне сервера. А еще добавили ленивую подгрузку зависимостей, изоляцию CSS/JS в рамках файла, новые контролы и многое другое. В общем, если вы собирались попробовать Blazor, но все никак не доходили руки сейчас он выглядит куда более production-ready технологией.

Из оставшихся изменений заметнее всего смотрятся те, которые призваны помочь микросервисам и работе с облачными сервисами в целом. Здесь и уменьшение размеров Docker-контейнеров, и улучшенная поддержка gRPC, и поддержка OpenAPI по умолчанию, и многое другое. Кстати, Azure полностью поддерживает .NET 5 со дня релиза.

А еще Microsoft выкатили Project Tye, который как раз является инструментом для удобного управления микросервисами. На текущий момент трудно сказать, стоит ли использовать Tye в продакшене, но обратить внимание и поиграться с ним в свободное время определенно нужно.

Коротко Microsoft улучшили поддержку отдельных инструментов и добавили приятных фич для облака. Если вы используете WinForms, WPF или Blazor обновиться определенно стоит.

Миграция

Давайте разберемся, насколько сложно будет мигрировать ваше приложение с .NET Core 3 на .NET 5?

Гайд по миграции от Microsoft говорит нам, что основные сложности в миграции коснутся приложений на Blazor, там произошло много ломающих изменений. Для большинства же остальных приложений понадобится просто обновить версию дотнета в application.json, файл проекта и версии зависимостей. А еще адрес докер-контейнера с .NET 5 немного отличается от соответствующего адреса для .NET 3.1:

docker pull mcr.microsoft.com/dotnet/core/aspnet:3.1docker pull mcr.microsoft.com/dotnet/aspnet:5.0

Другие отзывы о миграции, которые я смог найти например, вот этот гайд от Alexandre Malavasi и твит о миграции Fusion от Александра Якунина тоже говорят, что миграция проходит без каких-то специфических трудностей. Я также не столкнулся с особыми проблемами, пока мигрировал свои проекты и демки на новый дотнет. В любом случае, перед миграцией на новую версию советую внимательно изучить список ломающих изменений. А еще стоит посмотреть доклад про миграцию с .NET Conf.

Итого

Подведем итоги. Стоит ли мигрировать на новый дотнет и ради чего?

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

Другие важные причины для миграции это улучшения для Blazor и WPF/WinForms. Если вы используете любой из этих фреймворков, стоит попробовать перейти на .NET 5, все же изменения достаточно заметные и полезные. Однако стоит учитывать, что для Blazor миграция выйдет достаточно непростой.

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

И на этом все! Удачной миграции на новый дотнет. Оставайтесь на связи, мы вернемся с более подробными материалами про современные возможности дотнета.

О Jupyter

О dotnet/interactive

Об AngouriMath

Встраиваем латех

let magic() =    let register (value : ILatexiseable) = $@"            <script src='https://polyfill.io/v3/polyfill.min.js?features=es6'></script>            <script id='MathJax-script' async src='https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js'></script>            \[{value.Latexise()}\]            "    Formatter.Register<ILatexiseable>(register, "text/html")

Дальнейшие планы

Ссылки

Предисловие

Мой переход на F# в качестве излюбленного языка был слегка усеян препятствиями. Примерно через десять лет почти постоянного использования C# у меня пробудилось любопытство, когда я услышал об этом другом #-языке. Моя первая реакция была той, которую с тех пор видел у других C#-разработчиков отрицание, C# является хорошим языком, и мне с ним комфортно, так зачем тратить силы на изучение другого? Но любопытство осталось и, по крайней мере, несколько раз выделил вечер, чтобы прочитать базовый вводный пост и попытаться написать каких-нибудь ката на F#. Это не прижилось, потому что я просто чувствовал себя потерянным и не мог воплотить свой опыт использования C# в ощущение даже отдаленного комфорта с F#. Достаточно легко опустить фигурные скобки, немного замяться, чтобы не забыть let вместо var но как сделать то, что я хотел?

Тогда я этого не осознавал, но, на мой взгляд, наблюдал потенциальный недостаток в том, как F#-разработчики говорят, описывают и представляют свой язык внешнему миру. Существует обширная база материалов обо всех возможностях и функциональности F#: Algebraic Data Types, Exhaustive Matching, Type Inference и т.д. Есть много статей, посвященных тому, как решать широкий спектр задач с помощью F#. Но, как мне кажется, не хватает чего-то вроде следующего: некоторых указаний о том, как взять то, что вам уже удобно в C#, и перевести их на F#. Так что мне интересно, можем ли мы как-то закрыть этот недостаток.

При этом от читателя требуется немного поверхностное знакомство с тремя основными моментами синтаксиса F#:

• let используется как var в C# для объявления переменной;
• |> это оператор пайпа (piping) в F#, который берет результат левой части и передает его в качестве аргумента для правой части;
• F# использует строчные буквы и апостроф для аннотаций обобщенного типа, поэтому SomeType<T> представлен как SomeType<'a>.

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

• Мне необходимо
  
  • Работать с коллекциями
    
    • Подобрать тип коллекции
      
      • Что-то похожее на Array<T>
      • Что-то похожее на List<T>
      • Что-то похожее на Dictionary<TKey,TValue>
    • Подобрать функцию
    • Просто хочу свой LINQ
    • Не уверен, какая функция нужна. У меня есть
      
      • Коллекция, а хочу
        
        • Отдельное значение или элемент
          
          • Равное количество элементов
          • Возможно меньшее количество элементов
          • Возможно большее количество элементов
          • Чтобы изменить форму коллекции
          • Чтобы пройти по коллекции без ее изменения
        • Отдельное значение и хочу
          
          • Чтобы было частью коллекции
        • Несколько коллекций и хотите
          
          • Скомбинировать их
  • Работать асинхронно
  • Сообщать об ошибке или контролировать выполнение программы
  • Использовать C#-библиотеки в F#

Мне необходимо

Работать с коллекциями

В F# базовые типы коллекций (в основном) как правило очень похожи на C#, но часто имеют (иногда незначительные) различия в поведении для обеспечения иммутабельности. В большинстве случаев функции, которые работают с этими коллекциями, будут возвращать ссылки и не будут изменять содержимое исходной ссылки.

Подобрать тип коллекции

Что-то похожее на Array<T>

Тебе повезло! Массивы в F# такие же как в C#. Однако следует отметить несколько моментов:

1. Массивы в F# обычно используют нотацию [|element|], потому что [] это нотация для списков в F#.

   
   

2. Для разделения элементов коллекции в F# используется точка с запятой, а не запятая: [|elementA;elementB|].

   
   

3. Для доступа по индексу в F# требуется префиксная точка перед фигурными скобками:

   
   

   let myArray = [|1;2;3|]myArray.[1] // 2
   

   
   

4. F# также предлагает многомерные массивы до 4-х измерений через типы Array2<'a>, Array3<'a> и Array4<'a>.

   
   

Что-то похожее на List<T>

По умолчанию в F# тип списка немного отличается от типа List<T> в C#.

Вот что вам нужно знать:

1. Списки в F# обычно используют нотацию [element] в отличие от массивов.

   
   

2. Списки, как и массивы, разделяют элементы точками с запятой вместо запятых: [elementA;elementB]

   
   

3. Списки в F# реализованы как односвязные списки это означает, что добавление отдельных элементов выполняется в начале списка с помощью оператора :::

   
   

   let myList = [1;2;3]4 :: myList // [4;1;2;3]
   

   
   

4. Если нам необходимо добавить в конец, мы можем использовать оператор @ для объединения двух списков:

   
   

   let listA = [1;2]let listB = [3;4]listA @ listB // [1;2;3;4]
   

   
   

Что-то похожее на Dictionary<TKey,TValue>

По мотивам списка выглядит похоже, но не нет F# предоставляет стандартный Map<'key,'value> тип, который не является родным для C# Dictionary<TKey,TValue>, но реализует обычную группу интерфейсов .NET, таких как IDictionary<TKey,TValue> и IEnumerable<T>

Вот что вам нужно знать:

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

   
   

   [(1,2);(3,4)] |> Map.ofList // [1] = 2, [3] = 4
   

   
   

2. Если создаем из последовательности, где есть дубликаты, то последний элемент для данного ключа является значением:

   
   

   [(1,2);(1,3)] |> Map.ofList |> Map.find 1 = 3 // true
   

   
   

3. Верен и обратный процесс: словари можно легко превратить в коллекции кортежей из двух элементов:

   
   

   [(1,2);(3,4)] |> Map.ofList |> Map.toList // [(1,2);(3,4)]
   

   
   

4. Встроенный тип Map в F# не очень хорошо подходит для использования в C#, в случаях интеропа мы можем создать более удобный для C# словарь IDictionary, используя функцию dict с любой коллекцией кортежей из двух элементов. Но учтите, что это по-прежнему неизменяемая структура, и при попытках добавить в нее элементы будет генерироваться исключение.

   
   

   [(1,2);(3,4)] |> dict
   

   
   

Подобрать функцию

Одно важное различие между F# и C#, когда дело доходит до работы с коллекциями, заключается в том, что в C# вы, как правило, оперируете над экземпляром коллекции, используя метод этого типа через точку; в то время как F# предпочитает предоставлять семейства функций в модулях, которые принимают экземпляры в качестве аргумента. Итак, C#-вариант myDictionary.Add(someKey,someValue) в F# будет Map.add someKey someValue myMap.

Просто хочу свой LINQ

F# предлагает функции, аналогичные тем, с которыми программисты на C# знакомы по LINQ, но названия часто отличаются, поскольку F# использует систему условных обозначений, которая больше соответствует терминологии, используемой в остальной части мира функционального программирования. Будьте уверены, они в основном ведут себя так, как вы и ожидаете. Дабы не утомлять LINQ огромен, я сопоставлю, по моему опыту, наиболее распространенные методы LINQ и их аналоги на F#:

• .Aggregate() именуется как .fold или .reduce, в зависимости от того, предоставляете ли вы начальное состояние или просто используете первый элемент, соответственно;
• .Select() именуется как .map;
• .SelectMany() именуется как .collect;
• .Where() именуется как .where или .filter (одно и то же, два имени, длинная история)
• .All() именуется как .forall;
• .Any() именуется как .exists, если мы подаем предикат, или .isEmpty, если мы просто хотим знать, есть ли в коллекции какие-либо элементы;
• .Distinct() по-прежнему как .distinct или .distinctBy, если мы подаем функцию проекция;
• .GroupBy() по-прежнему как .groupBy;
• .Min() и .Max() по-прежнему остаются как .min и .max с альтернативами .minBy и .maxBy для использования проекции
• .OrderBy() именуется как .sortBy, и аналогично .OrderByDescending() именуется как .sortbyDescending;
• .Reverse() именуется как .rev;
• .First() именуется как .head, если нам нужен первый элемент, или .find, если нам нужен первый элемент, который соответствует предикату. Точно так же вместо .FirstOrDefault() мы используем .tryHead и .tryFind, которые вернут Option, являющимся либо Some matchingValue, либо None, когда он не найден, вместо того, чтобы выбрасывать исключение;
• .Single() именуется как .exactlyOne, и аналогично .SingleOrDefault() именуется как .tryExactlyOne.

Не уверен, какая функция нужна. У меня есть

Коллекция, а хочу

Отдельное значение или элемент

• .min, .minBy, .max и .maxBy найдут элемент коллекции относительно других;
• .sum, .sumBy, .average, .averageBy;
• .find, .tryFind, .pick и .tryPick позволят найти один конкретный элемент коллекции;
• .head, .tryHead, .last и .tryLast найдут элементы из начала или конца коллекции;
• .fold и .reduce позволят применить логику и использовать каждый элемент коллекции для формирования другого значения;
• .foldBack и .reduceBack делают то же самое, но с конца коллекции.

Равное количество элементов

• .map позволит преобразовать каждый элемент коллекции;
• .indexed свернет каждый элемент вашей коллекции в кортеж, первым элементом которого является индексом в коллекции: например, [1] станет [(0,1)];
• .mapi делает это неявно, учитывая индекс в качестве дополнительного первого аргумента функции маппинга;
• .sort, .sortDescending, .sortBy и .sortByDescending позволяют изменить порядок вашей коллекции.

Возможно меньшее количество элементов

• .filter вернет коллекцию, содержащую только элементы, соответствующие указанному предикату;
• .choose похож на .filter, но заодно позволяет маппить элементы;
• .skip вернет оставшиеся элементы после игнорирования первых n;
• .take и .truncate возвращают первые n-элементов, выбрасывая или нет исключение, соответственно;
• .distinct и .independentBy позволят удалить дубликаты из коллекции.

Возможно большее количество элементов

• .collect применит функцию создания коллекции к каждому элементу вашей коллекции и объединит все результаты воедино.

Чтобы изменить форму коллекции

• .windowed вернет новую коллекцию всех групп размером n из исходной коллекции: например, [1; 2; 3] станет [[1; 2]; [2; 3]], когда n = 2;
• .groupBy вернет новую коллекцию кортежей, где первый элемент является ассоциативным ключом, а второй набором начальных элементов, которые соответствуют ассоциации: например, [1; 2; 3], преобразованной (fun i -> i % 2), приведет к [(0, [2]); (1, [1; 3])];
• .chunkBySize вернет новую коллекцию, содержащую до n коллекций оригинала: например, [1; 2; 3] станет [[1; 2]; [3]], когда n = 2;
• .splitInto вернет новую коллекцию, содержащую n коллекций одинакового размера из исходного: например, [1; 2; 3] станет [[1]; [2]; [3]], когда n = 3.

Чтобы пройти по коллекции без ее изменения

• .iter и .iteri берут и применяют функцию к каждому элементу вашей коллекции, но не возвращают никакого значения.

Отдельное значение и хочу

Чтобы было частью коллекции

• .singleton можно использовать для создания коллекции из одного элемента из значения;
• .init примет размер и функцию инициализатора и создаст новую коллекцию этого размера.

Несколько коллекций и хотите

Скомбинировать их

• .append принимает две коллекции и создает новую единую коллекцию, содержащую все элементы обеих;
• .concat делает то же самое, но для коллекции коллекций;
• .map2 и .fold2 действуют как выше указанные .map и .fold, но будут предоставлять элементы из одного индекса в двух исходных коллекциях для функции маппинга / свертки;
• .allPairs принимает две коллекции и образует все перестановки по 2 элемента между ними;
• .zip и .zip3 берут 2 (или 3) коллекции и создают одну коллекцию, состоящую из кортежей элементов из одного индекса в источниках.

Работать асинхронно

Модель асинхронности в F# похожа на модель в C#, но имеет несколько важных отличий, которые иногда застают врасплох C#-разработчиков:

1. F# имеет отдельный тип Async<'t>, похожий на Task<T> в C#.

   
   

2. Из-за того, что система типов F# требует возврата, она использует Async<unit> вместо Task в случаях, когда мы не возвращаем фактического значения.

   
   

3. F# может генерировать и использовать Task<T> с помощью функций Async.StartAsTask и Async.AwaitTask из базовой библиотеки.

   
   

У F# есть еще одно очень заметное отличие от C# в отношении асинхронного кода: C# "включает" ключевое слово await внутри метода, применяя ключевое слово async к сигнатуре этого метода; F# использует языковую функцию, называемую computation expression, в результате чего асинхронность становится частью тела функции. Это также имеет некоторые последствия на то, как вы пишете код внутри этого тела функции:

let timesTwo i = i * 2 // У нас есть определение нашей базовой функции// И теперь мы можем сделать это асинхроннымlet timesTwoAsync i = async { // Обратите внимание, что при работе с computation expression мы начинаем с нашего ключевого слова, а затем с самой функции внутри фигурных скобок   return i * 2 // Мы также используем ключевое слово `return` для завершения выражения}let timesFour i = async {    let! doubleOnce = timesTwoAsync i // Обратите внимание  на `!` в нашем `let!`  это похоже на `await` в C#  правосторонняя функция должна возвращать `Async<'a>`    // После того, как мы связали результат асинхронной функции с помощью `let!`  мы можем использовать его потом как обычно    let doubleTwice = timesTwo doubleOnce // В случае неасинхронных функций мы можем написать наш код как обычно    return doubleTwice}

1. Имейте в виду, что let! в Async-блоках работают только при вызове Async-образующих функций аналогично тому, как в C# await можно использовать только для методов, возвращающих Task.

   
   

2. Другой путь, однако, заключается в том, что поскольку F# обрабатывает асинхронность исключительно в теле функций, нет никаких требований о том, какие функции вы можете связывать с let! все, что возвращает Async<'a>, допустимо. Это противоположно требованиям C# о том, что вы можете применять await только к методам, помеченным как async.

   
   

Сообщать об ошибке или контролировать выполнение программы

Во-первых, определение: когда мы говорим об ошибках и выполнении программы, я не имею в виду исключения в F# они есть и вполне схожим образом работают как в C#. Я имею в виду предсказуемые и потенциально исправимые ошибки; потому что эта та область, в которой F# с первого взгляда может показаться похож на C#, но очень быстро становится очевидно, насколько они различаются. В частности, это проявляется в использовании значения null как распространенного сигнала об ошибки в C#. Это не редкий паттерн в C#, который выглядит примерно так:

public Foo DoSomething(Bar bar){    if (bar.IsInvalid)    {        return null;    }    return new Foo(bar.Value);}

И затем, вызывающий DoSomething может проверить возвращаемое значение на null и либо обработать, либо передать его дальше. По моему опыту, одна из областей, где это часто возникает это функция LINQ FirstOrDefault(), которая используется, чтобы избежать исключения в случае пустого IEnumerable<T>, но часто заканчивается просто продвижением дальше null.

Изначально кажется, что F# пытается осуществить это с помощью своего типа Option<'a> и часто возникает вопрос: не является ли None просто ярлыком для null, за исключением того, что теперь труднее получить значение обернутое в Some? Потому что для этого потребуется pattern matching или проверка .HasValue для опции и действительно ли это лучше? Это не так, и именно поэтому F# посредством функционального программирования предлагает более чистое решение: разрабатывать основную часть кодовой базы, не беспокоясь о проверке на существующие ошибки, а вместо этого беспокоясь только об оповещении потенциально новых, специфичных для данной функции. Мы можем сделать это, написав большинство наших функций так, как будто входные данные уже были проверены для нас, и затем, с помощью функций map или bind, связать наши безответственные функции вместе. Давайте посмотрим на них в контексте Option:

• map требуется два аргумента: функция 'a -> 'b и Option<'a>, из которых она будет генерировать Option<'b>;
• bind также требует два аргумента: функция 'a -> Option<'b> и Option<'a>, из которых она будет генерировать Option<'a>.

Давайте посмотрим, что они могут для нас сделать:

// string -> Option<string>let getConfigVariable varName =    Private.configFile    |> Map.tryFind varName// string -> Option<string[]>let readFile filename =    if File.Exists(filename)        then Some File.ReadLines(filename)        else None// string[] -> intlet countLines textRows = Seq.length filegetConfigVariable "storageFile"                 // 1|> Option.bind readFile                         // 2|> Option.map countLines                        // 3

Так что тут происходит?

1. Мы пытаемся взять переменную из нашей конфигурации. Может быть, она существует, а может и нет, но это имеет значение только для этой единственной функции.
2. Затем мы перенаправляем в Option.bind который неявно обрабатывает логику безопасности для нас: если предыдущий шаг имеет значение Some используйте его в качестве аргумента этой функции, в противном случае оставьте его как None и двигайтесь дальше.
3. Option.map делает то же самое если есть значение Some, используйте его с этой функцией, в противном случае просто двигайтесь дальше.

Прозорливый наблюдатель заметит, что на шаге 3 нет непосредственной разницы между bind и map они оба автоматически обрабатывают одно и то же, верно? Но обратите внимание на разные сигнатуры между readFile и countLines bind имеет дополнительный шаг, который производит flatten (прим. перев.: разворачивает вложенную структуру, Option.flatten) над параметром Option, который выводит его функция. Рассмотрим альтернативу: если бы мы использовали map, то в конце строки 2 у нас было бы Option<Option<string[]>> и так в строке 3 нам потребуется Option.map (Option. map countLines)!

Но возникает вопрос, как мне на самом деле получить значение, если оно есть выводом этого Option? И это справедливый вопрос. И ответ избегать этого как можно дольше. Поскольку, чем позже вы откладываете попытку развернуть Option, тем меньше кода вам нужно написать, который хоть как-то предполагает, что ошибка возможна. И в тот момент, когда вам, наконец, определенно необходимо получить значение, у вас есть два варианта:

• Option.defaultValue принимает 'a и Option<'a> если Option имеет значение, он возвращает его, в противном случае он возвращает значение 'a, которое вы ему дали.

  
  

• Option.defaultWith то же самое, но вместо значения для генерации значения требуется функция unit -> 'a.

  
  

Так уж совпало, что та же самая логика применима к встроенному в F# типу Result<'a,'b>, который также предлагает bind и map (и mapError, если вам это нужно) но вместо None у вас есть вариант Error, который вы можете использовать для хранения информации о том, что пошло не так будь то string или пользовательский тип ошибки по вашему выбору.

Использовать C#-библиотеки в F

Одно из восхитительных преимуществ F# и, вероятно, почему C#-разработчик сначала смотрит на него, а не на что-то вроде Haskell, это то, что он является частью большой экосистемы .NET и поддерживает взаимодействие со всеми C#-библиотеками, с которыми разработчик уже знаком. Код на C# может (в основном) использоваться в F#, но иногда возникают некоторые затруднения, но обычно с легкими обходными путями:

• При вызове C#-методов компилятор F# рассматривает метод как кортеж с одним аргументом. Из-за этого частичное применение строго невозможно, и пайпинг может быть затруднен из-за перегрузки:

  
  

  "1" |> Int32.Parse                          // Подобно Int32.Parse("1")("1", NumberStyles.Integer) |> Int32.Parse  // Подобно Int32.Parse("1", NumberStyles.Integer)NumberStyles.Integer |> Int32.Parse "1"     // Не компилируется, потому что ожидает кортежный аргумент, а не два отдельных аргумента.
  

  
  

• C#-Библиотеки особенно те, которые включают сериализацию или рефлексию, часто не приспособлены для понимания встроенных типов F#. Наиболее распространенным случаем здесь являются библиотеки JSON, которые могут затрудняются над сериализацией и/или десериализацией Unions и Records в таких случаях настоятельно рекомендуется проверить на существование библиотеки расширений, которая предоставляет специфичную функциональность F#. Например, Newtonsoft.Json имеет пакет Newtonsoft.Json.FSharp, System.Text.Json FSharp.SystemTextJson. С другой стороны, в этих случаях может быть также хорошо проверить нативные библиотеки на F# подобно Thoth или Chiron.

  
  

• Благодаря возможности C# создавать null для любого ссылочного типа, и отсутствию (на момент написания) (прим. перев.: fsharp/fslang-suggestions#577) встроенного интеропа для обозначения nullable reference type в C#, полезно попытаться изолировать код C# на внешнем уровне вашей логики и использовать утилиты, такие как Option.ofNullable (для Nullable<T>) или Option.ofObj (для ссылочных типов), чтобы быстро обеспечить безопасность типов для вашего собственного кода.

  
  

• Методы в C#, которые ожидают типы делегатов, такие как Action<T> или Func<T>, могут получить лямбда-выражение F# соответствующей сигнатуры, и компилятор будет обрабатывать преобразование. Помните: unit заменяет void в F# и его () значение поэтому Action<T> будет ожидать 'T -> unit, например (fun _ -> printfn "I'm a lambda!"); и аналогично, Fun <T> ожидает unit -> 'T, например (fun () -> 123).

  
  

• В тех случаях, когда C#-библиотека ожидает, что объекты будут декорированы атрибутами, то для этого используется хитрость в виде <>, которую F# использует внутри квадратных скобок так что [Serializable] C# превратится в [<Serializable>] F#. Аргументы работают одинаково: [<DllImport('user32.dll', CharSet = CharSet.Auto)>]. И, как и в случае с коллекциями выше, несколько атрибутов разделяются точкой с запятой, а не запятой: например, [<AttributeOne; AttributeTwo>].

  
  

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

Я подумал ну окей, так, наверное, бывает не всегда. С тех пор прошло лет 5, я не раз менял работу, но везде и всегда созвоны были пустой тратой времени.

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

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

Для меня стало принципиальным понять и объяснить всем, почему все эти синки бесполезны. Я нашел много аргументов.

У нас вот тут есть гит, гитхаб, рабочий чат, конфлюенс, в конце концов код и комменты в нем. Код ревью, ишьюс, жира. Ало, вам мало места, где обсуждать рабочие моменты? А, вам неудобно текстом. А почему не удобно? Может потому, что ты, осел такой, нихрена у себя в башке не можешь уложить, что именно хочешь сказать, и теперь хочешь поразмышлять вслух за счет моего времени? Может быть дело в том, что тебе на самом деле не надо ничего ни с кем обсуждать, и ты просто хочешь поизображать продуктивность?

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

Так может быть, ну я не знаю, СРАЗУ это записывать вместо созвона?

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

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

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

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

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

Так вот, если многим программистам не нравится созваниваться, то как тогда вышло, что долбанные синкапы занимают такое место в нашей рабочей культуре?

Я нашёл три причины. Есть люди, которые плохо воспринимают текстовую информацию, и не могут без собеседника нормально сформулировать мысль. Это знаете, такой твой тимлид, который выдает "давай голосом" на любую мелочь, с которой тебе не повезло к нему прийти. Для таких людей у меня очень плохие новости им надо или переучиваться, или проваливать из цифровой индустрии. Разработка это про текстовое взаимодействие, и только так.

Есть люди, которые просто любят поболтать. Они самое меньшее из зол, потому что у меня всегда срабатывал такой лайфак: "Братан, если ты хочешь поболтать, звони после работы. Я возьму пивка, и мы обсудим все, что ты хочешь без давящей иллюзии, что мы решаем рабочие задачи". Если человек просто хочет поболтать с ним можно просто поболтать. Просто не надо делать это частью рабочих обязанностей людей в команде. Если у тебя в команде есть хороший друг, и вы любите программировать в паре флаг в руки. Когда созвон происходит по обоюдной инициативе, тут все в порядке. Но в моей практике, мне их всегда навязывали, и мой отказ созваниваться воспринимался как нежелание работать.

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

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

Я искренне ненавижу этих людей. Я их презираю. Как разраб я умею неплохо писать код на пяти языках, заниматься девопс задачами, тестировать, тестировать из кода, знаю кучу библиотек, фреймворков и рантаймов. Умею проектировать базы данных. Разбираюсь в межсетевом взаимодействии, алгоритмах, оптимизациях, управлении, мать его, проектами, обучении людей, и ещё много в чем ещё. Знаю предметную область процессов, которые автоматизирую. Мой минимум необходимых компетенций включает огромное количество вещей из смежных направлений потому что иначе я буду попросту бесполезным. Это в той или иной степени умеют вообще все программисты. А вот люди из IT, которые ни разу в жизни не удосужились написать простейший скрипт я не понимаю, что они тут забыли. Их непрошибаемое нежелание изучить хоть что-то техническое вызывает отвращение.

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

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

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

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

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

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

Смотрите мой подкаст

Смотрите мой подкаст