Pull to refresh

Comments 88

Нажимать кнопки пахом — это какое-то совсем уж особенное извращение.
«фронтэндер не учитывает»

Ну зачем же так? почему никто не говорит что дизайнер не учел этого, проектировщик не учел этого, манагер не учел этого в конце концов.
Потому что есть разработчик, который не учел этого =))
Потому что я фронтэндер, и в этом контексте «дизайнер с менеджером не учли» — обвинение, а «фронтэндер не учел» — это конструктивный мотив для развития.
Это безусловно хороший повод, но не в случае ограниченного времени и оценки (если платят за часы). В редкие моменты удается прошерстить Github и посмотреть что используют в своих интересных проектах другие, чтобы потом использовать это в своих целях. Всегда хочется решить задачу не как обычно, а как кажется лучше и правильнее, даже в ущерб оплате… но вот несколько раз «согрешишь» и до следующего порыва (а потому что печеньки стали внезапно дороже и кофе уже не греет по дороге домой, лишь одноразовый стаканчик, заправленный офисной кофе-машиной в целях экономии).
На стабильных проектах можно и нужно постоянно развиваться, даже увлекаться «добрым мазохизмом».
На разовых проектах теряет смысл само понятие регрессии. Но таких проектов мало, всегда есть поддержка, хотя бы в рамках обсуждений «а давай бордер на три пикселя подвинем».
Конечно, проще найти другого «виноватого», вместо того чтобы сесть вместе и договориться как сделать лучше и наладить процесс.
Поиск виновного, если так подумать, он как раз и нужен для того, чтобы понять, на каком этапе начался факап. И вот тут как раз и нужно садиться и думать всем вместе, как улучшить процесс.
Ага. Менеджер особенно.

Очень люблю разработчиков, которые говорят, что в ТЗ не было указано «сделать без ошибок» (утрирую конечно)

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

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

Про проектировщика, дизайнера уже писали выше — зачастую они об этом вообще не думают (а дизайнер так мыслит вообще фиксированными габаритами и объектами).

И кстати, вы описали «сферическую» кнопку в отрыве от контента, но кнопка обычно находится в контексте и контекст может зависеть от этой кнопки и следовательно его видоизменение тоже нужно предусматривать.
Так ведь никто не говорит что все 100500 состояний кнопки нужно учесть здесь и сейчас!
Такой подход позволит при создании нового состояния убедиться что старые не поломались.
А как же трудозатраты?

На старте мы обычно учитываем всего 1 дополнительный кейс к дизайнам, это вот эти многострочные одиннадцатиклассницы. Затем «база» кейсов просто наращивается. По сути, вопрос стоит лишь так: делать ли двухминутную регрессию (с вероятным последующим фиксом багов) после внедрения очередной фичи, или забить и не думать о возникших багах, а фиксать их потом вне очереди как блокеры.

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

Безусловно) Например, мы все блоки делаем резиновыми и проверяем это во время регрессии в специальной тулзе, о которой напишем позже. Хотя большинство блоков имеют фиксированную ширину по дизайну.
На некоторые блоки у нас даже есть «контентные» автотесты, которые проверяют резиновость блока, то есть вообще без участия человека.
Стабильность проекта в любом случае требует трудозатрат. Экономия времени на таких вещах может легко превратить в краткосрочной перспективе разработку в ад. Нам хочется быть в любую минуту уверенными в качестве продукта.

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

" выдаёт менеджеру время на работу, за которое можно сделать пол-сайта, менеджер в недоумении и сомневается в компетенции фронтенда" это стереотипы, которые нужно ломать.

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

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

Как тестировщик, от работы которого успешно и регулярно избавляется автор статьи, могу заметить еще один профит — имея инструмент контроля верстки на старте и грамотный подход к архитектуре, менеджер будет вас еще больше любить и поощерять. Потому что вы становитесь гибче к изменению его требований, доставляете эти изменения быстрее, сохраняя при этом стабильность приложения.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Там все линии пересекают друг друга под 90°, это и есть перпендикулярность, по определению.
так ещё и продумывать как должен выглядеть блок при бОльшем чем в макете материале?

