"Как сделать обзор кода?" или "Как сообщить сотруднику, что ее HTML отстой?"

Ответ 1

Просто не забудьте точно объяснить, почему это отстой.

Плохо: Ваш HTML отстой.

Лучше: Ваш HTML отстой, потому что вы используете множество встроенных стилей для HTML-элементов

Даже лучше:. Ваш HTML отстой, потому что вы используете множество встроенных стилей, что делает его намного сложнее сделать эстетические изменения на всем сайте за один раз, потому что нужно редактировать каждый отдельный тег вместо единого правила CSS, которое предназначено для каждого отдельного тега. Кроме того, время загрузки страниц может быть уменьшено путем перехода к одному файлу CSS, так как он может быть отдельно кэширован клиентом.

И, очевидно, избегать зажигательного языка, такого как "ваш html sucks", тоже хорошая идея. Я просто использую "ваш HTML sucks" в качестве заполнителя для любой критики.

Ответ 2

Одна из проблем, с которой сталкиваются дизайнеры, заключается в следующем:

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

Я нашел демонстрацию дизайнеров Главная страница Zen Garden помогает понять неточные HTML файлы. Zen Garden можно настроить, используя только один CSS и стал очень хорошей демонстрацией красивых дизайнов, которые могут быть достигнуты с помощью div. Дополнительный вы можете скачать каждый CSS и изучить его, это был очень хороший источник обучения для меня.

Многие веб-дизайнеры скажут WOW после просмотра страницы; -)

Ответ 3

Скажите ей использовать валидатор;)

Покажите ей, "почему дизайн таблицы плохой", домашние страницы и т.д.

http://phrogz.net/CSS/WhyTablesAreBadForLayout.html ...

Ответ 4

Проект, над которым я работаю, включает только двух программистов (включая меня), и вместе мы разработали систему обзора (на основе соображений "Лучшие сохраненные секреты обзора однорангового кода" ), и это работает довольно хорошо. Я узнал довольно неплохие программные трюки. Вывод: проверка кода (если сделано правильно) также работает в небольших командах.

Жесткая часть - убедить своего коллегу в необходимости пересмотра кода. Один трюк здесь - запустить ее код через валидатор на www.w3.org или заставить ее прочитать книгу. Старайтесь всегда быть позитивными, даже если вы говорите ей, что ее код сосет (вместо этого попробуйте что-то вроде "эй, я видел этот трюк. Это может сработать и для нас", чтобы заставить ее изменить ее код). Убедитесь, что вы никогда не говорите, что ее код отстой.

Ответ 5

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

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

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

Ответ 6

Найдите обоснование того, почему вы считаете, что ваши методы лучше. Возможно, что-то вроде книги Refactoring HTML.

Ответ 7

Вы (команда) должны сначала согласовать мандатный набор правил. Использование таблиц для макета запрещено? Хорошо. Сделайте это явным правилом. Без набора "законов" вам будет трудно сказать ей, какие правила она нарушает с ее кодом.

Ответ 8

В том же духе, в котором предлагалось AmmoQ (мне не хватает кармы, чтобы прокомментировать их сообщение). Вместо "законов" зафиксировано "Стандарты кода". Это большая работа, но неконфронтационный способ заставить всех на борту улучшить качество кода. Если у вас есть код поставщика, который является некачественным, используйте это как оправдание необходимости документированных стандартов кода. В противном случае просто используйте что-то вроде "усиления нашей приверженности высококачественному коду". Когда люди восприимчивы, сделайте свое исследование, напишите документ, а затем просмотрите его с вашими коллегами. Вы можете включить цитаты для поддержки стандартов, чтобы показать, что они не субъективны, а фактические "Лучшие практики".

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

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

Ответ 9

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

Ответ 10

1) Совет от Hagakure (http://en.wikipedia.org/wiki/Hagakure): расскажите о своем собственном сосательном коде, sth. "Я сделал эту уродливую таблицу bla bla здесь, но я не доволен ею. Вы хоть представляете, как ее улучшить?" Никто не чувствует себя критическим.

2) терпение, длительные плохие habbits не уходят быстро.

Это главное мышление. Все остальные ответы также применимы. Это должно сделать трюк...

Ответ 11

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

Итак... скажите, что вы нашли способ уменьшить HTML-версию домашней страницы на 5 КБ за счет более эффективного использования CSS. Затем вы можете показать, как вы это сделали.

Я был на обоих концах этого. И одна константа состоит в том, что доказательство обычно необходимо, чтобы убедить кого-то изменить то, как они это делают.

Ответ 12

