JavaScript
Perfect code
Designing and refactoring
API
TypeScript
Comments 258
+23
Т. е. вы за деньги бизнеса заново изобрели SOAP/WSDL с квадратными колесами?
+20

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


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

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

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

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

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

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


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

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

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

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


1

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

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

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


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

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

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

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


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

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

+1

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

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

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

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

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

0

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

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

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

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


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

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

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

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

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

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

0

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

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

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

UFO landed and left these words here
+1

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

+4

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

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

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

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

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

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

UFO landed and left these words here
+36
Статья — поразительный памятник трудолюбию и невежеству. Изобрести xsd в 2019 году — это сильно.
-9

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

+1

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


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

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

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

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

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

0

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

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

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


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

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


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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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


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

+3

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

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

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

+2

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

0

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

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

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

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

-2

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

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

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


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

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


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

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

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

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

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


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


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

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

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

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

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

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


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

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

0

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

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

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

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

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

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

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

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

0

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


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

0

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

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

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

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

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

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

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

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

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

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

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

Из минусов:


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

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

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

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

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

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

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

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

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

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

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

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

0

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

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

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

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

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

0

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


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

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

+1

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

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

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

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

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

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

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

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

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

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

UFO landed and left these words here
+2
Фил с Антохой разрабы. Где работают, не скрывают, и кучу людей ваша конспирология только посмешит. А про тексты ради заработка поржут уже менеджеры, которые им зарплаты выписывают.

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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


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

+1

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

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

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

0

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


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

0

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

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

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

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

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

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

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

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

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


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

0

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

0

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

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


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

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

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

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

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

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

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


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


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

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

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


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

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

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

+1

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

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


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

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

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

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

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

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

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


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

Да, это сильно бьет по самолюбию, очень сильно. Но когда нас нанимали на работу, самолюбие в требования не входило. Вот и надо оставлять его дома. Это не значит, что нужно «забить» и превратиться в «зомби 9-17». Не надо терять интерес к своей работе, нужно просто делать, то что просят и делать это хорошо. Т.е. чтобы заказчик был доволен.

Я руководствуюсь вопросом: а что будет если меня завтра снимут с проекта — сможет кто-то продолжить то, что я делаю без моей помощи? И сколько из того, что я сделал уже работает. Т.е. как можно чаще выкатывать value. Чтобы после меня осталось «доделывать» как можно меньше. Я плохо себя чувствую когда мой код не интегрирован в продукт. Он не приносит пользы. Код, как деньги — должен работать, а не лежать на диске. Чем длинее становится «резинка» оттягивающая интеграцию «пользы» в продукт, тем неуютнее я себя чувствую.

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

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

«Лучшее — враг хорошего», не зря говорят.
+3
Но когда нас нанимали на работу, самолюбие в требования не входило. Вот и надо оставлять его дома.

Правда? И про интерес к самой технологии ничего не говорят? Про мотивацию? Про passion?


Я плохо себя чувствую когда мой код не интегрирован в продукт.

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

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

Это верное утверждение для джуна, но не верное для мидла и выше.
Профессионал от новичка отличается в частности тем, что понимает куда будет двигаться проект с большой вероятностью и пишет код с учетом этого. Новичок не обладает такими знаниями, поэтому ему самодеятельность лидом и запрещается.
+3
Реальность такова, что мы, как правило, понятия не имеем куда будет двигатъся проект. Особенно на аутсорсе. Клиенты не распространяются о планах на будущее. А их планы на будущее, в свою очередь, зависят от ситуации на рынке, которая может поменяться в любой момент, стоит конкуренту выпустить какую нибудь новую финтифлюшку. Поэтому разработка ведется по принципу локальной оптимизации. Все гибкие методологии сводятся к итеративному подходу. Не закладываться на будущее, а создавать минимальный ценный продукт, который уже будет работать здесь и сейчас. Если продать клиенту которому нужен лендинг, вместо SPA целый кастомный СМS, то это может, случайно, и окажется в будущем удачным решением, но как правило — оверинжиниринг. Тем более, технологии устаревают так быстро, что загадывать наперед, кажется вообще оторванной от жизни идеей.
+1
С аутсорсом согласен. Нужно подешевле и побыстрее сваять, поддерживать и развивать же всё равно другие будут.
А НЕ на аутсорсе вполне реально предсказать куда будет двигаться проект. Возможно у вас какие-то супер особенные проекты, которые ну вообще никакому анализу не поддаются, но таких проектов доли процентов. Основная же масса без проблем позволяет роадмап на годы вперед расписать.
0

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

