• Patch me if you can: как мы отлаживаемся на production. Часть 2

      В первой части своей статьи я рассказал о том, как мы в Badoo создали первую версию системы патчей. Если коротко, то нам нужно было найти способ исправления серьёзных ошибок прямо на production, доступный всем разработчикам. Однако первая версия была не без недостатков: мы использовали своеобразный способ раскладки, который не позволял гарантировать атомарность выкладок патчей и консистентность кода.

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


      Изображение: источник
      Читать дальше →
    • Концепции автоматического тестирования

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


      1. Зачем мы пишем тесты?
      2. Какие бывают тесты?
      3. Как мы пишем тесты?
      4. Как их стоит писать?
      5. Почему модульные тесты — это плохо?

      Правильная пирамида тестирования

      Читать дальше →
    • Внедрение code style в разработку

        Добрый день, %username%

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

        Немного о нашем проекте: PHP сайт, лежит в git репозитории объемом 2Gb, состоит из 20k php файлов, возраст проекта- 10 лет, в данный момент у нас 15 разработчиков. Для code review используем atlassian stash. Всю разработку ведем в рамках отдельных веток, которые после прохождения code review вливаем в master и деплоим на прод
        Читать дальше →
      • Чек-лист вёрстки. Что можно отдавать клиенту, а что надо переделывать

          Идеальная вёрсткаВы PM. Как узнать – готова ли вёрстка к реальному использованию?
          Вы заказчик. Как убедиться, что работа выполнена качественно?
          Как оценить качество вёрстки?

          Когда я стал тим-лидом, а позже PM, передо мной стала задача проверять вёрстку наших проектов. Нужно было выработать формальные, легкопроверяемые критерии, соответствие кода которым, должно было давать некую гарантию, что не будет факапов и ни клиент, ни программеры не сказажут потом “WTF?”.

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

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

          Итак что же это за список?

          Краткая версия теперь доступна на html5checklist.com (github), где можно вносить pull-request'ы.

          История обновлений:
          • 2015/08/11: Актуализировал рекомендации по оптимизации скорости загрузки. Добавил требование поддержки Retina. Дополнил «19. Мелочи» требованием что изображения должны масштабироваться в зависимости от размера окна.
          • 2015/08/10: актуализирован список исключений для CSSLint
          • 2015/07/29: актуализирован пункт №13 «плохо»/«хорошо»
          • 2015/04/08: добавлено требование использования препроцессоров и рекомендация использования систем сборки
          • 2013/04/25: добавлены анализаторами качества кода: CSSLint и JSHint, указан сайт подбора css font stack (спасибо @fliptheweb), мелкие уточнения (работу интерактивных элементов страницы, что не пропадает фон на высоких разрешениях, не должно быть пустых презентационных блоков, при проверках контента — пробовать удалять заголовки, менять местами блоки)
          • 2013/04/24: добавил пункт об минимизации каскада (БЭМ-техники, MCSS, SMACSS), необходимости вписывания в экран моб. устройства, заменил ссылку на проверочный текст отображения стандартного html на код с normalize.css, поправил пример где в рекомендации встречался длинный каскад, упомянул про Opera на Presto и новый уровень семантики — в именах классов BEM.
          • 2012/04/12: отсортировал пункты проверки в порядке важности, выделил главные, дополнил статью подробностями
          • 2011/12/07: дополнил согласно доклада на WSD Минск'2011.
          • 2011/07/19: добавлено про повышение надёжности вёрстки благодаря html5-тэгам, про необходимость favicon/apple-touch-icon, отсутствие багов при ресайзе textarea
          • 2011/06/15: добавил пояснения какие ошибки валидации допустимы, рассказал про отсутствие официальной кнопки «HTML5 Valid» и про официальное лого HTML5 на сайте.


          Далее с примерами - как проверить html, даже если вы ничего не понимаете в вёрстке.