Обычно ничего придумывать не надо, надо просто не хардкодить размеры.
Иногда нужно «придумывать» text-overflow: ellipsis, просто для того, чтобы контент не мог расгеить верстку при любых условиях.

Ну и мне не очень понятна позиция «кто-то должен», если честно) Если дизайнер, менеджер и фронтэндер объединены общей целью, то какая разница кто чего должен. Главное — результат.
UFO just landed and posted this here
А если это элемент внутри небольшого блока?

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

Если речь о виджете в произвольном окружении, то это отдельная тема. Тут можно и про iframe поговорить, и про кастомные теги…

Вот в том и дело, а тут чётко обвиняют фронта, он не учёл.

В таких случаях виноваты все, но статья про фронтэнд, поэтому вот так.
UFO just landed and posted this here
Не подскажите, случаем, как сделать ellipsis для многострочного текста? С однострочным это действительно рабочее «полу-решение». Но как только дело доходит до многострочных блоков…

К тому же не очень приятно многократно за 1 макет брать на себя ответственность за решения из области «чтобы не развалилось и было удобно», которые должен был взять на себя дизайнер. Получается что большинство дизайнеров не утруждают себя сделать нечто большее, чем просто красивую картинку, которая понравилась клиенту.
Есть CSS решение, надо поискать. Если забуду тут скинуть, напишите в личку.
Очень любопытно. Все известные мне решения имеют ряд недостатков:
  • position: absolute блок с «…» строго в нижнем правом углу. Выглядит вовсе не так, как хотелось бы. И если блок содержит текст, который всё таки помещается, то выглядит и вовсе глупо;
  • javascript-решения. Помимо прочего плохи эти решения тем, что любое изменение размера блока (к примеру повернуть смартфон на 90 градусов) нуждаются в повторной обрезке. Да и до загрузки скриптом текст выглядит некрасиво;
  • only -webkit или -opera css. Решения для firefox-а мне найти не удалось :( да и не только firefox в них нуждается.

Ну собственно вы про п.1 из моего списка… На мой взгляд лучше воспользоваться JS решением, чем таким.
Нет, эта штука работает адекватно когда текста мало, и когда много, в отличие от позиционирования.
Да-да, до определенного предела тянем контейнер, потом ellipsis, но если он обрезает слишком много от и так небольшого контента или начался после пробела нужно просто резать и…
Фронтендер везде свой ад найдет.
как минимум, вы должны можете задать вопрос дизайнеру на предмет «А как должна выглядеть кнопка, если будет то-то?» и исходя из ответа уже делать реализацию
UFO just landed and posted this here
Конечно, вы ничего не должны проектировать, просто будьте эдаким HTML–оператором, печатайте код и ни о чем не думайте.
UFO just landed and posted this here
Вас задевает то, что кто-то работает больше? Или вы в курсе обязанностей фронтендера в 2GIS?
UFO just landed and posted this here
Есть интересный доклад Артема Поликарпова «Технолог — тоже дизайнер». И не все можно учесть при дизайне.
www.youtube.com/watch?v=h4QuJ0xBGfc
О-о-о, одиннадцатиклассница-а-а. Имхо, у кнопок просто не должно быть таких названий и описаний. Хотя… это же заказчик решает, а жаль.
UFO just landed and posted this here
Вы торгуете одиннадцатиклассницами? Что за бизнес такой, если не секрет?
UFO just landed and posted this here
Могу предположить, что данная проблема стоит свеч при выводе введённых пользовательских данных или данных из какой-нибудь импортированной БД — никогда не знаешь фамилия пользователя 10 букв или 30. уместится в 1 строчку имя с фамилией или нужно просчитывать 2 или 3. Количество цифр в сумме какого-нибудь заказа.
Счет Германия-Бразилия, курс доллара… ))
UFO just landed and posted this here
там был скролл, потому-что 8 фамилий не вмещались в фиксированный блок по высоте.
UFO just landed and posted this here
Не пользовались, но в целом скриншотеры это отдельный подход тестирования UI который, безусловно, имеет право на существование.