+3
Реальность такова, что мы, как правило, понятия не имеем куда будет двигатъся проект.

Что же вас всех в космос то тянет?
Вам дали задачу сделать библиотеку логирования в системе (апи для фронта, аудита, генерации отчета, что угодно еще). Какое вам особенное знание о направлении движения проекта нужно? Это четкая функция системы. Условно: джун будет писать ровно так как ему скажут, мидлу дадут направление, сеньер сам может предусмотреть что надо от того же логирования.
Думаю все эти рассказы про «мне надо знать направление бизнеса», оно от банального бессилия человека понять, что ему надо делать. Вот он и прячется за софистическими формулировка о необходимости чего-то…

Как иллюстрацию к сказанному, посмотрите на проект Spring для Java. Люди делают кучу достаточно гибких решений, которые с успехом применяются в самых разных проектах.
И никто из них не говорит «дайте мне видение вашего бизнеса и только тогда я смогу написать SpringData». Это и есть инженерные решения, которые должны принимать не менеджеры, а технари которых нанимают — как именно решать поставленную задачу бизнеса.
0
Либа как проект тоже вполне может иметь видиние перспективы развития и формулировки целей и идеалов.
0

У Pivotal свой бизнес и он спланирован.
Разработчики там пишут с учётом интересов компании. Компания решает, что надо поддерживать Kafka — пишут. Надо депрекейтить RestTemplate — будут трогать только для критических уязвимостей.
И сеньор знает, что компания через год выпускает новую библиотеку, и ему надо писать текущий код с оглядкой на будущий релиз.

+2
Утверждение верное и для мидла и выше. Разница между джуном и прочими только в том, что у джуна заточенный код будет вбит гвоздями, а у мидла и выше заточенный код будет изолирован и заменяем. Смысла писать функционал под предлогом «авось понадобится» особо нет, если только нет лишнего времени.
0
Профессионал от новичка отличается в частности тем, что понимает куда будет двигаться проект с большой вероятностью и пишет код с учетом этого. Новичок не обладает такими знаниями, поэтому ему самодеятельность лидом и запрещается.

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

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

