Наверх ▲

Ошибка. Осознание, анализ, извлечение пользы

Вадим Макишвили Вадим Макишвили Руководитель группы вёрстки в компании "Яндекс", представитель украинского крыла WSG.
View more presentations from rit2010.

Вадим Макишвили: Добрый день, меня зовут Вадим Макишвили, я работаю в «Яндексе» больше трех лет. За эти три года через мои руки прошло очень много сервисов Яндекса. Только не думайте, что я один сверстал их все от начала и до конца. 

Правильнее было бы сказать, что я их "потрогал". В разное время на разных сервисах я выполнял разные задачи. Мне стало просто интересно, сколько задач прошло через мои руки за эти три года. Оказалось, это полторы тысячи задач. Полторы тысячи "issue" в багтрекере.

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

Больше тысячи "issue" имели тип "bug", то есть что-то было неправильно, и требовалось это исправить.

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

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

Что это значит? Что лично я - один! - наплодил в Яндексе больше тысячи ошибок за три года. Другими словами, я дестабилизировал сервисы Яндекса на эту тысячу ошибок.

Мне стало грустно. Но потом меня посетила утешительная мысль: "В Яндексе, наверное, много разработчиков. И, наверное, у каждого из них есть какая-то своя тысяча..." Как говорят, у каждого врача свое кладбище.

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

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

Для кого-то это мало, для кого-то много. Для меня нормально. Это число про меня. Главное, что два часа — это четверть рабочего дня. Если я тысячу разделю на четверть, я получу 250 рабочих дней. В году всего 270 рабочих дней. Фактически один год из трех я занимался исправлением ошибок, багфиксингом. Работаю три года, и год из них исправляю свои ошибки. Это было тоже неприятно осознать.

С другой стороны, остальные-то два года я приношу пользу. Два года — это приблизительно 500 рабочих дней. Я выполнил 500 задач. В среднем, на одну задачу у меня уходит 8 рабочих часов.

Вот такое число я про себя еще получил. Если мы посмотрим на соотношение количества задач и соотношение количества ошибок в моей работе (500:1000), то мы увидим, что они относятся, как 1:2.

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

Как это происходит? Я беру задачу «А». Выполняю ее за 8 часов. Отдаю на тестирование. Потом беру задачу «Б». Пока я выполнял задачу «Б», задачу «А» протестировали. Мне вернули два отчета об ошибках. То есть, когда я «А» туда отдавал, я уже мог быть уверен, что там есть две мои ошибки. 

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

Это формула выглядит так: t1 — время на первичную заверстку задачи, а t2 — это время на исправление одной ошибки. Когда я подставлю сюда числа про себя, то я узнаю, что в среднем на выполнение одной задачи, включая устранение ошибок, у меня уходит двенадцать часов. Полтора рабочих дня.

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

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

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

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

Любая ошибка — это как астрономическая черная дыра. Стоит тебе только приблизиться, как тебя туда засасывает целиком: с твоим настроением, временем, со всеми силами.

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

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

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

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

Туда пришел я. Новенький. Когда приходишь в новый коллектив, что происходит? Обычно все смотрят, как ты работаешь: быстро-медленно, хорошо-плохо.

К тебе привыкают, приглядываются. Если ты работаешь хорошо, у тебя постепенно растет авторитет. Благодаря этому авторитету растет и самооценка.

Спустя три месяца мне сообщают об ошибке: на второй и главной странице сервиса текстовые блоки наслаиваются друг на друга. На иллюстрации видно, как они наслаиваются.

Кажется, что ошибка пустяковая. Но так как она воспроизводится на второй, но главной странице сервиса, и релиз проекта чуть ли не завтра, то ошибке присваивается статус «critical» («критическая ошибка»).

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

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

Статус ошибки "Critical" меняется на "blocker". Мне стало казаться, что менеджеры и коллеги на меня смотрят с нарастающим сомнением. Человек что-то делает неделю. На первый взгляд, ошибка мелкая, но верстальщик что-то делает, а результата нет. Тут два варианта: или он не способен ее исправить (тогда зачем он с нами работает?), или же он ничего не делает.

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

