Здравствуйте, меня зовут Дмитрий Карловский, и я.. многим тут больше известен как автор фреймворка $mol, названного так в честь моего маленького друга - доллара, так как позволяет здорово экономить деньги при разработке больших проектов. Но сегодня речь не о нём, а о том, как мы, программисты, осознано или нет обманываем бизнес, вынуждая его тратить много денег ради мизерного выхлопа. Можете глянуть видео запись..
А можете почитать несколько расширенную текстовую расшифровку с более выверенными формулировками..
Какая компания?
Я почти 30 лет в программировании, из них 20 занимаюсь этим профессионально. Вот наиболее известные компании, где я работал..
Кто узнал себя в этом списке? Надеюсь, вы меня не побьёте, так как далее я буду нас сильно ругать. На всякий случай всё же запаситесь огнетушителем.
Какая фронтенд-технология?
Работал я профессионально как с различными noname велосипедами, так и с довольно известными технологиями..
Это конечно далеко не всё, с чем я знаком, это лишь то, за работу с чем мне платили деньги.
Кто не узнал себя в этом списке? Значит мы крутимся в разных экосистемах, и нам с вами будет о чём поговорить.
Какой левел?
Прошёл я путь по карьерной лестнице от джуна, который простые вещи делает сложным способом, а сложные не может сделать вообще, до синьора, который сложные вещи делает простым способом, а простые делать просто лень. А уперевшись в стеклянный потолок, занялся своими проектами, которые делаю так, как считаю правильным, тогда, когда есть для этого настроение.
Есть ли тут джуны? Надеюсь, мой рассказ не отпугнёт вас от желания пройти весь этот путь.
А есть ли мидлы? Вы каждый день крутитесь во всём этом дикообразии, так что прошу прощения, если у вас возникнут вьетнамские флешбеки.
А есть ли синьоры? Очень приятно, что меня пришли послушать и серьёзные ребята.
Что любят программисты?
Конечно же писать свои велосипеды!
Это просто интересно.
Это даёт саморазвитие.
Это развивает прогресс.
Это тешит самолюбие.
Все самые крутые разработки когда-то были просто наколеночными велосипедами талантливых людей, которые они не бросили, а улучшали, попутно повышая и свою экспертизу.
Чего боится бизнес?
Конечно же наших самописных велосипедов!
Часто имеют низкое качество.
Требуют много времени для доведения до ума.
Привязаны к автору.
Потратив кучу времени на разработку и вылизывание, автор велосипеда может покинуть проект и тогда бизнес остаётся у разбитого корыта. Новый программист смотрит на всё это, говорит "это невозможно поддерживать, надо всё переписывать", и.. пилит новый велосипед. И так несколько кругов, пока не будет создан такой велосипед, который никому не захочется переписывать. Ну или пока либо ишак не сдохнет, либо падишах. Но не будем о грустном..
Как бизнес закручивает гайки?
Требует коробочные решения.
Верит большим корпорациям.
Следует за рынком труда.
Давайте обсудим эти чаянья, но сперва разберёмся с уровнями абстракций..
Какие бывают решения?
Я выделяю 4 уровня решений помимо языкового..
Уровень |
Определение |
Примеры |
|---|---|---|
Библиотека |
Полный контроль над всем |
jQuery, Backbone, React |
Фреймворк |
Единые архитектурные рамки |
Angular, Vue, Ember |
Конструктор |
Сборка из готовых кирпичиков |
ExtJS, SAPUI5, $mol |
Платформа |
Подстройка под себя уже готового |
SAP, 1C, Drupal, Wordpress |
Чтобы проиллюстрировать ключевую разницу между уровнями, позвольте рассказать вам одну историю из жизни..
Зачем нужны высокоуровневые решения?
В одной компании мы разрабатывали свой фреймворк на базе React. И решили мы как-то сделать простое приложение для ведения заметок для проверки его в деле. Заняло у нас это несколько дней, но результат получился ещё не готовый к продакшену: нужны были доработки дизайна, фиксы багов и тд.
Неудовлетворённый таким положением дел, я взял свой любимый конструктор $mol и сделал аналогичное приложение за 2 часа (я засекал). И оно мало того, что было готово к продакшену, так ещё и обладало большей функциональностью. До сих пор использую его для своих личных нужд практически в первозданном виде..
Но и это ещё не конец! Тут мой коллега берёт платформу 1С и делает аналог вообще за пол часа. Казалось бы, чем выше уровень, тем быстрее разработка. Однако, необходимо признать, что получившееся приложение выглядело так себе, было не удобным, но самое страшное - не хватало некоторых фич, которые платформа не поддерживала вообще. Добавление оных, если и было возможно, то потребовало бы куда больше времени, чем мы сэкономили на использовании более высокоуровневого решения.
Ключевой вывод из этой истории: чем выше уровень решения, тем быстрее вы выполняете типовые задачи, но кастомизации зачастую даются с большим трудом. Зачастую, но не всегда. И $mol тут редкостное исключение, ведь проектировался он мной под простоту кастомизации без компромиссов со скоростью разработки.
Большие компании плохого не посоветуют?
На одном уровне абстракции слишком много решений. Какое же выбрать? Конечно же мы отдаём предпочтение крупным корпорациям с кучей бабла. Мы ожидаем, что большая компания потратила кучу времени и денег, чтобы проверить все варианты архитектур, выбрала наилучший из них, отполировала и представила общественности.
Ага, конечно. Возьмём историю с React. Когда FaceBook выпустила его в свет и распиарила на весь мир как серебряную пулю, в самой этой социальной сети React ещё не использовался. И только когда куча компаний на него подсела, набила всевозможных шишек, переписала несколько раз с свои приложения, только тогда в самом FaceBook начали появляться части написанные на React. Спасибо за бета-тест, как говорится.
Особую пикантность этой истории придаёт тот факт, что FaceBook, не смотря на кучу бабла и людей, является технологически весьма простым приложением. А вот, например, Яндекс - куда более крупный. Ведь это сотни проектов, которые должны быть выполнены в едином стиле, и по максимуму использовать наработки друг друга.
Для решения проблем, которые есть лишь в по настоящему крупных проектах, у Яндекса был даже разработан свой фреймворк - BEM. Я работал в Яндексе как раз, когда он только зарождался, так что прекрасно понимаю проблемы, которые он решал. Но уже в тот момент его подходы были весьма консервативными, а на текущий момент они и вовсе устаревшие.
По хорошему, его надо было бы осовременить, и тогда получилось бы что-то типа $mol. Фактически кроме BEM и $mol сейчас нет ни одного решения, которое бы действительно решало проблемы большого энтерпрайза, а не просто выглядело как энтерпрайз (привет, Angular).
Но, под давлением ситуации на рынке труда, где любой войтивайти, выучивший за месяц, как писать шаблоны на JSX, пишет у себя в резюме Senior React Developer, Яндекс отказался от своего решения в пользу React. Вы только гляньте, как разработчики буквально резали свою архитектуру по живому, чтобы хоть как-то приспособить React под свои нужды:
Получается абсурдная ситуация: технологически маленькая экстремистская компания FaceBook диктует огромному православному Яндексу как писать код. И ладно бы диктовала что-то хорошее. Но нет, код только деградирует. А ведь именно такие крупные компании как Яндекс имеют все возможности разрабатывать и внедрять лучшие технологические решения, двигающие индустрию вперёд. Но вместо этого.. компании поменьше ориентируются на выбор крупных компаний, и всё катится во всем известное место.
Большая компания же не убьёт свой проект?
Даже если проект приносит по меркам обычного работяги огромные суммы, то по меркам большой компании, это могут быть просто крошки на столе. Так что проект может быть легко закрыт, если менеджмент посчитает, что проект приносит недостаточно прибыли. А уж про проекты, приносящие лишь убытки, и говорить нечего.
Одним из таких проектов в своё время стал, например, AngularJS. Многие компании тогда делали свои стартапы именно на нём. И сколько же счастья было в их глазах, когда Google такой вышел и сказал, мол весь ваш только что написанный код теперь легаси, и предложил полностью переписать его на совершенно другом фреймворке с похожим названием - Angular. Что ж, спи спокойно AngularJS, ты прожил почти 6 лет.
И даже если разработчики горят проектом и хотят его дальше развивать - это не всегда возможно по лицензионным причинам. А если это ещё и закрытая разработка, то она так и умирает в недрах компании.
Так, например, случилось с моей интеграцией Angular + MobX + SuspenseAPI, позволяющей капитально снизить сложность и, как следствие, стоимость разработки на Angular.
Или с более амбициозным проектом - легковесным WYSIWYG редактором, который и для комментариев было бы не дорого затянуть, и документы на сотни страниц можно было бы редактировать с pixel-perfect выводом на печать.
Не основной бизнес - первый кандидат на оптимизацию.
Даже если разрабы горят проектом - у них нет прав.
Ну ладно, будем верить в долгую поддержку..
Хороша ли документация от большой компании?
Решения от большой компании часто сопровождаются обширной документацией, ведь она может позволить себе нанять толпу технических писателей, которые напишут много текста.
Однако, важно иметь ввиду, что по настоящему хорошая документация должна в максимально лаконичной форме быстро отвечать на возникающие у прикладника вопросы, а не вываливать на него тонны информации.
Если взять хорошее техническое решение, то оно обычно настолько просто в использовании, что зачастую достаточно краткого описания, несколько примеров, и можно идти в бой.
В переусложнённых же решениях так просто уже не разберёшься. Так что талмуды текстов, кукбуков, видеоуроков становятся жизненно необходимыми. Иначе вообще ничего сделать не получится.
Но какая бы документация ни была исчерпывающей, в ней всё равно остаются пробелы. И если решение простое, то нет проблемы заглянуть в исходники и понять "ага, во я дурак, надо делать иначе" или "ага, у вас тут бага, держите мерж-реквест". С переусложнёнными же решениями такое уже не прокатывает. Открываешь такой исходники и понимаешь, что неделю только будешь разбираться, как оно вообще работает, и ещё пару недель потребуется, чтобы исправить проблему. Ну или проще написать issue вендору и ждать с моря погоды.
Обширная !== хорошая.
Следствие переусложнённости.
Всё равно будут пробелы.
Хороша ли поддержка от большой компании?
От большой компании мы ожидаем быстрое решение возникающих проблем, ведь она же может позволить себе нанять кучу высококвалифицированных разрабов на поддержку их продукта.
Ага, держи карман шире! Случаев обратного на моём веку было много, но наиболее ярким был связанный с Angular Router, который не обновлял адрес ссылки, когда менялось значение поля, от которого он зависел.
Казалось бы, обеспечение инвариантов - это основа любой реактивной системы. Оно должно работать как часы, иначе разработка превращается в ад отладки. То есть этой проблемы не должно было быть в принципе - она не должна допускаться уже на уровне архитектуры..
Но её не просто выпустили в прод, но и чинили несколько лет, исправив лишь в 10 версии. А до тех пор пользователи плакали, а прикладные разработчики тратили кучу времени на придумывание воркэраундов, чтобы хоть как-то с этим жить, добавляя ко всем ссылкам такого рода костыли..
[routerLinkActiveOptions]="{ __hack__: [ id, mode ] }"Они писали статьи и записывали видео о проблеме, которой не должно было быть вообще. И это лишь одна из многих, ведь Angular вышел в свет крайне сырым. Обилие проблем и сложность их решения - следствие переусложнённости решения. Даже самая божественная поддержка здесь бы не справилась, а тут она вообще бесплатная.
Хороша ли платная поддержка?
Есть у меня история и про коммерческую поддержку коммерческого коробочного продукта SAPUI5 от компании SAP. Делали мы как-то на нём бэкофис для маркетологов Ленты. И вот, сделали мы интерактивную табличку на 30 строк, а она так сильно тормозит, что пользоваться этим невозможно.
Пишем в поддержку, мол "что за дела? как ускорить?". На что нам был дан потрясающей лаконичности ответ: "а вы не выводите в таблицу больше 20 строк". Прекрасно, следующий месяц мы потратили на рефакторинг с прикручиванием к табличке пагинации.
Вообще, мы здорово налетались с этим коробочным решением: пролетели по срокам, влетели на бабки, а потом ещё и разработчики все разлетелись. Показать эту табличку я вам, конечно, не могу, но могу показать вам кое-что по интереснее. Вот смотрите, табличка на 10 тысяч строк, реализованная за 10 минут предельно наивным кодом..
И она не тормозит даже без поддержки от вендора. Примерно такого обычно ожидаешь от коробочного решения от большой компании за много-много денег: чтобы ты просто сел и поехал, не думая про архитектуру, оптимизации и тп. Чтобы профессионалы своего дела продумали всё за тебя и дали лучший инструмент из возможных. А с SAP-ом у нас получилось: "Спасибо, что заплатили. Следующий. А вы мучайтесь дальше сами, отстёгивая нам взносы".
Большое комьюнити же поможет?
Ну ладно, ничто не совершенно под луной. Но у популярного решения будет и большое комьюнити, и вместе мы решим все проблемы.. Ага, как бы не так..
У специалистов на вас нет времени.
Остальные ничем вам не помогут.
Зато страдать будешь не в одиночестве.
Комьюнити поможет вам с тривиальными вопросами, ответы на которые есть в документации, если не полениться её прочитать. Но чуть менее тривиальный вопрос, и вы в жопе: в лучшем случае вам ничего не ответят, а в худшем такого насоветуют, что лучше бы молчали. Плюс вам несколько раз объяснят, какой вы дурак, раз хотите от инструмента таких странных вещей как эффективность работы, адекватное поведение в исключительных ситуациях, минимум писанины и максимум гибкости.
Ладно, наивно было бы ожидать бесплатную помощь..
Мы же наймём хорошего спеца?
Чем больше комьюнити той или иной технологии, тем проще найти специалиста на ней. Однако, одно дело искать плотника для создания табурета, и быть уверенным в результате. И совершенно другое - искать специалиста по закручиванию шурупов крестовой отвёрткой и ожидать, что собранный им табурет не развалится, когда вы на него сядете.
Много дилетантов: jQuery-программист, React-девелопер.
Мало профи: знают разные фреймворки и разные языки.
Курица или яйцо?
К сожалению, часто вместо того, чтобы выбирать технологии, основываясь на технической целесообразности, тем самым популяризируя лучшие инструменты, мы выбираем популярные технологии, в надежде, что среди сотен дилетантов найдём хоть одного профи, но при этом усложняя разработку, что требует найма всё большего числа разработчиков. А больше вакансий - это больше внимания разработчиков именно к этой технологии, ведь все хотят быть востребованными.
Разрабы учат то, что указывают в вакансиях.
Технологии выбирают по числу специалистов.
Узкий спец быстрее вольётся?
Но даже найдя разработчика, например, "на React", важно иметь ввиду, что это великое знание - на самом деле капля в море необходимого для разработки именно вашего проекта. И чем ниже уровень этой технологи, тем меньше эта капля, и тем больше надо знать вещей за её пределами. Тот же React - это просто разросшийся XML-шаблонизатор.
Отсюда вывод: лучше нанимать талантливых и опытных людей, ведь они быстро разберутся в вашем проекте и смогут его улучшить, даже если изначально и не знакомы с той технологией, которая лучше всего подошла проекту по техническим соображениям.
Что должны делать программисты?
Объяснить бизнесу последствия выбранных решений.
Провести анализ существующих коробок.
Обосновать написание своей, если остальные не годятся.
Но это долго, сложно и порой безрезультатно. Так, например, однажды меня хантили в стартап на роль техдира, чтобы я возглавил их разработку, построил архитектуру, собрал команду и вот это всё. Но наше партнёрство сорвалось с буквально такими словами: "ты просто самый звёздный кандидат, идеально нам подходишь, но мы решили делать проект на Реакт". То есть человек был готов доверить мне технический успех проекта, но не был готов доверить выбор.. шаблонизатора? Серьёзно?
Что программисты реально делают?
Программисты - люди умные и ленивые, так что они быстро смекнули лайфхак..
Берут низкоуровневую библиотеку.
Называют её UI-фреймворком.
Спокойно пилят свои велосипеды поверх.
На другом проекте как раз пилили свой MVC конструктор интерфейсов "на Реакт", где последний отвечал за отображение, которое через MobX реагировало на модель.
Так я и не понял, зачем там, собственно, нужен был Реакт, ведь через тот же MobX легко делать точечный рендеринг безо всякого Virtual DOM. Не говоря уж о том, что ещё проще, быстрее и дешевле было бы взять, высокоуровневый $mol, и за пару месяцев допилить его под свои нужды, а не решать несколько лет детские болезни в своём велосипеде.
Но, как мне не раз заявляли, "использовать не распиаренные технологии - большой финансовый и продуктовый риск".
Бизнес правда этого ждёт?
Каждый проект имеет уникальную архитектуру.
Одни и те же детские болезни в каждом проекте.
Программисты вовсе не взаимозаменяемы.
Каждый год всё переписывается под веяния моды.
Медленная разработка с отрицательным ускорением.
Прогрессирующее увеличение команд для сохранения темпа.
Вот и получается, что бизнес теряет время и деньги, пока программисты развлекаются велосипедостроением, тычась как слепые котята из стороны в сторону: вчера были классовые компоненты, сегодня - функциональные; вчера всё заворачивали в HOC-и, сегодня - внедряют Hook-и; вчера хранили состояние в MobX, сегодня - в Redux. И это всё ещё "на React".
И ладно бы новые веяния были существенно лучше. Но зачастую я вижу, как одно кривое решение меняют на.. ещё более кривое. И так каждый год под давлением хайпа меняют шило на мыло, мыло на верёвку, верёвку на гвоздь в крышку проекта.
Пользователь правда доволен?
Приложение долго грузится.
Интерфейс дико тормозит.
Аккумулятор быстро садится.
Память утекает в трубу.
Хоть за все эти наши развлечения и платит в итоге конечный пользователь, но взамен мы ему даже не можем предоставить должный уровень сервиса.
Так, например, недавно я столкнулся с Самокатом. Это food-tech стартап такой. За кучу денег наняли толпу программистов. Они взяли всё самое модное: React в качестве "кроссплатформеннго фреймворка"; ReactNative, чтобы летало на мобилках; GraphQL для эффективного общения с сервером; MobX для хранения состояния. Не знаю как последний сюда затесался. Думаю скоро на Effector перепишут, а то MobX уже выходит из моды.
И вот, открываю я их сайт, чтобы потратить купон, а через веб у них только лендинг - извольте ставить приложение. Вот тебе и "веб-фреймворк". Руки ещё не дошли, наверно, веб-фреймворк в вебе завести. Ладно, ставим приложение и.. ждём пол минуты пока оно просто запустится. Вот тебе и GraphQL, позволяющий все нужные данные вытянуть одним запросом. Тыкаем по кнопкам, а реакция от приложения поступает лишь через пару секунд с красивой.. лагающей анимацией. Вот тебе и ReactNative с рендерингом в отдельном потоке.
У меня, конечно, не последний айфон на Apple M1 Max, но реально, этот результат 4 лет разработки, чтобы показать каталог на пару десятков товаров, - никуда не годится. То чувство, когда накосячили другие, а стыдно мне. Ведь я тоже из этих, из фронтендеров. Но как пользователь я плачу всё больше и больше, ибо кейс Самоката не единичный, а тенденция.
Мы же видим эти проблемы?
Мы, программисты, уже настолько заврались, что обманываем не только бизнес, но и своих коллег, и даже самих себя. Вы только гляньте пресс-релизы от больших компаний, где они хвастаются, как хорошо оптимизировали свои приложения..
Типичный комментарий из первых же: стало медленнее, меньше функциональности, больше багов и больше потребление памяти. Ну, зато кто-то получил зарплату, и скорее всего даже премию.
Бизнес же это устраивает?
Это только в теории бизнес максимизирует доходы и минимизирует расходы. Если бы он знал, как мы транжирим бабки, он бы нас всех поувольнял. Но он ничего в этом не понимает, оценить долгосрочные финансовые последствия технических решений не способен. Так что всё, что ему остаётся, - нанимать всё больше людей.
Нет экспертизы, чтобы понять неоптимальность.
Плохие технические решения заливаются деньгами.
Однажды я работал в Райке, где мы пилили проект на JavaScript + ExtJS + собственные велосипеды. Только-только отвязали его от JSP. И тут приходит к нам новый разработчик, который очень хочет попробовать язык Dart от Google в деле. Долго ходил он обедать с техдиром, пока таки не убедил его прыгнуть в этот омут с головой.
Причём главный аргумент был, вы только не смейтесь, что в JavaScript (и как следствие в TypeScript) много разных библиотек разного качества, и приходится выбирать, а для Dart есть лишь прекрасная стандартная библиотека от Гугла, и выбирать больше не из чего.
Эта авантюра обернулась в превращение проекта в лоскутное одеяло с бандлами на десятки мегабайт. За 8 лет они вложили кучу средств в продвижение Dart, найм кучи программистов и их переобучение, перепробовали сырой Dart, PolymerDart, AngularDart, Dart + OverReact, и, наконец, пришли к TypeScript + React. На моей практике это выдался самый дорогой эксперимент, выбросивший миллионы долларов в трубу с получением в итоге тонн легаси кода, которые неизбежно придётся снова переписывать.
Как мы до этого докатились?
IT индустрия (и особенно фронтенд) растёт гораздо быстрее, чем появляются и набираются опыта таланты. Это приводит к тому, что технические решения с далеко идущими последствиями часто принимаются не профессионалами. Выбор кривых технологий приводит к большим накладным расходам, что вынуждает раздувать штат под этими непрофессионалами. В результате мы получаем людей с сомнительным опытом у руля больших кораблей. И они рулят не в светлое будущее, а куда попало.
Решения принимают люди с узким кругозором или без технического бэкграунда.
Технологии выбирают "по звёздочкам", а не по технической целесообразности.
Что же с этим всем делать?
Простого ответа у меня нет, поэтому я приглашаю вас к дискуссии. Отмечу, однако, несколько своих соображений.
В IT сильный дефицит кадров, а хороших кадров - острый дефицит. Поэтому наивно надеяться на быстрый найм, а стоит вкладываться в повышение эффективности работы существующих разработчиков. А это не только и не столько обучение. Куда важнее выбор и создание более эффективных инструментов.
Вкладываясь в инновации, в долгосрочной перспективе мы получаем конкурентное преимущество. Но тут важно не просто бежать за хайпом и пилить очередной никому не нужный кривой велосипед. А важно трезво и объективно оценивать не только технические, но и бизнес последствия технических решений. А для этого нам нужно формировать культуру технического анализа:
Перед реализацией новой фичи, составляется документ с описанием вариантов решений, анализом их сильных и слабых сторон, и обоснованием выбора одного из них. После чего проводится ревью, где другие разработчики помогают улучшить анализ, если автор что-то не учёл. И только после всего этого начинается собственно написание кода. Примеры можно найти на $mol вики.
Можно назвать это "разработкой через анализ", по аналогии с модной сейчас "разработкой через тестирование". Раньше на предложение написать тесты менеджер отвечал нам, что "сроки горят, давай потом". А потом так и не наступало, код без тестов было сложно поддерживать, а тот же менеджер приходил с претензией "почему на перекрасить кнопочку нужно 2 месяца?!?" и слушать не хотел о том, что это последствия его недальновидного решения.
Теперь же мы уже договорились и не спрашиваем про тесты, а сразу их пишем, так как все понимают, что это неотъемлемая часть разработки - понимать, что всё работает так, как задумано. Так же и анализ должен стать неотъемлемой частью разработки, чтобы мы понимали, что задумано было в наилучшем виде, и мы не потратим время зря. За всю мою двадцатилетнюю карьеру лишь в одной компании я наблюдал такую практику. И это была, внезапно, в 1С. Но хотелось бы видеть это везде.
Один Бык >> семеро бычат!
На велосипедах тандемом с бизнесом!
Но сперва хорошо подумай!
Да кто мы такие?
Как говорил один мой коллега: ты начальник - я дурак; я начальник - ты дурак.
Но позвольте напомнить вам, что вы не рабы, а интеллектуальная элита современности. Вы создаёте новые информационные миры и только вы имеете квалификацию и талант определять, как они будут работать.
Так что поднимите голову. Расправьте плечи. Честно и прямо объясните бизнесу, что это не он покупает вас как программеров лёгкого поведения, а это вы даёте ему возможность вложить в вас свои средства, чтобы заработать гораздо больше.
Но для этого он должен хотя бы не мешать вам делать своё дело хорошо. И речь не про "клац-клац и в продакшен", а про создание миров с непротиворечивой логикой, автоматизацией рутины и инновациями, двигающими индустрию по пути прогресса.
Что ещё интересного расскажешь?
habhub.hyoo.ru - мои статьи
nin-jin/slides - мои выступления
Core Dump - видео о фундаментальном
mol_news - новости гильдии гипер-дев
nin_jin - связь со мной
Ответочка
???? Хороший доклад, подняты интересные проблемы
???? Чувствуется фундаментальный подход. Но на мой взгляд, доклад был несколько про другое. Как мне показалась, скорее про проблемы в АйТи.
???? с $mol мы бы вообще эту конференцию закрыли бы
???? Отличная идея, удачи в продвижении и развитии! Все дурят бизнес, не только программисты :)
???? Прочитав тему доклада, ожидал другого содержания. Но фактическое содержание доклада было интересным
???? Так и не выкупил поинта докладчика. Кликбейт, который отвлек от других докладов.
???? Название кликбейтное, подача монотонная, по факту какой-то пиар собственной технологии вышел, а не глубокое рассуждение на заявленную тему.
???? Какой-то сюр, я вообще не понял о чем доклад
Комментарии (112)
akakoychenko
16.12.2022 11:53+7И тут приходит к нам новый разработчик, который очень хочет попробовать язык Dart от Google в деле. Долго ходил он обедать с техдиром, пока таки не убедил его прыгнуть в этот омут с головой.
СТО, который сам не наигрался ещё в технологии, и на подобное соглашается, - горе в компании.
usego
16.12.2022 12:28+19>лучше нанимать талантливых и опытных людей
Тут есть другая крайность. Талантливые и опытные люди, уже на смотревшись на взлёт и падение проектов, повзрослев, переходят в состояние "всё тлен" и не зацикливаются на фреймворках и архитектурах, а больше мыслят прототипами, наименьшими усилиями и мыслями "взлетит, тогда и будем рефакторить". А молодёжь готова именно на модном современном фигачить велосипеды любого конструктива и они будут ездить, пусть и в 5 раз медленней, чем могли бы.
А бизнес... А что бизнес? Думаете современный бизнес мыслит понятиями красот технических решений? Для бизнеса есть условная капитализация, и в эпоху печатанья денег от технических решений программистов капитализация практически не зависит. Ну выкинули мильон на велосипед, а за тем и сам велосипед, но за это время понабежало 2 мильона клиентов, никто ничего и не заметил. Программисты пьют смузи, бизнес делает байбеки, все счастливы.
akakoychenko
16.12.2022 13:00+5и в эпоху печатанья денег от технических решений программистов капитализация практически не зависит. Ну выкинули мильон на велосипед, а за тем и сам велосипед, но за это время понабежало 2 мильона клиентов
Бизнес это ж тоже, не великий и ужасный рациональный ИИ, типа того, что обыгрывает чемпионов по шахматам или го, а система из людей с различной мотивацией, убеждениями, моральными принципами, планами.
К примеру, я видел акционеров, умных логичных и молниеносно соображающих людей с крепким финансовым и маркетинговым бекграундом, которые искренее верили, что аутсорс рулит, и что после сковывающего со всех сторон, и требующего постоянных копромисов инхауса, это как новый виток развития бизнеса, новый уровень, где ресурсы безграничны, и девять женщин рождают ребенка за месяц, если только акционеры найдут деньги на эту авантюру.
Там, среди тех, кто делает байбеки и кешауты, тоже искренее хотят хороших технических решений, только вот не знают как, и могут лишь доверится нааемным работникам (или довериться не до конца, и позвать техаудит, что часто является ожесточенным рытьем, находясь в яме)usego
16.12.2022 13:49+1Техаудит бизнес интересует ровно во время дью дилидженс )) А аутсорс бизнесу приятен лёгкостью его ампутации. Какие люди, какие технические решения? Цифры в балансе - всё что бизнесу интересно. А то, что эти цифры через десятый уровень взаимосвязаны с "техникой" - мало кто видит и вообще хочет видеть. Бизнес через 5 лет продадут и это будет уже не их проблема, как оно и на чём шевелится.
akakoychenko
16.12.2022 13:57Вот видите, ту же ситуацию мы видим по разному. Но я же не зря написал "искренне верили". То есть, эти люди делали ставку на взрывное ускорение деливери за счет аутсорса, и подкрепляли ставку своими деньгами. А техаудит делали не перед продажей, а потому, что подгорело знатно от в пятый раз сорванных сроков при эеспоненциальном росте штата.
J_8
17.12.2022 15:39Как по мне тут надо внести некоторые поправки, про какой бизнес идет речь))) если про практически монополи и прочие конторы в кучей нулей в прибыли, так меня это вообще не трогает (молодцы программеры), а если под бизнесом понимается то, чего у нас собственно нет, то бизнес конечно жаль потому как ввиду отсутствия знаний он доверяет всему, что пишут в том числе на Хабре)) или говорят с высоких трибун(цифровизация наша ВСЕ))
nin-jin Автор
17.12.2022 16:03-1Чтобы конкурировать с конторами, у которых много нулей, и нужны инновации, позволяющие на порядки снижать косты.
ReadOnlySadUser
16.12.2022 13:18+15Вот смотрите, табличка на 10 тысяч строк, реализованная за 10 минут предельно наивным кодом..
Занятный прикол у этой таблички. Скролл вниз работает, ок. Но если взять ползунток справа и пролистать резко куда-нибудь в середину - я уже вот минуты 2 жду пока загрузятся строки. Причем переключил вкладку и вернулся обратно и что я вижу:
Ничего
Уверен оно дозагрузится и всё будет окей, но что-то не очень шустро оно по итогу летает. Firefox 108.
nin-jin Автор
16.12.2022 13:29-2В FF, к сожалению, сломали overflow-anchor (скачки при инерции скролла), так что приходится пока что переключаться в нём с виртуального рендеринга на ленивый.
ReadOnlySadUser
16.12.2022 14:47+23Мне кажется это слабоватым аргументом, ведь $mol позиционируется как победное решение без боли. Я, к слову, не фронтендер, и хуже того, даже не веб-разработчик, так что судить о качестве фреймворка (конструктора, если угодно) не могу. Просто прочитал статью, зацепился за одну проблему, но уверен, если копнуть, и другие всплывут.
Причём причина-таки всех мелких бед будет упираться в то, что у вас нет ресурсов на то, чтобы такие косяки исправлять, а у крупных компаний, вроде как и есть.
nin-jin Автор
16.12.2022 15:03-7Любое другое решение с адаптивной табличкой на 10к строк умрёт сразу, даже не показав вам скроллбар.
RekGRpth
16.12.2022 17:32+5https://clusterize.js.org не тормозит даже в FF
nin-jin Автор
16.12.2022 17:54-1Это не адаптивная таблица. Так-то и в $mol можно зафиксировать высоты и заэнфорсить виртуализацию. Лучше глянуть мой доклад про виртуализацию рендеринга, чтобы лучше понимать проблемы.
pavelsc
17.12.2022 04:36+17Мне кажется вы пытаетесь продать то что не нужно. Один раз высота просчитывается и фиксируется, никто в своем уме изменение размеров таблицы на лету не посчитает адекватным юзер-кейсом, кроме джуна тестера, который вчера карандаши тестировал и пришел к выводу, что гранёный плохо ощущается в *опе, лучше круглый ????
Не говоря уже о том, что 10к строк ни одно известное живое существо в нашей вселенной не воспримет. Моя задача как профессионала отговорить бизнес от технологий ради технологий, заставить 10 раз подумать. И ваше "в FF к сожалению сломали" яркий тому пример.
maxnemkov
16.12.2022 13:30+4Как бы непонятно, а что делать-то? Писать свой более лучший фреймвёрк для всего?)
nin-jin Автор
16.12.2022 13:32-6Начать стоит с повышения технической культуры в сторону выбора лучших решений.
maxnemkov
16.12.2022 16:35+8Это всё лозунги.
А на прикладном уровне вам это как видится? Поделитесь, по возможности.
nin-jin Автор
16.12.2022 16:38-3Я же целый раздел в конце этому посвятил.
maxnemkov
16.12.2022 16:46+1Перед реализацией новой фичи, составляется документ с описанием вариантов решений, анализом их сильных и слабых сторон, и обоснованием выбора одного из них. После чего проводится ревью, где другие разработчики помогают улучшить анализ, если автор что-то не учёл. И только после всего этого начинается собственно написание кода.Вы это прикладным решением называете? Извиняюсь за подробности, а кто за эти упражнения будет платить?)
nin-jin Автор
16.12.2022 16:50-1Тот же, кто платит за тесты - конечный пользователь.
maxnemkov
16.12.2022 16:58+2Я несколько сомневаюсь, что пользователь осознанно пожелает оплачивать состязания творческого коллектива в перфекционизме.
Если ваша личная практика строится именно так, то я выступаю с усредненной больничной позиции. Как ваши, вне сомнения, прекрасные порывы претворить в жизнь массово?
nin-jin Автор
16.12.2022 17:00-3А пользователя кто-то разве спрашивает? Я вам по секрету скажу, лучшие технические решения снижают косты, а не повышают.
PuerteMuerte
16.12.2022 19:06+3Проблема в том, что "стоимость поиска лучшего решения" + "стоимость реализации лучшего решения" далеко не всегда окупают экономию на костах. А ещё самое неприятное в том, что нередко все эти посиделки с поиском, анализом и обоснованными/согласованными выводами не выдают решение, которое на поверку оказывается лучшим. Это только эксплуатация покажет.
nin-jin Автор
16.12.2022 19:41+2Стоимость поиска в масштабах проекта ничтожна. И она как раз позволяет не разрабатывать своё, а взять лучшее. В отличие от более распространённого подхода: сэкономили на анализе, потом потратили кучу времени на кривой велосипед, а бизнесу сказали, что у нас всё "на Реакте".
onets
17.12.2022 07:15Это не так, зависит от глубины поиска. Я вот выбирал набор визуальных компонентов для фронта.
Быстрый поиск и анализ - это посмотреть сайт, сам набор, пошерстить доку на предмет адекватности, посмотреть примеры.
Второй уровень - почитать ишшью на гитхабе (несколько дней, неделя), поизучать исходники (месяцы?).
И третий уровень - использовать эти компоненты в реальном проекте, в течении например года, потому как не знаешь что и когда всплывает, и составить свое мнение + наткнутся на свои ишшью. Все компоненты.
Шорт лист компонентов у меня состоял из трех. Три года для продукта - это ощутимый срок. А для заказной разработки и подавно.
Так что, позволю себе гиперболу, - чтобы быть профессионалом и не обманывать бизнес надо 30 лет опыта на рекате, 30 лет на ангуляре и 30 лет на вуе. Но позвольте, это в сумме 90 лет, жизни не хватит. И 30 лет назад был дос.
maxnemkov
16.12.2022 20:06У вас прекрасная индивидуальная вселенная, Виктор Олегович позавидует.
Коммерческая разработка (в основном) редко предполагает творческие изыскания, поскольку есть ТЗ и фиксированные ресурсы на реализацию этого ТЗ в рамках договора.
Что если субъект не имеет возможности обедать своего ГД? Какую рекомендацию вы дадите в этой ситуации? Когда нет пользователя, который безропотно за всё заплатит.
markelov69
16.12.2022 13:51+10В прямых руках React + Typescript + MobX идеально подходит и справляется с 99.9% всех проектов.
nin-jin Автор
17.12.2022 05:57-7Сможете на этой связке за пол часа поднять новый бизнес процесс в компании?
usego
17.12.2022 09:55+25В атоматизации бизнес процессов компании (быстрее крупной, чем мелкой) непосредственно само программирование занимает дай бог 10% и, в конечном итоге, будут это пол часа или 2 дня - никто не заметит. И поосторожней с такими эстимейтами. По опыту - такое шапкозакидательство практически всегда выдаёт неопытность как минимум именно во внедрении.
nin-jin Автор
17.12.2022 10:59-10Ну да, подумаешь, держать штат из 2 программистов или из 32, никто не заметит.
zlat_zlat
17.12.2022 12:47+12Кажется, вы скатываетесь в агрессивную защиту. То есть ваше творение настолько эффективно, что повышает производительность программиста в 16 раз? Извините, такого в жизни не встречал пока.
nin-jin Автор
17.12.2022 13:03-10Ну вот теперь и встретили. Добро пожаловать в мир высокоуровневых решений.
s207883
17.12.2022 16:05+7Тогда почему ваше великое творение никому не известно, а 99.99% "велосипедистов" и компании предпочитают тратить на разработку в 16 раз больше времени и в 32 раза больше программистов? Этож какие деньжищи-то можно сберечь!
nin-jin Автор
17.12.2022 16:45-1А вы статью вообще не читали?
s207883
17.12.2022 19:53+6Там воды больше, чем в типичной курсовой. Не решился тратить свое время на это.
nin-jin Автор
18.12.2022 05:26+1В таком случае на комментарии можете тоже его не тратить, а то фичу до конца спринта доделать не успеете.
К слову, многие фичи на $mol деливерятся за пол часа.
s207883
18.12.2022 15:50+1Не давайте мне своих ценных(нет) советов, а я не скажу, куда вам идти.
На asp.net + vue.js я могу запулить фичу за 15 минут. Уже готовы бросить js и свой велосипед и перейти на сторону санитаров?
zlat_zlat
17.12.2022 10:58+2А такой срочности точно есть необходимость? Прямо за полчаса, к окончания митинга, чтоли?
v3shin
16.12.2022 13:58+10Вот смотрите, табличка на 10 тысяч строк, реализованная за 10 минут предельно наивным кодом..
Подергал ползунок туда-сюда. Чем дольше дергал - тем больше памяти жрала вкладка в Хроме. Тоже недоработка разработчиков браузера?
nin-jin Автор
16.12.2022 14:01По умолчанию, не используемые ресурсы автоматически очищаются. Но конкретно в этой демке данные генерируются на лету, и чтобы они не перегенерировались постоянно (что вызывало бы недоумение), для них автоочистка отключена.
LuggerFormas
16.12.2022 14:08+19Товарищ рекламную часть даже жирным выделяет! Нагло, но не продано...
nin-jin Автор
18.12.2022 13:54+3Если вы про слайды с компаниями и технологиями, то жирным выделены те, с которыми я работаю в настоящее время. На остальных слайдах жирным выделены ключевые моменты для тех, кто читает по диагонали.
1Tiger1
16.12.2022 14:45+15ну не должна реклама быть такой длинной. лаконичнее надо быть, никто же до конца не дочитал.
murkin-kot
16.12.2022 15:01+8Эмоционально видение проблемы разделяю. Но рационально автор не сумел отделить личную боль от общественной.
Общая боль состоит в неэффективности бизнеса. От этого все тормоза, неудобства и баги.
Личная боль - нарушение гармонии (в понимании автора). Да, убогие решения строят ерунду, на которой пишут "мега-супер-храм-вашего-всего". То есть бьют больно по мечте, по красоте, по идеалу, наклеивая ярлык "идеал" на кучу из отходов жизнедеятельности. Ну и рекламируя громко это изделие, разумеется, под флагом "идеальное лично для вас" (хотя меня они не знают ни на грамм, разумеется).
Раздел "что делать" так же несколько искажает реальность, а потому нереалистичен по части воплощения в жизнь.
Например:
вы не рабы, а интеллектуальная элита современности
Интеллектуальная элита современности, я уж извиняюсь, но это точно не IT. IT - это слесаря. Им поручают напилить гаек, ну и они дают стране угля именно в указанных габаритах.
Интеллектуальная элита же не даёт стране угля. Она даёт стране будущее. Какое будущее нам дали IT-шники? Нет, они лишь угля нам навалили, а дальше мы вот разгребаем все эти тормоза и баги.
Из показанного непонимания следует:
В IT сильный дефицит кадров, а хороших кадров - острый дефицит.
Понятно, что если себя причислил к интеллектуальной элите, то сразу начинаешь думать "как меня такого гениального мало".
Но в реальности кадров завались. Дефицита реально нет. Хотя есть искажённые требования к слесарям, определяемые самими слесарями с целью улучшения позиции оных слесарей на их текущем рабочем месте. Ну а причина опять та же самая - неэффективность бизнеса. Не следствие, а именно причина.
Каждый проект имеет уникальную архитектуру
И опять мимо. Названия там могут быть отличающиеся, но от общего цикла работы с данными никто из велосипедистов никуда не денется. Всегда - взять данные, передать, показать, прочитать ввод, передать, сохранить. Ну а если при этом чешут ухо пяткой, то нового от этого в проекте ничего не появляется. Или если показывают с графиками и анимацией, то суть явления "показать" от этого тоже никуда не девается.
Одни и те же детские болезни в каждом проекте.
Вот и подтверждение от автора - ничего в проектах не меняется, включая одни и те же болезни.
Но, тем не менее, автор поднял важную тему. Не беда, что не дотянул до глубин. Главное - чем больше подобных обсуждений случится, тем будет лучше. Хотя быстро уменьшающаяся карма, похоже, сильно ограничит данное направление дискуссии. А жаль. Но это тоже часть нашего неидеального мира.
DmitryKazakov8
16.12.2022 16:19+2Поддерживаю. Архитектуры и проекты в целом в подавляющем большинстве одинаковые с небольшой в масштабах приложения спецификой (для того же получения данных - REST, RPC, Socket, binary, GraphQL), которая разруливается адаптерами. Целые массивные слои (роутинг, сборка, валидация, кодогенерация, темизация, локализация, механизмы SSR, BFF) с незначительными изменениями таскаю из конторы в контору с крайне различающимся бизнес-направлением (от банков до бирж), если сделать их достаточно гибкими и фреймворконезависимыми.
И по поводу основной проблемы бизнеса тоже соглашусь, на мой взгляд это "все надо очень быстро", которая исходит из самой сути предпринимательства - вложения денег ради получения денег. Это приводит к требованиям использовать широко распространенный фреймворк, готовые библиотеки и взаимозаменяемых сотрудников, которых легко найти на рынке. И рождает требование "технари в первую очередь должны думать о бизнесе (читай - быстром росте количества фичей), а потом о своих идеалах, скорости приложений, стабильности, архитектурной согласованности, поддерживаемости". Мне это тоже доставляет личную боль как творческому человеку, и боль за результаты своего труда, потому что высокая скорость разработки приводит к формированию легаси и техдолга, которые за пару лет могут превратить проект в неподдерживаемый и нестабильный. Но с этим приходится мириться, вкладывая усилия в гибкость архитектуры, чтобы в будущем довольно просто можно было сменить одни части на другие и достаточно изолированно отрефакторить.
murkin-kot
16.12.2022 19:44Тоже поддерживаю.
взаимозаменяемых сотрудников, которых легко найти на рынке
Хотя в этом случае желание бизнеса приводит к обратным результатам. Бизнес хочет взаимозаменяемое, но он ведь не один. Все хотят взаимозаменяемое, и их много, поэтому все ищут "специалиста по ХХХ с опытом от УУУ лет". Но когда все ищут одно и тоже, то получаем дефицит. А потом, когда специалисты наелись технологией ХХХ и перепрыгнули на технологию ZZZ, она постепенно становится новой модой и бизнес теперь начинает искать спецов по ZZZ. Но их массово опять нет, опять имеем голод. И так продолжается уже лет 30.
DmitryKazakov8
16.12.2022 20:37Рынок подстраивается под популярные технологии, это нормально для всех отраслей - раньше нужны были кто работал лопатой, теперь экскаватором. Много курсов Реакта и Вью выпускают много потенциальных разработчиков. Есть временной лаг между этапами спрос-предложение-"предложение с опытом работы YYY", но не критичный на мой взгляд, и доносит до бизнеса идею что сотрудников нужно в том числе выращивать самостоятельно.
pavelsc
17.12.2022 05:11+11Я спросил на работе, хочет ли бизнес много некачественных фич - сказали нет. Но каждые недели надо что-то выпускать.
На данный момент вижу проблему в самом скраме. Ничего кроме мелких правок не укладывается в две недели скрама. Что-то более менее достойное нельзя разбить на тестируемые куски, можно либо сделать но не протестировать - такое не хотят, либо выходит такое мелкое и изолированное, что тестер не может тестировать. Ну не пишется софт настолько мелкими самостоятельными модулями.
Но пока на весь негатив по скраму один ответ - если вы не можете есть суп вилкой, вы не правильно её применяете. Гениально же.
Поэтому в программировании я теперь люблю только деньги, и то, что можно за них купить. При том что я не свитчер, всю жизнь код пишу. И кажется я теперь понимаю прикол опенсорса - ты просто не участвуешь в этом балагане, в котором испохаблен весь дух профессии и переписаны качества хорошего программиста в угоду тем, кто платит.
zlat_zlat
17.12.2022 11:02+1Бизнес врёт, это нормально. Они просто верят, что можно «много качественных фич», и поэтому не хотят некачественных. Но много-то всё равно хотят.
ApeCoder
17.12.2022 12:18+1Но каждые недели надо что-то выпускать.
по гайду продолжительность спринта не больше месяца. Также не обязательно, собственно, выпускать результат работы за спринт.
А почему это должны быть отдельные именно модули? Это ж изменения - они не обязаны быть модулями
DmitryKazakov8
18.12.2022 11:34+1Я когда ни спрашиваю "хочет ли бизнес много некачественных фич", отвечают "хотим 30% усилий которые дают 70% результата". Эта сказка качует из ума одного менеджера к другому, дает им отчитаться про "мы внедрили вот это по плану 1 неделя вместо 1 месяца, супер-топ команда и метод управления". В реальности получается костыльное минимально рабочее решение + 70% техдолга, который в геометрической прогрессии растет и сначала тормозит дальнейшую разработку, а в скором времени - блокирует. Факт, что то что таким образом написано за год надо дорабатывать еще 2 года все гонят прочь, разработчики не могут разобраться в той каше, которую из себя представляет продукт и уходят, новые нанятые какое-то время мучаются и смиряются до тех пор, пока история не повторится, внедрение фич идет медленно, менеджеры нанимают еще разработчиков и затраты растут как снежный ком, денег не хватает, клиенты и инвесторы в ярости, компания рушится.
Стандартный кейс, который встречал практически везде, где бизнес гонится за скоростью и играет "в быструю", а не "в долгую". Ситуация особенно усугубляется, если используются велосипедные решения и их разработчики становятся ключевыми, тогда скорый исход проекта в небытие еще ускорится, сколько бы строк в таблице ни выводил этот фреймворк. Исходя из этой специфики я бы все равно придерживался популярных решений (React, Vue, Angular) - так хотя бы можно отсрочить кризис в компании. Но решить его может только сам бизнес, кардинально изменив модель требований и ожиданий.
Adiutant
16.12.2022 20:24+2А интеллектуальная элита это простите кто? Nullопроизводители или Zaконодатели?)
hapcode
16.12.2022 15:19+2Заметил забавный баг в вашем приложении. Если выделять текст в строке ввода мышкой слева-направо, то все работает. Если наоборот, нет. Браузеры Chromium 110 и Safari 16. Популярные фрейворки может громоздкие и неэффективные, но там такие вещи отлажены.
Видео
nin-jin Автор
16.12.2022 15:59-5В Хроме на Винде не смог воспроизвести. Возможно это какая-то МакОС специфика. А мака у меня нет. Поэтому придётся вам использовать популярные отлаженные фреймворки, которые при обновлении текста инпута будут просто сбрасывать каретку в самый конец (поведение по умолчанию в браузерах), а не пытаться оставлять её на месте, а то и привязывать к словам, как это делает $mol.
LuggerFormas
16.12.2022 16:21+3return "" <- ?????, очень много недоумения
Попытался посмотреть что из себя это все представляет - или я чего не очень понял, но принцип минимального удивления чет не работает: все в кучу
То есть если я введу в инпуте в середину слова новую букву - каретка сбросится на конец?
>>>Watching dependencies by fact of using and automatic inclusion of the needed modules on further bundling. You don't need to write
includeandrequire. All you need is to refer instance by full name like$mol_state_argand$mol.state.arg(depending on its definition) in*.ts,*.view.ts,*.view.treeand*.jam.jsfiles. Dependencies in CSS files are looked for by entries like[mol_check_checked],[mol_check_checked=and.mol_check_checked.На этом я забросил. Очень непрозрачно, автоматизм который вреден имхо.
Попробовал нажать на f12 в примере - drawer улетел в тартарары
Чуть ниже автор предлагает Пользователю (клиенту) поотлаживать и поковыряться - и вот тут меня пробило уж совсем на неполиткорректное хи-хи
nin-jin Автор
16.12.2022 16:49То есть если я введу в инпуте в середину слова новую букву - каретка сбросится на конец?
Если измените текст программно.
автор предлагает Пользователю (клиенту) поотлаживать
Коллегам, которые строят из себя клиентов.
hapcode
16.12.2022 16:25+1Пользователи MacOS пошли нафиг). Прекрасный фреймворк. А какие проблемы с кареткой? Первый попавшийся пример на React с поиском. Ничего не сбрасывается. Даже на MacOS.
nin-jin Автор
16.12.2022 16:34-12Пользователи МакОС могут помочь с отладкой под МакОС, а не ныть, что у подаренного им айфона попсокет отваливается.
panzerfaust
16.12.2022 17:06+9В одной компании мы разрабатывали свой фреймворк на базе React. И решили мы как-то сделать простое приложение для ведения заметок для проверки его в деле. Заняло у нас это несколько дней ...
Неудовлетворённый таким положением дел, я взял свой любимый конструктор $mol и сделал аналогичное приложение за 2 часа (я засекал).
Аргументы уровня "защиты Чубакки". А если кто-то выполнит ту же задачу на реакте за 2 часа, то что? Я тоже могу сказать, что напишу парсер JSON на Kotlin за 2 часа, а на Erlang за неделю. Это вообще хоть что-то говорит об этих двух языках?
gwathedhel
16.12.2022 17:28+15Какой то поток графомании. Устал читать на десятом абзаце. Извините.
Femistoklov
18.12.2022 07:30Поддерживаю, если выкинуть $моль, останется только очевидная банальщина, про которую все в курсе давно. Всё равно что писать про проблемы рекрутинга в IT.
Refridgerator
16.12.2022 17:50+4Я искренне не понимаю, за что минусят Дмитрия. Интересные статьи, интересные мысли, интересные идеи.
GbrtR
16.12.2022 18:23+9Дмитрий молодец, минусят не за то что он делает, а то как это продаёт.
Надо понимать, что вырости из российского рынка на мировой, фактически не реально.
Люди которые конкретную работу работают, не будут затачиваться на гения-одиночку, с учётом того что все выученные знания по молу скорее всего на следующем месте работы окажутся не востребованными, так как они не смогут влиять на принятие решений по используемым технологиям. Особенно если ты вливаешься в проект не с самого начала.
Поэтому вместо того чтобы пытаться продать $мол русскоязычным разработчикам, ему либо надо вещать на англоязычную аудиторию и потом $мол вернётся в Россию с общей популярностью. Либо договорится с компанией уровня яндекса, что они переходят на его проект и позади проекта будет некоторое количество разработчиков. Ну либо найти инвестора котрый даст ему скажем 2-3 миллиона бакинских, чтобы вывести проект на новый уровень качества.
Но конечно, это если у проекта есть реальное революционное преимущество, которое позволяет повысить эффективность хотя бы на 50% или принципиальная технологическая новизна. Если нету, то ничего не поможет. Тем более что время идёт и появляются новые продукты, которые вполне могут реализовывать идеи которые присутсвовали в $мол и лишают его новизны.
Если уж хочется российский рынок окучивать, вот например он про 1С упоминает — вполне себе направление продвижения. Сделай безболезненную интеграцию с 1С, чтобы из 1С формы можно было $мол апп в три щелчка превратить. Тогда через 1С рынок в конце концов выльется и в обычный фронтенд. Или например запилить RAD для VS Code, которое будет давать скорость разработки сопостовимую с 1С или как было для десктопов с дельфи.
А если же продолжать биться говолой в стену и всё более агрессивный маркетинг вести, то закономерный результат — минуса.nin-jin Автор
16.12.2022 18:48+1
nikolas78
18.12.2022 13:55Хорошие статьи, хороший продукт! И тут где-то рядом был совет, к которому я тоже присоединюсь: взять узкое направление и прокачать его до уровня лучшего в мире. А потом уже, после завоевания популярности в этой узкой нише, расширяться в стороны.
ef_end_y
17.12.2022 07:30+3Автор напоминает чем-то dz - тот долго разрабатывал и толкал свою "вечную ос", не знаю чем все закончилось, но ничего о ней уже давно не слышал.
Refridgerator
19.12.2022 06:24Желание пропиарить свои проекты вполне естественно, и это не обязательно воспринимать как «все переходите на $mol и будет вам счастье». Я воспринимаю как «не бойтесь писать свои велосипеды и будет вам счастье, как минимум в долгосрочной перспективе». Многие популярные сейчас решения на старте были велосипедами, а некоторые из них весьма костыльными.
rm-hbr
17.12.2022 05:50+6Согласен. Часто не хватает критики вокруг технологий и инструментов которые нас окружают.
Дмитрий делает это прекрасно (слог хороший) и соответствует фразе "критикуешь - предлагай". Вот он и предлагает, но пока это слабо подхватывается. Надеюсь у него от этого руки не опускаются
san-smith
18.12.2022 08:50+3Слог может и хороший, но сюжет больно уж узнаваемо-агрессивный: во многих статьях и комментах здесь, на хабре, автор высказывался в духе "$mol — д'Артаньян, а все остальные — сами знаете кто!".
Собственно, я и статью-то открыл с мыслью «Ну-с, кого там сегодня $mol победил?».
AllexIn
18.12.2022 10:40+2Кого победил, пока не понятно.
А вот тех кого не победил уже вылезли: Mac OS, Firefox, выделение справа на лево, ну и еще мелочи.
GothicJS
16.12.2022 18:50+2Мало профи: знают разные фреймворки и разные языки
Решения принимают люди с узким кругозором или без технического бэкграунда.Вот что то здесь явно не так)
GothicJS
16.12.2022 19:09+3Тот же React - это просто разросшийся XML-шаблонизатор.
А php это просто разросшийся html-шаблонизатор.
Но наше партнёрство сорвалось с буквально такими словами: "ты просто
самый звёздный кандидат, идеально нам подходишь, но мы решили делать
проект на Реакт". То есть человек был готов доверить мне технический
успех проекта, но не был готов доверить выбор.. шаблонизатора?То есть это как удивиться тому, что стартап решили делать на php и потому не взяли звездного разраба на другом языке, так чтоли?)
saboteur_kiev
16.12.2022 20:07+13Самое интересное, что автор так и не понял что на самом деле дурит бизнес.
Не программисты дурят. Менеджеры дурят. Каждый менеджер продвигает свой проект, либо себя на более высокую позицию. И в меру своего разумения внедряет что-нибудь, на что компания выделяет деньги.
А то, что программисты получают свою ЗП, так это так принято в развитом мире.
vassabi
16.12.2022 20:19+1это да. начиная с уровня ПМа - дальше идет "внутрикорпоративная политика" :)
vis_inet
16.12.2022 21:39+2Тут мой коллега берёт платформу 1С и делает аналог вообще за пол часа
Вы не пошутили тут?
RomanistHere
16.12.2022 23:08+2Вот я фронт, вроде знаю все технологии, про которые рассказывает автор, и даже больше. Но вот абсолютно не могу понять, что за проблема тут решается. Пытался осилить офф. сайт, там в интродакшне картинка, ноль описания. Всё какие-то высокороувневые конструкторы. Кто-то что-то понял? Если да, как вы это сделали?
dagen
17.12.2022 07:32+10что за проблема тут решается
Автор продаёт вам свой велосипед, ругая чужие велосипеды.
GothicJS
17.12.2022 12:33+14Но вот абсолютно не могу понять, что за проблема тут решается.
Автор решает проблему нужности себя на рынке. Эта статья не для программистов. Она для бизнеса.
Автор по сути пытается обмануть бизнес, заявив - вот все они фигня, а я именно тот, кто вам нужен. Купите меня.rm-hbr
18.12.2022 09:22+1Не думаю что дело в бизнесе. Скорее попытки повлиять на саму фронтенд экосистему. А это уже личные нематериальные амбиции
KongEnGe
17.12.2022 11:32-2Ровно те же выводы после почти 30 лет в велосипедостроении. Спасибо за обобщения.
xammi-1
17.12.2022 14:43https://mol.hyoo.ru/#!demo=mol_list_demo_table/section=demos
виджет для выбора дат проработан слабо. Нет возможности быстрого выбора года курсором, высота поля ввода скачет при переключении месяца.nin-jin Автор
17.12.2022 14:44-1Что значит "быстрый выбор года курсором"? Не накликать мышью? Так это не быстро. Быстрее ввести 4 цифры.
Убрал автоматический выбор числа недель в календаре, теперь будет фиксированная высота на 6 недель.
SergeyDeryabin
17.12.2022 20:44+1Первый раз вижу такую противоречивую статью на Хабре. 26 тыс. просмотров, под 90 комментариев и рейтинг 0 ))) 52 на 52
kepatopoc
18.12.2022 01:53+1Прогресс движется к тому, что большая часть сегодняшних айтишников будет не нужна, потому что делают одно и тоже.
Называть всех тех, кто создаёт "информационные миры" - "интеллектуальной элитой современности " не совсем корректно. Одно дело код уметь писать, какой бы он эффективный не был, а другое - быть интеллектуалом. Единицы задумываются о реальных проблемах и как-то пытаются с ними работать. Большинство получают хорошую ЗП и закрывают свои потребности. Зачем им делать свою работу лучше, если это приведёт к их сокращению? Не все готовы сделать еще один шаг на уровень выше, чтобы оставаться востребованными.
С другой стороны сам бизнес работает по своим правилам. Бизнесу не нужен ваш супергибкий фреймворк, который работает в сотни раз лучше и быстрее аналогов. Ему нужно конкретное решение текущей проблемы с поддержкой этого решения. Да, бизнес чаще всего переплачивает за это, но получает рабочее решение. Взять всё переписать, чтобы получить профит - идея конечно хорошая, но чаще не реализуемая.
Есть огромное количество накопившихся системных проблем, которые просто решить не получится. Нужны фундаментальные изменения в подходах к разработке и организации информационных систем, включая работу с персональными данными. Хорошо бы всё переписывать, но другой вопрос - как это должно выглядеть, чтобы могло эволюционно развиваться в течении следующих десятков лет. А то каждый раз всё переписывать - слишком дорогая затея. IT сегодня находится во власти корпораций и пока так будет особых изменений можно не ждать, так как они не заинтересованы в эффективности \ выгодности для конечного потребителя своих услуг.
vasyapupkin835
18.12.2022 05:37+5Я один такой невнимательный, что не рассмотрел плашку "на правах рекламы"?
Dmitry89
18.12.2022 12:55Программисты дурят бизнес (в лице менеджеров);
Бизнес (в лице менеджеров) дурит клиента;
Клиенты дурят бизнес (через программистов);
GOTO 1
Впрочем, ничего нового.
AllexIn
18.12.2022 16:40+2Забавно. У большинства комментариев критикующих статью, автора или mol - ровно один минус.
Интересно
c_kotik
Ой как хитро - тегнуть ангулар, реакт, от души набросить на них и пропихивать втихаря мол...
ky0
Втихаря?! :) Это же тот случай, когда можно понять тему статьи по КДПВ с фоткой автора. Бла-бла-бла, мол, бла-бла, мол, бла…
c_kotik
бла-бла-$mol - это профессия такая?)
Pyreshka
Тогда уж для справедливости давай статью про то "как бизнес дурит пролитариат и весь остальной мир". С волками по волчьи, кодеры как представители умственного класса пролитариата это понимают лучше других.
Lizdroz
Это статус такой. Судя по доллару, ещё и престижный.