Комментарии 259
Такие аргументы обычно используются в корпоративной борьбе. Пофиг что не SOAP, пофиг, что не WSDL, ОНИ ПОТРАТИЛИ ДЕНЬГИ БИЗНЕСА, вместо того, чтобы взять уже написанное бесплатно!
После такого вброса уже сложно объяснять кумулятивную разницу между заточенным на свои нужды велосипедом и затратами на уже готовое решение.
Покажите мне, пожалуйста, место в статье где действительно обосновывается необходимость собственного велосипеда.
Если разницу объяснять сложно — значит ее нет, увы.
Покажите мне, пожалуйста, место в статье где действительно обосновывается необходимость собственного велосипеда.
В коде. Заглядывал туда?
К сожалению, уровень профессионализма для меня недостижимо высок и мне стыдно разбазаривать Ваше время, поэтому, пожалуйста, не отвечайте на мой вопрос.
Покажите мне, пожалуйста, место в статье где действительно обосновывается необходимость собственного велосипеда.
Мы не изобрели велосипед. Мы увидели, как люди на беке катаются на велосипедах, и решили, что на фронте тоже было бы здорово на нём покататься.
Для меня необходимость иметь полную проверку типов при работе с внешним источником данных очевидна.
Инструментов, которые бы уже делали тоже самое, причём именно для typescript — мы не нашли
UPD и множество всего в комментариях к статье и дальше в гугле
> внешним источником данных
Не чувствуете противоречия?
Мы долго думали над стратегией обработки таких кейсов, и решили, что такая стратегия должна максимально настраиваться пользователем. К сожалению, огромный блок про это не вошёл в статью (она и так слишком огромная получилась).
Т.е. идеал такой — пользователь либы сам решает, какие поля данных — rerquired, какие опциональные. И он же сам решает, хочет он получать неполные данные, или ошибку
День, когда бизнес полным составом переедет на ФЯП будет праздником
Говорю это как человек, тысячи тысяч раз делавший проверку на нул, только потому, что система типов C# не позволяла мне отделять нулабл от не нулабл.
но ей никто не пользуетс
Вы сейчас походя сказали весьма важную вещь. Я вам больше скажу — основная масса программистов неспособна полноценно использовать даже систему типов джавы (я говорю конкретно о тех, кто пишет на джаве при этом).
У людей просто отсутствует соответствующее мышление, нету вообще в голове вот этой концепции "тэкс, у меня тут есть инвариант, зафиксирую-ка его типом" и более того — они ее простор неспособны в принципе осознать. Это какая-то фундаментальная проблема, прямо-таки дыра в ментальной модели, которая возникает из-за каких-то специфических особенностей обучения программированию, по всей видимости. И пока это в индустрии не изменится, не появится и нужных инструментов. Потому что инструменты следуют за задачами, а не задачи за инструментами.
Не способна или не использует? Расмматриваете вариант "тэкс, у меня тут есть инвариант, зафиксирую-ка его типом… да ну, сложно и непонятно будет, лучше в рантайме"
Не способна или не использует?
"не способна" — конечно, очень неточный термин. Вот, допустим, если какой-то человек прыгать технически может (ну, в плане, взять и оттолкнуться ногами от поверхности), но при этом не в курсе о том, что есть вообще такая штука — "прыгать". Незнакома ему подобная концепция.
вместо того, чтобы взять уже написанное бесплатно!
Если смотреть с позии среднего/крупного бизнеса, то главное чтобы не бесплатно/быстро, а чтобы предсказуемо в средне- и долгосрочной перспективе. Хороший разработчик может запилить решение, которое порвет все существующие аналоги, как опенсорс так и энтерпрайс, и на короткой дистанции это может быть прорывом, но что делать с этим крутым решением через три года, когда крутой разработчик пилит мегарешения уже в пятой компании, а корпорации нужно как-то поддерживать проект, обеспечивающие потребности бизнеса? Отсюда и дорогостоящие консультанты, обслуживающие тормозные решения — бизнес точно знает сколько это стоит, где/как это достать и куда послать своего специалиста на обучение и сертификацию в случае необходимости. Платные версии условно-бесплатных продуктов, типа nginx+ и т.п. из этой же оперы — если у продукта нет платной поддержки (бесплатная означает отсутствие предсказуемости), то многие средние/крупные компании такие решения даже не рассматривают.
В итоге люди которые говорили это все сложно JSON наше все, выдали точно такое же решение. Только с JSON и YAML.
Знаете, я бы ни слова не сказал, если бы в статье просто описывался подход и лежала ссылка на гитхаб. Но эти крайне интересные подробности про плохих менеджеров и удаленные исходники...
А точно в SOAP/WSDL!
А разве SOAP не мертв? Мне казалось, его никто не использует уже лет так 10, в основном из-за того, что в него заложено слишком многое, что оказывается не нужно в 90% случаев.
А я делал REST не по HTTP
WCF умеет по TCP ходить, например. Там вообще много транспортов.
Может, SOAP и REST — и не одно и то же, но вот SOAP+WSDL и REST+OpenApi почему-то все равно очень похожи.
В системах старого типа — да. Но есть системы, в которых не только бек определяет формат обмена.
И тут манипуляции с данными нужны на фронте. Ведь сервисов, используемых фронтом — не один, и с разными рода апи.
Идея в том. что нужно сделать фронтенд приложение, которое сравнительно дешево сможет супортить огромное количество принципиально разных API
Конечно в перфомансе здесь выигрыша нет.
Тем не менее, библиотека не занимает большого объема в рантайме и не сжирает кучу памяти. Что касается оптимизаций, то вполне можно использовать стандартные практики и результат будет такой же.
А насчёт того, что сейчас фронт стал жирным — это не нам решать, какой он должен быть. Наша задача — заставить его работать хорошо независимо от идиотизма бизнес требований
Есть еще jsonschema https://json-schema.org/implementations.html
Верно. Но json-schema — это стандарт. Стандартам никогда не следуют, если нет жестких рамок инструментария. В случае с json-schema поддержка ts библиотеками практически отсутствует. Мы бы могли поддержать только этот стандарт, но мы решили дать возможность пользователю определять самостоятельно тот формат, который он хочет, либо воспользоваться теми, что мы поддерживаем.
https://github.com/YousefED/typescript-json-schema вот например генерация схем из исходников typescript. И например вот валидатор https://github.com/epoberezkin/ajv
Не совсем понятно. Библиотека сделана для случая, когда и фронт, и бэк на node.js и шарят общую схему, написанную руками?
Я бы предпочел кодогенерацию клиентского и серверного кода. Проще добавлять новые языки и протоколы, проще пользоваться — в сгенеренном коде нет никакой магии.
Зачем тогда нужна схема? Если нужно написать просто клиент к стороннему апи, можно обойтись обычной моделью и интерфейсами вместо схемы.
Можно же проверки генерить вместе с типами и все.
Кодогенрация парсера из грамматики — это потому что не смог в автоматизацию и потому что тупой?
Как минимум потому, что она очень усложняет процесс разработки.
Усложняет как именно?
Вообще, у меня есть ощущение. что каждый раз, когда прибегаешь к кодогенерации — ты не смог в автоматизацию.
А разве кодогенерация — не способ автоматизации? Странно как-то.
В любом случае — непонятно, зачем писать руками то, что может нагенерировать машина?
Тратится меньше усилий, проще проводить рефакторинг, код проще и чище, т.к. кодовая база значительно меньше, меньше вероятность ошибки. Одни плюсы, кажется.
В конце концов, сам тайпчек — это тоже метапрограммирование.
самодельный кодогенератор за пять лет превратится в чудовище которое все ненавидят.
Вы так говорите, как будто этот кодогенератор — какое-то большое, серьезное решение, требующее существенных затрат на внедрение и поддержку.
Мы же говорим просто о генережке вьюх/апи-сервисов. Там все тривиально, пишется за пару дней и потом работает себе и работает.
Я повесил у себя в подвале боксерскую грушу, приклеил на нее стоковое фото типичного менеджера и запихал внутрь динамик, чтобы он проигрывал фразы, которые меня злят.
Первая ошибка. Вместо того чтобы считать менеджеров «идиотами» следовало бы научится их слушать и правильно интерпретировать то что они пытаются донести.
Поэтому, вместо узкозаточенной либы, на которую стоял таск, мы решили делать гораздо более мощную и абстрактную — подходящую для всего. И мы невероятно верили в свою правоту, потому что только так и создаются по-настоящему хорошие вещи.
Вторая ошибка. Вместо решения поставленой бизнесом задачи вы решили послать всех к чертям и за счет бизнеса реализовать свои амбиции.
Чтобы делать хорошие дела, надо уметь убеждать людей в своей правоте.
Третья ошибка. Чтобы делать хорошин дела, нужно чтобы эти дела приносили людям пользу. В таком случае, не придется ни кого ни в чем убеждать.
Когда делаешь фронт, есть два источника проблем — пользователь и бекенд.
Четвертая ошибка. Не то ни другое не является проблемой. Пользователи — это те без кого ваша работа не имеет смысла, бэкэнд — это те без кого вы не сможете решить большинство сложных задач современного мира требующих большого кол-ва вычислительных мощностей.
… Но такие придурки существуют, причём существуют в том же самом мире, где есть другие придурки, пропускающие это говно на кодревью.
… Но мы сделаем, потому что мы профессионалы…
… и дураки легко сломают наш код.
Пятая ошибка. Считать всех вокруг придурками, идиотами, дураками, при этом считать себя профессионалами.
Мы написали самый полезный код в своей жизни, но его выкинули на помойку. Вместе с нами
В завершении ожидаемый и закономерный результат. Жизнь все расставила по местам.
К чему я это все? Я бы рекомендовал вам к прочтению вот эти книги. Все они в меньшей степени про код и в большей степени про то, как перестать доказывать всем, что ты профессионал и стать профессионалом:
- 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)
Вообще-то это как раз их прямая работа — уметь донести.
так они вроде прямо и недвухсмысленно говорили
"Бизнесу не нужен твой идеальный код. Ему нужно решить проблему так, чтобы прибыль покрыла затраты. Если для этого нужен говнокод, значит будет говнокод" — Если разработчик не может это понять — то это сугубо проблема разработчика
Если вам не нужно, чтобы он исполнял свои обязанности хорошо, а достаточно чтобы он исполнял на уровне, позволяющем избежать увольнения по ТК(КЗоТ), то не убеждайте, а наслаждайтесь результатами чего-то типа итальянской забастовки.
Кстати, фраза типа "или делаешь как я скажу, или я тебя уволю" — это тоже один из способов убеждения.
Если оценивать полезный эффект для бизнеса как баланс между количеством хороших дел и количеством плохих, то какой-нибудь джуниор мог быть даже более полезен компании (ну если бы не говнокодил совсем).
Потому что после него остальным программистам не пришлось бы продираться через лютый велосипед и слои абстракции.
следовало бы научится их слушать и правильно интерпретировать
Если человек менеджер, это не делает его автоматически правым.
послать всех к чертям и за счет бизнеса реализовать свои амбиции
Никаких лишних амбиций. Полученную задачу декомозировали и предложили лучшее решение, какое нашли. Оно укладывалось в задачу, но как выяснилось позже, мешало амбициям других.
нужно чтобы эти дела приносили людям пользу
Либа принесла бы гораздо больше пользы, чем очередное узкое решение.
Считать всех вокруг придурками, идиотами, дураками
Не всех)
Почему вы думаете что рядом ошибаются?
Если пацаны так ценят хорошую инженерию, то они могли поступить как инженеры — поискать готовые решения, сравнить, выделить плюсы и минусы, сделать прототип своего и дать менеджеру цифры. Это принятый у профессионалов способ доносить вещи.
Собственно, я бы с удовольствием сам посравнивал, да вот проблема — работающей библиотеки у пацанов нет и сравнивать не с чем. А какое угодно, но работающее решение заведомо лучше удаленного (если оно вообще работало).
Меня учили в вузе.
Технико-экономическое обоснование раньше каждый инженер писал хоть раз — в дипломе. Сейчас не так?
У нас и на прикладой математике ТЭО было. А вот ОБЖ — это, кажется, ввели в школах, когда мы курсе на третьем учились.
А вот ОБЖ — это, кажется, ввели в школах, когда мы курсе на третьем учились.
Ну, это он условно назвал. В диплом инженера-программиста входит раздел по безопасности (при разработке и эксплуатации «изделия»). Там расчитывается, исходя из размера команды разработчиков, какое им потребуется помещение, по метражу/кубатуре, какой воздухообмен, какое освещение, какие столы/стулья, какие мощности по электричеству подводить для запитки ПК и т.д. Какой режим проветривания, если нет принудительной вентиляции и все такое.
Первая ошибка. Вместо того чтобы считать менеджеров «идиотами» следовало бы научится их слушать и правильно интерпретировать то что они пытаются донести.
Если менеджер не может донести до программиста что-то — зачем он нужен?
Вторая ошибка. Вместо решения поставленой бизнесом задачи вы решили послать всех к чертям и за счет бизнеса реализовать свои амбиции.
Ну да, ведь у нас уже все напилено, что бы решать исключительно бизнес-задачи… а стойте, не напилено же! Если реализовывать строго по одной бизнес-задаче за раз, все очень быстро поломается.
Третья ошибка. Чтобы делать хорошин дела, нужно чтобы эти дела приносили людям пользу. В таком случае, не придется ни кого ни в чем убеждать.
Очень смешно. Видели картинку про квадартные колеса и "мы очень заняты?".
Если менеджер не может донести до программиста что-то — зачем он нужен?
Эта палка обоюдоострая. Программист — взрослый человек, если он не понимает, что хочет менеджер, он точно так же по-хорошему может взять и выяснить, что и зачем. А не тихо записать его в идиоты и гнуть свою линию.
Я сам не раз осаживал программистов, которые нередко хотят сделать крутые универсальные решения в том случае, когда нужно обычное частное. Не надо бежать спасать мир, если вас попросили просто приготовить яичницу. Вы будете сто лет полировать свою крутую библиотеку, хотя вы бы уже давным-давно решили бы ту задачу, ради которой всё затевалось, и ещё десяток других.
Эта палка обоюдоострая. Программист — взрослый человек, если он не понимает, что хочет менеджер, он точно так же по-хорошему может взять и выяснить, что и зачем. А не тихо записать его в идиоты и гнуть свою линию.
Я, конечно, дико прошу прощения, но зачем вообще нужны менеджеры? Мне казалось, что раз они менеджеры, то они должны управлять программистами, управлять которыми их делегировали. Если у вас скрам и самоменеджент окей, но в 99% случаев у вас в любом случае есть техлид/пм, который считается "главным". И если он не выполняет, свою, по факту, единственную обязанность — зачем он?
Программист может быть умным и понимать все сам, может быть туп и упрям как пробка, но в любом случае, работать с ним — это все-таки задача менеджера. Если человек слишком сложный для того, что бы с ним работать, мне кажется, единственным решением будет эскалация наверх и страдания. И когда вы пишите "следовало бы научится слушать" получается "вам следовало бы научится выполнять за менеджеров их работу".
Меня просто довольно сильно раздражает такой подход, когда менеджер приходит и выдвигает претензии, почему за него не делают его работу.
И когда вы пишите «следовало бы научится слушать»
А что, у обычного взрослого человека с адекватной психикой этот навык не должен присутствовать по умолчанию? Это разве какая-то уникальная абилка руководителей?
Классически, менеджер — руководитель среднего и верхнего звена, у которого в подчинении есть сотрудники. И один из его базовых навыков — умение работать с персоналом.
У практически любого менеджера основной способ получать ожидаемые от него руководством результаты — мотивировать других людей делать что-то, приводящее к этим результатам. На разных позициях в разной степени, у кого-то прямые подчинённые, у кого-то равные смежники в одной организации, у кого-то топы контрагентов даже.
Очень смешно. Видели картинку про квадартные колеса и «мы очень заняты?».
Если узкий подход не создает проблем, какого-то overhead'а, зачем overengineer'ить?
Это — не инженерный подход, а процесс ради процесса. «Мы программисты и мы кодим ради того, чтобы кодить».
Инженерный подход — это когда ты видишь, что потратил, решая вторую, подобную задачу, скажем, 43 часа на написание оберточного типового мусора, который можно решить библиотекой, на разработку которой уйдет 200 часов. Поскольку тебе надо решить еще 7 задач примерно того же плана, на которых ты потеряешь 43*7=301 час, то ты сэкономишь 101 час рабочего времени.
А писать ради того, чтобы писать — ну, в свободное время — пожалуйста.
Не нужно смешивать программирование как таковое и технологию разработки программного обеспечения.
Со всем остальным — согласен.
Чтобы делать хорошие дела, надо уметь убеждать людей в своей правоте.
Третья ошибка. Чтобы делать хорошин дела, нужно чтобы эти дела приносили людям пользу. В таком случае, не придется ни кого ни в чем убеждать.
Вы искренне настолько верите в человеческую цивилизацию,
или сознательно игнорируете факты реальности: существование и широкое распространение государств, армий, полиции, уголовных и налоговых кодексов и прочих инструментов, предназначенных для силового воплощения хороших дел?
Каковые инструменты необходимы именно потому, что большинство дел, в необходимости которых людей не нужно убеждать, не являются т.н. «хорошими».
А выбирая типизированный язык, вы не смотрели в сторону Dart? По каким критериям выбирали TypeScript?
Очень сложно продать дарт бизнесу
Ну, это не совсем так, уже не так мало компаний его используют. Вон на конфе спикеры не только от нас были https://www.youtube.com/playlist?list=PLxcvsYzLfaTAwLy1UO2Y6b_AMg-0uDSjX
Просто когда вижу пост про типы на фронтенде, то Dart тут далеко от TS шагнул
Здесь важно то, что огромные инфраструктуры построены на JS и эти инфраструктуры поддерживаются разработчиками без знаний других языков. В связи с чем, процесс миграции на TS наименее болезненный, хотя даже здесь встречаются ярые противники добавления типизации. То есть по сути выбирать и не приходится (разве что рассматривать flow vs ts)
Просто когда вижу пост про типы на фронтенде, то Dart тут далеко от TS шагнул
Наоборот — система типов в дарте по сравнению с ts очень примитивна и невыразительна. С-но, ничего из того, что описано в статье, в дарте даже близко сделать не получится.
Flutter/Dart поглотят мобильную разработку в будущем
Хамарин и рядом не стоял. У них с флаттером очень большие отличия
Я не разработчик под мобилы, но мне правда интересно. Почему вдруг флаттер должен победить (и почему не победил до сих пор)? Чем он принципиально отличается от xamarin и react native(в том плане, что они тоже предлагают кроссплатформенную разработку)?
У флаттера:
— свой графический движок. Можно сделать iOS приложения с родными для iOS элементами и просто запустить его на андроиде. Оно будет выглядеть точно так же.
— удобная (хотя и немного непривычная) верстка. После Storyboards это манна небесная.
— не привязан к среде разработки, в отличие от хамарина. Можно писать где угодно и компилить с помощью flutter toolbox.
— Hot reload — мега фича, сокращает время разработки заметно.
— Флаттер — не только mobile, но еще и desktop и (скоро) web.
— Приложение выглядит одинаково на iOS и Android, это нужно? Скорее нет, т.к. у каждой ОС свои гайдлайны интерфейса, и надо им следовать, а не делать имитацию iOS под Андроид и наоборот.
— Верстка как вёрстка. Ничего особо удобного ни для нативных разработчиков, ни для тех, кто освоил React Native или Хamarin, не предложит.
— Не привязан к среде разработки? Ну и что? Наоборот, намного удобнее, когда инструмент тесно интегрирован в среду разработки. Ведь проще освоить незнакомую среду разработки с интегрированным инструментом, чем прикручивать сторонний инструмент к знакомой среде.
— Hot reload нынче есть практически везде, это не уникальная фича Флаттера.
— С точки зрения пользователя, ему пофигу, сделаете ли вы одно и то же приложение для десктопа, мобилы и для веба, или разные. С точки зрения разработчика, все равно верстка для десктопа и мобильных приложений должна отличаться.
Но это не более чем моё мнение. Рад буду ошибиться в нём, dart мне показался достаточно удобным языком
Мне вот кажется, что структурная типизация (естественно статическая) не хуже и не лучше номинативной, и у обеих очень много проблем. В статье вот мы например боролись со структурной природой тайпскрипта, потому что у нас был кейс, где нужно было номинативное поведение. С другой стороны, прир азработке на C# я постоянно борюсь с его номинативностью, городя тонны бойлерплейта.
В целом, я бы не стал сравнивать такие две разные модели типизации с точки зрения «кто дальше».
Поделюсь другим опытом решения подобных проблем.
В одной очень большой компании вопрос решен повсеместным применение протобафов, которыми описаны не только модели но и сами сервисы, которые с этими моделями работают.
Из протобафов генерируются хэндлеры на бэкенде (их конечно потом надо имплементировать чтобы не получать UNIMPLEMENTED при вызове), из них собираются структуры, которые пойдут в БД («внешние» и «внутренние» протобафы конечно же не обязаны быть одними и теми же), из них же генерируются автоматически клиентские сильно типизированные библиотеки (какие душе угодно — dart, c++, java, python, go, nodejs ну и тайпскрипт конечно). Причем в настройках этих «генераторов» можно указать нужны ли тебе только интерфейсы или полнофункциональный клиент со всеми возможными вызовами, нужны тебе результаты в вибе промисов или observable.
Тут, конечно, нет возможности модифицировать схему на лету, но она получается фактически гвоздями прибита на всех сторонах.
От каста в any защищита на уровне ci — коммит с кастом в any просто не пройдет presubmit проверки.
Любое изменение схемы в ci триггерит пересборку всего, что с этой схемой связано и если где-то что-то не собралось (будь то хэндлеры на стороне сервера или какие-то взаимодействия с автосгенерированным клиентом в тайпскрипте) — коммит опять же просто завалится на пресабмите.
Из протобафов же генерируется документация (поэтому codestyle весьма жесткий), в них же поддерживается куча аннотаций для тюнинга прав доступа/visibility каких-то конкретных вещей, нужности аудита, серверных логов, требований к авторизации. «Фронтенд бэкенда» в общем случае один и тот же для имплементации сервиса на любом языке и он как раз потребляет эти аннотации сервисов из протобафов.
в случае развесистых интерфейсов сервисов сгенерированный JS-модуль получается неприлично большим
Да, но с парой оговорок
1) Режим interfaces only позволяет пожертвовать удобством работы в пользу размера модуля (там генерируются только типы, которые исчезают при компиляции, для реквестов используется отдельная стандартная либа).
2) Какая-то общая часть внутренностей этих итоговых модулей вынесена в отдельный родительский класс, общий для всех сгенерированных модулей (в случае если их несколько). В самих модулях по факту как раз схема, енумы, геттеры/сеттеры, прокси-методы для вызовов процедур (но этого всего все равно очень много).
все поля всех интерфейсов становятся опциональными.
С интерфейсам — да, надо долго и нудно проверять все на null (также ci-enforced), но при генерации моделей в них можно добавить геттеры и сеттеры, которые предсказуемо работают.
Что автор и другие считают про кодогенерацию меня не очень интересует, тем более что я не настаиваю на правильности этого решения, просто поделился тем, как этот вопрос решен в одной конкретной очень большой компании.
А уже внутренняя вся инфраструктура разговаривает по бинарному протоколу, но там и проблем с размерами модулей и интерфейсами нет.
все поля всех интерфейсов становятся опциональными.
Почему? Если сервер возвращает поле, то он возвращает, оно не опционально.
а значит, рано или поздно появятся баги, когда казалось бы обязательное поле будет пустым
Каким образом? Если кто-то на беке забудет поле добавить, то код не скомпилируется и не запустится. А если скомпилируется и запустится — значит, с бека поле гарантированно придет.
А ещё внутренние БД нативно поддерживают протобафы и можно спокойно эти данные туда сохранить.
Мне этот подход показался наиболее удобным
И runtime валидация тоже есть. Хотя либа все же для другого конечно. И ничего не знает про бекэнд.
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 минуса…
Я не разраб и никогда не был. Но реально офигевал, когда с пацанами сидел в баре и слушал их споры. Заслушаешься!
Сначала Фил помогал мне брать интервью как технический эксперт. Потом я взял у него интервью для пилота одной рубрики. И мы все офигели, какой это вызвало отклик. Порадовались и забыли, занимались каждый своими делами. Однажды Фил дико бомбил с неудачного собеседования. Я предложил ему сделать из этого колонку. Помог структурировать, причесал стиль. Получилось неплохо, и мы продолжили. Потом так же помог Антохе, когда у него появилась тема.
Вроде это нормально, когда обычные разрабы приходят и пишут о том, что болит? Так что не переживайте, писака здесь только я. Разрабы настоящие, никакого “заговора гуманитариев” нет, и не вижу ничего плохого, когда технарям помогают нормально доносить мысли, чтобы вам же, блин, и было интереснее читать.
Разрабы настоящие, никакого “заговора гуманитариев” нет,
Человек сказал не это по сути, вы передергиваете. Было сказано:
«В целом это не плохо. Плохо другое. Плохо выдавать себя за «высококлассного эксперта отрасли» имея суммарно 6 лет опыта работы в этой самой отрасли публикуя статьи, единственная цель которых — поднятие траффика и заработок»
У меня такое ощущение возникло ещё в момент вброса про синьоров и virtual (ну просто потому что так не бывает), но хочется верить в хорошее.
Вот активность
да, я не херачу как индус по милиону строк кода в день.
До этого на работах использовались всякие VSTSы и гитлабы
Резюме на хедхантере, не самый вроде левый сайт
Насчёт твиттера — ну я подумал, раз люди меня читают на хабре,
почему бы мне не вести твиттер. Тем про которые хочется поговорить хватает
И айти журналист из меня как из вас журналист расследователь
Про трёхмесячную работу — я начал писать статью про тайпскрипт, когда Антохе дали тот таск.
После увольнения статья превратилась в статью про Антоху.
Про то, что строю из себя эксперта. Я несколько раз подряд устраивался на синьорскую позицию в американские фирмы.
Может я конечно, и хер с горы, но ребятам вроде норм
Про минусы — ну извините, если мне говорят что мой труд говно, и при этом мне кажется, что человек даже не внимкал в суть статьи — я херачу минус.
Проблему я вижу в посыле который вы несете и в созданном вами образе. Вот этот ваш образ «Разработчика бунтаря. Рок-звезды, которую менеджмент не понимает» ни одной компании не принес ни чего хорошего.
А вот когда я в чём то убеждён, а все делают по-другому, Меня подбамбливает и я сажусь писать об этом, как вижу
Про пользу комании — я лично, клал на неё. Антоха вот нет.
А вот когда я в чём то убеждён, а все делают по-другому, Меня подбамбливает и я сажусь писать об этом, как вижу.
Я тоже был в чем то таким как вы. Примерно лет 5 назад. Меня тоже в свое время подобным образом бомбило. К сожалению или к счастью (я не знаю) я не писал об этом а посему такое вот мое видение мира не вышло в свет.
Про пользу комании — я лично, клал на неё. Антоха вот нет
Вы можете мне не верить, но рано или поздно вы пересмотрите этот вопрос. Причем чем раньше это случится, тем успешнее будет ваша карьера (Но это не точно).
Мне тоже раньше было срать, а потом мне пришлось встать «по другую сторону баррикад». Cобрать команду, возглавить разработку, поработать CTO.
Сейчас я снова работаю разработчиком. И не потому что меня уволили, менеджеры идиоты или я не справился с обязанностями, а потому что я люблю эту профессию и пока еще не «напрограммировался».
Но в отличие от меня старого, моя картина мира существенным образом изменилась и сейчас мне не срать, чего и вам желаю… И если вы не верите мне, почитайте хотя бы книги которые я давал выше. Они написаны людьми которые в профессии гораздо дольше вас и меня. Поверьте, они знают о чем пишут. Вы не раз найдете там себя…
Вы знаете, надо быть очень сильным синьором, чтобы так качественно и целенаправленно цеплять людей за больные места и косить под "миллениала в кедах".
То что статья написана с целью вызвать ещё один срачик (как и прошлые) — очевидно.
Так не бывает, конечно. Но если бы у меня была кнопка — снизить градус агрессии в коментах, я бы давил на нее не переставая.
Потому что даже когда очевидный хейтер приходит в одну мою статью за другой, что бы написать, что я идиот — это всё равно неприятно.
Под этой статьёй норм коментов хотелось особенно сильно.
Для меня это очень важные вопросы — типизация, бизнес, который никогда не даёт бюджета на тех. таски — я живу с этим каждый день.
Хуже всего то, что это я убедил Антоху сделать его таск по серьёзному. И. когда он ушёл с работы, я же его убедил написать об этом.
В принципе, если бы я работал над статьей один — чёрта с два бы стал оправдываться, и убеждать кого-то в чём-то в коментариях.
Понимаете, из ваших статей рисуется образ человека, который собрал в своей карьере все возможные грабли, которые мог собрать разработчик, включая граблю непризнанного гения. Мне сложно поверить, что так бывает, это выглядит как собирательный образ, созданный человеком (или группой людей), которые очень хорошо понимают какие грабли бывают и куда надо давить. Думаю, не только мне, отсюда и теории заговора у людей.
Не знаю, насколько уместно говорить про себя, что ты горишь разработкой, но я точно не горю ничем другим. И вряд ли смогу вспомнить день, когда я бы не писал какой-то код.
Ага, по будням. Причем практически все коммиты в приватные репозитории, оценить вклад не получилось. Зачем автор выложил этот скрин и указанием его активности — не понятно. С тем же успехом можно выложить активность на каком-нибудь рабочем гитлабе. А еще аккаунт гитхаба не указан в профиле у автора, но вот он.
То, что у автора на гитхабе есть хоть какая-то активность — это ж только в плюс.
Как вариант: решая рабочую задачу понимаешь, что хорошо бы иметь библиотеку для этих целей. И в личное время её пилишь, в один прекрасный момент, заменяя костыль на работе на её использование.
И в личное время её пилишь
Если это библиотека для рабочей задачи, почему бы не пилить ее в рабочее время?
Это отлично все, но зачастую можно согласовать с работодателем. И заниматься работой на работе :)
А так, во многих случаях, если просто взять, подойти и объяснить преимущества своей идеи, то и карт-бланш на её реализацию дают. По крайней мере, если объяснил понятно, а идея стоящая.
Это тоже рабочее время, но отданное взаймы. Оно вернётся, когда библиотека начнёт экономить тебе основное рабочее время.
Если бы он сделал анализ «экономического эффекта», имея численные данные, это был бы другой разговор.
Если работодатель понимает ценность чтения книг и тематических блогов и не против, то why not? Если же это самодеятельность, которую работодатель не понимает, и за которую потенциально можно получить по шапке, но очень хочется, то лучше делать это в личное время (отдавая своё время взаймы), а в случае удачи можно будет либо потратить сэкономленное рабочее время на то, что хочется тебе, либо повысить свою производительность и попросить повышения зарплаты, либо улучшить резюме и поменять работодателя.
В рабочее время решаешь задачу без библиотеки точечно. В личное генерализируешь решение, выделяешь библиотеку/фреймворк.
То, что у автора на гитхабе есть хоть какая-то активность — это ж только в плюс.
Да кто ж спорит…
Это вы ранимы, а не сообщество токсично. Или вам просто не интересно.
(а еще расхождение в дате регистрации и дате «приглашения» на сайт. Зарегестрирован на 2 года раньше чем приглашен. Ума не приложу, как такое возможно)
В этом нет ничего необычного. Например, я зарегистрирован в 2013-м году, а получил приглашение только в 2018-м. Пять лет я просто читал хабр и был read-only пользователем.
Мне поручили разработку внутренней платформенной тулзы — библиотеки для выражения программных сущностей в виде объектно-ориентированных моделей и для однообразной работы с API сервисов.
Насколько вы уверены, что с той и другой стороны правильно понимали задачу? Насколько это начинание изначально было поддеражно всей командой?
Сама задача концептуально понималась одинаково с обеих сторон. Кроме того, она была декомпозирована, согласована и прочее. Здесь была моя ошибка в неверной оценке, так как я изначально не думал делать сильную систему типов
1. Согласовали кусок работы, выбили время
2. Декомпозировали задачу, разбили на куски
3. Разраб берет первый кусок задачи, начинает делать. Находит новую идею:
«делать сильную систему типов» Начинает делать ее.
4. Сроки по куску провалены. Разраб говорит, что возникли проблемы, он их решил и следующая часть будет готова в срок. На самом деле дальше пилит идею. И вовсе не уверен в сроках, возможно даже о них не думает.
5. Результат: ничего не сделано или сделано не то, о чем договаривались или сделано больше чем то, о чем договариваись
6. Тимлид думает, что его обманули, разработчик, что его идею недооценили.
Софт скил для менеджера заключался в том, чтобы устранить проблему и договориться после фейла первой части, если задача декомпозирована (Если не декомпозирована, то это тоже проблема). Софт скил разраба здесь в том, чтобы постараться понятно объяснить для чего он делает и почему и если с ним сразу не согласились, то не делать этого, пока все не согласятся.
Полезность решения выношу за скобки. Тяжело решить насколько решение уместно без мнения второй стороны.
Вообще, если исходить из рассказа, то там человек регулярно объяснял, чем он конкретно занимается, но его особо не слушал никто.
А так, если он сказал, что "я типы пилю за тем-то и затем-то" и регулярно так отчитывался и всех все устраивало в процессе — можно считать что решение было согласовано, по факту.
Но я начал делать так, как считал правильным. На дейли я рассказывал, что и зачем делаю, но меня в принципе никто не понимал. Мои вопросы команде касательно возникшей проблемы всегда оставались без ответа. Меня словно и не существовало. Чувак, который делает что-то очень сложное и непонятное.
Но когда я что-то заливал в репозиторий, никто не мог понять, «что там еще за сложные типы». Я объяснял на дейли снова и снова, но натыкался на полный игнор. Энтузиазм и вера в правоту настолько придавали сил, что был почти уверен — скоро результат переломит недопонимание. Наконец в репо заглянул лид, и увидев там только типы, посчитал, что я нихера не делаю
Хрен знает, чем он слушал на дейли.
Выглядит не сильно убедительно. То есть я сказал, и дальше ваша проблема, что вы меня не слушаете и что вы поняли. Может быть нужно в этот момент оставновиться, согласовать действия с лидом? Я сильно сомневаюсь, что цель лида помешать расти прекрасным и универсальным инструменам любой ценой и душить мотивацию сотрудников на корню.
При этом вопросы и к лиду тоже есть, почему он не был в курсе процесса по задаче? Почему он не знал, что в рамках задачи нужно сделать и почему сейчас что-то другое делается?
Поэтому, вместо узкозаточенной либы, на которую стоял таск, мы решили делать гораздо более мощную и абстрактную — подходящую для всего.И мы невероятно верили в свою правоту, потому что только так и создаются по-настоящему хорошие вещиМне тимлид как-то раз пояснил, что нужно рационально тратить свой ресурс. Решать поставленную задачу кратчайшим способом. Всегда если просят что-то, надо именно это и делать. Только тогда заказчик будет тебе доверять. И не пытаться сделать что-то другое. Если просят сделать автомобиль — не нужно делать фабрику по изготовлению автомобилей. Если просят табличку эксель — нужно сделать табличку эксель. Нужно снизойти до уровня технического понимания заказчика и решать его проблему доступным, понятным ему способом.
Да, это сильно бьет по самолюбию, очень сильно. Но когда нас нанимали на работу, самолюбие в требования не входило. Вот и надо оставлять его дома. Это не значит, что нужно «забить» и превратиться в «зомби 9-17». Не надо терять интерес к своей работе, нужно просто делать, то что просят и делать это хорошо. Т.е. чтобы заказчик был доволен.
Я руководствуюсь вопросом: а что будет если меня завтра снимут с проекта — сможет кто-то продолжить то, что я делаю без моей помощи? И сколько из того, что я сделал уже работает. Т.е. как можно чаще выкатывать value. Чтобы после меня осталось «доделывать» как можно меньше. Я плохо себя чувствую когда мой код не интегрирован в продукт. Он не приносит пользы. Код, как деньги — должен работать, а не лежать на диске. Чем длинее становится «резинка» оттягивающая интеграцию «пользы» в продукт, тем неуютнее я себя чувствую.
И этим же ощущением обуславливается поиск технических решений. Не «лучшее», а «достаточно хорошее, которое как можно скорее можно запустить, чтобы оно начало приносить пользу». Сначала решаем проблему бизнеса кратчайшим путем, таким образом получая свободное пространство для творчества, и тогда уже делаем офигенно. Чтобы уже что-то крутилось. Ведь в программировании так же — сперва — лишь бы работало, а потом рефакторинг.
У нас на проекте тоже есть интерфейс, который написал умный архитектор. Интерфейс решает много проблем. Им удобно пользоваться. Но вот только кроме него никто полностью не понимает тонкостей внутреннего устройства этого интерфейса. Т.е. как только у тебя нештатная ситуация, а он в отпуске — все, приплыли. Пишем костыли. Тратим кучу времени на дебаг того в чем не разбираемся, потому что не должны. Ведь интерфейсы должны просто работать. Только и в них могут возникнуть ошибки. И тогда все прелести сразу перекрываются одним недостатком — сложно. Слишком умно. Недоступно среднестатистическому разработчику. Заумно. А когда работает, конечно — ну чудесно, гениально.
«Лучшее — враг хорошего», не зря говорят.
Мне тимлид как-то раз пояснил, что нужно рационально тратить свой ресурс. Решать поставленную задачу кратчайшим способом. Всегда если просят что-то, надо именно это и делать.
Это верное утверждение для джуна, но не верное для мидла и выше.
Профессионал от новичка отличается в частности тем, что понимает куда будет двигаться проект с большой вероятностью и пишет код с учетом этого. Новичок не обладает такими знаниями, поэтому ему самодеятельность лидом и запрещается.
А НЕ на аутсорсе вполне реально предсказать куда будет двигаться проект. Возможно у вас какие-то супер особенные проекты, которые ну вообще никакому анализу не поддаются, но таких проектов доли процентов. Основная же масса без проблем позволяет роадмап на годы вперед расписать.
Реальность такова, что мы, как правило, понятия не имеем куда будет двигатъся проект.
Что же вас всех в космос то тянет?
Вам дали задачу сделать библиотеку логирования в системе (апи для фронта, аудита, генерации отчета, что угодно еще). Какое вам особенное знание о направлении движения проекта нужно? Это четкая функция системы. Условно: джун будет писать ровно так как ему скажут, мидлу дадут направление, сеньер сам может предусмотреть что надо от того же логирования.
Думаю все эти рассказы про «мне надо знать направление бизнеса», оно от банального бессилия человека понять, что ему надо делать. Вот он и прячется за софистическими формулировка о необходимости чего-то…
Как иллюстрацию к сказанному, посмотрите на проект Spring для Java. Люди делают кучу достаточно гибких решений, которые с успехом применяются в самых разных проектах.
И никто из них не говорит «дайте мне видение вашего бизнеса и только тогда я смогу написать SpringData». Это и есть инженерные решения, которые должны принимать не менеджеры, а технари которых нанимают — как именно решать поставленную задачу бизнеса.
У Pivotal свой бизнес и он спланирован.
Разработчики там пишут с учётом интересов компании. Компания решает, что надо поддерживать Kafka — пишут. Надо депрекейтить RestTemplate — будут трогать только для критических уязвимостей.
И сеньор знает, что компания через год выпускает новую библиотеку, и ему надо писать текущий код с оглядкой на будущий релиз.
Профессионал от новичка отличается в частности тем, что понимает куда будет двигаться проект с большой вероятностью и пишет код с учетом этого. Новичок не обладает такими знаниями, поэтому ему самодеятельность лидом и запрещается.
Но это зависит от позиции — исполнитель он или «архитектор системы». В статье же говориться о несоответствии: «наняли как суперсиньора с видением, чтобы он пришел и рассказал команде, как решить проблему. Так ему сказали на собесе. А теперь выставили так, что нанимали аджайлового солдата»
Но вот только кроме него никто полностью не понимает тонкостей внутреннего устройства этого интерфейса. Т.е. как только у тебя нештатная ситуация, а он в отпуске — все, приплыли. Пишем костыли.То есть лучше писать костыли чем один раз разобраться с могучим «интерфейсом»?
Иногда получается и покруче.
Построить фабрику по изготовлению кирпичей из которых будет построена фабрика по построению автомобилей.
Не знаю, свойство ли это русских разработчиков или разработчиков вообще, но зачастую люди пытаются решать задачу глобально, чтобы решить не задачу, а целый класс задач. Цель грандиозная и потому сложно реализуемая, особенно в ограниченном интервале времени.
Есть старый такой принцип «Мыслить глобально, действовать — локально». Ребятам бы проработать концепцию, спланировать, так сказать, машиностроение. Затем, с учетом этой концепции сделать машинку (вот просто ту либу, что заказчик заказал), таким образом доказать что концепция работает (хотя бы вот в этом частном случае), получить за это деньги, а затем доработать и расширить функционал, реализовав свою концепцию полностью
А теперь им надо реализовывать свою концепцию заново, с нуля, без бюджета и так далее. Доказывать что оно внедряемо и работоспособно. Нелегко будет им. Удачи, сил и терпения.
Вышеперечисленное — ИМХО конечно.
Да, мы все еще хотим ее доделать и заопенсорсить. В ней еще довольно много работы и скорей всего придется переосмыслить дизайн в некоторой части.
Может быть сначала ее нужно заопенсорсить, а потом доделывать?
Может быть. Но я считаю, что сначала должна быть выражена главная идея инструмента, а для этого должна существовать возможность использования этого инструмента. Сейчас это может зайти как учебное пособие по тс, так как много практик по использованию системы типов тс. Но, конечно, мое мнение не догма и я рассматриваю вариант более скорой публикации репозитория
Но вы упорно продолжаете стоять на своём и доказывать свою правоту. Эта статья и вы сквозите налётом очень высокого о себе мнения и считаете всех вокруг идиотами, это заметно и в статье и в комментариях.
Знаете, если вы не измените своё отношение не только к этой ситуации, но и в общем и не сделаете выводов — ваш ждёт неминуемое наказание. Жизнь очень хорошо умеет ставить на колени тех, кто не умеет слушать и делать выводы.
Дальше можно было не читать. :D
А вообще выкручивать руки другим разработчикам — так себе идея.
честно скажу, под конец статьи, где-то на 70%, продираться стало сложно.
Я правильно понимаю, что вы переизобрели io-ts?
Если да — то не очень круто. Не потому что хуже или лучше, а потому что io-ts основывается на fp-ts, который основывается на fantasy-land (хотя и чуть отходит от него), спецификации, которая описывает взаимодействие алгебраических структур на JS. Иначе говоря, обеспечивает совместимость кучи библиотек.
Если нет — готов признать, что не осилил статью
Вот от такого действительно разрывает шаблоны)
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’>;
}
не, изобрели динамическую валидацию при стёртых типах, которая слабо похожа на что там в SOAP. Приятно видеть что эта маленькая функция которую очень кратко можно написать для питона с валидацией по типам, полям и т.п. — это «самый полезный код», ребята что же вы намриер про трейс исполнения кода по строкам в Питоне то скажите…
А потом да, говнокодищеес большой буквы Г)))
странно подтверждает эмпирический закон что то не напишешь на JS получишь быдлокод)))
из пустого в порожнее темплейты, потом слишком специализированный код для видители робота )))
ребята, кидайте обязательно этот код в резюме!!!
1) Дубасит грушу, на которой висит портрет ненавистного менеджера, который не даёт бедному дитятке играться в свои игрушки за деньги компании.
2) Пишет лютый велосипед, переизобретая давно известные вещи. Ок, возможно в нерабочее время, но см. пункт 1.
пережил один из самых вопиющих кейсов в своей карьере.
Почему не «случаев»?
Компания поатит работникам не за результаты работы
Компания платя работникам, надеятся что они выдадут результаты, которыми она сможет распоряжаться. Но это лишь надежда, по сути инвестиция.
Строго говоря, верно и то, и другое, в зависимости от уровня занудства, с которым вы подошли к формулировке вопроса :)
DrPass, с точки зрения политэкономии труда, зарплата — это плата за рабочую силу — авансовая. Т.е. это плата не за результат, а за возможность человека совершать работу определенного вида и квалификации (при этом это не значит, что он будет ее совершать). Аналогия с поездом — негодная, потому что покупая билет, вы покупаете услугу, оплачиваете её, потребляемую вами, полностью, а покупая рабочую силу (платя ЗП) вы оплачиваете рабочую силу работников, а не результат труда этих работников. На разнице цены результата и рабочей силы «вот на эти два процента капитализм и живет».
Но это с т.з. марксовой политэкономии.
Так, просто пояснение к диалогу выше.
История, типичная для растущего программиста. "Болезнь роста" называется. Создание программ — производственный процесс, зачастую превращаемый программистом в творческий. Это порождает конфликты. Проблемы те же, что были 30 лет назад у тогдашних девелоперов. По опыту общения с программистами мэйнстримов в крупных госконторах знаю, что все примочки, а также "волшебные палочки", многократно ускоряющие разработки, тесты ПО, контрольные примеры и т.д. и т.п. (фактически, инструментарий девелопера), разрабатываются в свободное от работы время. Профессионалам это знакомо. Ну, а производственный процесс — это священная корова и ею рисковать нельзя.
При разработке важно охватить разнообразие входящей информации, классифицировать ее на типы, и эта классификация неизбежно отразится на внутренней структуре ПО. Отсюда обобщение кода и типизация идут на последующих этапах. Об этом многие тут писали.
Крик души авторов де факто посвящен их попытке оптимизации кода параллельно с разработкой, чего делать нельзя. И это опять же болезнь роста девелопера. Надо было идти дальше — писать говнокод, но разбивать его на модули/либы с мыслью последующей замены их на более продвинутые.
Надо было задуматься о ОТДЕЛЬНОЙ разработке новой системы, которую можно было бы по частям использовать в работе над похожими проектами или над этим же, но на последующих этапах. Об этом тоже здесь писали.
В общем этот случай очень напоминает историю "разностной машины" Бэббиджа, которая так и не была построена полностью.
И напоследок пару почти анекдотов о говнокоде. В 90е годы шла дискуссия в компьютерных изданиях о том, на каких языках лучше писать прикладное ПО. Несмотря на приоритет С во множестве мнений, помню автора, который писал, что ПО для решения множества задач (того времени), связанных с базами данных, он многократно разрабатывал на одном из диалектов BASIC и клиента это полностью устраивало.
И еще был свидетелем удивления заказчика, нацеленного на красивую, большую программу с навороченным интерфейсом, когда оказалось, что задача, поставленная им, легко и быстро (за 1-2 вечера за счет времени отдыха, поскольку основную работу никто не отменял) решилась разработкой таблицей Excel с той же функциональностью.
Мораль: 1 — производственный процесс надо уважать, как и лидов и манагеров всех уровней; 2 — ОЧЕНЬ СИЛЬНО ценить полученные возможности по доступу к разнообразию входной информации, чего никто и ни при каких обстоятельствах не будет иметь, находясь ВНЕ организации заказчика (именно этот доступ дает возможность учиться девелоперу); 2 — все примочки делать ТОЛЬКО в личное время; 3 — не афишировать заранее и не манить лидов и менеджеров еще не выращенной морковкой; 4 — тем временем структурировать говнокод под свои будущие магические софтгаджеты и либы; 5 — главное, чтобы говнокод, пусть даже временный, работал НАДЕЖНО — это устроит всех, потому что магическая "кухня" девелопера со всяческими чудесами, на самом деле нужно ТОЛЬКО ему, что ускорить разработку похожих задач; 6 — говнокод не приносит ощущения собственной гениальности, элитарности, но может сильно экономить время, которое можно потратить на: а) творчество; б) на доп. подработку; 7 — описанные хождения авторов по мукам на самом деле относятся к оптимизации, а место оптимизации д.б. не первым; 8 — код, написанный однажды, не должен уничтожаться ни при каких..., а должен тщательно документироваться и складываться в архив (никто не знает, что будет потом — приходилось возвращаться к старым находкам, чтобы ускорить новые разработки); 9 — как многие писали, код должен решать поставленные задачи, но не быть избыточным, и это касается и внутренней структуры кода и его внутренней функциональности. В самом деле лучшее враг хорошего
Опять же ошибка роста. Но общеизвестно, кто именно никогда не ошибается.
Антоху наняли как суперсиньора с видением, чтобы он пришел и рассказал команде, как решить проблему. Так ему сказали на собесе. А теперь выставили так, что нанимали аджайлового солдата, который должен пилить в срок, что скажут.
В контракте-то что написано, к чему крокодиловы слезы?
1. > <много умных слов не имеющих вместе никакого смысла> То есть, инструмента для взаимодействия с данными, которые ходят от источника к отображению и обратно.
Что за взаимодействие такое? Какие проблемы требовалось решить?
2. Вы делали какую-то фундаментальную для всего фронта вещь.
> Антоху наняли как суперсиньора с видением, чтобы он пришел и рассказал команде, как решить проблему.
Кто нанимал? Почему на выходе работу курировал линейный тимлид а не условный CTO? Почему вы не убедились сначала что он в курсе что вы делаете?
3. Ничего не сказано про процесс внедрения. Было какое-то приложение в котором вы проверяли свои идеи? Они работали? Откуда брались вводные для всех изменений и 24 часовых рабочих дней?
Пропущено действительно очень много, а многое упрощено.
- Говоря аналогиями, то это такой "mongoose для API". По факту задача тривиальна в рамках имплементации на js, но без качественной системы типов это бессмысленно. Много умных слов — издержки формы постановки задачи.
- На самом деле это и был не линейный руководитель. Понимание назначении библиотеки было у всех, но не было понимания по системе типов. Здесь я допустил ошибку и не донес представление о сложностях реализации системы типов с ts.
- Внедрения не было, я до него не добрался. Проверка идей проводилась как в рамках бизнес-приложений, так и в изолированной среде (проверка системы типов). Функциональная часть в большей степени была задекларирована перед разработкой, в период анализа и декомпозиции задачи. Изменения были минимальны. А вот в отношении системы типов пришлось исследовать возможности ts, вырабатывать практики. То есть мы делали ровно то, что требовалось, но с типизацией компайл-тайм. И эта типизация сожрала нам весь бюджет.
Так и не понял что там у вас за проблемы такие фундаментальные с типами. Вы смотрели ссылку, что я привёл?
3. Так проверяемые приложения получалось портировать на эту бибилотеку или нет? После этого появлялся список ошибок в использовании которые пропускались в компайлтайме? Он не устраивал вас или руководителя?
- Есть система типов языка и система типов библиотеки. Это несколько разные вещи. Ко второй, например, относится сама схема. Т.е. это типы, используемые в библиотеке и поставляемые ей. Такие типы и их взаимодействие — система типов библиотеки. Это здесь и имелось ввиду.
- Библиотека не была реализована в полной мере. Были задекларированы типы. В части типов и минимально готового функционала были произведены проверки. Конечно, промежуточный результат меня не мог устраивать.
Поэтому, такие масштабные решения нужно внедрять только по предварительному согласию руководства. Т.е. разработать основную концепцию, сделать презентацию, получить фидбек, доработать концепцию, сделать презентацию,… (и так несколько раз), и только в том случае, если бизнес руководство поймет и поддержит ваше предложение и выделит средства, можно приступать непосредственно к реализации.
Иначе, если вы не сможете убедить руководство вначале, то вы (как говорилось вначале: в большинстве случаев) не сможете его убедить никогда и ваш труд выбросят на свалку (вместе с вами).
После прочтения первых абзацев, я долго искал ссылку на оригинал статьи, и не мог поверить, что родной русский может быть настолько американским.
Мы написали самый полезный код в своей жизни, но его выкинули на помойку. Вместе с нами