Об этом говорить важно. Любая работа с ошибками влияет на нашу самооценку. Если самооценка снижается, то снижается наша работоспособность. Кому это нравится?

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

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

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

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

  • Если ваш документ сверстан в quirksmode.
  • Если в вашем документе есть таблица шириной 100%.
  • Если в этой таблице есть хотя бы один элемент со свойством "float left".
  • Если при этом внутри "float left" есть хотя бы один длинный неразрывный текстовый узел
  • Или вместо "float left" с текстовым узлом есть хотя бы один элемент со свойством "line hate".

При этих условиях в IE 6 ячейки наслаиваются друг на друга при изменении размеров окна.

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

Это та ошибка, которую я пытался победить полторы недели. Исправил я ее быстро — за полчаса. Я убрал все свойства "float left" (по-моему, использовал вместо них "inline-block"), убрал свойство "line hate" и стили. Ошибка была исправлена. Но на понимание ушло полторы недели.

К слову, именно с этого момента некоторые менеджеры усомнились в моей профпригодности навсегда. Я их в этом не виню. Они не виноваты, что в Интернете бытует мнение о том, что html-верстка — это просто. Они не виноваты, и если бы я был на их месте, я бы тоже сильно усомнился в парне, который полторы недели что-то делает с такой ошибкой, и у него ничего не получается.

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

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

Честно говоря, мне боязно не то что признавать ошибки, мне даже совершать их боязно! Смотрите, я уже стал руководителем группы в «Яндексе», у меня есть какой авторитет, у меня есть какая-то самооценка, более или менее стабильная. Мне просто боязно потерять авторитет, ударить в грязь лицом, - потерять работу, в конце концов.

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

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

С годами они только накапливаются. Все плохое в человеке обязательно начинает искать выход. Куда я могу это выплеснуть? На работе раздражаться не принято. В культуре у нас это не принято. Где я могу излить наболевшее?

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

Куда я обычно хожу? Не знаю, как вы, а я хожу домой. Туда, где меня ждут жена и ребенок.

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

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

Психологи совсем не оригинальны. Я так и не смог понять, кто больше двух тысяч лет назад сказал эту банальность: «Человеку свойственно ошибаться». Не то Аристотель, не то Цицерон, не то Марк Сенека Старший.

Эта фраза в оригинале звучит вообще не так. Звучит она так: «Errare humanum est».

Слово «est» означает «характерный отличительный признак». Правильнее эту фразу переводить: «Ошибаться — характерный отличительный признак человека».

Сказать это коротко, в виде афоризма, можно так: «Ошибаться — человеческая сущность».

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

Если это так, какой смысл этого стыдиться или бояться? Поэтому я выбираю «не бояться». Я хочу научиться жить со своими ошибками. Я хочу научиться относиться к ним как к неизбежности. К тому, чего я избежать не могу. Уменьшить могу — избежать не могу.

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

С ошибками так же. С ними можно и нужно научиться жить. Чтобы научиться, нужно понять, что такое ошибка.

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

Помню, в средних классах школы учитель математики сказал какую-то странную фразу. Тогда я не понял, что он сказал. Он сказал: «Отрицательный результат — тоже результат». Если я в задаче делал ошибку, то задача считалась решенной неправильно. Двух мнений не было.

А тут — тоже результат. Оказалось, что учитель-то был взрослый. Он понимал, что в жизни все существует относительно чего-то.

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

К какой мысли я вас веду, если брать работу верстальщика? Нет такого понятия, как абсолютная ошибка. Нет их в нашей работе. Любая ошибка совершается относительно двух вещей:

1) относительно условиям задачи, которую я выполняю,

2) относительно человека, который проверяет выполнение условий этой задачи.

Время от времени бывает, что приходят тестировщики и говорят: «Ребята, что это такое? Это баг или фича? Понять не можем». Тут как у меня получится. Если получится доказать, что фича, одним багом будет меньше.

Но зачем убеждать тестировщика? Надо убедить не только его, но еще и заказчика, правильно? Для заказчика любая моя ошибка имеет совершенно определенную ценность и важность. Для меня, для разработчика, эта ошибка имеет другую ценность и важность. Для пользователя — третью ценность и важность.

Кажется, что заказчик и разработчик работают для блага пользователя. Так и есть, но потому, что заказчик и разработчик находятся на разных "колокольнях", они это удобство видят по-разному. О ценности для пользователя я сейчас говорить не буду. Я поговорю о ценности для заказчика и разработчика.

Что такое ошибка для заказчика? Тут все очень просто. Для заказчика ошибка — это абсолютное зло.

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

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

Что я имею в виду?