Главная проблема, на мой взгляд, у этого подхода одна: правильный подсчет процента расхождения. Он сильно повышается из-за, например, разного механизма рендеринга шрифтов на разных платформах. А это значит, что для pixel-perfect подхода тесты должны запускаться не у разработчика, а где-то на одном сервере…

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

Проверка глазами хоть и не полностью автоматическая, но достаточно быстрая (быстрее приемочных тестов) и гораздо надёжнее.
UFO just landed and posted this here
Могу предложить вам для тестирования верстки вот этот инструмент galenframework.com
Я уже писал для него статью на хабре habrahabr.ru/post/203506/

Он позволяет проверять расположение элементов относительно друг друга, а также имеет возможность проверять изображения отдельных элементов по цветовой схеме или по-пиксельно. При грамотном подходе ваши тесты могут превратится в читабельный документ полностью описывающий верстку.
Спасибо! Давно присматриваюсь к такому подходу, но не знал, что уже что-то есть.
Первый десяток сайтов, который пришел на ум (исключая 2ГИС Онлайн, конечно), был сломан до такой степени, что пользоваться ими стало абсолютно невозможно.


Наполнять текстом даже пустые текст-ноды немного не честно.
Ну это как минимум говорит о том, что на проекте нет минификации)

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

Одиннадцатикл
ассница

Вот это очень убого смотрится.

Одиннадцати-
классница

Вот это гораздо лучше.
Не во всех браузерах работает без допусилий (разбиения на сервере).
Насколько я понимаю, речь идёт о предопределённых словах, а не пользовательском вводе. Кроме того реально длинных слов, которым это надо, очень мало. Наконец, есть алгоритмы, которые неплохо разбивают автоматически и редко ошибаются. Думаю, было бы желание, а сделать можно.
Мне кажется, что метод оправдан в основном на крупных/сложных проектах.
На простых проектах, действительно, менеджеры будут возмущены сроками и стоимостью.
Но, в принципе, подход интересный.
Фраза
Не дожидайтесь, когда одиннадцатиклассница придёт к вам сама!
ушла в сборник цитат =)
добавьте код в виде ссылки-закладки для браузера. кол-во желающих воспользоваться увеличиться в разы.
javascript:(function(){var%20a,w=document.createTreeWalker(document,NodeFilter.SHOW_TEXT);while(a=w.nextNode()){if(a.textContent.trim().length)a.textContent='Lorem%20ipsum%20dolor%20sit%20amet,%20consectetur%20adipiscing%20elit.%20Fusce%20congue%20semper%20sodales.%20Sed%20ultricies%20eget%20neque%20eu%20semper.%20Nam%20ut%20diam%20vitae%20orci%20blandit%20eleifend%20a%20eget%20sapien.%20';}})()
Дык это же не тут выполнять надо, а на любимом сайте)
это понятно :) но если я хочу девелопить сайты и тестировать, то и не знаю, куда деть кусочек текста, а в виде буркмарка в браузере оч удобно.

