-
Зачем фронтенд? (2)
Ситуация: сломался фронтенд. Непонятная ошибка с null, код обфусцирован, сорс-мап нет, хотя это тестовое окружение.
Открываю исходник и вижу: поиск в коллекциях, парсинг чисел и дат, форматирование с учетом локали, поход в сеть и прочие штучки. И мне правда интересно — что этот код делает на фронтенде? Почему он не на бекенде? Чего ты добился, заставив этот код крутиться на клиентской машине?
Ты потерял всякую предсказуемость, потому что код выполняется уже не на сервере с линуксом и джавой фиксированных версий. У тебя зоопарк клиентов, где хромы-фаерфоксы с блокироващиками всего и вся. Ты потерял нормальные стек-трейсы. Ты потерял удобный прогон тестов. Ты потерял логирование и отправку ошибок в Sentry. Ты банально сделал хуже по всем статьям.
Звоню фронтендеру. Первое, что от него слышу — сегодня пятница, и он уходит через две минуты. Падает фронтенд? Это с бэка приходят неверные данные, почисти базу и заработает. Сорс-мапы? Тебе надо, ты и добавь. Созвониться в понедельник? У меня будет выходной. Но ты держись!
Я понимаю, что фронтендеру надо зарабатывать, да. Однако лучшее, что можно сделать с проектом — это сократить фронт до одного верстальщика и переехать на северный рендер. Вся логика будет в одном месте; будут тесты, будут прогоны на CI, будут предсказуемые билды. А верстальщик пусть рисует макеты.
Да, будет что-то, что не ложиться на серверный рендер. В таком случае мы это просто не делаем. Если из десяти хотелок мы сделали девять, а последняя ложится поперек, то ее перерабатывают. Например, бьют фичу на два экрана, убирают лишнюю интерактивность и так далее.
Кому-то это не понравится, но что поделать? Чтобы проект шел легко, нужно сбросить балласт. А роль балласта часто играет фронтенд.
-
Зачем фронтенд? (1)
Признаться, я давно потерял мысль, зачем нам фронтенд. Я имею в виду реакты-вуи, папки
node_modulesвесом в тонну, тормозной гуй и спиннеры в каждом углу.В самом деле, какую проблему мы решаем? Неужели так важно писать километры кода на js, чтобы элемент обновился динамически? Почему никто не помнит закон сохранения энергии: если на беке кода стало меньше, его станет больше на фронте? Плюс и минус схлопываются, и в лучшем случае получится то же самое. Но прибавляется энтропия, вызванная фрагментацией технологий и стеков, тулинга, языков.
Есть и другое замечание. Когда-то браузеры были медленными, и рендеринг страницы был узким местом. Даже если разметка приходила быстро, ее было трудно вывести на экран. Сайты верстали таблицами, на которых IE знатно подвисал. Поэтому Ajax казался спасением: выдернем данные в полете, не придется перезагружать страничку.
Сегодня браузеры ушли в космос: это уже почти операционные системы. Видео, дизайн, игры, офисный редактор. Если взять обычный сайт и доработать под стандарты — Etag-и, кэширование, правильная разметка, оптимизация стилей — то он будет работать мгновенно. Страницы будут открываться так быстро, что никакие аяксы не понадобятся.
Вместо того, чтобы ускорить сайт целиком, фронтендеры пишут приложения. Они как Джава — загружаются долго, но, вроде бы как, работают быстро. С оговоркой, потому что новых вкладок порой не избежать, и загружается вторая копия приложения. Со всеми этими спиннерами, загрузками и клиентским рендером.
Казалось бы, хочешь обновить кусок страницы динамически — пришли с сервера кусок разметки и вставь в нужное место. Это самый простой способ, проще невозможно. Но у фронтендера свой путь: он запрашивает данные, складывает во внутреннюю базу, подписывается на обновление базы, по событию ее изменения вызывает другое событие, которое читает базу, рендерит HTML и вставляет в документ.
Этот как налить чай не в кружку, а сначала в тазик, потом в блюдце, потом по трубочке в кувшин, а оттуда в кружку. Что ты хотел этим доказать?
Разработчики разучились мыслить критически. У всех перед глазами шоры: реакт-вуй-протобуф-кубернетис. Никто не думает, как решить задачу просто, дешево и в срок. Всем подавай бест-практис и блидинг-эдж.
-
Новый вид людей
Меня волнует, что когда-то было два вида людей: неандертальский и кроманьонский. Это именно два разных вида, а не отличие в цвете кожи или разрезе глаз. Сегодня ничего такого нет: люди всех рас отличаются незначительно (но и не абсолютно одинаковы, как любит западная повестка).
Мне бы хотелось, чтобы появился новый вид людей. Я часто их представляю: возможно, они будут жить чуть дольше; беременность будет длиться год, а не девять месяцев; их слух и зрение будут работать слегка в другом диапазоне. Возможности интеллекта не будут отличаться от нашего; будет другая система оволосения и потоотделения.
Появление конкурентов будет столь жарким событием, что ковиды и войны покажутся детским садом. Мир погрузится в истерику. Верующие найдут в Библии факты, что это потомки зверя. Военные окажутся на коне: кто как не они защитят человечество. Социальные сети лопнут от твитов и аналитики. Будет всемирная жесть.
Это будет проверка, чего мы добились за сорок тысяч лет. Я не сомневаюсь, что люди убьют конкурентов подобно тому, как кроманьонский человек убил неандертальцев.
То есть — ничего.
-
Джон и чат
Предположим, Джон не может сегодня работать. Заболела дочь, и он везет ее по врачам. Джон заходит в рабочий чат и пишет: гайз, заболел ребенок, сегодня работать не смогу.
Через двадцать минут просыпается Майкл, заходит в чат, видит сообщение Джона и отвечает: Джон, желаю твоей дочери поправиться! Еще через полчаса заходит Карл и пишет: скорее поправляйся! Через сорок минут… короче, вы поняли. В час дня выползает как-то тип со сдвинутым графиком и мотает чат. Пролистав десяток пожеланий, что он делает? Правильно — желает выздоровления дочери, а поскольку речь о ребенке, ставит тупую гифку с плюшевым медведем.
Обеим сторонам нужно помнить следующее.
Если вы — Майкл и Карл, то желать выздоровления больше одного раза не нужно. Если прям неймется, поставьте к первому сообщению лайк — в знак того, что вы присоединяетесь к пожеланию. Иначе вы затрахете коллегу и всех, кто в чате.
Если вы — Джон, и коллег не перевоспитать, не пишите о личных проблемах в общий чат. Достаточно написать руководителю и паре людей, с которыми вы плотно работаете. Остальным хватит и статуса в мессаджере.
Формально все эти пожелания вежливы. Но иногда еще вежливей будет помолчать.
-
Репозиторий функций
Где-то я прочел тезис: мол, хорошо бы иметь платформу, где в репозитории лежат не пакеты, а функции. То есть гранулярность библиотек столь мала, насколько это возможно. И вот тогда бы мы зажили.
Не понимаю, зачем об этом мечтать, ведь такая платформа есть — это Node.js и npm. В ней тысячи пакетов, которые состоят из одной-двух функций. Прямо сейчас прошелся по папке
node_modulesодного проекта. Обнаружил там забавные вещи:-
ansi-red— пакет для вывода текста красным, одна функция, пять строк на весь файл; -
expand-range— что-то для диапазона значений, одна функция; -
for-in— синтаксический сахар для цикла, одна функция, 6 строк; -
is-buffer,is-number,isarray,isobject— пакеты-проверки на нужный тип, везде одна функция на 5-6 строк; -
list-item— генерилка списка с буллитами, одна функция; -
markdown-link— рендер ссылки markdown, одна функция; -
randomatic— генератор случайной строки, две функции; -
repeat-element— генератор массива с повтором элемента, одна функция.
Есть и другие однострочники, не хочу утомлять. Просто факт: вот тебе платформа, куда можно заливать функции и делать ссылку на них, и это даже работает.
Имея все это на руках, хочется спросить: помогли тебе твои ляхи? Мы уже переехали в рай Node.js верхом на радуге? И что сегодня сказал бы автор тезиса? Опять чего-то не хватает?
Я очень скептичен к Node.js как платформе и не вижу смысла опять об этом писать. Речь о другом: высказывая тезис, даже самый фантастический, нужно помнить о том, что его легко проверить. Для этого не нужно ждать пять лет. Почти все, о чем мы мечтаем — это лишь слабые навороты к тому, что уже есть.
А истинно новые вещи проверить наперед невозможно.
-
-
Концепция
Итак, вы придумали изящную концепцию, простую и понятную. Но в процессе выяснилось, что ей мешают костыли: надо воткнуть условие здесь, условие там, словом, концепция поползла. Никакая она больше не изящная.
Возможны три варианта. Первый — идти до конца, то есть воткнуть столько костылей, сколько нужно для запуска в проде. Далее отчитаться перед начальством, съездить на конференцию с зажигательным толком, собрать все ништяки и уйти в закат. Позже фирма наймет кого-то другого, чтобы все переделать.
Второй путь — изменить внешние условия так, чтобы концепция не разваливалась. Например, переместить данные в другое место, отказаться от устаревших протоколов, поменять рабочий процесс. Это может быть справедливо, если сохранит изящность концепции.
Третий путь — если концепция, пусть даже изящная, не может жить в текущих условиях, она признается негодной. Вместо нее ищут другую концепцию. На первый взгляд она может быть уродливой, но ее достоинство в том, что она хорошо себя чувствует в тяжелых условиях.
Что именно выбрать — каждый решает сам. Лично мне нравится второй вариант. Если концепция простая, то есть может быть описана двумя предложениями, она прослужит долго. Ради этого стоит напрячься и передвинуть мебель так, чтобы в будущем ничего не двигать.
-
SOLID (2)
В продолжение прошлой заметки: особого упоминания заслуживает ООП. С ним можно играть в бинго. Если разговор зашел про ООП, кто-то обязательно скажет, что НА САМОМ ДЕЛЕ под ним имеется в виду что-то другое. То ООП, что в джавах и питонах, неправильное! Был божественный замысел, который неверно истолковали.
Дальше пойдет кряхтение о том, что Алан Кей был биологом. По аналогии с клетками он придумал обмен сообщениями, и что верное ООП только в Эрланге из-за модели акторов… все это я слышал много раз. Но скажите, что делать с зоопарком ООП в разных языках? Если это другое ООП, то может и назвать его по-другому? Если оно то же самое, то попуститься и все-таки признать?
И вообще, ничего, что прошло полвека со времен Кея и модели клеток? Ситуация как бы изменилась. Слегка.
Современное ООП — примерно как живопись. Найдено столько стилей и направлений, что их нельзя описать пятью буквами SOLID. Да, когда-то в них помещался весь опыт индустрии, и их возвели в догму. Но сегодня попытки объяснить ООП в Питоне терминами SOLID напоминают попытку заправить шубу в трусы. Не вмещается!
От ООП, кстати, уходят к классическому подходу структура-функция. Тысячи гоферов колбасят код в Гугле и других фирмах. Структура-функция-интерфейс, структура-функция-интерфейс… теперь это тоже ООП называется? Или все-таки можно писать в прод без ООП?
Просто маятник качнулся в обратную сторону. Теперь он удаляется от тех, к кому двигался раньше.
Если сравнивать языки, то в плане ООП мне больше всего нравится Lua. Там концепция ООП умещается в абзац. Объект — это таблица с данными, которой назначена мета-таблица с функциями. Когда вы обращаетесь к таблице, она ищет поле или метод в себе, потом в мета-таблице, потом в мете той таблицы и так далее. Вот и все ООП: инкапсуляция и наследование одим махом. Никаких виртуальных деструкторов, никаких Function.Prototype. И никто не парится.
Конечно, с такими тезисами вы не пройдете собес, если встретится ООП-маньяк. Но и вести себя с ним надо подобающе: не поднимать больные темы, принимать его сторону, если становится буйным. И все получится.
-
SOLID (1)
Когда говорят о REST, SOLID и прочих абстракциях, допускают следующий оборот. Мол, вы не так поняли оригинальный замысел: НА САМОМ ДЕЛЕ имелось в виду другое, просто техническая реализация отличается от задуманного.
Я никогда не мог понять, зачем так говорят. Если реализация REST на базе HTTP + JSON отличается от абстрактного REST, то либо не называйте ее так, либо смиритесь, что она отличается от замысла. Всяко лучше, чем с пеной у рта доказывать, что на самом деле имелось в виду что-то там.
Если идею автора пришлось доработать, чтобы претворить в жизнь, то это проблема автора, а не того, кто пользуется реализацией.
Конечно, есть те, кому нравится унижать людей на собесах. Тут REST и SOLID заходят на ура. Маньяки, ничего не поделаешь. Но мы-то с вами тут при чем?
-
Замеры
Если вы долго поддерживаете код, полезно делать замеры: стал ли он быстрее, медленнее или ничего не изменилось.
Не обязательно замерять каждый коммит. Достаточно делать это каждые N версий. Даже скромных данных будет достаточно, чтобы понять, где вы свернули не туда или наоборот — в проекте все круто.
Ниже — замеры драйвера Postgresql в разрезе версий. Разрыв между версиями 0.1.2 и 0.1.11 вызван тем, что в этот период я исправлял то, что не окажет влияния на производительность. А в 0.1.12 было то, что оказывает, поэтому замер необходим.
Картинка ниже показывает, сколько времени нужно, чтобы забрать данные с сервера без парсинга. С каждой версией эта метрика уменьшается. Вызвано это ленивым парсингом. Данные не разбираются сразу, а оборачиваются в класс, который притворяется словарем. При обращении к ключу происходит разбор поля и сохранение во внутреннем кэше.
То же самое, но для сложного запроса с полями разных типов:
Последняя версия выигрывает у конкурента на порядок: 59 против 590 милисекунд. Разве не круто, когда оцениваешь разницу визуально?
Другая метрика: число запросов в секунду HTTP сервера, который вынимает из базы случайные данные и отдает в JSON. Здесь видно, что хотя прирост есть, но на некоторых платформах число RPS слабо, но проседает. Это потому, что при сбросе данных в JSON срабатывает тот самый ленивый парсинг, а он отнимает время.
Есть еще одна метрика: очень сложный запрос с принудительным парсингом. Здесь видно, что он дает о себе знать: с каждой версией цифра повышается.
Из этих картинок можно извлечь пользу, например оценить, где мы выиграли и потеряли и насколько. В моем случае я считаю, что главное — как можно скорее забрать данные с сервера и освободить соединение. За это мы платим чуть менее быстрым парсингом, но ничего — это осознанный выбор.
Другое дело, когда замеров нет в принципе и остается гадать — может, станет быстрее, а может быть, медленнее. Компьютеры у всех мощные, телефоны меняют каждый год, поэтому выкатывай, там разберемся. Кажется, большинство программ обновляют именно так.
-
Никнейм в JetBrains
Смешно: регистрация в JetBrains запрашивает никнейм.
Вот у меня есть имя и фамилия. У меня есть электронная почта. У меня есть телефон. А никнейма нет. Где взять никнейм? Где его выдают?
Считается, что я должен его придумать. Но зачем? Какую пользу дает никнейм? Вы там что, не можете сгенерить UUID, а в сообщении писать имя и фамилию?
Согласен, что на форуме майнеров или имиджборде без ника никуда. Не будешь же ты подписываться полным ФИО. Но у JetBrains не форум анонимных программистов. У них продукт, и какую роль в нем играет никнейм — неясно.
Никнейм — это либо рудимент нулевых, машинное имя пользователя, удобное на бекенде. Либо это способ анонимности, чтобы постить сомнительный контент без разоблачения.
Оба случая проходят мимо JetBrains, что и желаю им понять.
Ну и классика: еще ничего не написал, а форма кричит ошибками.
Ivan Grishaev's blog
Writing on programming, education, books and negotiations.