Есть такая чудесная техника, она называется "Any Order Columns". Если вам нужно сверстать раскладку страниц, не используя таблицы, надо брать и использовать ее. Она хорошо себя ведет.

Три года назад (когда я начинал работать в «Яндексе»), я работал не только над «Я.ru», но еще и над проектом «Яндекс.Кубок». Это небольшой, но интересный проект соревнований по поиску в Интернете.

При верстке этого веб-сервиса была использована техника "Any Order Columns". Все было прекрасно до того момента, когда сервис был запущен в продакшн и "полетел". После этого в сервис стали приходить реальные данные с длинными URL.

Некоторые из URL были настолько длинны, что раскладка ломалась. По задумке дизайна, мы не должны были ни обрезать их, используя "overflow:hidden", ни переносить на следующую строку. Раскладка "поплыла".

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

Но, с другой стороны, благодаря этой ошибке мы узнали, что раскладка на "Any Order Columns" непригодна для ситуаций, когда мы не контролируем контент, который к нам приходит. Именно благодаря этой ошибке в «Яндексе» было принято решение использовать только табличную раскладку как наиболее предсказуемую, надежную и гибкую. Уже потом в «Я.ru» мы узнали, что она не слишком надежна, но это другая история.

Возьмем, к примеру, обычную лампочку. С виду это очень простое устройство. Цоколь, какая-то стеклянная колба (внутри вакуум или газ), электроды и нить накаливания. Знаете ли вы, сколько Томасу Эдисону потребовалось провести опытов, чтобы найти  для нити накаливания такой материал, который был бы одновременно и дешевым, и долговечным? Шесть тысяч опытов. Шесть тысяч материалов пришлось исследовать.

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

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

Если такой заказчик у него был, то какой мудростью надо было обладать, чтобы семь лет оплачивать ежедневные ошибки? Но это того стоило. В результате был найден нужный материал. Я уже не помню... По-моему, какая-то нить японского бамбука из Японии. Такой материал был найден.

Было запущено производство дешевых лампочек. Мир вошел в эру электрического освещения. Чуть позже последовательи ученик Эдисона Никола Тесла придумал систему централизованного освещения, которой мы с вами до сих пор пользуемся. Стоило ли совершать все эти ошибки? Однозначно — да.

Когда я допускаю ошибки, заказчик думает, что это все ошибки - мои, правильно? Он не знает тонкостей про браузеры и про стандарты. Хороший знает. Обычный не знает. Для него все ошибки — мои.

У меня в работе есть серьезная трудность. С одной стороны, я хочу работать хорошо. Я для этого делаю все, что могу: изучаю технологии, читаю ресурсы. С другой стороны, у меня есть стопперы. К примеру, браузеры, которые еще не могут воспроизвести все то, чему я уже научился. 

Образно говоря, я пытаюсь состыковать две трубы разного диаметра, чтобы вода потекла, чтобы все было хорошо. Но у меня это не получается. Мне приходится заматывать трубы скотчем, затыкать дырки паклей, делать самостоятельные решения. Но эти решения всегда несовершенны.
 
Заказчики об этом не знают. Хорошо, заказчик мне может сказать: «Ладно. Про браузерные ошибки я с тобой соглашусь. От них никуда не деться, но как быть с архитектурными ошибками? Это же твои ошибки. Ошибки проектирования».

С одной стороны, да. Кажется, что ошибки проектирования — это только моя ошибка. Но если вернуться к ошибке с "Any Order Columns", там моя ошибка: я неправильно спроектировал интерфейс. Но если бы браузер предоставлял мне возможность создавать надежную раскладку, разве я стал бы обращаться к каким-то "костылям", хитрым техникам? Нет, не стал бы.

Расскажу про одну серьезную архитектурную ошибку. Когда я пришел в «Я.ru»  на стадии его проектирования, нужно было поддерживать пятую версию Internet Explorer. Пятая версия IE не умеет рендерить документ в standard mode, она только в quirksmode умеет рендерить.

У архитекторов интерфейса встала проблема: «Что нам делать? Писать одновременно три стилевых файла? Один — для IE 5, который в quirksmode. Один — для IE 6, который в standard mode. Один — для IE 7, который тоже в standard mode». IE 6 и IE 7 в standard mode — это два разных браузера.