как пример подобных полезных закладок — авторелоадер css стилей nv.github.io/css_auto-reload/
Какая-то притянутая за уши проблема, я считаю.
Ваша одиннадцатиклассница ломает на моём сайте блок с номером телефона. И блок с ценой. О чем это говорит? Да ни о чем.
Вы пришли с каким-то громким тезисом «все сайты в интернете свёрстаны неправильно», хотя оснований для таких утверждений нет.
Идея, разумеется, здравая, но с очень узкой областью применения: с помощью таких методик можно тестировать только элементы интерфейса (меню, кнопки), а не элементы оформления, коих на обычном сайте на порядок больше.
Попробуйте бутстрап потестировать таким способом. Тоже, считаете, непрофессионально свёрстан?
Проблемы людей, у которых «нет шрифта», «изменен зум» или иным образом целенаправленно сломан мой сайт, я решать не собираюсь. А все остальные кейсы (вроде кривого контента, плохого перевода или сломанного яваскрипта) закрывают тестировщики.
А разве кому-то Bootstrap обещает пуленепробиваемую верстку и кофе в постель? Это лишь инструмент для облегчения рутины и повод к созданию своего луна-парка с кефиром и поэтессами (как мне кажется поводом становится использование практически любого фрэймворка).
Описанные вами проблемы не пользователя, а вашего не слишком удачного подхода к разработке.
Скажите, почему производители любой электроники отказывают в гарантии на устройство из-за любого вмешательства в его конструкцию? Чем сложный веб-сайт отличается от сложной электроники? Почему я должен предоставлять гарантию на работоспособность, если пользователь самовольно внёс какие-то изменения в мой сайт?
Производители электроники не откажут в гарантии если обновленная версия ПО внезапно привела к частичной утрате заявленного в спеках функционала.
То же самое справедливо и в случае с «одиннадцатиклассницей», внезапно выбравшейся из очередной таблицы БД. Вы же не скажете клиенту «это все ваш MySQL, у меня в верстке все шикарно с 200 символами».
А, вы про это. Я упорно настаиваю на том, что задача выявления таких проблем — это задача QA. У профессиональных QA есть всегда набор кейсов вроде аномально длинного имени пользователя.
Но выявление таких багов должно быть делом точечным — есть сценарии вроде «длинное имя пользователя», «длинное слово в названии товара» и именно их невоспроизводимость и должна проверяться на тестовом окружении. А пихать длинное слово во все текстовые ноды страницы и называть это тестированием — это, извините, профанация какая-то.
Хотите пуленепробиваемую верстку — пихайте во все ноды. Во всех остальных случаях делайте соглашения типа «вот в этой ноде должно быть не более 12 символов». Иначе баг становится сиротой на фоне выясняющих друг с другом его отцовство создателей.

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

Ну и потом, речь ведь не о кардинальном смене воркфлоу, разметки или css-кода, увеличении временного бюджета задачи на 50%; в большинстве случаев всё сводится к градиентику или text-overflow: ellipsis. То есть, у разработчика учёт одиннадцатиклассниц занимает порядка 1% времени от задачи (1-5 минут), а поиск бага с дальнейшей игрой в футбол им — в сумме может достигать десятков минут, неприятные ощущения у пользователей и ухудшения отношений с коллегами по этому футболу.

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

Это называется «защита от дурака».
Ваше право, конечно, предоставлять доступ к своему сайту «as is» и на любых условиях.
Но бывают случаи, когда сайт приносит его владельцу деньги, и такие случаи нужно стараться учитывать.
В том числе варианты, когда у пользователя:
  • Отключён JavaScript
  • Отключены картинки
  • Включён режим «Турбо», что может повлиять на качество картинок и на часть вёрстки
  • Стоит AdBlock или его параметры
  • Слабое зрение и он использует собственный набор CSS
  • и т. д.

Посмотрите на Яндекс, например, без JavaScript, без картинок и с AdBlock и вы меня поймёте, что такое «сайт с гарантией».
UFO just landed and posted this here
UFO just landed and posted this here
Хоть один человек проверил)
Я намерено не правил эти баги, чтоб было видно, насколько на самом деле у нас лучше чем у других.
UFO just landed and posted this here
Я так и не понял в чем ценность этой статьи. Вы решили рассказать, что начали использовать регрессионное тестирование для js в своих проектах?
Ну ок, только что в этом нового, интересного, неизвестного? Кажется, что профита от этой статьи ноль.

Ну и да, попробуйте делать регрессионные тесты для css (like gemini, huxley, etc), кажется, что для ваших проблем это эффективней.
для верстки, без использования фреймворков
Забрать работу у машин и начать делать ее руками, да, кажется, что это прорыв.
Можно вопрос? (слегка оффтопик). Чем chai нравится больше других библиотек (should.js)?
Другими не пользовался, могу сравнить только с нодовским асертом — у него лучше вывод. Но есть и нюансы)
АААААААА!
Спасибо за слово)
Первый десяток сайтов, который пришел на ум (исключая 2ГИС Онлайн, конечно), был сломан до такой степени, что пользоваться ими стало абсолютно невозможно.

К сожалению ваш скрипт вставляет одиннадцатиклассницу в теги style и script. В таком случае сайты сделанные с учетом critical css ломаются вне зависимости от текста.

Я набросал небольшое логическое продолжение этой статьи и добавил туда букмарклет, который не лезет в стили и скрипты.
Sign up to leave a comment.