Мы написали самый полезный код в своей жизни, но его выкинули на помойку. Вместе с нами



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

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

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

    1


    — (Антоха rcanedu ) Мне поручили разработку внутренней платформенной тулзы — библиотеки для выражения программных сущностей в виде объектно-ориентированных моделей и для однообразной работы с API сервисов. То есть, инструмента для взаимодействия с данными, которые ходят от источника к отображению и обратно.

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

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

    Когда делаешь фронт, есть два источника проблем — пользователь и бекенд. С пользователем все просто — есть много удобных, абстрагирующих от пользовательского I/O библиотек и фреймворков (react, angular, vue и другие).

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

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

    — (Фил) Если ты бэкендер, у тебя полно взрослых решений и практик по моделированию данных для приложения. Например, в C# ты фигачишь класс модели данных. Берешь либу, какой-нибудь EntityFramework, либа поставляет тебе атрибуты, которыми ты обмазываешь свои модели. Говоришь либе, как ей достучаться до базы. Дальше юзаешь ее интерфейс для манипулирования этими данными. Эта штука называется ORM.

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

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

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

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

    — (Фил) Нужна либа, которая даст возможность подробного описания и управления каждой сущности, получения данных для этой сущности с разных ресурсов с разным интерфейсом, от REST API и json-rpc до graphQL и NQL. Которая позволит держать разрастающуюся кодовую базу и структуру в строгости и порядке. Простой и понятной в использовании. В любой момент предоставляющая полное и точное описание состояния сущностей. Мы хотим абстрагировать модули своих пользователей от слоя данных настолько, насколько это возможно.

    Первым делом мы посмотрели существующее. Нам ничего не понравилось. Почему-то все библиотеки для работы с данными сделаны или на js, или с кучей any наружу. Эти any все портят. Они закрывают глаза разработчикам, говоря, что такая библиотека тебе мало чем поможет, что ты не сможешь ориентироваться в типах своих данных, не сможешь выразить их связи. Всё становится ещё хуже, когда используется несколько API разных видов или оно неоднородно.

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

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



    2


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

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

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

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

    — (Фил) Я долго ждал дня, когда Антоха поймет прелесть typeScript.

    — (Антоха) Но и в нем есть ряд проблем, которые сводят с ума. Типизация есть, но идеально соответствия между выполнением программы у меня и выполнением у пользователя все равно нет. Поначалу Тайпскрипт кажется сложным. Его приходится терпеть. Всегда хочется взять и кинуть какой-нибудь object или any. Постепенно углубляешься в язык, в его систему типов, и тут начинает происходить интересное. Он становится волшебным. Можно типизировать вообще все.

    — (Фил) Впервые в жизни мы в чем-то сошлись и приступили.

    Первый шаг — пользователь должен описать схему данных. Прикидываем, как оно выглядит. Что-то вроде такого:

    type CustomerSchema = { 
      id: number;
      name: string;
    }
    const Customer = new Model<CustomerSchema>(‘Customer’);
    

    Этот код означает, что есть схема данных, описывающая кастомеров. У каждого кастомера есть id, представленный в виде целого числа, и имя, в виде строки.
    Следом создается модель по этой схеме, переданной дженериком. Главная проблема такого подхода в том, что мы определяем тип данных с помощью дженерика, передавая туда тайпскрипт-тип. Так делать нельзя, потому что типы тайпскрипта исчезают после компиляции, а они нам нужны.

    Хорошо, что мы быстро откинули такой вариант. Сама схема — это в каком-то смысле и тип, и значение. Когда мы это поняли, стало необходимо не просто декларировать свойства, но и использовать их. Нам сразу пришло в голову: ведь в языке есть такие штуки, которые одновременно и типы, и значения. Это конструкторы. Теперь объявление схемы приобрело такой вид:

     /**
       name: String
       String - встроенный в js тип-значение: StringConstructor
       для нас было очень важно не вводить для этих целей свои типы
       чтобы упростить понимание и использование библиотеки
    */
    const customerSchema = Schema.create({
      id: Number,
      name: String,
    });
    

    Вот это уже можно сделать. Здесь дженерик тоже есть, но он выводится из объекта, который был скормлен схеме. А самое главное, Number и String существуют в рантайме. Но тут тоже есть проблема: юзер может скормить сюда всё, что он хочет. Например:

    const customerSchema = Schema.create({
      id: 1,
      name: 2,
    });
    

    Потому что мы ничего не типизировали. Можно написать код нашей `Schema.create` так, чтобы она плевалась исключениями времени выполнения. Всякие `if (!(property instanceof String)) throw new Error(«читай спеку, мудак»)`. Но это плохой подход.

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

    Есть очевидный способ подобного избежать. Мы просто сделаем свое дело и опишем тип данных, которые принимает Schema.create.

    Примерно так:

    // вспомогательный тип для рекурсивного определения 
    type Map<T> = {
      [key: string]: T | Map<T>; 
    };
    
    /**
      кусок возможных типов значений декларации,
      существующие как во время компиляции,
      так и в рантайме.
    */
    type NumberType = Template<NumberConstructor, number, 'number'>;
    type StringType = Template<StringConstructor, string, 'string'>;
    type SymbolType = Template<SymbolConstructor, symbol, 'symbol'>;
    type BooleanType = Template<BooleanConstructor, boolean, 'boolean'>;
    type DateType = Template<DateConstructor, Date, 'date'>;
    
    interface ArrayType extends Array<ExtractTypeValues<Types>> {};
    
    type Types = {
      Number: NumberType;
      String: StringType;
      Symbol: SymbolType;
      Boolean: BooleanType;
      Date: DateType;
      Array: ArrayType;
    };
    // алиас для нашего типа
    type MapTypes= Map<ApplyTemplate<Types>>;
    // алиас для типов декларации - конструкторы
    type Declaration = ExtractInputTypes<MapTypes>;
    interface Schema<...> {
     // Дефинишн типа функции, которая создает схему.
     create: <T extends Declaration>(
        declaration: ConvertInstanceTypesToConstructorTypes<T>
      ) => Schema<T>;
    };
    

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

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

    type CustomerSchema = {
      id: number;
      name: string;
    };
    const customerSchema: CustomerSchema = Schema.create({
      id: Number,
      name: String,
    });
    

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

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

    Но такие придурки существуют, причём существуют в том же самом мире, где есть другие придурки, пропускающие это говно на кодревью. Поэтому мы должны защититься и от этого тоже. Мы добавляем внутрь `Schema.create` наши проверки на инстансоф. У 99% людей это лишний оверхед на производительность, остальные выявят проблему чуть раньше. Мы долго думали, нужно ли это делать. Я считаю — а пошли они! Но мы сделаем, потому что мы профессионалы.

    Идём дальше. У нас есть инструмент, чтобы описать схему данных, но у нас нет инструментов, чтобы её изменять. Здесь есть проблемы. Сейчас мы можем пользоваться схемой так:

    const customerSchema = Schema.create({
     id: Number,
     name: String,
    });
    
    // вот тут vscode предлагает нам: id, name 
    Schema.raw(customerSchema). 
    
    // если мы напишем
    // это скомпилируется без проблем.
    Schema.raw(customerSchema).id;
    
    // такой код будет подчеркнут красным и не скомпилится.
    Schema.raw(customerSchema).neId;
    

    Но. Если дать пользователю возможность добавлять в схему свойства с помощью мутации объекта схемы:
    const customerSchema = Schema.create({
     id: Number,
     name: String,
    });
    
    if (true) {
      customerSchema.add({gender: String});
    } 
    
    // здесь мы уже не знаем во время компиляции,
    // что у схемы есть свойство gender.
    // Это значит, что вся наша работа по выводу типов не имеет никакого 
    // смысла.
    Schema.raw(customerSchema).
    

    То есть, если у схемы будет мутабельное апи, наша проверка типов не сможет работать, и дураки легко сломают наш код. А если пользователь может присвоить схеме свойство gender, считай, что это свойство у схемы есть (да, в тайпскрипте есть магия, меняющая тип this внутри метода!). Он может сделать это внутри какого-нибудь условия или вообще в другой части кодовой базы. Компилятор не сможет точно знать, в какой момент у схемы есть это свойство, что неизбежно приведет к ошибкам времени выполнения.

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

    Вот так:

    const customerSchema = Schema.create({
     id: Number,
     name: String,
    });
    
    // customerSchema.add({gender: String});
    // Пусть эта штука создаёт новую схему, а не меняет предыдущую.
    // Вот так:
    const customerWithGenderSchema = customerSchema.add({gender: String});
    
    // теперь все ок.
    // Пишем:
    Schema.raw(customerWithGenderSchema).
    // видим id, name, gender
    
    // Пишем
    Schema.raw(customerSchema).
    // видим id, name
    

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

    Вывод типов после создания схемы и вообще сами схемы нужны вот зачем:

    const customerSchema = Schema.create({
     id: Number,
     name: String,
    });
    
    const repository = RepositoryManager.create(openApiDriver, { 
     // config
    });
    const Customer = Model.create(repository, customerSchema);
    
    Customer.getAll().first().
    // вот тут ide будет знать, что у инстанса данных есть поля id, name и gender.
    // для нас это значит, что вот так
    Customer.getAll().first().age;
    // написать будет нельзя. Этот код не скомпилится, бага не поедет на прод, 
    // все в плюсе.
    

    Мы выводим тип getAll из типа схемы.
    Примерно так:

    type MapSchemaToDriver<S extends Schema, D extends Driver> = 
      InferSchemaDeclaration<S> extends SchemaDeclaration
        ? InferDriverMethods<D> extends DriverTemplate<IMRReader, IMRWriter>
          ? Repository<InferSchemaDeclaration<S>, InferDriverMethods<D>>
          : never
        : never;
    
    interface Repository<D extends Driver, S extends Schema> {
      get: <T extends DSLTerm>(dsl: ParseDSLTerm<T>) => MapSchemaToDriver<S, D> extends RepositoryTemplate ? ApplyDSLTerm<MapSchemaToDriver<S, D>, T> : Error<’type’, ‘Type error’>;
    }
    

    То есть, тайпскрипт умеет так:

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

    Это магия. Настоящий конвейер прокси и декораторов.

    Мы научили свой тип «репозиторий» предоставлять методы, считывающие данные, и предоставляющие пользователю доступ к этим данным с проверкой типов во время компиляции. А типы мы выводим, исходя из типа схемы.

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

    «Эй либа, у меня есть хранилище по адресу *бла-бла-бла.ком*, там лежат тысячи записей о клиентах. Я думаю, у каждого клиента есть id и имя. Достань-ка мне оттуда первых сто клиентов, и если данные валидные, выведи их на экран».

    Почти идеал.



    2.5


    Мы не написали код, мы просто описали типы, и теперь, по этим лекалам легко сошьем рабочее решение. Проектирование типами в деле.

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

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

    Наша библиотека не ODM и не ORM — она IMR (Isomorphic Model Representation)


    Более абстрактная, она может работать с различными хранилищами, различными API одного или разных сервисов. Ей неважно, как структурированы данные. В отличие от аналогов, мы не реализуем select-where сами, предоставляя эту возможность пользователю.

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

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

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

    Как бы не так.



    3


    — (Антоха) Мы продолжали делать либу, но я чувствовал, что могу сорвать сроки. Поэтому мы решили, жестко перерабатывать, чтобы успеть собрать вариант, который всех убедит. Реально работать днями и ночами. Я тратил все восемь часов, приходил домой, списывался с Филом, который заканчивал свою основную работу и убивал еще полночи на этот проект.

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

    Хрен знает, чем он слушал на дейли.

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

    — (Фил) Антоху наняли как суперсиньора с видением, чтобы он пришел и рассказал команде, как решить проблему. Так ему сказали на собесе. А теперь выставили так, что нанимали аджайлового солдата, который должен пилить в срок, что скажут.

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

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

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

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



    4


    — (Фил) Когда Антоха мне сказал, чем все закончилось — я охренел. Сделано слишком мало! Что?! Засранцы получили двух разрабов вместо одного, я тратил кучу своего времени, Антон работал по восемь часов, потом созванивался со мной, снова работал, а потом мы вместе шли читать про все эти ODM/ORM и прочее дата-рилейтед говно, чтобы не допустить глубоких ошибок. Мы делали инструмент, которым будут пользоваться тысячи наших коллег. Короче, я мог бы понять любую претензию по качеству решения, но не «Чё-то вы нихера не сделали, пацаны».

    То, что Антоха все стер, меня вообще убило. Этот инструмент был важнее просто работы по найму. Фиг с ними, с корпорациями, их жирными офферами и комфортной средой для сложной разработки. Такая либа нужна.

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

    У нас есть приватный репо с кучей типов, но без реализации. В итоге мы хотим получить что-такое:

    /*
    Мы делаем сервис доставки пиццы роботами.
    Под капотом здоровая платформа — микросервисы.
    Нам нужно отобразить оператору таблицу со свободными роботами.
    Вот так это выглядит в коде
    */
    
    import { View } from '@view';
    import { Logger } from '@utils';
    
    // Модель робота — основной инструмент, который мы поставляем юзеру.
    // Ей была передана схема данных и способ их получения.
    import { Robot } from '@domain/models';
    
    // Функция, которая использует либу для получения с бека
    // ближайших свободных роботов
    function foo() {
     Robot.fetch({
       location: {
         area: 2,
         free: true,
         key: 'f49a6712', // все эти штуки - compile-time checked
       }
     })
     .then(View.Grid.display)
     .catch(Logger.error);
    }
    

    Мы с Антохой чуть не поубивали друг друга, когда обсуждали стратегию обработки ошибок. Я топил за монаду, он — за идиоматичные для js/ts промисы. В итоге решили сделать так и так, и управлять этим на уровне конфига либы. То-есть где-то в другом файле мы один раз решили, как хотим работать в случае неудачного запроса, и теперь здесь система типов точно знает, что у нас — промис или Result монада.

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

    /*
     Приходит бизнес требование:
     если мы подключены к такой то ноде,
     при запросах к роботам нужно использовать дополнительный параметр - тип батареи.
     и исключать другой параметр - скорость
     И в таком случае мы должны использовать только роботов с определенным типом батарей.
     Вот как это можно описать:
    */
    import { Schema, Model } from 'imr';
    import { Logger } from '@utils';
    import { View } from '@view';
    import { robotSchema } from '@domain/schemas';
    import { batteryStationService } from '@domain/infrastructure/services/batteryStation';
    import { Robot } from '@domain/models';
    import { batteryNode } from '../services/nodeNames';
    
    // Мы на лету расширяем предыдущую схему робота
    // говорим, что у таких роботов есть тип батареи, который может иметь одно из двух значений,
    // и говорим, что у этих роботов не существует параметра «скорость»
    const robotSchemaWithBattery =
      robotSchema
        .add('battery', Schema.union('li-ion', 'silicon'))
        .remove('speed');
    
    // Функция, которая использует либу для получения с бека
    // роботов на основании заданной ноды:
    function foo(nodeName) {
    
     // Это наш бизнес-кейс: если нода такая-то, значит наши данные выглядят по другому
     if (nodeName === batteryNode) {
       // Мы создаём штуку, которая получает данные по новой схеме
       const CustomerRobot = Model.create(robotSchemaWithBattery, batteryStationService);
    
       CustomerRobot
         // Тут у нас компайл тайм поддержка параметров фильтра.
         // Написать, например, 'li-notIon' не получится
         .fetch({ filter: { battery: 'li-ion' } })
        
         // Скармливаем данные гриду.
         // фишка в том, что если грид писали умные люди, он будет декларировать тип данных, с которыми работает.
         // Это значит, что если грид хочет рендерить скорость,
         // а мы её выпилили из схемы, мы получим здесь ошибку времени компиляции.
         .then(View.Grid.display)
         .catch(Logger.error)
    
     } else {
       Robot
         .fetch()
         .then(View.Grid.display)
         .catch(Logger.error)
     }
    }
    



    5


    — (Фил) Жизнь научила меня, что каждый раз, когда ты думаешь, что изобрел что-то в программировании, ты жестоко ошибаешься. В этом случае мы не думаем, что что-то изобрели, но мне кажется, мы первые попробовали типизировать абстрактный инструмент для работы с данными на таком глубоком уровне.

    Но вот что главное я для себя вынес.

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

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

    Я люблю большие корпорации — у них всегда есть бюджет на качественные решения. Просто нам надо уметь не только делать, но и доносить.
    Над статьей также работали: rcanedu, arttom
    Поддержать автора
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 259

      +23
      Т. е. вы за деньги бизнеса заново изобрели SOAP/WSDL с квадратными колесами?
        +20

        Такие аргументы обычно используются в корпоративной борьбе. Пофиг что не SOAP, пофиг, что не WSDL, ОНИ ПОТРАТИЛИ ДЕНЬГИ БИЗНЕСА, вместо того, чтобы взять уже написанное бесплатно!


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

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

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

          Если разницу объяснять сложно — значит ее нет, увы.
            –61
            Покажите мне, пожалуйста, место в статье где действительно обосновывается необходимость собственного велосипеда.

            В коде. Заглядывал туда?
              +60
              Спасибо, что Вы сразу подняли уровень аргументации на этот уровень. Серьезно.

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


                Мы не изобрели велосипед. Мы увидели, как люди на беке катаются на велосипедах, и решили, что на фронте тоже было бы здорово на нём покататься.
                Для меня необходимость иметь полную проверку типов при работе с внешним источником данных очевидна.
                Инструментов, которые бы уже делали тоже самое, причём именно для typescript — мы не нашли
                  +17
                  Первая же ссылка в гугле — spin.atomicobject.com/2018/03/26/typescript-data-validation

                  UPD и множество всего в комментариях к статье и дальше в гугле
                    0
                    > иметь полную проверку типов
                    > внешним источником данных
                    Не чувствуете противоречия?
                      0
                      Эм, нет. Есть источник данных, ты его описываешь типом, на основании твоего описанию данные из источника проверяются. Где я ошибаюсь?
                        0
                        То есть ваша бибилиотека занималась проверками в рантайме. Допустим какой-то шмоток данных её не проходит. Что дальше?
                          0
                          Дальше она выкидывает ошибку. Сейчас мы поддерживаем только промисы (спасибо антохе с его джсом), т.е. если ты делаешь запрос, а данные пришли не в полном объеме, свалишься в промис-catch.

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

                          Т.е. идеал такой — пользователь либы сам решает, какие поля данных — rerquired, какие опциональные. И он же сам решает, хочет он получать неполные данные, или ошибку
                        0

                        Как раз наоборот, типы (и, например, зависимые типы1) гарантируют, что все нужные проверки в рантайме вы точно сделаете.


                        1

                        Я вообще статью читал и всё время повторял про себя, мол, на что люди только не идут, лишь бы не использовать полноценные завтипы

                          0
                          Мы бы с радостью пошли, только у нас не хаскель а тайпскрипт.
                          День, когда бизнес полным составом переедет на ФЯП будет праздником
                            0

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


                            А я не далее как вчера в очередной раз матерился, что система типов хаскеля не даёт мне выразить нужные инварианты для доступа к БД. С другой стороны, в том же идрисе вообще никаких библиотек для работы с БД, считайте, нет.

                              –1
                              Совпадение? Не думаю…
                                +1

                                Молодой язык, что с него взять.

                                0
                                Чего бы меня это должно было утешить? Если кратко выразить мои требования к любому ЯП: типы, которыми можно детально выразить абсолютно любой кейс. Такая система типов, которая позволит на этапе компиляции покрывать все возможные ветви выполнения приложения. Хаскель непопулярен настолько, что бы делать на него ставку — это очень плохо. У тайпскрипта очень мощная система типов для популярного ЯПа, но ей никто не пользуется.

                                Говорю это как человек, тысячи тысяч раз делавший проверку на нул, только потому, что система типов C# не позволяла мне отделять нулабл от не нулабл.
                                  0
                                  Такая система типов, которая позволит на этапе компиляции покрывать все возможные ветви выполнения приложения.

                                  Это не случай хаскеля, только и всего.


                                  Хаскель непопулярен настолько, что бы делать на него ставку — это очень плохо.

                                  А вот тут я бы поспорил. Но у каждого свой опыт.

                                    0
                                    Это не случай какого угодно ЯП сегодня, насколько я понимаю
                                      +1

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

                                    +1
                                    но ей никто не пользуетс

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

                                      0
                                      Я бы ещё добавил, что когда ты на проекте описываешь типами что-то действительно сложное, этим тоже никто не пользуется
                                        +1

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

                                          0

                                          Не способна или не использует? Расмматриваете вариант "тэкс, у меня тут есть инвариант, зафиксирую-ка его типом… да ну, сложно и непонятно будет, лучше в рантайме"

                                            0

                                            А что именно непонятно и кому?

                                              0
                                              Не способна или не использует?

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

                          +8
                          вместо того, чтобы взять уже написанное бесплатно!


                          Если смотреть с позии среднего/крупного бизнеса, то главное чтобы не бесплатно/быстро, а чтобы предсказуемо в средне- и долгосрочной перспективе. Хороший разработчик может запилить решение, которое порвет все существующие аналоги, как опенсорс так и энтерпрайс, и на короткой дистанции это может быть прорывом, но что делать с этим крутым решением через три года, когда крутой разработчик пилит мегарешения уже в пятой компании, а корпорации нужно как-то поддерживать проект, обеспечивающие потребности бизнеса? Отсюда и дорогостоящие консультанты, обслуживающие тормозные решения — бизнес точно знает сколько это стоит, где/как это достать и куда послать своего специалиста на обучение и сертификацию в случае необходимости. Платные версии условно-бесплатных продуктов, типа nginx+ и т.п. из этой же оперы — если у продукта нет платной поддержки (бесплатная означает отсутствие предсказуемости), то многие средние/крупные компании такие решения даже не рассматривают.
                          +8
                          А вас это удивляет? Я в openAPI смотрю такой и ммм я где-то это видел. А точно в SOAP/WSDL!
                          В итоге люди которые говорили это все сложно JSON наше все, выдали точно такое же решение. Только с JSON и YAML.
                            +5

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

                              0
                              А точно в SOAP/WSDL!

                              А разве SOAP не мертв? Мне казалось, его никто не использует уже лет так 10, в основном из-за того, что в него заложено слишком многое, что оказывается не нужно в 90% случаев.

                                +9
                                Это вам только кажется. Если сделать шаг от ноды а контейнере, в сторону кондового энтерпрайза, то выяснится что и SOAP не пропал, и WS-Policy вполне себе в ходу. Все живет долго и заменяется медленно.
                                  +10
                                  Да никуда он не делся. Просто это не стильная молодежная технология.
                                    0
                                    Около 4 лет назад впиливал его в клиент-сервер (Линь-Вин), банально из-за того что других готовых API-либ под Линь Питон (3.4 ещё был емнип) просто не нашёл.
                                    +2
                                    Как бы SOAP и REST (cсоответственно WSDL и OpenApi) — это сильно не одно и то же. Хотя бы в том, что SOAP — это конкретный протокол, а REST — сферовакуумный архитектурный принцип. Всё сходство между WSDL и OpenApi — это только назначение — формализованные форматы описания протокола.
                                      –1
                                      А вы где-то видели чтоб SOAP использовали не по верх http? Если рассматривать применение, то SOAP/REST фактически тоже самое. Просто REST немного попроще и все.
                                        +7
                                        А вы где-то видели, чтобы HTTP реализовывали не поверх TCP? Если рассматривать применение, то HTTP/транспортные протоколы фактически тоже самое. Просто транспортные протокол немного попроще и все.
                                          0

                                          QUIC, не?

                                            0

                                            Вы не поверите, HTTP/3 — это именно версия HTTP не поверх TCP.

                                            +2
                                            я видел, без http, через MQ :)
                                              +1

                                              А я делал REST не по HTTP

                                                +2
                                                Через SMTP ещё видел. :D
                                                  +1
                                                  Месье знает толк…
                                                  +1

                                                  WCF умеет по TCP ходить, например. Там вообще много транспортов.

                                                  0

                                                  Может, SOAP и REST — и не одно и то же, но вот SOAP+WSDL и REST+OpenApi почему-то все равно очень похожи.

                                                    –1
                                                    Конечно похожи. Это пары «базовые принципы + язык описания спецификации». По этому принципу очень много чего похоже.
                                                      0

                                                      Формально аналогия для REST — SOA, как архитектурные принципы, а не SOAP, для него аналогия больше HTTP

                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                  +1

                                                  В системах старого типа — да. Но есть системы, в которых не только бек определяет формат обмена.
                                                  И тут манипуляции с данными нужны на фронте. Ведь сервисов, используемых фронтом — не один, и с разными рода апи.
                                                  Идея в том. что нужно сделать фронтенд приложение, которое сравнительно дешево сможет супортить огромное количество принципиально разных API

                                                    +7
                                                    и как долго такой сайт будет грузится?
                                                      +4

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

                                                        0
                                                        Интересный кейс в том, что 80% нашего кода — это типы, которые исчезают при компиляции.
                                                        А насчёт того, что сейчас фронт стал жирным — это не нам решать, какой он должен быть. Наша задача — заставить его работать хорошо независимо от идиотизма бизнес требований
                                                          +2
                                                          > Интересный кейс в том, что 80% нашего кода — это типы, которые исчезают при компиляции.

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

                                                          > это не нам решать, какой он должен быть.

                                                          Сильно протеворечит посылу правильного кода из начала статьи.
                                                            +2

                                                            Дополнительные абстракции действительно есть. Но в них нет сложных алгоритмических преобразований в рантайме. Это такая минимальная плата за дизайн.

                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                          +1
                                                          Одно api, чтобы править всеми
                                                        +36
                                                        Статья — поразительный памятник трудолюбию и невежеству. Изобрести xsd в 2019 году — это сильно.
                                                          +11
                                                            –9

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

                                                          +1

                                                          Не совсем понятно. Библиотека сделана для случая, когда и фронт, и бэк на node.js и шарят общую схему, написанную руками?


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

                                                            0
                                                            Нет. Когда бэк и фронт написаны на одном ЯПе — тебе не нужна библиотека. Наша либа для того, что бы декларировать на клиентской стороне, с какими данными мы работаем. Насчёт кодогенерации — это очень спорная штука.
                                                              0

                                                              Зачем тогда нужна схема? Если нужно написать просто клиент к стороннему апи, можно обойтись обычной моделью и интерфейсами вместо схемы.

                                                                0
                                                                Потому что в ts нет рантайм проверок из коробки.
                                                                  +1

                                                                  Можно же проверки генерить вместе с типами и все.

                                                                    –11
                                                                    Кодогенерация — есть кодогенерация. Она может решить огромное количество проблем, но я бы старался её избегать. Как минимум потому, что она очень усложняет процесс разработки. Вообще, у меня есть ощущение. что каждый раз, когда прибегаешь к кодогенерации — ты не смог в автоматизацию. Иногда это происходит от несовершенства инструментов, иногда потому что ты тупой.
                                                                      +3
                                                                      Разве TS не кодогенерит JS? Чем фоновая компиляция tsc отличается от любой другой?
                                                                        +1
                                                                        Тем, что у ts куча пользователей, и в него вкладываются ресурсы значительно большие чем может себе позволить отдельная команда. Когда основная задача команды — пилить по пятнадцать бизнес-фич за итерацию, то самодельный кодогенератор за пять лет превратится в чудовище которое все ненавидят.
                                                                        +4

                                                                        Кодогенрация парсера из грамматики — это потому что не смог в автоматизацию и потому что тупой?

                                                                          0

                                                                          Потому что не смог в attoparsec или trifecta! Ну или потому, что не смог разобрать ошибки при компиляции boost.spirit.

                                                                          +4
                                                                          Как минимум потому, что она очень усложняет процесс разработки.

                                                                          Усложняет как именно?


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

                                                                          А разве кодогенерация — не способ автоматизации? Странно как-то.


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


                                                                          В конце концов, сам тайпчек — это тоже метапрограммирование.


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

                                                                          Вы так говорите, как будто этот кодогенератор — какое-то большое, серьезное решение, требующее существенных затрат на внедрение и поддержку.
                                                                          Мы же говорим просто о генережке вьюх/апи-сервисов. Там все тривиально, пишется за пару дней и потом работает себе и работает.

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

                                                                Первая ошибка. Вместо того чтобы считать менеджеров «идиотами» следовало бы научится их слушать и правильно интерпретировать то что они пытаются донести.

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

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

                                                                Чтобы делать хорошие дела, надо уметь убеждать людей в своей правоте.

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

                                                                Когда делаешь фронт, есть два источника проблем — пользователь и бекенд.

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

                                                                … Но такие придурки существуют, причём существуют в том же самом мире, где есть другие придурки, пропускающие это говно на кодревью.
                                                                … Но мы сделаем, потому что мы профессионалы…
                                                                … и дураки легко сломают наш код.

                                                                Пятая ошибка. Считать всех вокруг придурками, идиотами, дураками, при этом считать себя профессионалами.

                                                                Мы написали самый полезный код в своей жизни, но его выкинули на помойку. Вместе с нами

                                                                В завершении ожидаемый и закономерный результат. Жизнь все расставила по местам.

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

                                                                • The Pragmatic Programmer: From Journeyman to Master (by Andrew Hunt_
                                                                • The Passionate Programmer: Creating a Remarkable Career in Software Development (by Chad Fowler)
                                                                • Soft Skills: The software developer's life manual (by John Sonmez)
                                                                • The Clean Coder: A Code of Conduct for Professional Programmers (by Robert C. Martin)
                                                                  +10
                                                                  > Вместо того чтобы считать менеджеров… и правильно интерпретировать то что они пытаются донести.

                                                                  Вообще-то это как раз их прямая работа — уметь донести.
                                                                    +8
                                                                    Вообще-то это как раз их прямая работа — уметь донести.

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

                                                                      0
                                                                      Эта фраза без конкретики — пустое поднятие ЧСВ.
                                                                      Если по статье — то там нет никаких намеков на альтернативу и сравнение.
                                                                      Если по комментарию, на который я ответил — то там вообще ни слова про качество кода.
                                                                        –4
                                                                        А ещё есть такое понятие как работодатель и трудовая иерархия. По личному опыту скажу, что меньше всего мне нужно убеждать подчинённого исполнять свои трудовые обязанности.
                                                                          0

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


                                                                          Кстати, фраза типа "или делаешь как я скажу, или я тебя уволю" — это тоже один из способов убеждения.

                                                                      +5
                                                                      Если посмотреть на телодвижения менеджеров то видно что они пытались вернуть на стезю нашего изобретателя велосипедов, потом просто микроменеджели его давая маленькие таски, а уж потом он ушёл. Как бы налицо относительно правильные попытки минимализировать ущерб от буйного сеньор девелопера.
                                                                        –2
                                                                        Да там лол а не синьор )
                                                                        Если оценивать полезный эффект для бизнеса как баланс между количеством хороших дел и количеством плохих, то какой-нибудь джуниор мог быть даже более полезен компании (ну если бы не говнокодил совсем).
                                                                        Потому что после него остальным программистам не пришлось бы продираться через лютый велосипед и слои абстракции.
                                                                      +4
                                                                      следовало бы научится их слушать и правильно интерпретировать

                                                                      Если человек менеджер, это не делает его автоматически правым.

                                                                      послать всех к чертям и за счет бизнеса реализовать свои амбиции

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

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

                                                                      Не всех)
                                                                        –1
                                                                        Если человек менеджер, это не делает его автоматически правым.
                                                                        Но оценивать правоту решений уж точно не задача программиста. Как минимум из-за того, что всю ответственность за реализацию задач руководства и принятие решений в своей зоне ответственности несёт менеджер. И если программист делает что-то не то — для бизнеса виноват будет менеджер.
                                                                        Более того, неправильные решения могут поступать и со стороны руководства, но программистам же за их реализацию платят, а не за оценку и корректировку (без какой-либо ответственности за плохую корректировку).
                                                                          +2
                                                                          Видимо, пацаны не достаточно выгорели, чтобы молча цинично поглядывать, как рядом ошибаются. Можно же помочь. Просто некоторые вещи иногда сложнее донести
                                                                            +9

                                                                            Почему вы думаете что рядом ошибаются?


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

                                                                              +3

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

                                                                                +2
                                                                                К сожалению, программистов давать менеджеру цифры учат только менеджеры, и то далеко не все и далеко не сразу, и как парвило без конкретных методик, а только косвенно ставя такую задачу. Это ИМХО большая беда образования программистов.
                                                                                  0

                                                                                  Меня учили в вузе.

                                                                                    +1

                                                                                    Технико-экономическое обоснование раньше каждый инженер писал хоть раз — в дипломе. Сейчас не так?

                                                                                      +2

                                                                                      Так не все инженеры. У меня диплом по прикладной математике, там никаких экономических обоснований и ОБЖ не было.

                                                                                        0

                                                                                        У нас и на прикладой математике ТЭО было. А вот ОБЖ — это, кажется, ввели в школах, когда мы курсе на третьем учились.

                                                                                          +1
                                                                                          А вот ОБЖ — это, кажется, ввели в школах, когда мы курсе на третьем учились.

                                                                                          Ну, это он условно назвал. В диплом инженера-программиста входит раздел по безопасности (при разработке и эксплуатации «изделия»). Там расчитывается, исходя из размера команды разработчиков, какое им потребуется помещение, по метражу/кубатуре, какой воздухообмен, какое освещение, какие столы/стулья, какие мощности по электричеству подводить для запитки ПК и т.д. Какой режим проветривания, если нет принудительной вентиляции и все такое.
                                                                                  +7

                                                                                  А почему вы так уверены, что пацаны уж точно не ошибаются и лучше бизнеса знают что ему сейчас нужно? А если ошибаются, то что? "Извините, ну мы пошли"?

                                                                                    –2

                                                                                    Уверен, что вам не ответят, но у комментария появятся ровно два минуса.

                                                                                      +4
                                                                                      Да там классика жанра, самокоронованный «король разработки» знает что нужно остальным лучше, чем они ))
                                                                                0
                                                                                Первая ошибка. Вместо того чтобы считать менеджеров «идиотами» следовало бы научится их слушать и правильно интерпретировать то что они пытаются донести.

                                                                                Если менеджер не может донести до программиста что-то — зачем он нужен?


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

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


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

                                                                                Очень смешно. Видели картинку про квадартные колеса и "мы очень заняты?".

                                                                                  +13
                                                                                  Если менеджер не может донести до программиста что-то — зачем он нужен?

                                                                                  Эта палка обоюдоострая. Программист — взрослый человек, если он не понимает, что хочет менеджер, он точно так же по-хорошему может взять и выяснить, что и зачем. А не тихо записать его в идиоты и гнуть свою линию.
                                                                                  Я сам не раз осаживал программистов, которые нередко хотят сделать крутые универсальные решения в том случае, когда нужно обычное частное. Не надо бежать спасать мир, если вас попросили просто приготовить яичницу. Вы будете сто лет полировать свою крутую библиотеку, хотя вы бы уже давным-давно решили бы ту задачу, ради которой всё затевалось, и ещё десяток других.
                                                                                    +1
                                                                                    У нас была задача сделать решение надолго и для кучи команд. Оно и должно быть универсальным.
                                                                                      +5
                                                                                      Эта палка обоюдоострая. Программист — взрослый человек, если он не понимает, что хочет менеджер, он точно так же по-хорошему может взять и выяснить, что и зачем. А не тихо записать его в идиоты и гнуть свою линию.

                                                                                      Я, конечно, дико прошу прощения, но зачем вообще нужны менеджеры? Мне казалось, что раз они менеджеры, то они должны управлять программистами, управлять которыми их делегировали. Если у вас скрам и самоменеджент окей, но в 99% случаев у вас в любом случае есть техлид/пм, который считается "главным". И если он не выполняет, свою, по факту, единственную обязанность — зачем он?


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


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

                                                                                        +2
                                                                                        Менеджеры не обязательно должны управлять программистами. Менеджер может быть менеджером проекта, продукта, менеджером по работе с клиентами. Во всех этих ипостасях он не является нянькой для программистов. Подразумевается, что он ставит задачи и контролирует их выполнение, а не ищет психологический подход, как там кого мотивировать.
                                                                                        И когда вы пишите «следовало бы научится слушать»

                                                                                        А что, у обычного взрослого человека с адекватной психикой этот навык не должен присутствовать по умолчанию? Это разве какая-то уникальная абилка руководителей?
                                                                                          +5
                                                                                          Это просто российская мода на красивые названия. Уборщиц записывают как клининг-менеджеров, приёмщиц как сервис-менеджеров, продавцов как менеджеров по работе с клиентами и т.д.
                                                                                          Классически, менеджер — руководитель среднего и верхнего звена, у которого в подчинении есть сотрудники. И один из его базовых навыков — умение работать с персоналом.
                                                                                            +2

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

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

                                                                                          Если узкий подход не создает проблем, какого-то overhead'а, зачем overengineer'ить?
                                                                                          Это — не инженерный подход, а процесс ради процесса. «Мы программисты и мы кодим ради того, чтобы кодить».
                                                                                          Инженерный подход — это когда ты видишь, что потратил, решая вторую, подобную задачу, скажем, 43 часа на написание оберточного типового мусора, который можно решить библиотекой, на разработку которой уйдет 200 часов. Поскольку тебе надо решить еще 7 задач примерно того же плана, на которых ты потеряешь 43*7=301 час, то ты сэкономишь 101 час рабочего времени.
                                                                                          А писать ради того, чтобы писать — ну, в свободное время — пожалуйста.
                                                                                          Не нужно смешивать программирование как таковое и технологию разработки программного обеспечения.
                                                                                          +1
                                                                                          Про хорошие дела и пользу — польза часто получается сильно позже самих дел, либо дела — это какой-то продолжительный процесс. Поэтому надо уметь убеждать людей что ваше решение действительно полезно — часто «на пальцах». И, соответственно, слушать их аргументы — иногда они тоже бывают правы.
                                                                                          Со всем остальным — согласен.
                                                                                            0
                                                                                            Чтобы делать хорошие дела, надо уметь убеждать людей в своей правоте.
                                                                                            Третья ошибка. Чтобы делать хорошин дела, нужно чтобы эти дела приносили людям пользу. В таком случае, не придется ни кого ни в чем убеждать.


                                                                                            Вы искренне настолько верите в человеческую цивилизацию,
                                                                                            или сознательно игнорируете факты реальности: существование и широкое распространение государств, армий, полиции, уголовных и налоговых кодексов и прочих инструментов, предназначенных для силового воплощения хороших дел?
                                                                                            Каковые инструменты необходимы именно потому, что большинство дел, в необходимости которых людей не нужно убеждать, не являются т.н. «хорошими».
                                                                                            +7
                                                                                            Зачем вы сделали то что удешевит разработку для бизнеса? Программистам выгодно что бы бизнес больше тратил денег на задачи и проекты а не наоборот, вы какие то парни диверсанты в айти сфере.
                                                                                              +10
                                                                                              Профессиональная этика.
                                                                                                +6

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

                                                                                                0

                                                                                                А выбирая типизированный язык, вы не смотрели в сторону Dart? По каким критериям выбирали TypeScript?

                                                                                                  0
                                                                                                  Потому что кроме wrike никто на нём не пишет)

                                                                                                  Очень сложно продать дарт бизнесу
                                                                                                    +2

                                                                                                    Ну, это не совсем так, уже не так мало компаний его используют. Вон на конфе спикеры не только от нас были https://www.youtube.com/playlist?list=PLxcvsYzLfaTAwLy1UO2Y6b_AMg-0uDSjX


                                                                                                    Просто когда вижу пост про типы на фронтенде, то Dart тут далеко от TS шагнул

                                                                                                      +3

                                                                                                      Здесь важно то, что огромные инфраструктуры построены на JS и эти инфраструктуры поддерживаются разработчиками без знаний других языков. В связи с чем, процесс миграции на TS наименее болезненный, хотя даже здесь встречаются ярые противники добавления типизации. То есть по сути выбирать и не приходится (разве что рассматривать flow vs ts)

                                                                                                        +5
                                                                                                        Просто когда вижу пост про типы на фронтенде, то Dart тут далеко от TS шагнул

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

                                                                                                        0
                                                                                                        Эээ? Такое можно было говорить до появления Flutter, но сейчас? :)
                                                                                                        Flutter/Dart поглотят мобильную разработку в будущем
                                                                                                          +8
                                                                                                          React native что-то не поглотил.
                                                                                                            0

                                                                                                            При чем тут реакт? Это другая парадигма программирования. Естественно, что переход на нее тяжел для разработчиков.

                                                                                                              0

                                                                                                              И в чем же фундаментальное отличие React Native и Flutter?


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

                                                                                                            0
                                                                                                            Кажется, про xamarin так же говорили
                                                                                                              0

                                                                                                              Хамарин и рядом не стоял. У них с флаттером очень большие отличия

                                                                                                                0
                                                                                                                Например какие?
                                                                                                                Я не разработчик под мобилы, но мне правда интересно. Почему вдруг флаттер должен победить (и почему не победил до сих пор)? Чем он принципиально отличается от xamarin и react native(в том плане, что они тоже предлагают кроссплатформенную разработку)?
                                                                                                                  0
                                                                                                                  Потому что он еще очень молод? Первый релиз был в начале этого года, до этого — беты.
                                                                                                                  У флаттера:
                                                                                                                  — свой графический движок. Можно сделать iOS приложения с родными для iOS элементами и просто запустить его на андроиде. Оно будет выглядеть точно так же.
                                                                                                                  — удобная (хотя и немного непривычная) верстка. После Storyboards это манна небесная.
                                                                                                                  — не привязан к среде разработки, в отличие от хамарина. Можно писать где угодно и компилить с помощью flutter toolbox.
                                                                                                                  — Hot reload — мега фича, сокращает время разработки заметно.
                                                                                                                  — Флаттер — не только mobile, но еще и desktop и (скоро) web.
                                                                                                                    0
                                                                                                                    Да так себе преимущества, если честно.
                                                                                                                    — Приложение выглядит одинаково на iOS и Android, это нужно? Скорее нет, т.к. у каждой ОС свои гайдлайны интерфейса, и надо им следовать, а не делать имитацию iOS под Андроид и наоборот.
                                                                                                                    — Верстка как вёрстка. Ничего особо удобного ни для нативных разработчиков, ни для тех, кто освоил React Native или Хamarin, не предложит.
                                                                                                                    — Не привязан к среде разработки? Ну и что? Наоборот, намного удобнее, когда инструмент тесно интегрирован в среду разработки. Ведь проще освоить незнакомую среду разработки с интегрированным инструментом, чем прикручивать сторонний инструмент к знакомой среде.
                                                                                                                    — Hot reload нынче есть практически везде, это не уникальная фича Флаттера.
                                                                                                                    — С точки зрения пользователя, ему пофигу, сделаете ли вы одно и то же приложение для десктопа, мобилы и для веба, или разные. С точки зрения разработчика, все равно верстка для десктопа и мобильных приложений должна отличаться.
                                                                                                                      0
                                                                                                                      Мне почему-то кажется, что если технология действительно прорывная, если у неё есть будущее, то часто даже до релиза она во всю используется. Я не наблюдал хайпа вокруг flatter, ожиданий его релиза. Мне кажется, он уже «не выстрелил».
                                                                                                                      Но это не более чем моё мнение. Рад буду ошибиться в нём, dart мне показался достаточно удобным языком
                                                                                                              0
                                                                                                              Гугл пишет.
                                                                                                              0
                                                                                                              Кстати, не смог сходу нагуглить. Насколько я понимаю, в дарте строгая статическая номинативная типизация?
                                                                                                                +1
                                                                                                                  +2
                                                                                                                  Вот идея, что дарт дальше тайпскрипта в типах — он дальше в том, что типизация строгая и номинативная.

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

                                                                                                                  В целом, я бы не стал сравнивать такие две разные модели типизации с точки зрения «кто дальше».
                                                                                                              +6
                                                                                                              Интересно, спасибо.

                                                                                                              Поделюсь другим опытом решения подобных проблем.

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

                                                                                                              Из протобафов генерируются хэндлеры на бэкенде (их конечно потом надо имплементировать чтобы не получать UNIMPLEMENTED при вызове), из них собираются структуры, которые пойдут в БД («внешние» и «внутренние» протобафы конечно же не обязаны быть одними и теми же), из них же генерируются автоматически клиентские сильно типизированные библиотеки (какие душе угодно — dart, c++, java, python, go, nodejs ну и тайпскрипт конечно). Причем в настройках этих «генераторов» можно указать нужны ли тебе только интерфейсы или полнофункциональный клиент со всеми возможными вызовами, нужны тебе результаты в вибе промисов или observable.

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

                                                                                                              От каста в any защищита на уровне ci — коммит с кастом в any просто не пройдет presubmit проверки.

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

                                                                                                              Из протобафов же генерируется документация (поэтому codestyle весьма жесткий), в них же поддерживается куча аннотаций для тюнинга прав доступа/visibility каких-то конкретных вещей, нужности аудита, серверных логов, требований к авторизации. «Фронтенд бэкенда» в общем случае один и тот же для имплементации сервиса на любом языке и он как раз потребляет эти аннотации сервисов из протобафов.
                                                                                                                +1

                                                                                                                Из минусов:


                                                                                                                • в случае развесистых интерфейсов сервисов сгенерированный JS-модуль получается неприлично большим;
                                                                                                                • все поля всех интерфейсов становятся опциональными.
                                                                                                                  +1
                                                                                                                  в случае развесистых интерфейсов сервисов сгенерированный JS-модуль получается неприлично большим

                                                                                                                  Да, но с парой оговорок

                                                                                                                  1) Режим interfaces only позволяет пожертвовать удобством работы в пользу размера модуля (там генерируются только типы, которые исчезают при компиляции, для реквестов используется отдельная стандартная либа).
                                                                                                                  2) Какая-то общая часть внутренностей этих итоговых модулей вынесена в отдельный родительский класс, общий для всех сгенерированных модулей (в случае если их несколько). В самих модулях по факту как раз схема, енумы, геттеры/сеттеры, прокси-методы для вызовов процедур (но этого всего все равно очень много).

                                                                                                                  все поля всех интерфейсов становятся опциональными.

                                                                                                                  С интерфейсам — да, надо долго и нудно проверять все на null (также ci-enforced), но при генерации моделей в них можно добавить геттеры и сеттеры, которые предсказуемо работают.
                                                                                                                    0
                                                                                                                    Режим interfaces only позволяет пожертвовать удобством работы в пользу размера модуля

                                                                                                                    Но это же сразу лишает нас хоть какого-то тайпчекинга, нет?

                                                                                                                      0
                                                                                                                      Почему? При компиляции все проверки на месте — интерфейсы это ведь про типизацию.
                                                                                                                        0

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

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

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

                                                                                                                      Кстати, а как в режиме interface only протобаф будет парсить и сериализовать объекты? Скармливать ему proto-файлы или метаинфу в json?

                                                                                                                        0
                                                                                                                        А это, кстати, хороший вопрос, на который я сходу не отвечу. У нас последняя миля (браузер <-> фронтенд бэкенда) работает по обычному http (и это тоже настраивается через аннотации к протобафам), поэтому просто гоняем json и все работает.

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

                                                                                                                      Почему? Если сервер возвращает поле, то он возвращает, оно не опционально.

                                                                                                                        0

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

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

                                                                                                                          Каким образом? Если кто-то на беке забудет поле добавить, то код не скомпилируется и не запустится. А если скомпилируется и запустится — значит, с бека поле гарантированно придет.

                                                                                                                            0

                                                                                                                            null всё ещё существует в популярных языках программирования.

                                                                                                                              0
                                                                                                                              null всё ещё существует в популярных языках программирования.

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

                                                                                                                                0

                                                                                                                                Однако pbts генерирует интерфейсы вида


                                                                                                                                interface IStruct {
                                                                                                                                  foo?: (number|null);
                                                                                                                                  bar?: (string|null);
                                                                                                                                }
                                                                                                                                  0

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

                                                                                                                      +1

                                                                                                                      А ещё внутренние БД нативно поддерживают протобафы и можно спокойно эти данные туда сохранить.
                                                                                                                      Мне этот подход показался наиболее удобным

                                                                                                                      0
                                                                                                                      А на MobX State Tree не смотрели? По части типизации выглядит очень похоже.
                                                                                                                      И runtime валидация тоже есть. Хотя либа все же для другого конечно. И ничего не знает про бекэнд.
                                                                                                                          +58
                                                                                                                          Ознакомился я тут с авторами статьи. Все авторы (arttom, fillpackart, rcanedu) подписаны друг на друга.

                                                                                                                          arttom «Редактор» и работает в компании «Мой Круг». Подписан на 3-ех пользователей. 2 из которых авторы данной статьи.
                                                                                                                          fillpackart подписан на Хабре на 6 человек, 2 из которых авторы данной статьи. Так же подписан на baragol который работает в Хабре и тоже является «Редактором».
                                                                                                                          rcanedu подписан на Хабре на 3 человек, 2 из которых авторы данной статьи.

                                                                                                                          Твиттеры fillpackart и rcanedu заведены в 2019 году. В одном из них набита куча постов для «видимости» в другом нет практически ничего кроме ссылок на статьи на Хабре. GitHub аккаунты fillpackart и rcanedu в общем то практически пусты. Т.е. посмотреть реальный код авторов (или вклад в OpenSource) не представляется возможным.
                                                                                                                          Резюме в паблике, на том же МоемКруге или лучше на LinkedIn найти тоже не получилось. Нашел только резюме fillpackart на каком то левом сайте. Но там в общем то ни чего особенного. Обычное резюме обычного разработчика. Это то что мы имеем с одной стороны.

                                                                                                                          С другой стороны. Все статьи fillpackart, достаточно качественно написаны и оформлены. одинаковый стиль написания, повествования, иллюстраций. Все они имеют «кричащие заголовки» и написаны на «злободневные темы», вызывающие горячие споры. Статьи rcanedu так же похожи по оформлени, стилистике и заголовкам. Как результат у товарища fillpackart неимоверно высокие показатели кармы и рейтинга (а еще расхождение в дате регистрации и дате «приглашения» на сайт. Зарегестрирован на 2 года раньше чем приглашен. Ума не приложу, как такое возможно). rcanedu приглашен товарищем fillpackart и не смотря на то что он имеет только 2 публикации, рейтинги этих статей зашкаливают.

                                                                                                                          Вот кстати что пишет в своем твиттере по поводу данной статьи товарищ fillpackart:
                                                                                                                          Фух. Три с лишним месяца работы — и техническая статья готова.
                                                                                                                          Захерачили с пацанами на Хабр

                                                                                                                          Как я понимаю 3 месяца работы над статьей?

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

                                                                                                                          В общем данная ситуация завставила меня по другому взглянуть на Хабр. Теперь я понимаю, почему некоторые статьи на профессиональные темы в области разработки частенько остаются здесь недооценены а иногда и заганяются в минуса. Я на 100% убежден в том, что не стоит рассматривать Хабр как профессиональное сообщество. Очень жаль, что из сообщества IT-профессионалов Хабр превратился в обычное технологическое СМИ.

                                                                                                                          PS. И да ребят, вы когда минусуете не нравящиеся вам коменты, договоритесь, кто кого минусует, а то в целом ряде комментов ровно по 3 минуса…

                                                                                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                              +2
                                                                                                                              Фил с Антохой разрабы. Где работают, не скрывают, и кучу людей ваша конспирология только посмешит. А про тексты ради заработка поржут уже менеджеры, которые им зарплаты выписывают.

                                                                                                                              Я не разраб и никогда не был. Но реально офигевал, когда с пацанами сидел в баре и слушал их споры. Заслушаешься!

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

                                                                                                                              Вроде это нормально, когда обычные разрабы приходят и пишут о том, что болит? Так что не переживайте, писака здесь только я. Разрабы настоящие, никакого “заговора гуманитариев” нет, и не вижу ничего плохого, когда технарям помогают нормально доносить мысли, чтобы вам же, блин, и было интереснее читать.
                                                                                                                                +1
                                                                                                                                Разрабы настоящие, никакого “заговора гуманитариев” нет,

                                                                                                                                Человек сказал не это по сути, вы передергиваете. Было сказано:
                                                                                                                                «В целом это не плохо. Плохо другое. Плохо выдавать себя за «высококлассного эксперта отрасли» имея суммарно 6 лет опыта работы в этой самой отрасли публикуя статьи, единственная цель которых — поднятие траффика и заработок»
                                                                                                                                +3

                                                                                                                                У меня такое ощущение возникло ещё в момент вброса про синьоров и virtual (ну просто потому что так не бывает), но хочется верить в хорошее.

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


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

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

                                                                                                                                  Про трёхмесячную работу — я начал писать статью про тайпскрипт, когда Антохе дали тот таск.
                                                                                                                                  После увольнения статья превратилась в статью про Антоху.

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

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

                                                                                                                                    Проблему я вижу в посыле который вы несете и в созданном вами образе. Вот этот ваш образ «Разработчика бунтаря. Рок-звезды, которую менеджмент не понимает» ни одной компании не принес ни чего хорошего.
                                                                                                                                      –14
                                                                                                                                      Это не «мой образ», это я. Да, я часто не согласен с тем, что происходит вокруг. но не так часто, как кажется из статей. Тут проблоема в том, что когда всё хорошо — мне не хочется писать статью. Когда всё идёт окей, статья не нужна.

                                                                                                                                      А вот когда я в чём то убеждён, а все делают по-другому, Меня подбамбливает и я сажусь писать об этом, как вижу

                                                                                                                                      Про пользу комании — я лично, клал на неё. Антоха вот нет.
                                                                                                                                        +16
                                                                                                                                        А вот когда я в чём то убеждён, а все делают по-другому, Меня подбамбливает и я сажусь писать об этом, как вижу.

                                                                                                                                        Я тоже был в чем то таким как вы. Примерно лет 5 назад. Меня тоже в свое время подобным образом бомбило. К сожалению или к счастью (я не знаю) я не писал об этом а посему такое вот мое видение мира не вышло в свет.

                                                                                                                                        Про пользу комании — я лично, клал на неё. Антоха вот нет

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

                                                                                                                                        Мне тоже раньше было срать, а потом мне пришлось встать «по другую сторону баррикад». Cобрать команду, возглавить разработку, поработать CTO.

                                                                                                                                        Сейчас я снова работаю разработчиком. И не потому что меня уволили, менеджеры идиоты или я не справился с обязанностями, а потому что я люблю эту профессию и пока еще не «напрограммировался».

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

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


                                                                                                                                      То что статья написана с целью вызвать ещё один срачик (как и прошлые) — очевидно.

                                                                                                                                        –7
                                                                                                                                        Срач — не цель. Я очень рад, когда есть фидбек, но в целом, я всегда хочу увидеть сотню-другую коментов про то, что я прав.
                                                                                                                                        Так не бывает, конечно. Но если бы у меня была кнопка — снизить градус агрессии в коментах, я бы давил на нее не переставая.

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

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

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

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

                                                                                                                                            +4
                                                                                                                                            Думаю, здесь каждый второй собрал граблей еще больше, просто не будет об этом рассказаывать, потому что постесняется — вдруг какой-нибудь образ сложится
                                                                                                                                        +6

                                                                                                                                        Паттерн активности хорошо совпадает с образом девелопера, горящего разработкой, ага.

                                                                                                                                          0
                                                                                                                                          Хех, ну тут больше моё флоу. Я так и не научился делать много комитов, у меня обычно один-два комита на задачу. Да и большинство вещей, которые я делаю для себя, я не сваливаю в гит, потому что это не проекты. Так, захотел что то проверить, сделал локально, забыл.

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

                                                                                                                                            У этого флоу статистически значимы (на глазок, p-value не считал, сорри) провалы по выходным, а также недельные и двухнедельные (отпуск?).


                                                                                                                                            Ну а насчёт гита — это же просто удобно. Я туда (пусть и в приватную репу на гитхабе) сваливаю решения задач из purely functional data structures, которую читаю сейчас, или из types and programming languages, тайпчекеры из которой реализовывал год назад. Да чего там, люди туда решения задач по абстрактной алгебре пишут, но это уже для меня перебор, я-то ручкой по бумажке еложу, в TeX это оформлять слишком геморно.

                                                                                                                                            +1

                                                                                                                                            Ага, по будням. Причем практически все коммиты в приватные репозитории, оценить вклад не получилось. Зачем автор выложил этот скрин и указанием его активности — не понятно. С тем же успехом можно выложить активность на каком-нибудь рабочем гитлабе. А еще аккаунт гитхаба не указан в профиле у автора, но вот он.

                                                                                                                                              0
                                                                                                                                              Выложил, потому что меня обвинили, что я вообще не разработчик
                                                                                                                                                +2
                                                                                                                                                Что-то как-то совсем уныло. Даже у меня гитхаб интересней, хоть я и не «король».
                                                                                                                                                  +2
                                                                                                                                                  Я не очень понимаю ваших претензий к автору. У меня на гитхабе вообще нет активности, но это не мешает мне быть старшим разработчиком и тимлидом и иногда кодить по 12 часов в день по настроению.
                                                                                                                                                  То, что у автора на гитхабе есть хоть какая-то активность — это ж только в плюс.
                                                                                                                                                    0

                                                                                                                                                    А вы эти 12 часов по настроению кодите рабочие таски или для себя?

                                                                                                                                                      +2
                                                                                                                                                      Рабочие таски для себя, нравится мне моя работа.
                                                                                                                                                        0

                                                                                                                                                        Мне это сложно понять, я так никогда не мог, всегда хотелось поделать что-то ещё, вне работы.


                                                                                                                                                        Да и для резюме полезно, если уж совсем утилитарно подходить.

                                                                                                                                                          0

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

                                                                                                                                                            0
                                                                                                                                                            И в личное время её пилишь

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

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

                                                                                                                                                                Это отлично все, но зачастую можно согласовать с работодателем. И заниматься работой на работе :)

                                                                                                                                                                  0
                                                                                                                                                                  Не, ну то понятно. Я имею в виду исключительно кейс, когда кто-то решил наваять какой-то проект по своей инициативе, не договорившись с работодателем об этом изначально. Примерно как те парни, про которых статья.
                                                                                                                                                                  А так, во многих случаях, если просто взять, подойти и объяснить преимущества своей идеи, то и карт-бланш на её реализацию дают. По крайней мере, если объяснил понятно, а идея стоящая.
                                                                                                                                                                0

                                                                                                                                                                Это тоже рабочее время, но отданное взаймы. Оно вернётся, когда библиотека начнёт экономить тебе основное рабочее время.

                                                                                                                                                                  0
                                                                                                                                                                  Это еще неизвестно и только является прикидкой автора.
                                                                                                                                                                  Если бы он сделал анализ «экономического эффекта», имея численные данные, это был бы другой разговор.
                                                                                                                                                                    0

                                                                                                                                                                    А вот когда я читаю блоги по C++ или, ещё глубже, книжку Алюффи по алгебре (офигенная книжка, кстати, рекомендую, у меня от неё брат ожил), что это тоже положительно сказывается на моей производительности в отдалённой перспективе. Получается, я это тоже могу со свободной душой делать на работе?


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

                                                                                                                                                                      0

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

                                                                                                                                                                    0

                                                                                                                                                                    В рабочее время решаешь задачу без библиотеки точечно. В личное генерализируешь решение, выделяешь библиотеку/фреймворк.

                                                                                                                                                            0
                                                                                                                                                            То, что у автора на гитхабе есть хоть какая-то активность — это ж только в плюс.


                                                                                                                                                            Да кто ж спорит…
                                                                                                                                                  –7
                                                                                                                                                  Чтобы быть высококлассным специалистом обязательно необходимо сутками писать в OpenSource?

                                                                                                                                                  Ясно, понятно.
                                                                                                                                                  Боже, когда же это наконец закончится…

                                                                                                                                                  Лично вот у меня нет ни времени, ни желания писать в Open source из-за его токсичности.
                                                                                                                                                    +2

                                                                                                                                                    Это вы ранимы, а не сообщество токсично. Или вам просто не интересно.

                                                                                                                                                      +2
                                                                                                                                                      Да?
                                                                                                                                                      Когда пользователи приложения, которое написали, разработчика обзывают геем, посылают на 3 буквы, за баги в приложении, это не токсично?
                                                                                                                                                      Это я только самое неоскорбляющие слова написал, как меня обзывали.
                                                                                                                                                      Возьмите тот же linux.org.ru или opennet или 4pda, там сидит куча троллей и токсичных людей, которые только и норовят оскорбить или послать разработчика куда подальше.

                                                                                                                                                      Спасибо, я в Open source больше ничего никогда писать не буду.
                                                                                                                                                      Буду писать только проприетарное по за деньги.
                                                                                                                                                        0

                                                                                                                                                        Забейте на пользователей, не ходите на лор, опеннет или 4pda.


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


                                                                                                                                                        Или можно тусить среди библиотекописателей. Вон, не далее как вчера issue открыл, всё чинно-вежливо-мило. Никакой токсичности.

                                                                                                                                                          0
                                                                                                                                                          Полгода назад на питерском ФП митапе затирали точно про такую же фиговину для Neo4J.
                                                                                                                                                            0

                                                                                                                                                            Я эту фиговину в итоге не осилил и перешёл на более приземлённый (на самом деле нет), но более проработанный beam, кстати. В opaleye семейства типов как-то сбоку прикручены, и это чувствуется по всей библиотеке.


                                                                                                                                                            В итоге продолбал почти неделю зря.

                                                                                                                                                          0
                                                                                                                                                          Спасибо, я в Open source больше ничего никогда писать не буду. Буду писать только проприетарное по за деньги.

                                                                                                                                                          Да. Если кто-то проявляет агрессию и неуважение, это не значит, что так поступают все. Неверное обобщение.

                                                                                                                                                        +1

                                                                                                                                                        Пишу лет 13 в опенсорс, заметил токсичность только в одном проекте, который ориентировался на пользователей. Забил на хотелки пользователей, токсичность куда-то делась, последние лет 8 опенсорс несёт только счастье и радость, ЧЯДНТ?

                                                                                                                                                        +3
                                                                                                                                                        (а еще расхождение в дате регистрации и дате «приглашения» на сайт. Зарегестрирован на 2 года раньше чем приглашен. Ума не приложу, как такое возможно)


                                                                                                                                                        В этом нет ничего необычного. Например, я зарегистрирован в 2013-м году, а получил приглашение только в 2018-м. Пять лет я просто читал хабр и был read-only пользователем.
                                                                                                                                                          0
                                                                                                                                                          Зарегестрирован на 2 года раньше чем приглашен. — такое очень даже возможно т.к. был и остаётся период свободной регистрации рид-онли аккаунта, который сейчас уже не рид-онли, и можно оставлять комментарии, но не нельзя влиять на карму и голосование и какие-то еще ограничения. А приглашение — это билет в про-двинутую ступень аккаунта на хабре. (возможно я не точен, не слежу за изменениями политики, описал по памяти).
                                                                                                                                                          +1
                                                                                                                                                          Смущает формулировка:
                                                                                                                                                          Мне поручили разработку внутренней платформенной тулзы — библиотеки для выражения программных сущностей в виде объектно-ориентированных моделей и для однообразной работы с API сервисов
                                                                                                                                                          .
                                                                                                                                                          Насколько вы уверены, что с той и другой стороны правильно понимали задачу? Насколько это начинание изначально было поддеражно всей командой?
                                                                                                                                                            +1

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

                                                                                                                                                              +4
                                                                                                                                                              Я конечно не знаю как это у вас, но обычно со стороны лида это выглядит так:
                                                                                                                                                              1. Согласовали кусок работы, выбили время
                                                                                                                                                              2. Декомпозировали задачу, разбили на куски
                                                                                                                                                              3. Разраб берет первый кусок задачи, начинает делать. Находит новую идею:
                                                                                                                                                                «делать сильную систему типов» Начинает делать ее.
                                                                                                                                                              4. Сроки по куску провалены. Разраб говорит, что возникли проблемы, он их решил и следующая часть будет готова в срок. На самом деле дальше пилит идею. И вовсе не уверен в сроках, возможно даже о них не думает.
                                                                                                                                                              5. Результат: ничего не сделано или сделано не то, о чем договаривались или сделано больше чем то, о чем договариваись
                                                                                                                                                              6. Тимлид думает, что его обманули, разработчик, что его идею недооценили.
                                                                                                                                                              Софт скил для менеджера заключался в том, чтобы устранить проблему и договориться после фейла первой части, если задача декомпозирована (Если не декомпозирована, то это тоже проблема). Софт скил разраба здесь в том, чтобы постараться понятно объяснить для чего он делает и почему и если с ним сразу не согласились, то не делать этого, пока все не согласятся.
                                                                                                                                                              Полезность решения выношу за скобки. Тяжело решить насколько решение уместно без мнения второй стороны.