Была придумана, по-моему, гениальная идея. Она заключалась в том, чтобы свалить IE 6 тоже в quirksmode. Тогда нам надо было бы писать всего два файла. Для IE в quirksmode, где бы мы писали для IE 5 и для IE 6, и для IE 7 в standard mode. Придумано — сделано.

По задумке мы должны были сэкономить массу часов на написание и на багфиксинг. Но вышло по-другому. Появилась масса ошибок из-за того, что IE 6 рендерился в quirksmode. Пришлось расставлять под проектом "костыли". Работать стало сложнее. Ошибка с раскладкой, с которой я начал доклад, возникла только из-за того, что IE 6 был в quirksmode.

Это, кстати, очень хороший пример того, что standard mode — это правильно. Даже под IE 6 легче писать в standard mode.

Мне очень нужно вам кое-что сказать про IE 6.

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

То, что там много ошибок, это по-человечески понятно. Этот браузер писали живые люди - такие же, как мы с вами. Кто не ошибается? Насчет стандартов — извините, этому браузеру десять лет в обед! Какие могут быть требования к браузеру, который вышел давным-давно?

Я помню, что десять лет назад было всего три хороших браузера. Это были Netscape Navigator 7.0, Internet Explorer 6.0 и Opera (не помню, какая версия). Сейчас уже исчезли Netscape Navigator 7.0 и Opera не-помню-какая-версия, зато есть этот старичок IE 6, который еще работает!

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

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

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

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

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

«Знаешь, дочка, блок с закругленными уголками я раньше верстал многими способами. Сначала это была девятиячеечная таблица с картинками по углам. Потом я научился верстать это с восемью вложенными div’ами. Потом я эти div’ы стал разбрасывать абсолютным позиционированием по углам. Потом я научился генерить эти части с помощью JavaScript на лету. Потом я стал кроссбраузерно использовать "data:URL"».

Ребенок будет слушать и удивляться. Тогда она просто задаст значение "border-radius" — и все. В этом сила веб-стандартов. Разве плохо?

Это прекрасно. Для ребенка это прекрасно, для меня — пока не очень. Я устал от "костылей".

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

Если мы пишем для одного и того же элемента два фильтра, - первый Alpha (opacity) и второй "AlphaImageloader", - то браузер ничего нам не загрузит. Он перестанет работать.

Вот забавная ошибка. Если после знака равенства в этом фильтре вы поставите пробел и это свойство случайно дадите браузеру IE 7, то после этого свойства он вообще ничего не прочитает. Пробел.

Если случайно в имени файла вы поставите закрывающую скобку, то после этого свойства IE 6 вообще ничего не отобразит. Стили для других блоков, которые описаны ниже этого свойства, не отобразятся. Эта ошибка висела пару минут на главной странице Яндекса. 

Если в свойстве "background" после закрывающей скобки вы не поставите пробел, то все браузеры "поймут", что вы хотели, а IE 6 эту картинку не отобразит вообще.

Ошибка, решением которой я горжусь, - мне посчастливилось найти это решение. Известно, что такой селектор в IE 6 не сработает. Содержимое внутри "span" не покраснеет, если мы наведем мышь на ссылку. Как мы это делали раньше? Писали "expression", который исходя из "mouseover" и "mouseout" вычислял этот "span".

Оказалось, все проще. Если рядом написать вот такой селектор, то IE 6 начнет стилизовать этот "span" по наведению на "hover". Нолик означает «не изменять размер пространства между словами».

В этом нет никакого волшебства. Это свойство заставляет IE перезапускать "reflow" при каждом наведении на "hover". Когда "reflow" перезапускается, то первый селектор срабатывает.

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

В какой-то момент верстки большого сервера на странице, где есть много блоков, в какой-то момент верстки все хорошо, а потом — хоп, в IE 7 страница начинает резко тормозить.

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

В Интернете упоминания об этой проблеме есть. Именно про IE 7 и про "тормоза" отрисовки и реакции на действия пользователя. Предлагаются очень поверхностные решения: «Знаем, знаем, это происходит только тогда, когда вы "вешаете" псевдосостояние "hover" на ссылку (на элементы списка, на строку таблицы). Уберите "hover" от нессылок, и все у вас будет хорошо».

Это, конечно, так. Убираем. Проблем меньше не становится. Если на такой странице оставить хотя бы одну ссылку, у которой есть селектор «имя.get:hover», "тормоза" будут воспроизводиться.

