Я повесил у себя в подвале боксерскую грушу, приклеил на нее стоковое фото типичного менеджера и запихал внутрь динамик, чтобы он проигрывал фразы, которые меня злят. Например, груша говорит: «Бизнесу не нужен твой идеальный код. Ему нужно решить проблему так, чтобы прибыль покрыла затраты. Если для этого нужен говнокод, значит будет говнокод». И начинаю дубасить.
Недавно я добавил в грушу запись: «Типы — это сложно и ненужно». В этот момент я бью так сильно, что рука чуть не ломается. Потому что с меня хватит. Пару месяцев назад я пережил один из самых вопиющих кейсов в своей карьере.
Мой друг Антоха попросил меня помочь с решением для одной большой-большой корпорации. Я согласился, и мы влезли в бездонную пучину корпоративного абсурда, кранча, войны с ничего не понимающими коллегами и всеми видами несправедливости. Нам ничего нельзя говорить, поэтому мы будем говорить про типы, чтобы такая фигня никогда ни у кого не повторялась.
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
Комментарии (215)
Peter03
04.06.2019 18:30+2Непонятно, если уже есть бэкенд со всем что нужно, сделайте автогенератор typescript моделей и кода доступа. К тому же EntityFramework прикрутите пару Т4 скриптиков и дело в шляпе.
rcanedu
04.06.2019 18:42+1В системах старого типа — да. Но есть системы, в которых не только бек определяет формат обмена.
И тут манипуляции с данными нужны на фронте. Ведь сервисов, используемых фронтом — не один, и с разными рода апи.
Идея в том. что нужно сделать фронтенд приложение, которое сравнительно дешево сможет супортить огромное количество принципиально разных API
bm13kk
04.06.2019 18:53и как долго такой сайт будет грузится?
rcanedu
04.06.2019 19:00+1Конечно в перфомансе здесь выигрыша нет.
Тем не менее, библиотека не занимает большого объема в рантайме и не сжирает кучу памяти. Что касается оптимизаций, то вполне можно использовать стандартные практики и результат будет такой же.
fillpackart Автор
04.06.2019 19:00+2Интересный кейс в том, что 80% нашего кода — это типы, которые исчезают при компиляции.
А насчёт того, что сейчас фронт стал жирным — это не нам решать, какой он должен быть. Наша задача — заставить его работать хорошо независимо от идиотизма бизнес требованийbm13kk
04.06.2019 19:07> Интересный кейс в том, что 80% нашего кода — это типы, которые исчезают при компиляции.
Меня смутила именно часть про возможность быстрой смены трубы с данными. Это возможно либо благодаря лишним абстакциям — тогда все источники работают медленнее чем могли бы. Либо натягиванием абстракции одних над другими — тогда одини источники работают нормально, другие очень медленно.
> это не нам решать, какой он должен быть.
Сильно протеворечит посылу правильного кода из начала статьи.rcanedu
04.06.2019 19:25Дополнительные абстракции действительно есть. Но в них нет сложных алгоритмических преобразований в рантайме. Это такая минимальная плата за дизайн.
Peter03
04.06.2019 19:36Есть API management системы, которые как раз умеют подобное, генерировать клиенты и модели для множества языков. И как раз позволяют объединить несколько API в один и сделать необходимые манипуляции.
Хотя даже «add service reference» в VS понимает и SOAP и WSDL и REST. Сделать подобное на Т4 (или взяв подобные исходники из VS), достаточно просто, я лично для SOAP делал за пару дней.
Я не претендую что для вас это правильный вариант и знаю лучше что было правильно в вашем конкретном случае, просто у нас уже давно подобные вещи руками не пишут.
kmorozov
04.06.2019 18:38+1Статья — поразительный памятник трудолюбию и невежеству. Изобрести xsd в 2019 году — это сильно.
fillpackart Автор
04.06.2019 18:51Есть дохера хороших решений. проблема в том, что их нет для фронтенда. Потому что на фронте исторически плохо с типизацией. Мы решили исправить
TSR2013
04.06.2019 18:48+2Есть еще jsonschema https://json-schema.org/implementations.html
rcanedu
04.06.2019 19:21Верно. Но json-schema — это стандарт. Стандартам никогда не следуют, если нет жестких рамок инструментария. В случае с json-schema поддержка ts библиотеками практически отсутствует. Мы бы могли поддержать только этот стандарт, но мы решили дать возможность пользователю определять самостоятельно тот формат, который он хочет, либо воспользоваться теми, что мы поддерживаем.
TSR2013
04.06.2019 19:28https://github.com/YousefED/typescript-json-schema вот например генерация схем из исходников typescript. И например вот валидатор https://github.com/epoberezkin/ajv
Scf
04.06.2019 19:03+1Не совсем понятно. Библиотека сделана для случая, когда и фронт, и бэк на node.js и шарят общую схему, написанную руками?
Я бы предпочел кодогенерацию клиентского и серверного кода. Проще добавлять новые языки и протоколы, проще пользоваться — в сгенеренном коде нет никакой магии.
fillpackart Автор
04.06.2019 19:08+2Нет. Когда бэк и фронт написаны на одном ЯПе — тебе не нужна библиотека. Наша либа для того, что бы декларировать на клиентской стороне, с какими данными мы работаем. Насчёт кодогенерации — это очень спорная штука.
Scf
04.06.2019 19:11Зачем тогда нужна схема? Если нужно написать просто клиент к стороннему апи, можно обойтись обычной моделью и интерфейсами вместо схемы.
fillpackart Автор
04.06.2019 19:20+1Потому что в ts нет рантайм проверок из коробки.
Druu
05.06.2019 02:21Можно же проверки генерить вместе с типами и все.
fillpackart Автор
05.06.2019 02:24Кодогенерация — есть кодогенерация. Она может решить огромное количество проблем, но я бы старался её избегать. Как минимум потому, что она очень усложняет процесс разработки. Вообще, у меня есть ощущение. что каждый раз, когда прибегаешь к кодогенерации — ты не смог в автоматизацию. Иногда это происходит от несовершенства инструментов, иногда потому что ты тупой.
arvitaly
05.06.2019 10:50+2Разве TS не кодогенерит JS? Чем фоновая компиляция tsc отличается от любой другой?
soniq
05.06.2019 21:14+1Тем, что у ts куча пользователей, и в него вкладываются ресурсы значительно большие чем может себе позволить отдельная команда. Когда основная задача команды — пилить по пятнадцать бизнес-фич за итерацию, то самодельный кодогенератор за пять лет превратится в чудовище которое все ненавидят.
KvanTTT
05.06.2019 12:29Кодогенрация парсера из грамматики — это потому что не смог в автоматизацию и потому что тупой?
0xd34df00d
05.06.2019 17:23Потому что не смог в attoparsec или trifecta! Ну или потому, что не смог разобрать ошибки при компиляции boost.spirit.
Druu
06.06.2019 01:05+1Как минимум потому, что она очень усложняет процесс разработки.
Усложняет как именно?
Вообще, у меня есть ощущение. что каждый раз, когда прибегаешь к кодогенерации — ты не смог в автоматизацию.
А разве кодогенерация — не способ автоматизации? Странно как-то.
В любом случае — непонятно, зачем писать руками то, что может нагенерировать машина?
Тратится меньше усилий, проще проводить рефакторинг, код проще и чище, т.к. кодовая база значительно меньше, меньше вероятность ошибки. Одни плюсы, кажется.
В конце концов, сам тайпчек — это тоже метапрограммирование.
самодельный кодогенератор за пять лет превратится в чудовище которое все ненавидят.
Вы так говорите, как будто этот кодогенератор — какое-то большое, серьезное решение, требующее существенных затрат на внедрение и поддержку.
Мы же говорим просто о генережке вьюх/апи-сервисов. Там все тривиально, пишется за пару дней и потом работает себе и работает.
DexterHD
04.06.2019 19:10+2Я повесил у себя в подвале боксерскую грушу, приклеил на нее стоковое фото типичного менеджера и запихал внутрь динамик, чтобы он проигрывал фразы, которые меня злят.
Первая ошибка. Вместо того чтобы считать менеджеров «идиотами» следовало бы научится их слушать и правильно интерпретировать то что они пытаются донести.
Поэтому, вместо узкозаточенной либы, на которую стоял таск, мы решили делать гораздо более мощную и абстрактную — подходящую для всего. И мы невероятно верили в свою правоту, потому что только так и создаются по-настоящему хорошие вещи.
Вторая ошибка. Вместо решения поставленой бизнесом задачи вы решили послать всех к чертям и за счет бизнеса реализовать свои амбиции.
Чтобы делать хорошие дела, надо уметь убеждать людей в своей правоте.
Третья ошибка. Чтобы делать хорошин дела, нужно чтобы эти дела приносили людям пользу. В таком случае, не придется ни кого ни в чем убеждать.
Когда делаешь фронт, есть два источника проблем — пользователь и бекенд.
Четвертая ошибка. Не то ни другое не является проблемой. Пользователи — это те без кого ваша работа не имеет смысла, бэкэнд — это те без кого вы не сможете решить большинство сложных задач современного мира требующих большого кол-ва вычислительных мощностей.
… Но такие придурки существуют, причём существуют в том же самом мире, где есть другие придурки, пропускающие это говно на кодревью.
… Но мы сделаем, потому что мы профессионалы…
… и дураки легко сломают наш код.
Пятая ошибка. Считать всех вокруг придурками, идиотами, дураками, при этом считать себя профессионалами.
Мы написали самый полезный код в своей жизни, но его выкинули на помойку. Вместе с нами
В завершении ожидаемый и закономерный результат. Жизнь все расставила по местам.
К чему я это все? Я бы рекомендовал вам к прочтению вот эти книги. Все они в меньшей степени про код и в большей степени про то, как перестать доказывать всем, что ты профессионал и стать профессионалом:
- 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)
bm13kk
04.06.2019 19:13+3> Вместо того чтобы считать менеджеров… и правильно интерпретировать то что они пытаются донести.
Вообще-то это как раз их прямая работа — уметь донести.knotri
05.06.2019 13:20+1Вообще-то это как раз их прямая работа — уметь донести.
так они вроде прямо и недвухсмысленно говорили
"Бизнесу не нужен твой идеальный код. Ему нужно решить проблему так, чтобы прибыль покрыла затраты. Если для этого нужен говнокод, значит будет говнокод" — Если разработчик не может это понять — то это сугубо проблема разработчикаbm13kk
05.06.2019 14:11+1Эта фраза без конкретики — пустое поднятие ЧСВ.
Если по статье — то там нет никаких намеков на альтернативу и сравнение.
Если по комментарию, на который я ответил — то там вообще ни слова про качество кода.KilliarBarka
05.06.2019 20:33-2А ещё есть такое понятие как работодатель и трудовая иерархия. По личному опыту скажу, что меньше всего мне нужно убеждать подчинённого исполнять свои трудовые обязанности.
VolCh
06.06.2019 08:08Если вам не нужно, чтобы он исполнял свои обязанности хорошо, а достаточно чтобы он исполнял на уровне, позволяющем избежать увольнения по ТК(КЗоТ), то не убеждайте, а наслаждайтесь результатами чего-то типа итальянской забастовки.
Кстати, фраза типа "или делаешь как я скажу, или я тебя уволю" — это тоже один из способов убеждения.
Assimilator
05.06.2019 19:24+2Если посмотреть на телодвижения менеджеров то видно что они пытались вернуть на стезю нашего изобретателя велосипедов, потом просто микроменеджели его давая маленькие таски, а уж потом он ушёл. Как бы налицо относительно правильные попытки минимализировать ущерб от буйного сеньор девелопера.
andyN
06.06.2019 13:13Да там лол а не синьор )
Если оценивать полезный эффект для бизнеса как баланс между количеством хороших дел и количеством плохих, то какой-нибудь джуниор мог быть даже более полезен компании (ну если бы не говнокодил совсем).
Потому что после него остальным программистам не пришлось бы продираться через лютый велосипед и слои абстракции.
arttom
04.06.2019 19:20+2следовало бы научится их слушать и правильно интерпретировать
Если человек менеджер, это не делает его автоматически правым.
послать всех к чертям и за счет бизнеса реализовать свои амбиции
Никаких лишних амбиций. Полученную задачу декомозировали и предложили лучшее решение, какое нашли. Оно укладывалось в задачу, но как выяснилось позже, мешало амбициям других.
нужно чтобы эти дела приносили людям пользу
Либа принесла бы гораздо больше пользы, чем очередное узкое решение.
Считать всех вокруг придурками, идиотами, дураками
Не всех)Pydeg
04.06.2019 20:05-4Если человек менеджер, это не делает его автоматически правым.
Но оценивать правоту решений уж точно не задача программиста. Как минимум из-за того, что всю ответственность за реализацию задач руководства и принятие решений в своей зоне ответственности несёт менеджер. И если программист делает что-то не то — для бизнеса виноват будет менеджер.
Более того, неправильные решения могут поступать и со стороны руководства, но программистам же за их реализацию платят, а не за оценку и корректировку (без какой-либо ответственности за плохую корректировку).arttom
04.06.2019 20:25+4Видимо, пацаны не достаточно выгорели, чтобы молча цинично поглядывать, как рядом ошибаются. Можно же помочь. Просто некоторые вещи иногда сложнее донести
retran
04.06.2019 20:32Почему вы думаете что рядом ошибаются?
Если пацаны так ценят хорошую инженерию, то они могли поступить как инженеры — поискать готовые решения, сравнить, выделить плюсы и минусы, сделать прототип своего и дать менеджеру цифры. Это принятый у профессионалов способ доносить вещи.
retran
04.06.2019 20:51Собственно, я бы с удовольствием сам посравнивал, да вот проблема — работающей библиотеки у пацанов нет и сравнивать не с чем. А какое угодно, но работающее решение заведомо лучше удаленного (если оно вообще работало).
Nashev
05.06.2019 11:44К сожалению, программистов давать менеджеру цифры учат только менеджеры, и то далеко не все и далеко не сразу, и как парвило без конкретных методик, а только косвенно ставя такую задачу. Это ИМХО большая беда образования программистов.
VolCh
05.06.2019 16:29Технико-экономическое обоснование раньше каждый инженер писал хоть раз — в дипломе. Сейчас не так?
0xd34df00d
05.06.2019 17:23+1Так не все инженеры. У меня диплом по прикладной математике, там никаких экономических обоснований и ОБЖ не было.
VolCh
06.06.2019 08:10У нас и на прикладой математике ТЭО было. А вот ОБЖ — это, кажется, ввели в школах, когда мы курсе на третьем учились.
MacIn
06.06.2019 19:06А вот ОБЖ — это, кажется, ввели в школах, когда мы курсе на третьем учились.
Ну, это он условно назвал. В диплом инженера-программиста входит раздел по безопасности (при разработке и эксплуатации «изделия»). Там расчитывается, исходя из размера команды разработчиков, какое им потребуется помещение, по метражу/кубатуре, какой воздухообмен, какое освещение, какие столы/стулья, какие мощности по электричеству подводить для запитки ПК и т.д. Какой режим проветривания, если нет принудительной вентиляции и все такое.
SirEdvin
04.06.2019 20:47Первая ошибка. Вместо того чтобы считать менеджеров «идиотами» следовало бы научится их слушать и правильно интерпретировать то что они пытаются донести.
Если менеджер не может донести до программиста что-то — зачем он нужен?
Вторая ошибка. Вместо решения поставленой бизнесом задачи вы решили послать всех к чертям и за счет бизнеса реализовать свои амбиции.
Ну да, ведь у нас уже все напилено, что бы решать исключительно бизнес-задачи… а стойте, не напилено же! Если реализовывать строго по одной бизнес-задаче за раз, все очень быстро поломается.
Третья ошибка. Чтобы делать хорошин дела, нужно чтобы эти дела приносили людям пользу. В таком случае, не придется ни кого ни в чем убеждать.
Очень смешно. Видели картинку про квадартные колеса и "мы очень заняты?".
DrPass
04.06.2019 21:33+3Если менеджер не может донести до программиста что-то — зачем он нужен?
Эта палка обоюдоострая. Программист — взрослый человек, если он не понимает, что хочет менеджер, он точно так же по-хорошему может взять и выяснить, что и зачем. А не тихо записать его в идиоты и гнуть свою линию.
Я сам не раз осаживал программистов, которые нередко хотят сделать крутые универсальные решения в том случае, когда нужно обычное частное. Не надо бежать спасать мир, если вас попросили просто приготовить яичницу. Вы будете сто лет полировать свою крутую библиотеку, хотя вы бы уже давным-давно решили бы ту задачу, ради которой всё затевалось, и ещё десяток других.fillpackart Автор
04.06.2019 21:36+1У нас была задача сделать решение надолго и для кучи команд. Оно и должно быть универсальным.
SirEdvin
04.06.2019 23:57+3Эта палка обоюдоострая. Программист — взрослый человек, если он не понимает, что хочет менеджер, он точно так же по-хорошему может взять и выяснить, что и зачем. А не тихо записать его в идиоты и гнуть свою линию.
Я, конечно, дико прошу прощения, но зачем вообще нужны менеджеры? Мне казалось, что раз они менеджеры, то они должны управлять программистами, управлять которыми их делегировали. Если у вас скрам и самоменеджент окей, но в 99% случаев у вас в любом случае есть техлид/пм, который считается "главным". И если он не выполняет, свою, по факту, единственную обязанность — зачем он?
Программист может быть умным и понимать все сам, может быть туп и упрям как пробка, но в любом случае, работать с ним — это все-таки задача менеджера. Если человек слишком сложный для того, что бы с ним работать, мне кажется, единственным решением будет эскалация наверх и страдания. И когда вы пишите "следовало бы научится слушать" получается "вам следовало бы научится выполнять за менеджеров их работу".
Меня просто довольно сильно раздражает такой подход, когда менеджер приходит и выдвигает претензии, почему за него не делают его работу.
DrPass
05.06.2019 02:31-1Менеджеры не обязательно должны управлять программистами. Менеджер может быть менеджером проекта, продукта, менеджером по работе с клиентами. Во всех этих ипостасях он не является нянькой для программистов. Подразумевается, что он ставит задачи и контролирует их выполнение, а не ищет психологический подход, как там кого мотивировать.
И когда вы пишите «следовало бы научится слушать»
А что, у обычного взрослого человека с адекватной психикой этот навык не должен присутствовать по умолчанию? Это разве какая-то уникальная абилка руководителей?Rsa97
05.06.2019 08:13Это просто российская мода на красивые названия. Уборщиц записывают как клининг-менеджеров, приёмщиц как сервис-менеджеров, продавцов как менеджеров по работе с клиентами и т.д.
Классически, менеджер — руководитель среднего и верхнего звена, у которого в подчинении есть сотрудники. И один из его базовых навыков — умение работать с персоналом.
VolCh
05.06.2019 08:57У практически любого менеджера основной способ получать ожидаемые от него руководством результаты — мотивировать других людей делать что-то, приводящее к этим результатам. На разных позициях в разной степени, у кого-то прямые подчинённые, у кого-то равные смежники в одной организации, у кого-то топы контрагентов даже.
Nashev
05.06.2019 11:47Как минимум кто-то из этих двух — программиста и менеджера — должен уметь слушать и добиваться понятости. Но к сожалению, часто бывает что ни один не способен. И редко оба.
MacIn
06.06.2019 22:50Очень смешно. Видели картинку про квадартные колеса и «мы очень заняты?».
Если узкий подход не создает проблем, какого-то overhead'а, зачем overengineer'ить?
Это — не инженерный подход, а процесс ради процесса. «Мы программисты и мы кодим ради того, чтобы кодить».
Инженерный подход — это когда ты видишь, что потратил, решая вторую, подобную задачу, скажем, 43 часа на написание оберточного типового мусора, который можно решить библиотекой, на разработку которой уйдет 200 часов. Поскольку тебе надо решить еще 7 задач примерно того же плана, на которых ты потеряешь 43*7=301 час, то ты сэкономишь 101 час рабочего времени.
А писать ради того, чтобы писать — ну, в свободное время — пожалуйста.
Не нужно смешивать программирование как таковое и технологию разработки программного обеспечения.
Paskin
05.06.2019 00:39Про хорошие дела и пользу — польза часто получается сильно позже самих дел, либо дела — это какой-то продолжительный процесс. Поэтому надо уметь убеждать людей что ваше решение действительно полезно — часто «на пальцах». И, соответственно, слушать их аргументы — иногда они тоже бывают правы.
Со всем остальным — согласен.
LevOrdabesov
05.06.2019 12:36+1Чтобы делать хорошие дела, надо уметь убеждать людей в своей правоте.
Третья ошибка. Чтобы делать хорошин дела, нужно чтобы эти дела приносили людям пользу. В таком случае, не придется ни кого ни в чем убеждать.
Вы искренне настолько верите в человеческую цивилизацию,
или сознательно игнорируете факты реальности: существование и широкое распространение государств, армий, полиции, уголовных и налоговых кодексов и прочих инструментов, предназначенных для силового воплощения хороших дел?
Каковые инструменты необходимы именно потому, что большинство дел, в необходимости которых людей не нужно убеждать, не являются т.н. «хорошими».
Zet_Roy
04.06.2019 19:24+4Зачем вы сделали то что удешевит разработку для бизнеса? Программистам выгодно что бы бизнес больше тратил денег на задачи и проекты а не наоборот, вы какие то парни диверсанты в айти сфере.
VolCh
05.06.2019 09:00Бизнес тратит сколько может. Чем быстрее мы пилим задачи и проекты, тем больше у бизнеса денег в общем случае и тем больше он сможет на нас тратить.
bunopus
04.06.2019 19:40А выбирая типизированный язык, вы не смотрели в сторону Dart? По каким критериям выбирали TypeScript?
fillpackart Автор
04.06.2019 19:41Потому что кроме wrike никто на нём не пишет)
Очень сложно продать дарт бизнесуbunopus
04.06.2019 19:56+1Ну, это не совсем так, уже не так мало компаний его используют. Вон на конфе спикеры не только от нас были https://www.youtube.com/playlist?list=PLxcvsYzLfaTAwLy1UO2Y6b_AMg-0uDSjX
Просто когда вижу пост про типы на фронтенде, то Dart тут далеко от TS шагнул
rcanedu
04.06.2019 20:06+2Здесь важно то, что огромные инфраструктуры построены на JS и эти инфраструктуры поддерживаются разработчиками без знаний других языков. В связи с чем, процесс миграции на TS наименее болезненный, хотя даже здесь встречаются ярые противники добавления типизации. То есть по сути выбирать и не приходится (разве что рассматривать flow vs ts)
Druu
05.06.2019 02:30+1Просто когда вижу пост про типы на фронтенде, то Dart тут далеко от TS шагнул
Наоборот — система типов в дарте по сравнению с ts очень примитивна и невыразительна. С-но, ничего из того, что описано в статье, в дарте даже близко сделать не получится.
andrew8712
04.06.2019 20:06+1Эээ? Такое можно было говорить до появления Flutter, но сейчас? :)
Flutter/Dart поглотят мобильную разработку в будущем
braineater
05.06.2019 02:04+2React native что-то не поглотил.
andrew8712
05.06.2019 14:04При чем тут реакт? Это другая парадигма программирования. Естественно, что переход на нее тяжел для разработчиков.
mayorovp
06.06.2019 09:14И в чем же фундаментальное отличие React Native и Flutter?
И там, и там есть компоненты, их свойства, их состояние и рендер-функция, которая из свойств и состояния генерирует желаемое поддерево компонентов...
murzilka
05.06.2019 15:37Кажется, про xamarin так же говорили
andrew8712
05.06.2019 17:17Хамарин и рядом не стоял. У них с флаттером очень большие отличия
murzilka
05.06.2019 17:28Например какие?
Я не разработчик под мобилы, но мне правда интересно. Почему вдруг флаттер должен победить (и почему не победил до сих пор)? Чем он принципиально отличается от xamarin и react native(в том плане, что они тоже предлагают кроссплатформенную разработку)?andrew8712
05.06.2019 20:24Потому что он еще очень молод? Первый релиз был в начале этого года, до этого — беты.
У флаттера:
— свой графический движок. Можно сделать iOS приложения с родными для iOS элементами и просто запустить его на андроиде. Оно будет выглядеть точно так же.
— удобная (хотя и немного непривычная) верстка. После Storyboards это манна небесная.
— не привязан к среде разработки, в отличие от хамарина. Можно писать где угодно и компилить с помощью flutter toolbox.
— Hot reload — мега фича, сокращает время разработки заметно.
— Флаттер — не только mobile, но еще и desktop и (скоро) web.DrPass
05.06.2019 23:18Да так себе преимущества, если честно.
— Приложение выглядит одинаково на iOS и Android, это нужно? Скорее нет, т.к. у каждой ОС свои гайдлайны интерфейса, и надо им следовать, а не делать имитацию iOS под Андроид и наоборот.
— Верстка как вёрстка. Ничего особо удобного ни для нативных разработчиков, ни для тех, кто освоил React Native или Хamarin, не предложит.
— Не привязан к среде разработки? Ну и что? Наоборот, намного удобнее, когда инструмент тесно интегрирован в среду разработки. Ведь проще освоить незнакомую среду разработки с интегрированным инструментом, чем прикручивать сторонний инструмент к знакомой среде.
— Hot reload нынче есть практически везде, это не уникальная фича Флаттера.
— С точки зрения пользователя, ему пофигу, сделаете ли вы одно и то же приложение для десктопа, мобилы и для веба, или разные. С точки зрения разработчика, все равно верстка для десктопа и мобильных приложений должна отличаться.
murzilka
06.06.2019 14:09Мне почему-то кажется, что если технология действительно прорывная, если у неё есть будущее, то часто даже до релиза она во всю используется. Я не наблюдал хайпа вокруг flatter, ожиданий его релиза. Мне кажется, он уже «не выстрелил».
Но это не более чем моё мнение. Рад буду ошибиться в нём, dart мне показался достаточно удобным языком
fillpackart Автор
04.06.2019 21:50Кстати, не смог сходу нагуглить. Насколько я понимаю, в дарте строгая статическая номинативная типизация?
bunopus
05.06.2019 00:47fillpackart Автор
05.06.2019 02:09Вот идея, что дарт дальше тайпскрипта в типах — он дальше в том, что типизация строгая и номинативная.
Мне вот кажется, что структурная типизация (естественно статическая) не хуже и не лучше номинативной, и у обеих очень много проблем. В статье вот мы например боролись со структурной природой тайпскрипта, потому что у нас был кейс, где нужно было номинативное поведение. С другой стороны, прир азработке на C# я постоянно борюсь с его номинативностью, городя тонны бойлерплейта.
В целом, я бы не стал сравнивать такие две разные модели типизации с точки зрения «кто дальше».
Gugic
04.06.2019 20:56+3Интересно, спасибо.
Поделюсь другим опытом решения подобных проблем.
В одной очень большой компании вопрос решен повсеместным применение протобафов, которыми описаны не только модели но и сами сервисы, которые с этими моделями работают.
Из протобафов генерируются хэндлеры на бэкенде (их конечно потом надо имплементировать чтобы не получать UNIMPLEMENTED при вызове), из них собираются структуры, которые пойдут в БД («внешние» и «внутренние» протобафы конечно же не обязаны быть одними и теми же), из них же генерируются автоматически клиентские сильно типизированные библиотеки (какие душе угодно — dart, c++, java, python, go, nodejs ну и тайпскрипт конечно). Причем в настройках этих «генераторов» можно указать нужны ли тебе только интерфейсы или полнофункциональный клиент со всеми возможными вызовами, нужны тебе результаты в вибе промисов или observable.
Тут, конечно, нет возможности модифицировать схему на лету, но она получается фактически гвоздями прибита на всех сторонах.
От каста в any защищита на уровне ci — коммит с кастом в any просто не пройдет presubmit проверки.
Любое изменение схемы в ci триггерит пересборку всего, что с этой схемой связано и если где-то что-то не собралось (будь то хэндлеры на стороне сервера или какие-то взаимодействия с автосгенерированным клиентом в тайпскрипте) — коммит опять же просто завалится на пресабмите.
Из протобафов же генерируется документация (поэтому codestyle весьма жесткий), в них же поддерживается куча аннотаций для тюнинга прав доступа/visibility каких-то конкретных вещей, нужности аудита, серверных логов, требований к авторизации. «Фронтенд бэкенда» в общем случае один и тот же для имплементации сервиса на любом языке и он как раз потребляет эти аннотации сервисов из протобафов.staticlab
04.06.2019 21:16+1Из минусов:
- в случае развесистых интерфейсов сервисов сгенерированный JS-модуль получается неприлично большим;
- все поля всех интерфейсов становятся опциональными.
Gugic
04.06.2019 22:11+1в случае развесистых интерфейсов сервисов сгенерированный JS-модуль получается неприлично большим
Да, но с парой оговорок
1) Режим interfaces only позволяет пожертвовать удобством работы в пользу размера модуля (там генерируются только типы, которые исчезают при компиляции, для реквестов используется отдельная стандартная либа).
2) Какая-то общая часть внутренностей этих итоговых модулей вынесена в отдельный родительский класс, общий для всех сгенерированных модулей (в случае если их несколько). В самих модулях по факту как раз схема, енумы, геттеры/сеттеры, прокси-методы для вызовов процедур (но этого всего все равно очень много).
все поля всех интерфейсов становятся опциональными.
С интерфейсам — да, надо долго и нудно проверять все на null (также ci-enforced), но при генерации моделей в них можно добавить геттеры и сеттеры, которые предсказуемо работают.staticlab
05.06.2019 09:03Режим interfaces only позволяет пожертвовать удобством работы в пользу размера модуля
Но это же сразу лишает нас хоть какого-то тайпчекинга, нет?
Gugic
05.06.2019 09:30Почему? При компиляции все проверки на месте — интерфейсы это ведь про типизацию.
staticlab
05.06.2019 09:44Я имею в виду тайпчекинг в рантайме. Или вы предлагаете просто полагаться на то, что на бэкенде используются строго те же самые интерфейсы? В некоторых случаях это вполне приемлемо, тогда можно придумать и альтернативные способы, например, генерацию интерфейсов из сборок .net или java. Но автор считает кодогенерацию решением неудачников :)
Gugic
05.06.2019 19:20Тайпчекинг в рантайме да, пропадет. Но я же писал в первом комментарии что это просто немного другая парадигма — т.к. и бэкенд и фронтенд завязаны на одни и те же проты, у вас гарантирован (до определенной степени здравомыслия) одинаковый интерфейс на фронте и бэке. Потому что и фронт и бэк работают от одних и тех же определений, которые сами по себе абстрагированы и от одного и от другого.
Что автор и другие считают про кодогенерацию меня не очень интересует, тем более что я не настаиваю на правильности этого решения, просто поделился тем, как этот вопрос решен в одной конкретной очень большой компании.
staticlab
05.06.2019 12:44Кстати, а как в режиме interface only протобаф будет парсить и сериализовать объекты? Скармливать ему proto-файлы или метаинфу в json?
Gugic
05.06.2019 19:26А это, кстати, хороший вопрос, на который я сходу не отвечу. У нас последняя миля (браузер <-> фронтенд бэкенда) работает по обычному http (и это тоже настраивается через аннотации к протобафам), поэтому просто гоняем json и все работает.
А уже внутренняя вся инфраструктура разговаривает по бинарному протоколу, но там и проблем с размерами модулей и интерфейсами нет.
Druu
05.06.2019 02:35все поля всех интерфейсов становятся опциональными.
Почему? Если сервер возвращает поле, то он возвращает, оно не опционально.
staticlab
05.06.2019 08:59Но протокол не гарантирует, что в 100% случаев поле действительно придёт, а значит, рано или поздно появятся баги, когда казалось бы обязательное поле будет пустым, и придётся обкладывать всё if-ами.
Druu
05.06.2019 10:28а значит, рано или поздно появятся баги, когда казалось бы обязательное поле будет пустым
Каким образом? Если кто-то на беке забудет поле добавить, то код не скомпилируется и не запустится. А если скомпилируется и запустится — значит, с бека поле гарантированно придет.
staticlab
05.06.2019 11:56null всё ещё существует в популярных языках программирования.
Druu
05.06.2019 12:41null всё ещё существует в популярных языках программирования.
Ну там где наллы без поддержки то печалька, да. Но, по крайней мере, это только для непримитивных типов.
staticlab
05.06.2019 12:47Однако pbts генерирует интерфейсы вида
interface IStruct { foo?: (number|null); bar?: (string|null); }Druu
05.06.2019 13:22Речь, конечно, о случае с автоматической привязкой типов клиента и сервера друг к другу. Понятно, что отдельный инструмент для генерации типов на это закладываться не может и должен генерить общий вариант.
tamakio
06.06.2019 08:23+1А ещё внутренние БД нативно поддерживают протобафы и можно спокойно эти данные туда сохранить.
Мне этот подход показался наиболее удобным
gnaeus
04.06.2019 22:54А на MobX State Tree не смотрели? По части типизации выглядит очень похоже.
И runtime валидация тоже есть. Хотя либа все же для другого конечно. И ничего не знает про бекэнд.
DexterHD
05.06.2019 00:03+17Ознакомился я тут с авторами статьи. Все авторы (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 минуса…
Peter03
05.06.2019 00:19Не поверите, но у нас есть такая практика — с некоторой периодичностью мы регистрируем RO-аккаунт и публикуем с него написанную кем-то из сотрудников статью, как раз чтобы проверить, работает ли всё и можно ли жить, если постараться. Один раз даже смешно вышло — статья оказалась настолько удачной, что Deniskin попросил связаться с пользователем и пригласить его на собеседование :)
Проверьте соответствие стилю и может получиться что вы раскрыли загадку.
arttom
05.06.2019 01:00-1Фил с Антохой разрабы. Где работают, не скрывают, и кучу людей ваша конспирология только посмешит. А про тексты ради заработка поржут уже менеджеры, которые им зарплаты выписывают.
Я не разраб и никогда не был. Но реально офигевал, когда с пацанами сидел в баре и слушал их споры. Заслушаешься!
Сначала Фил помогал мне брать интервью как технический эксперт. Потом я взял у него интервью для пилота одной рубрики. И мы все офигели, какой это вызвало отклик. Порадовались и забыли, занимались каждый своими делами. Однажды Фил дико бомбил с неудачного собеседования. Я предложил ему сделать из этого колонку. Помог структурировать, причесал стиль. Получилось неплохо, и мы продолжили. Потом так же помог Антохе, когда у него появилась тема.
Вроде это нормально, когда обычные разрабы приходят и пишут о том, что болит? Так что не переживайте, писака здесь только я. Разрабы настоящие, никакого “заговора гуманитариев” нет, и не вижу ничего плохого, когда технарям помогают нормально доносить мысли, чтобы вам же, блин, и было интереснее читать.MacIn
06.06.2019 23:02Разрабы настоящие, никакого “заговора гуманитариев” нет,
Человек сказал не это по сути, вы передергиваете. Было сказано:
«В целом это не плохо. Плохо другое. Плохо выдавать себя за «высококлассного эксперта отрасли» имея суммарно 6 лет опыта работы в этой самой отрасли публикуя статьи, единственная цель которых — поднятие траффика и заработок»
retran
05.06.2019 01:00У меня такое ощущение возникло ещё в момент вброса про синьоров и virtual (ну просто потому что так не бывает), но хочется верить в хорошее.
fillpackart Автор
05.06.2019 01:09Насчёт моей репы — ну да, там в публичном доступе только тестовые задания.
Вот активность
Заголовок спойлера
DexterHD
05.06.2019 01:21+3Ваш труд, как статья не говно, наоборот все ваши посты взрывают рейтинги и это определенно талант, писать так, чтобы у всех бомбило.
Проблему я вижу в посыле который вы несете и в созданном вами образе. Вот этот ваш образ «Разработчика бунтаря. Рок-звезды, которую менеджмент не понимает» ни одной компании не принес ни чего хорошего.fillpackart Автор
05.06.2019 01:31-6Это не «мой образ», это я. Да, я часто не согласен с тем, что происходит вокруг. но не так часто, как кажется из статей. Тут проблоема в том, что когда всё хорошо — мне не хочется писать статью. Когда всё идёт окей, статья не нужна.
А вот когда я в чём то убеждён, а все делают по-другому, Меня подбамбливает и я сажусь писать об этом, как вижу
Про пользу комании — я лично, клал на неё. Антоха вот нет.DexterHD
05.06.2019 01:49+3А вот когда я в чём то убеждён, а все делают по-другому, Меня подбамбливает и я сажусь писать об этом, как вижу.
Я тоже был в чем то таким как вы. Примерно лет 5 назад. Меня тоже в свое время подобным образом бомбило. К сожалению или к счастью (я не знаю) я не писал об этом а посему такое вот мое видение мира не вышло в свет.
Про пользу комании — я лично, клал на неё. Антоха вот нет
Вы можете мне не верить, но рано или поздно вы пересмотрите этот вопрос. Причем чем раньше это случится, тем успешнее будет ваша карьера (Но это не точно).
Мне тоже раньше было срать, а потом мне пришлось встать «по другую сторону баррикад». Cобрать команду, возглавить разработку, поработать CTO.
Сейчас я снова работаю разработчиком. И не потому что меня уволили, менеджеры идиоты или я не справился с обязанностями, а потому что я люблю эту профессию и пока еще не «напрограммировался».
Но в отличие от меня старого, моя картина мира существенным образом изменилась и сейчас мне не срать, чего и вам желаю… И если вы не верите мне, почитайте хотя бы книги которые я давал выше. Они написаны людьми которые в профессии гораздо дольше вас и меня. Поверьте, они знают о чем пишут. Вы не раз найдете там себя…
retran
05.06.2019 01:24+1Вы знаете, надо быть очень сильным синьором, чтобы так качественно и целенаправленно цеплять людей за больные места и косить под "миллениала в кедах".
То что статья написана с целью вызвать ещё один срачик (как и прошлые) — очевидно.
fillpackart Автор
05.06.2019 01:40-3Срач — не цель. Я очень рад, когда есть фидбек, но в целом, я всегда хочу увидеть сотню-другую коментов про то, что я прав.
Так не бывает, конечно. Но если бы у меня была кнопка — снизить градус агрессии в коментах, я бы давил на нее не переставая.
Потому что даже когда очевидный хейтер приходит в одну мою статью за другой, что бы написать, что я идиот — это всё равно неприятно.
Под этой статьёй норм коментов хотелось особенно сильно.
Для меня это очень важные вопросы — типизация, бизнес, который никогда не даёт бюджета на тех. таски — я живу с этим каждый день.
Хуже всего то, что это я убедил Антоху сделать его таск по серьёзному. И. когда он ушёл с работы, я же его убедил написать об этом.
В принципе, если бы я работал над статьей один — чёрта с два бы стал оправдываться, и убеждать кого-то в чём-то в коментариях.retran
05.06.2019 01:49+1Понимаете, из ваших статей рисуется образ человека, который собрал в своей карьере все возможные грабли, которые мог собрать разработчик, включая граблю непризнанного гения. Мне сложно поверить, что так бывает, это выглядит как собирательный образ, созданный человеком (или группой людей), которые очень хорошо понимают какие грабли бывают и куда надо давить. Думаю, не только мне, отсюда и теории заговора у людей.
fillpackart Автор
05.06.2019 02:00Думаю, здесь каждый второй собрал граблей еще больше, просто не будет об этом рассказаывать, потому что постесняется — вдруг какой-нибудь образ сложится
0xd34df00d
05.06.2019 05:18+1Паттерн активности хорошо совпадает с образом девелопера, горящего разработкой, ага.
fillpackart Автор
05.06.2019 11:40Хех, ну тут больше моё флоу. Я так и не научился делать много комитов, у меня обычно один-два комита на задачу. Да и большинство вещей, которые я делаю для себя, я не сваливаю в гит, потому что это не проекты. Так, захотел что то проверить, сделал локально, забыл.
Не знаю, насколько уместно говорить про себя, что ты горишь разработкой, но я точно не горю ничем другим. И вряд ли смогу вспомнить день, когда я бы не писал какой-то код.0xd34df00d
05.06.2019 17:20У этого флоу статистически значимы (на глазок, p-value не считал, сорри) провалы по выходным, а также недельные и двухнедельные (отпуск?).
Ну а насчёт гита — это же просто удобно. Я туда (пусть и в приватную репу на гитхабе) сваливаю решения задач из purely functional data structures, которую читаю сейчас, или из types and programming languages, тайпчекеры из которой реализовывал год назад. Да чего там, люди туда решения задач по абстрактной алгебре пишут, но это уже для меня перебор, я-то ручкой по бумажке еложу, в TeX это оформлять слишком геморно.
KvanTTT
05.06.2019 12:39Ага, по будням. Причем практически все коммиты в приватные репозитории, оценить вклад не получилось. Зачем автор выложил этот скрин и указанием его активности — не понятно. С тем же успехом можно выложить активность на каком-нибудь рабочем гитлабе. А еще аккаунт гитхаба не указан в профиле у автора, но вот он.
fillpackart Автор
05.06.2019 13:14Выложил, потому что меня обвинили, что я вообще не разработчик
hd_keeper
05.06.2019 18:07Что-то как-то совсем уныло. Даже у меня гитхаб интересней, хоть я и не «король».
Gugic
05.06.2019 19:30Я не очень понимаю ваших претензий к автору. У меня на гитхабе вообще нет активности, но это не мешает мне быть старшим разработчиком и тимлидом и иногда кодить по 12 часов в день по настроению.
То, что у автора на гитхабе есть хоть какая-то активность — это ж только в плюс.0xd34df00d
06.06.2019 02:03А вы эти 12 часов по настроению кодите рабочие таски или для себя?
Gugic
06.06.2019 02:09Рабочие таски для себя, нравится мне моя работа.
0xd34df00d
06.06.2019 17:13Мне это сложно понять, я так никогда не мог, всегда хотелось поделать что-то ещё, вне работы.
Да и для резюме полезно, если уж совсем утилитарно подходить.
hd_keeper
06.06.2019 09:23То, что у автора на гитхабе есть хоть какая-то активность — это ж только в плюс.
Да кто ж спорит…
sandstramger
05.06.2019 09:41Чтобы быть высококлассным специалистом обязательно необходимо сутками писать в OpenSource?
Ясно, понятно.
Боже, когда же это наконец закончится…
Лично вот у меня нет ни времени, ни желания писать в Open source из-за его токсичности.KvanTTT
05.06.2019 12:42-1Это вы ранимы, а не сообщество токсично. Или вам просто не интересно.
sandstramger
05.06.2019 15:42+1Да?
Когда пользователи приложения, которое написали, разработчика обзывают геем, посылают на 3 буквы, за баги в приложении, это не токсично?
Это я только самое неоскорбляющие слова написал, как меня обзывали.
Возьмите тот же linux.org.ru или opennet или 4pda, там сидит куча троллей и токсичных людей, которые только и норовят оскорбить или послать разработчика куда подальше.
Спасибо, я в Open source больше ничего никогда писать не буду.
Буду писать только проприетарное по за деньги.0xd34df00d
05.06.2019 17:41Забейте на пользователей, не ходите на лор, опеннет или 4pda.
Мою поделку называли «эталонным нинужно» (лор), «автору руки вырвать, нельзя, чтобы он такой неюниксвей писал» (лор, опеннет, рандомные места), и так далее, так что понимаю, о чём вы говорите, но когда я понял, что это моё свободное время, как-то получилось ограничиться лишь плюсами от опенсорса (фан, изучение нового, строчки в резюме) без всех его минусов.
Или можно тусить среди библиотекописателей. Вон, не далее как вчера issue открыл, всё чинно-вежливо-мило. Никакой токсичности.
KvanTTT
05.06.2019 19:47Спасибо, я в Open source больше ничего никогда писать не буду. Буду писать только проприетарное по за деньги.
Да. Если кто-то проявляет агрессию и неуважение, это не значит, что так поступают все. Неверное обобщение.
0xd34df00d
05.06.2019 17:29Пишу лет 13 в опенсорс, заметил токсичность только в одном проекте, который ориентировался на пользователей. Забил на хотелки пользователей, токсичность куда-то делась, последние лет 8 опенсорс несёт только счастье и радость, ЧЯДНТ?
Perlovich
05.06.2019 10:30(а еще расхождение в дате регистрации и дате «приглашения» на сайт. Зарегестрирован на 2 года раньше чем приглашен. Ума не приложу, как такое возможно)
В этом нет ничего необычного. Например, я зарегистрирован в 2013-м году, а получил приглашение только в 2018-м. Пять лет я просто читал хабр и был read-only пользователем.
Tufed
05.06.2019 16:21Зарегестрирован на 2 года раньше чем приглашен. — такое очень даже возможно т.к. был и остаётся период свободной регистрации рид-онли аккаунта, который сейчас уже не рид-онли, и можно оставлять комментарии, но не нельзя влиять на карму и голосование и какие-то еще ограничения. А приглашение — это билет в про-двинутую ступень аккаунта на хабре. (возможно я не точен, не слежу за изменениями политики, описал по памяти).
zolotyh
05.06.2019 00:58Смущает формулировка:
Мне поручили разработку внутренней платформенной тулзы — библиотеки для выражения программных сущностей в виде объектно-ориентированных моделей и для однообразной работы с API сервисов
.
Насколько вы уверены, что с той и другой стороны правильно понимали задачу? Насколько это начинание изначально было поддеражно всей командой?rcanedu
05.06.2019 08:07Сама задача концептуально понималась одинаково с обеих сторон. Кроме того, она была декомпозирована, согласована и прочее. Здесь была моя ошибка в неверной оценке, так как я изначально не думал делать сильную систему типов
zolotyh
05.06.2019 13:23Я конечно не знаю как это у вас, но обычно со стороны лида это выглядит так:
1. Согласовали кусок работы, выбили время
2. Декомпозировали задачу, разбили на куски
3. Разраб берет первый кусок задачи, начинает делать. Находит новую идею:
«делать сильную систему типов» Начинает делать ее.
4. Сроки по куску провалены. Разраб говорит, что возникли проблемы, он их решил и следующая часть будет готова в срок. На самом деле дальше пилит идею. И вовсе не уверен в сроках, возможно даже о них не думает.
5. Результат: ничего не сделано или сделано не то, о чем договаривались или сделано больше чем то, о чем договариваись
6. Тимлид думает, что его обманули, разработчик, что его идею недооценили.
Софт скил для менеджера заключался в том, чтобы устранить проблему и договориться после фейла первой части, если задача декомпозирована (Если не декомпозирована, то это тоже проблема). Софт скил разраба здесь в том, чтобы постараться понятно объяснить для чего он делает и почему и если с ним сразу не согласились, то не делать этого, пока все не согласятся.
Полезность решения выношу за скобки. Тяжело решить насколько решение уместно без мнения второй стороны.Druu
05.06.2019 13:49+1Вообще, если исходить из рассказа, то там человек регулярно объяснял, чем он конкретно занимается, но его особо не слушал никто.
А так, если он сказал, что "я типы пилю за тем-то и затем-то" и регулярно так отчитывался и всех все устраивало в процессе — можно считать что решение было согласовано, по факту.zolotyh
05.06.2019 14:05Но я начал делать так, как считал правильным. На дейли я рассказывал, что и зачем делаю, но меня в принципе никто не понимал. Мои вопросы команде касательно возникшей проблемы всегда оставались без ответа. Меня словно и не существовало. Чувак, который делает что-то очень сложное и непонятное.
Но когда я что-то заливал в репозиторий, никто не мог понять, «что там еще за сложные типы». Я объяснял на дейли снова и снова, но натыкался на полный игнор. Энтузиазм и вера в правоту настолько придавали сил, что был почти уверен — скоро результат переломит недопонимание. Наконец в репо заглянул лид, и увидев там только типы, посчитал, что я нихера не делаю
Хрен знает, чем он слушал на дейли.
Выглядит не сильно убедительно. То есть я сказал, и дальше ваша проблема, что вы меня не слушаете и что вы поняли. Может быть нужно в этот момент оставновиться, согласовать действия с лидом? Я сильно сомневаюсь, что цель лида помешать расти прекрасным и универсальным инструменам любой ценой и душить мотивацию сотрудников на корню.
При этом вопросы и к лиду тоже есть, почему он не был в курсе процесса по задаче? Почему он не знал, что в рамках задачи нужно сделать и почему сейчас что-то другое делается?
lxsmkv
05.06.2019 05:04+1Поэтому, вместо узкозаточенной либы, на которую стоял таск, мы решили делать гораздо более мощную и абстрактную — подходящую для всего.И мы невероятно верили в свою правоту, потому что только так и создаются по-настоящему хорошие вещи
Мне тимлид как-то раз пояснил, что нужно рационально тратить свой ресурс. Решать поставленную задачу кратчайшим способом. Всегда если просят что-то, надо именно это и делать. Только тогда заказчик будет тебе доверять. И не пытаться сделать что-то другое. Если просят сделать автомобиль — не нужно делать фабрику по изготовлению автомобилей. Если просят табличку эксель — нужно сделать табличку эксель. Нужно снизойти до уровня технического понимания заказчика и решать его проблему доступным, понятным ему способом.
Да, это сильно бьет по самолюбию, очень сильно. Но когда нас нанимали на работу, самолюбие в требования не входило. Вот и надо оставлять его дома. Это не значит, что нужно «забить» и превратиться в «зомби 9-17». Не надо терять интерес к своей работе, нужно просто делать, то что просят и делать это хорошо. Т.е. чтобы заказчик был доволен.
Я руководствуюсь вопросом: а что будет если меня завтра снимут с проекта — сможет кто-то продолжить то, что я делаю без моей помощи? И сколько из того, что я сделал уже работает. Т.е. как можно чаще выкатывать value. Чтобы после меня осталось «доделывать» как можно меньше. Я плохо себя чувствую когда мой код не интегрирован в продукт. Он не приносит пользы. Код, как деньги — должен работать, а не лежать на диске. Чем длинее становится «резинка» оттягивающая интеграцию «пользы» в продукт, тем неуютнее я себя чувствую.
И этим же ощущением обуславливается поиск технических решений. Не «лучшее», а «достаточно хорошее, которое как можно скорее можно запустить, чтобы оно начало приносить пользу». Сначала решаем проблему бизнеса кратчайшим путем, таким образом получая свободное пространство для творчества, и тогда уже делаем офигенно. Чтобы уже что-то крутилось. Ведь в программировании так же — сперва — лишь бы работало, а потом рефакторинг.
У нас на проекте тоже есть интерфейс, который написал умный архитектор. Интерфейс решает много проблем. Им удобно пользоваться. Но вот только кроме него никто полностью не понимает тонкостей внутреннего устройства этого интерфейса. Т.е. как только у тебя нештатная ситуация, а он в отпуске — все, приплыли. Пишем костыли. Тратим кучу времени на дебаг того в чем не разбираемся, потому что не должны. Ведь интерфейсы должны просто работать. Только и в них могут возникнуть ошибки. И тогда все прелести сразу перекрываются одним недостатком — сложно. Слишком умно. Недоступно среднестатистическому разработчику. Заумно. А когда работает, конечно — ну чудесно, гениально.
«Лучшее — враг хорошего», не зря говорят.0xd34df00d
05.06.2019 05:29Но когда нас нанимали на работу, самолюбие в требования не входило. Вот и надо оставлять его дома.
Правда? И про интерес к самой технологии ничего не говорят? Про мотивацию? Про passion?
Я плохо себя чувствую когда мой код не интегрирован в продукт.
Заменили один источник мотивации другим. Принципиально ничего не поменялось, кроме того, что эта мотивация выгоднее владельцам бизнеса.
AllexIn
05.06.2019 09:23+1Мне тимлид как-то раз пояснил, что нужно рационально тратить свой ресурс. Решать поставленную задачу кратчайшим способом. Всегда если просят что-то, надо именно это и делать.
Это верное утверждение для джуна, но не верное для мидла и выше.
Профессионал от новичка отличается в частности тем, что понимает куда будет двигаться проект с большой вероятностью и пишет код с учетом этого. Новичок не обладает такими знаниями, поэтому ему самодеятельность лидом и запрещается.lxsmkv
05.06.2019 10:07Реальность такова, что мы, как правило, понятия не имеем куда будет двигатъся проект. Особенно на аутсорсе. Клиенты не распространяются о планах на будущее. А их планы на будущее, в свою очередь, зависят от ситуации на рынке, которая может поменяться в любой момент, стоит конкуренту выпустить какую нибудь новую финтифлюшку. Поэтому разработка ведется по принципу локальной оптимизации. Все гибкие методологии сводятся к итеративному подходу. Не закладываться на будущее, а создавать минимальный ценный продукт, который уже будет работать здесь и сейчас. Если продать клиенту которому нужен лендинг, вместо SPA целый кастомный СМS, то это может, случайно, и окажется в будущем удачным решением, но как правило — оверинжиниринг. Тем более, технологии устаревают так быстро, что загадывать наперед, кажется вообще оторванной от жизни идеей.
AllexIn
05.06.2019 10:35С аутсорсом согласен. Нужно подешевле и побыстрее сваять, поддерживать и развивать же всё равно другие будут.
А НЕ на аутсорсе вполне реально предсказать куда будет двигаться проект. Возможно у вас какие-то супер особенные проекты, которые ну вообще никакому анализу не поддаются, но таких проектов доли процентов. Основная же масса без проблем позволяет роадмап на годы вперед расписать.staticlab
05.06.2019 12:01Но даже для того, чтобы продать продуктовой компании CMS вместо статического лендинга, нужно договориться с бизнесом и показать ему ценность такого решения, а если не обращать внимания на business value, то и не следует обижаться, почему компания отвергает такое решение.
solver
05.06.2019 13:18+1Реальность такова, что мы, как правило, понятия не имеем куда будет двигатъся проект.
Что же вас всех в космос то тянет?
Вам дали задачу сделать библиотеку логирования в системе (апи для фронта, аудита, генерации отчета, что угодно еще). Какое вам особенное знание о направлении движения проекта нужно? Это четкая функция системы. Условно: джун будет писать ровно так как ему скажут, мидлу дадут направление, сеньер сам может предусмотреть что надо от того же логирования.
Думаю все эти рассказы про «мне надо знать направление бизнеса», оно от банального бессилия человека понять, что ему надо делать. Вот он и прячется за софистическими формулировка о необходимости чего-то…
Как иллюстрацию к сказанному, посмотрите на проект Spring для Java. Люди делают кучу достаточно гибких решений, которые с успехом применяются в самых разных проектах.
И никто из них не говорит «дайте мне видение вашего бизнеса и только тогда я смогу написать SpringData». Это и есть инженерные решения, которые должны принимать не менеджеры, а технари которых нанимают — как именно решать поставленную задачу бизнеса.Nashev
05.06.2019 18:02Либа как проект тоже вполне может иметь видиние перспективы развития и формулировки целей и идеалов.
tamakio
06.06.2019 07:56У Pivotal свой бизнес и он спланирован.
Разработчики там пишут с учётом интересов компании. Компания решает, что надо поддерживать Kafka — пишут. Надо депрекейтить RestTemplate — будут трогать только для критических уязвимостей.
И сеньор знает, что компания через год выпускает новую библиотеку, и ему надо писать текущий код с оглядкой на будущий релиз.
playermet
05.06.2019 11:51Утверждение верное и для мидла и выше. Разница между джуном и прочими только в том, что у джуна заточенный код будет вбит гвоздями, а у мидла и выше заточенный код будет изолирован и заменяем. Смысла писать функционал под предлогом «авось понадобится» особо нет, если только нет лишнего времени.
MacIn
06.06.2019 23:14Профессионал от новичка отличается в частности тем, что понимает куда будет двигаться проект с большой вероятностью и пишет код с учетом этого. Новичок не обладает такими знаниями, поэтому ему самодеятельность лидом и запрещается.
Но это зависит от позиции — исполнитель он или «архитектор системы». В статье же говориться о несоответствии: «наняли как суперсиньора с видением, чтобы он пришел и рассказал команде, как решить проблему. Так ему сказали на собесе. А теперь выставили так, что нанимали аджайлового солдата»staticlab
06.06.2019 23:23Ребята судя по всему на своих аутсорсовых галерах никогда не видели настоящего аджайла. Но ведь работать в продуктовой компании, где они реально могли бы внедрять технологии, они не хотят.
serf
05.06.2019 11:54Но вот только кроме него никто полностью не понимает тонкостей внутреннего устройства этого интерфейса. Т.е. как только у тебя нештатная ситуация, а он в отпуске — все, приплыли. Пишем костыли.
То есть лучше писать костыли чем один раз разобраться с могучим «интерфейсом»?lxsmkv
05.06.2019 14:14В энтерпрайзе на аутсорсе иногда нет времени разбираться, баг нужно пофиксить сегодня к двенадцати. Не важно какой он сложности. Точка. Может у кого-то на «шоколадных» проектах и по другому, у нас так. Или ты выполняешь поставленную задачу, или ты в следующем году можешь выбыть из числа подрядчиков и поставишь под угрозу существование всей своей фирмы, потому что этот заказчик дает больше половины оборота.
Nashev
05.06.2019 18:03Только волшебники там работают? Или и сказочники тоже?
Simplevolk
05.06.2019 19:19+3Сказочники обещают сделать к двенадцати, волшебники — делают.
lxsmkv
05.06.2019 20:40У нас тимплид такой волшебник. Он во первых знает систему вдоль и поперек, потому что стоял у ее истоков десять лет назад, и еще у него незаурядный интеллект. Может пофиксить проблему пока ты ему про нее рассказываешь. По сравнению с ним любой сениор выглядит джуниором. Такие люди большая редкость.
darkdan
05.06.2019 18:33Если просят сделать автомобиль — не нужно делать фабрику по изготовлению автомобилей.
Иногда получается и покруче.
Построить фабрику по изготовлению кирпичей из которых будет построена фабрика по построению автомобилей.
Не знаю, свойство ли это русских разработчиков или разработчиков вообще, но зачастую люди пытаются решать задачу глобально, чтобы решить не задачу, а целый класс задач. Цель грандиозная и потому сложно реализуемая, особенно в ограниченном интервале времени.braineater
06.06.2019 01:32К сожалению иногда бывает и наоборот. Проект на Юнити, код есть и работает но… Только в редакторе. На целевой платформе (web) не работает потому что там есть свои ограничения которые необходимо (было) учитывать при разработке. Тоже потрясающий подход. Я не буду детально изучать ТЗ, я не буду задавать уточняющие вопросы, просто нафигачу код.
darkdan
06.06.2019 02:05Да нет, это опять-таки в ту же тему. «Смотрите техзадание, понимайте для кого и для чего этот код делается.»
Есть старый такой принцип «Мыслить глобально, действовать — локально». Ребятам бы проработать концепцию, спланировать, так сказать, машиностроение. Затем, с учетом этой концепции сделать машинку (вот просто ту либу, что заказчик заказал), таким образом доказать что концепция работает (хотя бы вот в этом частном случае), получить за это деньги, а затем доработать и расширить функционал, реализовав свою концепцию полностьюво плотив коде — вот тогда шансы на успех, мне кажется, были бы выше. И концепция реализована, и частный случай реализации концепции есть, овеществлен и внедрен, проверен, работает.
А теперь им надо реализовывать свою концепцию заново, с нуля, без бюджета и так далее. Доказывать что оно внедряемо и работоспособно. Нелегко будет им. Удачи, сил и терпения.
Вышеперечисленное — ИМХО конечно.
Mox
05.06.2019 05:38+1Парни, вам было бы охота после отпуска погружаться опять в вашу библиотеку для внесения правок?
rcanedu
05.06.2019 08:12Да, мы все еще хотим ее доделать и заопенсорсить. В ней еще довольно много работы и скорей всего придется переосмыслить дизайн в некоторой части.
akryukov
05.06.2019 10:26Может быть сначала ее нужно заопенсорсить, а потом доделывать?
rcanedu
05.06.2019 10:44+2Может быть. Но я считаю, что сначала должна быть выражена главная идея инструмента, а для этого должна существовать возможность использования этого инструмента. Сейчас это может зайти как учебное пособие по тс, так как много практик по использованию системы типов тс. Но, конечно, мое мнение не догма и я рассматриваю вариант более скорой публикации репозитория
S-e-n
05.06.2019 12:05А в чём главная идея? Силился понять из статьи, но не смог.
Т.е. я правильно понимаю, что задача сводится к трансформации данных из одной структуры в другую? Если так, то универсальное решение — язык правил, по которым эта трансформация происходит.
Mugik
05.06.2019 07:58+1Авторы статьи. Вам ребята всё грамотно разъяснили и указали на ваши ошибки и обоснованно, аргументировано объяснили почему вы не правы.
Но вы упорно продолжаете стоять на своём и доказывать свою правоту. Эта статья и вы сквозите налётом очень высокого о себе мнения и считаете всех вокруг идиотами, это заметно и в статье и в комментариях.
Знаете, если вы не измените своё отношение не только к этой ситуации, но и в общем и не сделаете выводов — ваш ждёт неминуемое наказание. Жизнь очень хорошо умеет ставить на колени тех, кто не умеет слушать и делать выводы.
hd_keeper
05.06.2019 09:10-1> костыли вроде «нормализации структуры данных»
Дальше можно было не читать. :D
А вообще выкручивать руки другим разработчикам — так себе идея.
truthfinder
05.06.2019 10:49Это что ж за цветовая тема такая на первом скрине? Первый раз такую вижу.
fillpackart Автор
05.06.2019 10:57Расширение для vscode Rainglow, поставляет кучу тем. Эта называется Vision(colorbind).
Сверхохеренная.0xd34df00d
06.06.2019 02:01Голова болеть не начинает? У меня по опыту от такого оттенка синего глаза выжигаются очень быстро.
Solarized light получше для моих глаз.
StepanRodionov
05.06.2019 11:24Узнал автора статьи по заголовку в блоке «читают сейчас». С поправкой на эпоху, я бы назвал его труды современной версией «Героя нашего времени». Тексты читаются легко и интересно, с содержаним согласны отнюдь не все, а зеленая молодежь (да, реально знаю таких) хочет быть похожей на героя произведения.
serf
05.06.2019 11:33Готовых решений валидации по схеме/сериализации/десериализации/рантайм валидаций ведь для TS много. Свое начали писать потому что захотелось освоить всю мощь TS in action?
D_E_S
05.06.2019 13:09Есть у нас один программист в офисе с маниакальной идеей генерировать весь js через php. Пишет свои решения практически с нуля, оперируя тем что там удобней работать с backend и не надо вникать там в какой-то frontend. Бизнес всё больше и больше просит удобный решений и кнопочек на frontend что заставляет этого разработчика делать всё больше и больше таких решений. И с недоумениям воспринимают информацию о том, что чтобы сделать такое же окно, но зелёненькое надо столько же времени, как и первый раз. Это я к чему много того что пишет программист интересует результат, а не процесс и внутренний составляющая. Зачастую кажущими нам моментами мы считаем, что улучшаем свой внутренний процесс, но всегда надо думать об этом процессе как части процесса бизнеса.
Jabher
05.06.2019 15:10+1честно скажу, под конец статьи, где-то на 70%, продираться стало сложно.
Я правильно понимаю, что вы переизобрели io-ts?
Если да — то не очень круто. Не потому что хуже или лучше, а потому что io-ts основывается на fp-ts, который основывается на fantasy-land (хотя и чуть отходит от него), спецификации, которая описывает взаимодействие алгебраических структур на JS. Иначе говоря, обеспечивает совместимость кучи библиотек.
Если нет — готов признать, что не осилил статью
HellWalk
05.06.2019 15:17Вот когда говоришь «у вас тут во всех моделях SQL-инъекции, надо переделывать», а тебе отвечают «а что такого, работало же, и нас все устраивало».
Вот от такого действительно разрывает шаблоны)
bayarsaikhan
05.06.2019 16:07+1Дорогие авторы, вы реально считаете, что такое описание типа добавляет понимания при чтении кода? Погружаясь в сладкий мир абстракций, не забывайте, что с вашим кодом будут работать живые люди, у которых зачастую будет ограниченный запас времени и бизнес-задача в голове, отъедающая огромную часть ресурсов абстрактного мышления.
interface Repository<D extends Driver, S extends Schema> {
get: (dsl: ParseDSLTerm) => MapSchemaToDriver<S, D> extends RepositoryTemplate ? ApplyDSLTerm<MapSchemaToDriver<S, D>, T> : Error<’type’, ‘Type error’>;
}
smer44
05.06.2019 16:30-1Мы написали самый полезный код в своей жизни,
не, изобрели динамическую валидацию при стёртых типах, которая слабо похожа на что там в SOAP. Приятно видеть что эта маленькая функция которую очень кратко можно написать для питона с валидацией по типам, полям и т.п. — это «самый полезный код», ребята что же вы намриер про трейс исполнения кода по строкам в Питоне то скажите…
А потом да, говнокодищеес большой буквы Г)))
странно подтверждает эмпирический закон что то не напишешь на JS получишь быдлокод)))
из пустого в порожнее темплейты, потом слишком специализированный код для видители робота )))
ребята, кидайте обязательно этот код в резюме!!!
andyN
05.06.2019 16:53-1Как выглядит день типичного плохого программиста.
1) Дубасит грушу, на которой висит портрет ненавистного менеджера, который не даёт бедному дитятке играться в свои игрушки за деньги компании.
2) Пишет лютый велосипед, переизобретая давно известные вещи. Ок, возможно в нерабочее время, но см. пункт 1.
Exponent
05.06.2019 18:31«Я люблю большие корпорации..» — судя по этой фразе автор в том возрасте когда хочется изменить мир. В свое время проработал в корпорации 6 лет, насмотрелся на всякое, как людей повышают за то что спят с кем надо, как переводят в другия отделы по связям, как принимаются решения по разработке родственниками и т.д. Корпорации это точно не то место где что-то можно изменить, они поддерживают свой говнокод десятилетиями. Если и творить и рисковать так это стартапы, там можно за малое время опробовать много технологий.
Winnie13
06.06.2019 00:04Отдохнул пару дней, полностью удалил все исходники библиотеки
Стесняюсь спросить, но потраченная зарплата, надеюсь, в кассу тоже была возвращена в полном объёме после удаления исходников?
Всякие неявные штуки типа недополученной прибыли, упущенного времени, и прочего нанесённого ущерба я и так вывел за скобки.
nlog
06.06.2019 12:19Очень отдалённо напомнило обратную версию thedailywtf.com/articles/The-Expert-System
AndrewMayorov
06.06.2019 15:27+1Хорошая статья, спасибо! Причем сама статья не так важна, как количество ненависти в каментах. Такого количества «хозяин лучше знает», «не высовывайся» и «ты что здесь, ..., самый умный?» я давно не видел.
IMELIN
06.06.2019 15:31История, типичная для растущего программиста. "Болезнь роста" называется. Создание программ — производственный процесс, зачастую превращаемый программистом в творческий. Это порождает конфликты. Проблемы те же, что были 30 лет назад у тогдашних девелоперов. По опыту общения с программистами мэйнстримов в крупных госконторах знаю, что все примочки, а также "волшебные палочки", многократно ускоряющие разработки, тесты ПО, контрольные примеры и т.д. и т.п. (фактически, инструментарий девелопера), разрабатываются в свободное от работы время. Профессионалам это знакомо. Ну, а производственный процесс — это священная корова и ею рисковать нельзя.
При разработке важно охватить разнообразие входящей информации, классифицировать ее на типы, и эта классификация неизбежно отразится на внутренней структуре ПО. Отсюда обобщение кода и типизация идут на последующих этапах. Об этом многие тут писали.
Крик души авторов де факто посвящен их попытке оптимизации кода параллельно с разработкой, чего делать нельзя. И это опять же болезнь роста девелопера. Надо было идти дальше — писать говнокод, но разбивать его на модули/либы с мыслью последующей замены их на более продвинутые.
Надо было задуматься о ОТДЕЛЬНОЙ разработке новой системы, которую можно было бы по частям использовать в работе над похожими проектами или над этим же, но на последующих этапах. Об этом тоже здесь писали.
В общем этот случай очень напоминает историю "разностной машины" Бэббиджа, которая так и не была построена полностью.
И напоследок пару почти анекдотов о говнокоде. В 90е годы шла дискуссия в компьютерных изданиях о том, на каких языках лучше писать прикладное ПО. Несмотря на приоритет С во множестве мнений, помню автора, который писал, что ПО для решения множества задач (того времени), связанных с базами данных, он многократно разрабатывал на одном из диалектов BASIC и клиента это полностью устраивало.
И еще был свидетелем удивления заказчика, нацеленного на красивую, большую программу с навороченным интерфейсом, когда оказалось, что задача, поставленная им, легко и быстро (за 1-2 вечера за счет времени отдыха, поскольку основную работу никто не отменял) решилась разработкой таблицей Excel с той же функциональностью.
Мораль: 1 — производственный процесс надо уважать, как и лидов и манагеров всех уровней; 2 — ОЧЕНЬ СИЛЬНО ценить полученные возможности по доступу к разнообразию входной информации, чего никто и ни при каких обстоятельствах не будет иметь, находясь ВНЕ организации заказчика (именно этот доступ дает возможность учиться девелоперу); 2 — все примочки делать ТОЛЬКО в личное время; 3 — не афишировать заранее и не манить лидов и менеджеров еще не выращенной морковкой; 4 — тем временем структурировать говнокод под свои будущие магические софтгаджеты и либы; 5 — главное, чтобы говнокод, пусть даже временный, работал НАДЕЖНО — это устроит всех, потому что магическая "кухня" девелопера со всяческими чудесами, на самом деле нужно ТОЛЬКО ему, что ускорить разработку похожих задач; 6 — говнокод не приносит ощущения собственной гениальности, элитарности, но может сильно экономить время, которое можно потратить на: а) творчество; б) на доп. подработку; 7 — описанные хождения авторов по мукам на самом деле относятся к оптимизации, а место оптимизации д.б. не первым; 8 — код, написанный однажды, не должен уничтожаться ни при каких..., а должен тщательно документироваться и складываться в архив (никто не знает, что будет потом — приходилось возвращаться к старым находкам, чтобы ускорить новые разработки); 9 — как многие писали, код должен решать поставленные задачи, но не быть избыточным, и это касается и внутренней структуры кода и его внутренней функциональности. В самом деле лучшее враг хорошего
Опять же ошибка роста. Но общеизвестно, кто именно никогда не ошибается.
MacIn
06.06.2019 22:07+1Краткое содержание статьи: «мы решили в рабочее время и за деньги работодатели разработать отвлеченную шляпу, которой можно блеснуть где-нибудь на конфе, поставить себе галочку в резюме, но работодатель почему-то не захотел оплачивать наши эксперименты. Мы думали, что если успеем в сжатый срок сделать свою систему не по спецификации, но покрывающую узкий случай, то победителей не будут судить, но не успели. Ну, да, времени было отведено на создание более простого узкого решения N часов, мы решили, что успеем за это же время склепать более сложную абстрактную систему, требующую большей проработки, мы же професеоналы. Но даже переработки не спасли. Epic Fail».
Антоху наняли как суперсиньора с видением, чтобы он пришел и рассказал команде, как решить проблему. Так ему сказали на собесе. А теперь выставили так, что нанимали аджайлового солдата, который должен пилить в срок, что скажут.
В контракте-то что написано, к чему крокодиловы слезы?
retran
Т. е. вы за деньги бизнеса заново изобрели SOAP/WSDL с квадратными колесами?
Scf
Такие аргументы обычно используются в корпоративной борьбе. Пофиг что не SOAP, пофиг, что не WSDL, ОНИ ПОТРАТИЛИ ДЕНЬГИ БИЗНЕСА, вместо того, чтобы взять уже написанное бесплатно!
После такого вброса уже сложно объяснять кумулятивную разницу между заточенным на свои нужды велосипедом и затратами на уже готовое решение.
retran
Если бы в статье не было упоминаний про то как «нас не оценил бизнес», такого комментария не было бы. Я, к слову, как раз любитель поизобретать велосипеды. Вот только перед этим я обычно очень подробно изучаю доступный чужой опыт, просто потому что после этого велосипеды получаются лучше.
Покажите мне, пожалуйста, место в статье где действительно обосновывается необходимость собственного велосипеда.
Если разницу объяснять сложно — значит ее нет, увы.
fillpackart Автор
В коде. Заглядывал туда?
retran
Спасибо, что Вы сразу подняли уровень аргументации на этот уровень. Серьезно.
К сожалению, уровень профессионализма для меня недостижимо высок и мне стыдно разбазаривать Ваше время, поэтому, пожалуйста, не отвечайте на мой вопрос.
fillpackart Автор
Мы не изобрели велосипед. Мы увидели, как люди на беке катаются на велосипедах, и решили, что на фронте тоже было бы здорово на нём покататься.
Для меня необходимость иметь полную проверку типов при работе с внешним источником данных очевидна.
Инструментов, которые бы уже делали тоже самое, причём именно для typescript — мы не нашли
retran
Первая же ссылка в гугле — spin.atomicobject.com/2018/03/26/typescript-data-validation
UPD и множество всего в комментариях к статье и дальше в гугле
krig
Если смотреть с позии среднего/крупного бизнеса, то главное чтобы не бесплатно/быстро, а чтобы предсказуемо в средне- и долгосрочной перспективе. Хороший разработчик может запилить решение, которое порвет все существующие аналоги, как опенсорс так и энтерпрайс, и на короткой дистанции это может быть прорывом, но что делать с этим крутым решением через три года, когда крутой разработчик пилит мегарешения уже в пятой компании, а корпорации нужно как-то поддерживать проект, обеспечивающие потребности бизнеса? Отсюда и дорогостоящие консультанты, обслуживающие тормозные решения — бизнес точно знает сколько это стоит, где/как это достать и куда послать своего специалиста на обучение и сертификацию в случае необходимости. Платные версии условно-бесплатных продуктов, типа nginx+ и т.п. из этой же оперы — если у продукта нет платной поддержки (бесплатная означает отсутствие предсказуемости), то многие средние/крупные компании такие решения даже не рассматривают.
norguhtar
А вас это удивляет? Я в openAPI смотрю такой и ммм я где-то это видел. А точно в SOAP/WSDL!
В итоге люди которые говорили это все сложно JSON наше все, выдали точно такое же решение. Только с JSON и YAML.
retran
Знаете, я бы ни слова не сказал, если бы в статье просто описывался подход и лежала ссылка на гитхаб. Но эти крайне интересные подробности про плохих менеджеров и удаленные исходники...
SirEdvin
А разве SOAP не мертв? Мне казалось, его никто не использует уже лет так 10, в основном из-за того, что в него заложено слишком многое, что оказывается не нужно в 90% случаев.
mikhailidi
Это вам только кажется. Если сделать шаг от ноды а контейнере, в сторону кондового энтерпрайза, то выяснится что и SOAP не пропал, и WS-Policy вполне себе в ходу. Все живет долго и заменяется медленно.
norguhtar
Да никуда он не делся. Просто это не стильная молодежная технология.
Assimilator
Около 4 лет назад впиливал его в клиент-сервер (Линь-Вин), банально из-за того что других готовых API-либ под Линь Питон (3.4 ещё был емнип) просто не нашёл.
adictive_max
Как бы SOAP и REST (cсоответственно WSDL и OpenApi) — это сильно не одно и то же. Хотя бы в том, что SOAP — это конкретный протокол, а REST — сферовакуумный архитектурный принцип. Всё сходство между WSDL и OpenApi — это только назначение — формализованные форматы описания протокола.
norguhtar
А вы где-то видели чтоб SOAP использовали не по верх http? Если рассматривать применение, то SOAP/REST фактически тоже самое. Просто REST немного попроще и все.
adictive_max
А вы где-то видели, чтобы HTTP реализовывали не поверх TCP? Если рассматривать применение, то HTTP/транспортные протоколы фактически тоже самое. Просто транспортные протокол немного попроще и все.
vesper-bot
QUIC, не?
Aingis
Вы не поверите, HTTP/3 — это именно версия HTTP не поверх TCP.
jham1
я видел, без http, через MQ :)
VolCh
А я делал REST не по HTTP
hd_keeper
Через SMTP ещё видел. :D
Assimilator
Месье знает толк…
PsyHaSTe
WCF умеет по TCP ходить, например. Там вообще много транспортов.
mayorovp
Может, SOAP и REST — и не одно и то же, но вот SOAP+WSDL и REST+OpenApi почему-то все равно очень похожи.
adictive_max
Конечно похожи. Это пары «базовые принципы + язык описания спецификации». По этому принципу очень много чего похоже.