0
Но вот только кроме него никто полностью не понимает тонкостей внутреннего устройства этого интерфейса. Т.е. как только у тебя нештатная ситуация, а он в отпуске — все, приплыли. Пишем костыли.
То есть лучше писать костыли чем один раз разобраться с могучим «интерфейсом»?
0
В энтерпрайзе на аутсорсе иногда нет времени разбираться, баг нужно пофиксить сегодня к двенадцати. Не важно какой он сложности. Точка. Может у кого-то на «шоколадных» проектах и по другому, у нас так. Или ты выполняешь поставленную задачу, или ты в следующем году можешь выбыть из числа подрядчиков и поставишь под угрозу существование всей своей фирмы, потому что этот заказчик дает больше половины оборота.
0
Только волшебники там работают? Или и сказочники тоже?
+3
Сказочники обещают сделать к двенадцати, волшебники — делают.
0
У нас тимплид такой волшебник. Он во первых знает систему вдоль и поперек, потому что стоял у ее истоков десять лет назад, и еще у него незаурядный интеллект. Может пофиксить проблему пока ты ему про нее рассказываешь. По сравнению с ним любой сениор выглядит джуниором. Такие люди большая редкость.
+1
Если просят сделать автомобиль — не нужно делать фабрику по изготовлению автомобилей.
Иногда получается и покруче.
Построить фабрику по изготовлению кирпичей из которых будет построена фабрика по построению автомобилей.
Не знаю, свойство ли это русских разработчиков или разработчиков вообще, но зачастую люди пытаются решать задачу глобально, чтобы решить не задачу, а целый класс задач. Цель грандиозная и потому сложно реализуемая, особенно в ограниченном интервале времени.
0
К сожалению иногда бывает и наоборот. Проект на Юнити, код есть и работает но… Только в редакторе. На целевой платформе (web) не работает потому что там есть свои ограничения которые необходимо (было) учитывать при разработке. Тоже потрясающий подход. Я не буду детально изучать ТЗ, я не буду задавать уточняющие вопросы, просто нафигачу код.
+1
Да нет, это опять-таки в ту же тему. «Смотрите техзадание, понимайте для кого и для чего этот код делается.»
Есть старый такой принцип «Мыслить глобально, действовать — локально». Ребятам бы проработать концепцию, спланировать, так сказать, машиностроение. Затем, с учетом этой концепции сделать машинку (вот просто ту либу, что заказчик заказал), таким образом доказать что концепция работает (хотя бы вот в этом частном случае), получить за это деньги, а затем доработать и расширить функционал, реализовав свою концепцию полностью во плоти в коде — вот тогда шансы на успех, мне кажется, были бы выше. И концепция реализована, и частный случай реализации концепции есть, овеществлен и внедрен, проверен, работает.
А теперь им надо реализовывать свою концепцию заново, с нуля, без бюджета и так далее. Доказывать что оно внедряемо и работоспособно. Нелегко будет им. Удачи, сил и терпения.
Вышеперечисленное — ИМХО конечно.
+1
Парни, вам было бы охота после отпуска погружаться опять в вашу библиотеку для внесения правок?

+1

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

+3

Может быть сначала ее нужно заопенсорсить, а потом доделывать?

+3

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

0
А в чём главная идея? Силился понять из статьи, но не смог.

Т.е. я правильно понимаю, что задача сводится к трансформации данных из одной структуры в другую? Если так, то универсальное решение — язык правил, по которым эта трансформация происходит.
+6
Авторы статьи. Вам ребята всё грамотно разъяснили и указали на ваши ошибки и обоснованно, аргументировано объяснили почему вы не правы.

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

Знаете, если вы не измените своё отношение не только к этой ситуации, но и в общем и не сделаете выводов — ваш ждёт неминуемое наказание. Жизнь очень хорошо умеет ставить на колени тех, кто не умеет слушать и делать выводы.
+2
> костыли вроде «нормализации структуры данных»

Дальше можно было не читать. :D
А вообще выкручивать руки другим разработчикам — так себе идея.
0
Это что ж за цветовая тема такая на первом скрине? Первый раз такую вижу.
0
Расширение для vscode Rainglow, поставляет кучу тем. Эта называется Vision(colorbind).
Сверхохеренная.
0

Голова болеть не начинает? У меня по опыту от такого оттенка синего глаза выжигаются очень быстро.


Solarized light получше для моих глаз.

+6
Узнал автора статьи по заголовку в блоке «читают сейчас». С поправкой на эпоху, я бы назвал его труды современной версией «Героя нашего времени». Тексты читаются легко и интересно, с содержаним согласны отнюдь не все, а зеленая молодежь (да, реально знаю таких) хочет быть похожей на героя произведения.
0
Готовых решений валидации по схеме/сериализации/десериализации/рантайм валидаций ведь для TS много. Свое начали писать потому что захотелось освоить всю мощь TS in action?
+2
Есть у нас один программист в офисе с маниакальной идеей генерировать весь js через php. Пишет свои решения практически с нуля, оперируя тем что там удобней работать с backend и не надо вникать там в какой-то frontend. Бизнес всё больше и больше просит удобный решений и кнопочек на frontend что заставляет этого разработчика делать всё больше и больше таких решений. И с недоумениям воспринимают информацию о том, что чтобы сделать такое же окно, но зелёненькое надо столько же времени, как и первый раз. Это я к чему много того что пишет программист интересует результат, а не процесс и внутренний составляющая. Зачастую кажущими нам моментами мы считаем, что улучшаем свой внутренний процесс, но всегда надо думать об этом процессе как части процесса бизнеса.
+3