Я не думаю, что обзоры будут местом для обсуждения этой конкретной проблемы. То, что я видел других, - это выбрать другой сайт или набор сайтов, который является либо "врагом", либо "героем" для вашего сайта. Ваш сайт либо хочет взять их в своей игре, либо быть такими же, как и они (разница на самом деле минимальна в зависимости от того, как конкурирует ваш бизнес). Затем вы отслеживаете изменения, которые они совершили или делают, и следуйте этим указаниям, как это влияет на их тенденции движения (скажем, с Alexa). Должно быть легко найти, что 10/10 из них используют более минимальный блочный стиль. Эффективно это становится вашим стандартом для подражания тогда. Возможно, разработчик использует набор, в котором 10/10 сайтов имеют HTML, который похож на ее. Теперь вам нужно выяснить, кто убежден, что это сайты, которые нужно посмотреть, и как вы собираетесь передумать.

Вы когда-нибудь замечали, что примерно каждый bag производитель имеет страницу продукта, имитирующую страницу eBags.com? Я даже не уверен, что eBags не подражает другим. Цветные образцы в виде крошечных коробок, меньших, чем значок 32x32, с щелчком мыши, чтобы изменить основной вид, чтобы изменить основное изображение. Belkin конкурирует на другом рынке и не только делает сумки, но не соответствует групповому виду. О нет, Jansport нарушил правило опрокидывания и правило масштабирования. Наблюдайте за этим сообщением, когда вы становитесь старыми, как имитация/исследования рябь; Northface также использует этот стиль масштабирования. (Эти ссылки относятся к случайной странице продукта.Они иллюстрируют сходство страницы продукта. Также есть сходство в категории страниц. Я не одобряю ни один из этих элементов или компаний.)

Во всяком случае, я хочу сказать, что этот стиль и большинство других, будь то видимые или в HTML или CSS, основаны на распространении через имитацию. Как бы то ни было, как смелые цветовые шаблоны T.V., где популярны с домашними страницами и портфолио немецких дизайнеров 5 лет назад, но заметно отсутствовали на других языковых группах домашних страниц дизайнеров. Поэтому меняйте, кто имитируется, или (если их HTML выглядит отлично) подчеркивают, что базовый HTML содержит столько же секретов торговли и указывает на них.

Ответ 13

Пусть машина сделает грязную работу для вас. Пройдите веб-сайт с помощью валидаторов w3c.

http://validator.w3.org

Как минимум, все веб-сайты должны пройти стандарты доступности.

Ответ 14

Действительно, вам нужно найти ответ на вопрос: "Почему этот html сосет?" ИМО очень важно уметь формулировать проблемы для себя, прежде чем учиться так. (в этом отношении см. также h ttp://stackoverflow.com/questions/868301/how-can-i-teach-a-know-it-all-beginner-programmer/868395 # 868395).

Некоторые подсказки:

• Является ли html crossbrowser? Должно быть? Теперь, или, может быть, в будущем. Покажите ей, какие браузеры дают нечетные эффекты и показывают, почему ее html трудно изменить, чтобы работать.
• Она смешивает презентацию и контент? Найти ресурсы (и их много), которые указывают, почему именно.
• О смешивании: ее сайт поддерживается? Есть ли четкое разделение кода, стиля (css) и html?
• Использует ли контент, связанный с содержанием, как презентацию. Как и таблицы, iframes...?
• И самое главное: она придерживается стандартного (например, XHTML). Объясните ей, почему важно проверить, полезен ли стандарт и не устарел, и проверить его на стандартном контролере, есть много в Интернете.

Особенно последний момент может быть полезен, поскольку это своего рода цель. Придерживание стандарта - не чудо-решение. но по крайней мере ее html будет последовательным и более читаемым. И она будет обязана думать о ее кодировании, а именно: IMVHO (по моему очень скромному мнению) - начало всего.

Ответ 15

Неужели ей не хватает знаний в CSS? Может быть, у вас проблема технического образования. Покажите ее примеры хорошего настроения. Ей, возможно, потребуется прочитать некоторые книги (оплачиваемые вашей фирмой), и вам нужно быть тонким, чтобы не забыть о своем эго. Может быть что-то вроде:

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

Ответ 16

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

Затем покажите своим клиентам/боссам, насколько проще поддерживать хороший сайт, соответствующий стандартам.

Ответ 17

Вы никогда не сможете выиграть типичную дискуссию "ваш код сосет", такие дискуссии очень субъективны.

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

Ответ 18

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

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

Ответ 19

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

Таким образом, у вас открыта дверь, и это кажется намного менее угрожающим. Представьте ее вашему коду и вашему способу делать что-то в этом роде. Будьте готовы к резервному копированию стиля кодирования с документацией ( "Я использовал этот конкретный тег вместо таблицы, потому что он семантически корректен" или "Этот бит CSS был сложным, но он экономит нас, используя разделители gifs повсюду, что ускоряет сайт и улучшает пользовательский интерфейс." ).

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