"Костыль" мы придумали вот какой: для каждой ссылки, у которой есть "hover", написать имя элемента — «А». После этого тормоза резко прекращаются. Почему это происходит, мы не понимаем. Мы даже не знаем, как вычленить минимальное количество элементов, чтобы дать вам и попросить вас помочь.

Первое, что приходит в голову — наверное, слишком много блоков. Выяснилось, что нет определенного блока, после которого воспроизводятся тормоза. Убираем половину блоков, вполовину быстрее начинает реагировать. Убираем все блоки — вообще прекрасно реагирует. Такая ошибка.

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

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

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

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

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

Закончить свой доклад я хочу афоризмом Валерия Афонченко. Он сказал: «В попытке не допускать ошибок они перестали что-либо делать вообще. Это стало их самой большой ошибкой». Я желаю всем нам, чтобы следующее поколение верстальщиков про нас такого сказать не могло. Спасибо.

Вопросы и ответы

Вопрос:
— У меня один вопрос и одно предложение. Вопрос, может быть, банальный. Как вы тестируете верстку в разных браузерах?
Предложение. Вы говорили, что не знаете, как решить некоторые проблемы. Может быть, вы объявите конкурс «Реши эту проблему и получи 100 долларов», - как это делается в Google, например? Что-нибудь такое. Спасибо.
Вадим Макишвили:
— Да мы бы с радостью предложили конкурс, но для того, чтобы его предложить, нужно отдать вам прототип того интерфейса, в котором мы столкнулись с этой проблемой. Это пока секрет. Отдать его мы не можем. Воспроизвести эту ошибку — просто сесть и воспроизвести синтетически — мы тоже не можем.
Мы столкнулись в этом интерфейсе с проблемой, мы вокруг нее пляшем. Воспроизвести не можем. Пофиксить, понять тоже не можем. Нашли "костыль" — используем. Мы заложники этой проблемы.
По первому вопросу. Мы тестируем так же, как и Сергей Чикуенок. У нас есть виртуальные машины. По одной машине на каждый браузер. У нас есть IE 6, IE 7, IE 8. Будет IE 9 — будет виртуальная машина с IE 9. В каждой из этих виртуальных машин обязательно есть Firefox разных версий, Safari разных версий, Chrome. Так и тестируем.
Вопрос:
— Я тестирую точно так же. Просто захотелось услышать ответ именно от коллеги.
Вадим Макишвили:
— Вы правильным путем двигаетесь, да.
Вопрос:
— Небольшой вопрос по поводу командной коммуникации. В тех командах, в которых мне довелось работать, в ситуации, когда человек неделю бьется над ошибкой, которую считают простой, ему предлагают помощь.
В этом случае два варианта. Человеку быстро помогают. Зачастую так бывает, потому что нужен взгляд со стороны. Просто вы в этом давно, а со стороны посмотрел и увидел. Даже если квалификация другая.
Либо второй вариант. Он в этом покопался — убедился, что задача сложная. Соответственно, ваш авторитет восстановлен полностью.
Вадим Макишвили:
— Относительно той моей ситуации. Я был единственным клиентским верстальщиком в проекте. Обратиться за помощью можно было, но у тех ребят тоже есть свои задачи. Задача-то непростая. Если я обращусь за помощью, тому человеку придется бросить свои задачи и переключиться на мои. Мы бы вместе "копали" эти полторы недели, к примеру.
Но теперь я точно знаю (спасибо вам, я забыл об этом сказать на презентации), что если я или вы столкнетесь с такой ошибкой, над которой вы бьетесь, и заканчивается неделя — хватит биться. Зовите других ребят. Вместе устраивайте мозговой штурм. Если продолжать, вы потеряете самооценку. Это будет плохой результат для проекта, не только для вас. Спасибо.
Вопрос:
— Вы не пробовали в качестве автоматизации не просто виртуальные машины — их куча разных версий браузеров, а снимки экрана сравнивать, которые генерируются браузером? Тогда не потребуется почти ничего вручную делать, чтобы найти разницу в верстке. Когда появляется некая разница в верстке, это чаше всего говорит о том, что в каком-то браузере поехало или совсем все не так.
Тимур Хайруллин, руководитель нагрузочного тестирования компании «Яндекс»:
— Я про тестирование много чего знаю. Могу рассказать очень интересную историю. У нас, к сожалению, не завелось и не полетело, однако есть очень интересные методы и методики выявления багов, когда, например, один макет (англ. layout) на другой наехал. Есть именно автоматические методики выявления таких багов.
Осенью 2009 года была конференция GTAC (Google Test Automation Conference), в Цюрихе, в Швейцарии. На ней традиционно собираются очень интересные ребята из веб-разработки. Там был представлен доклад об автоматическом тестировании багов макета, багов верстки конкретно, которые нельзя найти автоматизированным функциональным тестированием. 
Представлен очень интересный доклад про то, как ребята тестируют это автоматически. Я всячески советую вам его посмотреть. Кратко суть такова.
Делается снимок экрана с черным текстом, потом текст меняется на белый. Делается скриншот с белым текстом. Накладывается одно на другое (чуть посложнее, но суть такова). Условно говоря, вычитается одно из другого. Таким образом, мы знаем, где расположен текст. Дальше мы его можем выкинуть, и остается только граница макета.
Дальше с помощью простейшего ACR можно выделить границы наезда одного на другое или слишком сильного "прижатия" текстовой колонки к борту. Или наезд текста на картинку. Или непомещение надписи в кнопку. Такие штуки очень за дешево, практически «на коленке» решаются автоматическим путем.
У меня есть электронная почта. Со мной можно связаться. Я могу ссылочку на этот доклад прислать. Там есть слайды и видео выступлений. Очень сильно рекомендую. Мы не завели это, потому что у нас руки не дошли. Тем не менее, решение существует. Решение автоматическое. Решение, конечно, не без багов, но очень облегчает жизнь на среднем этапе верстки, когда быстро, быстро что-то меняется. Быстро хочется что-то сверстать, посмотреть и выкатить.
Вопрос:
— Ты упомянул о том, что руководишь группой верстальщиков. Скажи, меняются ли твои ощущения или твоя реакция не на собственные ошибки, а на ошибки твоих сотрудников? Что меняется в восприятии такого рода ошибок?
Вадим Макишвили:
— Я стараюсь у ребят из своей группы всячески повышать самооценку. Если у них что-то не получается, я их стараюсь психологически погладить, успокоить, чем-то помочь. Я прошел через этот этап, когда моя самооценка скакала. Сейчас она более или менее выровнялась. Мне хочется, чтобы ребята в моей группе работали стабильно, благодаря ровной самооценке.
Вопрос:
— Вадим, некоторые ошибки складываются из маленьких ошибочек, которые допускают несколько человек, которые работают над одним проектом. В конце концов, такая ошибка когда-то вываливается наружу. Кто виноват в этом случае? Тот, кто был последним? Как с этим поступать?
Вадим Макишвили:
— Я считаю, что не очень правильно мыслить категориями «виноват — не виноват». В нашей работе в любых ошибках нет крайнего, нет виноватого.
Вопрос:
— Кто исправлять будет?
Вадим Макишвили:
— Исправлять будет тот, кто увидел. Если это его зона ответственности, то он будет исправлять. Если ты, Женя, Сережа допустили вместе ошибку... Ты ее начал, Сережа поддержал, Женя продолжила, а ты нашел и сообщил об ошибке мне, то я буду ее исправлять.

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Андрей Пантюхин

Андрей Пантюхин

В 2010–2012 построил Dream Industries в качестве первого CTO. Последние годы работает с ранними стартапами в России и за рубежом над продуктом и стратегией роста.

Андрей Пантюхин ведет речь о развитии технологий NFS v4.1 и новинках вроде pNFS (параллельный, кластерный NFS) и FedFS (федеративный NFS для глобальных хранилищ).

Александр Сербул

Александр Сербул

C 2011 года курирует направление контроля качества интеграции и внедрений ООО «1С-Битрикс», активно участвует как архитектор и разработчик в проектах компании, связанных с высокой нагрузкой и отказоустойчивостью («Битрикс24»), консультирует партнеров и клиентов по вопросам архитектуры высоконагруженных...

Александр Демидов (1С-Битрикс) делится опытом использования "облачного" хранилища и рассматривает хранилище как элемент масштабируемой отказоустойчивой архитектуры.

Сергей Ильинский

Сергей Ильинский

Cоздатель Backbase Ajax Framework и Ample SDK.

Сергей Ильинский (Clientside OY) рассказывает о малоизвестном фреймворке Ample SDK, которое уже успели метко окрестить "браузером в браузере".