честно скажу, под конец статьи, где-то на 70%, продираться стало сложно.


Я правильно понимаю, что вы переизобрели io-ts?
Если да — то не очень круто. Не потому что хуже или лучше, а потому что io-ts основывается на fp-ts, который основывается на fantasy-land (хотя и чуть отходит от него), спецификации, которая описывает взаимодействие алгебраических структур на JS. Иначе говоря, обеспечивает совместимость кучи библиотек.


Если нет — готов признать, что не осилил статью

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

Вот от такого действительно разрывает шаблоны)
+5
Дорогие авторы, вы реально считаете, что такое описание типа добавляет понимания при чтении кода? Погружаясь в сладкий мир абстракций, не забывайте, что с вашим кодом будут работать живые люди, у которых зачастую будет ограниченный запас времени и бизнес-задача в голове, отъедающая огромную часть ресурсов абстрактного мышления.

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’>;
}
-1
Мы написали самый полезный код в своей жизни,
не, изобрели динамическую валидацию при стёртых типах, которая слабо похожа на что там в SOAP. Приятно видеть что эта маленькая функция которую очень кратко можно написать для питона с валидацией по типам, полям и т.п. — это «самый полезный код», ребята что же вы намриер про трейс исполнения кода по строкам в Питоне то скажите…
А потом да, говнокодищеес большой буквы Г)))
странно подтверждает эмпирический закон что то не напишешь на JS получишь быдлокод)))
из пустого в порожнее темплейты, потом слишком специализированный код для видители робота )))
ребята, кидайте обязательно этот код в резюме!!!

+1
Как выглядит день типичного плохого программиста.
1) Дубасит грушу, на которой висит портрет ненавистного менеджера, который не даёт бедному дитятке играться в свои игрушки за деньги компании.
2) Пишет лютый велосипед, переизобретая давно известные вещи. Ок, возможно в нерабочее время, но см. пункт 1.
-1
пережил один из самых вопиющих кейсов в своей карьере.

Почему не «случаев»?
+2
«Я люблю большие корпорации..» — судя по этой фразе автор в том возрасте когда хочется изменить мир. В свое время проработал в корпорации 6 лет, насмотрелся на всякое, как людей повышают за то что спят с кем надо, как переводят в другия отделы по связям, как принимаются решения по разработке родственниками и т.д. Корпорации это точно не то место где что-то можно изменить, они поддерживают свой говнокод десятилетиями. Если и творить и рисковать так это стартапы, там можно за малое время опробовать много технологий.
+1
Отдохнул пару дней, полностью удалил все исходники библиотеки

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

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

0
Это просто риторика. Вы, покупая билет на поезд, платите за то, что вас довезут из пункта А в пункт Б, или платите в надежде, что вас довезут, инвестируя в будущее?
Строго говоря, верно и то, и другое, в зависимости от уровня занудства, с которым вы подошли к формулировке вопроса :)
0

Не риторика, а право, трудовое против гражданского (может транспортное). В гражданском вы приборетаете товар или услугу, заказываете работы у подрядчика. В случе несоблюдения им условий договора в общем случае не то что вы ему не должны, а он вам должен. В трудовом всё совсем по другому.

0
У меня в контракте, например, сказано, что авторское право на код, написанный в рабочее время, принадлежит мне. А эксклюзивное право коммерчески распоряжаться им — компании.

DrPass, с точки зрения политэкономии труда, зарплата — это плата за рабочую силу — авансовая. Т.е. это плата не за результат, а за возможность человека совершать работу определенного вида и квалификации (при этом это не значит, что он будет ее совершать). Аналогия с поездом — негодная, потому что покупая билет, вы покупаете услугу, оплачиваете её, потребляемую вами, полностью, а покупая рабочую силу (платя ЗП) вы оплачиваете рабочую силу работников, а не результат труда этих работников. На разнице цены результата и рабочей силы «вот на эти два процента капитализм и живет».
Но это с т.з. марксовой политэкономии.
Так, просто пояснение к диалогу выше.
+1
Хорошая статья, спасибо! Причем сама статья не так важна, как количество ненависти в каментах. Такого количества «хозяин лучше знает», «не высовывайся» и «ты что здесь, ..., самый умный?» я давно не видел.
-2

История, типичная для растущего программиста. "Болезнь роста" называется. Создание программ — производственный процесс, зачастую превращаемый программистом в творческий. Это порождает конфликты. Проблемы те же, что были 30 лет назад у тогдашних девелоперов. По опыту общения с программистами мэйнстримов в крупных госконторах знаю, что все примочки, а также "волшебные палочки", многократно ускоряющие разработки, тесты ПО, контрольные примеры и т.д. и т.п. (фактически, инструментарий девелопера), разрабатываются в свободное от работы время. Профессионалам это знакомо. Ну, а производственный процесс — это священная корова и ею рисковать нельзя.
При разработке важно охватить разнообразие входящей информации, классифицировать ее на типы, и эта классификация неизбежно отразится на внутренней структуре ПО. Отсюда обобщение кода и типизация идут на последующих этапах. Об этом многие тут писали.
Крик души авторов де факто посвящен их попытке оптимизации кода параллельно с разработкой, чего делать нельзя. И это опять же болезнь роста девелопера. Надо было идти дальше — писать говнокод, но разбивать его на модули/либы с мыслью последующей замены их на более продвинутые.
Надо было задуматься о ОТДЕЛЬНОЙ разработке новой системы, которую можно было бы по частям использовать в работе над похожими проектами или над этим же, но на последующих этапах. Об этом тоже здесь писали.
В общем этот случай очень напоминает историю "разностной машины" Бэббиджа, которая так и не была построена полностью.
И напоследок пару почти анекдотов о говнокоде. В 90е годы шла дискуссия в компьютерных изданиях о том, на каких языках лучше писать прикладное ПО. Несмотря на приоритет С во множестве мнений, помню автора, который писал, что ПО для решения множества задач (того времени), связанных с базами данных, он многократно разрабатывал на одном из диалектов BASIC и клиента это полностью устраивало.
И еще был свидетелем удивления заказчика, нацеленного на красивую, большую программу с навороченным интерфейсом, когда оказалось, что задача, поставленная им, легко и быстро (за 1-2 вечера за счет времени отдыха, поскольку основную работу никто не отменял) решилась разработкой таблицей Excel с той же функциональностью.
Мораль: 1 — производственный процесс надо уважать, как и лидов и манагеров всех уровней; 2 — ОЧЕНЬ СИЛЬНО ценить полученные возможности по доступу к разнообразию входной информации, чего никто и ни при каких обстоятельствах не будет иметь, находясь ВНЕ организации заказчика (именно этот доступ дает возможность учиться девелоперу); 2 — все примочки делать ТОЛЬКО в личное время; 3 — не афишировать заранее и не манить лидов и менеджеров еще не выращенной морковкой; 4 — тем временем структурировать говнокод под свои будущие магические софтгаджеты и либы; 5 — главное, чтобы говнокод, пусть даже временный, работал НАДЕЖНО — это устроит всех, потому что магическая "кухня" девелопера со всяческими чудесами, на самом деле нужно ТОЛЬКО ему, что ускорить разработку похожих задач; 6 — говнокод не приносит ощущения собственной гениальности, элитарности, но может сильно экономить время, которое можно потратить на: а) творчество; б) на доп. подработку; 7 — описанные хождения авторов по мукам на самом деле относятся к оптимизации, а место оптимизации д.б. не первым; 8 — код, написанный однажды, не должен уничтожаться ни при каких..., а должен тщательно документироваться и складываться в архив (никто не знает, что будет потом — приходилось возвращаться к старым находкам, чтобы ускорить новые разработки); 9 — как многие писали, код должен решать поставленные задачи, но не быть избыточным, и это касается и внутренней структуры кода и его внутренней функциональности. В самом деле лучшее враг хорошего
Опять же ошибка роста. Но общеизвестно, кто именно никогда не ошибается.

0
Краткое содержание статьи: «мы решили в рабочее время и за деньги работодатели разработать отвлеченную шляпу, которой можно блеснуть где-нибудь на конфе, поставить себе галочку в резюме, но работодатель почему-то не захотел оплачивать наши эксперименты. Мы думали, что если успеем в сжатый срок сделать свою систему не по спецификации, но покрывающую узкий случай, то победителей не будут судить, но не успели. Ну, да, времени было отведено на создание более простого узкого решения N часов, мы решили, что успеем за это же время склепать более сложную абстрактную систему, требующую большей проработки, мы же професеоналы. Но даже переработки не спасли. Epic Fail».

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

В контракте-то что написано, к чему крокодиловы слезы?
0
Чот в истории много пропущено.

1. > <много умных слов не имеющих вместе никакого смысла> То есть, инструмента для взаимодействия с данными, которые ходят от источника к отображению и обратно.
Что за взаимодействие такое? Какие проблемы требовалось решить?

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

Кто нанимал? Почему на выходе работу курировал линейный тимлид а не условный CTO? Почему вы не убедились сначала что он в курсе что вы делаете?

3. Ничего не сказано про процесс внедрения. Было какое-то приложение в котором вы проверяли свои идеи? Они работали? Откуда брались вводные для всех изменений и 24 часовых рабочих дней?
0

Пропущено действительно очень много, а многое упрощено.


  1. Говоря аналогиями, то это такой "mongoose для API". По факту задача тривиальна в рамках имплементации на js, но без качественной системы типов это бессмысленно. Много умных слов — издержки формы постановки задачи.
  2. На самом деле это и был не линейный руководитель. Понимание назначении библиотеки было у всех, но не было понимания по системе типов. Здесь я допустил ошибку и не донес представление о сложностях реализации системы типов с ts.
  3. Внедрения не было, я до него не добрался. Проверка идей проводилась как в рамках бизнес-приложений, так и в изолированной среде (проверка системы типов). Функциональная часть в большей степени была задекларирована перед разработкой, в период анализа и декомпозиции задачи. Изменения были минимальны. А вот в отношении системы типов пришлось исследовать возможности ts, вырабатывать практики. То есть мы делали ровно то, что требовалось, но с типизацией компайл-тайм. И эта типизация сожрала нам весь бюджет.
-1

Так и не понял что там у вас за проблемы такие фундаментальные с типами. Вы смотрели ссылку, что я привёл?

-1
2. Вы пишите бессмыслицу. Если выбран язык для бибилотеки, TS, то ситема типов зафиксирована, её не надо заново на нём реализовывать. Если Вы отчитывались с такими же формулировками, то замешательство окружающих понятно.

3. Так проверяемые приложения получалось портировать на эту бибилотеку или нет? После этого появлялся список ошибок в использовании которые пропускались в компайлтайме? Он не устраивал вас или руководителя?
0
  1. Есть система типов языка и система типов библиотеки. Это несколько разные вещи. Ко второй, например, относится сама схема. Т.е. это типы, используемые в библиотеке и поставляемые ей. Такие типы и их взаимодействие — система типов библиотеки. Это здесь и имелось ввиду.
  2. Библиотека не была реализована в полной мере. Были задекларированы типы. В части типов и минимально готового функционала были произведены проверки. Конечно, промежуточный результат меня не мог устраивать.
0
История знает очень немного случаев, когда, используя ресурсы компании, инженер втихаря занимался созданием крутых решений и потом эти решения были взяты на вооружение. В большинстве случаев, такие инжененры остаются без работы за нецелевое использование ресурсов.
Поэтому, такие масштабные решения нужно внедрять только по предварительному согласию руководства. Т.е. разработать основную концепцию, сделать презентацию, получить фидбек, доработать концепцию, сделать презентацию,… (и так несколько раз), и только в том случае, если бизнес руководство поймет и поддержит ваше предложение и выделит средства, можно приступать непосредственно к реализации.
Иначе, если вы не сможете убедить руководство вначале, то вы (как говорилось вначале: в большинстве случаев) не сможете его убедить никогда и ваш труд выбросят на свалку (вместе с вами).
Only those users with full accounts are able to leave comments. , please.