Содержание

Как написать слово «неправильно» — ТекстЭксперт

Правильно пишется: неправильно

Правильно пишется: не правильно

«Не» в написании с разными частями речи в русском языке – проблема сложная, но регулируется определёнными правилами. Допустимо чаще всего два варианта на письме, как слитно, так и раздельно, хотя и есть некоторые исключения. В вопросе, как написать слово «неправильно», как раз следует разобрать эти варианты. При сомнении, как писать «не» в составе «неправильно», одно нужно знать чётко – через дефис слово это не пишется никогда.

Когда наречия с «не» пишутся слитно и попадает ли слово «неправильно» в эту группу

Первый случай написания наречий с «не» в начале – если это не приставка, а часть корня, и отделить её от слова нельзя. Пример подобного наречия – нелепо.

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

Негде мне заночевать.
Нигде не нашёл я кошелёк: наверно, потерял.

Некуда ему идти, он бездомный.
Никуда без тебя не пойду!

И третий случай – когда наречие с «не» в начале можно заменить синонимом:

неправильно/неверно – ошибочно
негромко – тихо
невысоко – низко
неистово – одержимо.

Вот и найден раздел правил, в соответствии с которым «неправильно» может писаться слитно.

Неправильно (неверно) всё это.

Он выполнил перевод неправильно (неверно).

Раздельное написание «не правильно»: когда это допустимо

Таких случаев два. Первый – если в предложении после «неправильно» идут запятая и союз «а» и происходит противопоставление.

Он написал предложение не правильно, а абсолютно неверно.

Ты говоришь по-английски не правильно, а с ошибками и ужасным акцентом.

Второй допустимый случай раздельного написания данного слова – когда перед «правильно» стоят: вовсе не, ничуть не, далеко не, нисколько не, отнюдь не.

Вовсе не правильно ты поступил.

Далеко не правильно он говорит по-русски.

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

Не высоко, а низко — не далеко, а близко.

Вовсе не высоко летит самолёт, он чуть не задел крышу.
Нисколько не далеко он живёт, его дом отсюда видно.

Правила относительно «не» с наречиями идентичны практически всегда, но есть исключения. Только раздельно без вариантов слитного написания – временные наречия: не летом, не завтра. Ещё раздельно пишутся всегда наречия в сравнительной степени – не меньше, не выше. Мерные и степенные наречия тоже ни при каких обстоятельствах не будут писаться слитно, примеры – не очень, не полностью.

Также всегда на письме раздельно – наречие «не иначе».

Я не знаю, когда мы поедем на море, но точно не летом.

Почему ты перевёл текст не полностью?

Ты сделаешь, как я сказал, не иначе.

Как правильно пишется Неправильно или не правильно — как пишется

В русском языке есть и неизменяемое наречие-предикатив «неправильно», и словосочетание «не правильно». Эти лексические единицы правильны в разных ситуациях, так что выбор подходящего варианта зависит от контекста.

«Неправильно». В большинстве случаев пишется слитно

В подавляющем большинстве случаев пишется слитно. Здесь действует общее правило про «не» с наречиями: пишем слитно, если наречие на -о или -е можно заменить синонимом без «не». Наречие «неправильно» можно заменить словом «ошибочно». Значит, пишем в одно слово.

Это было неправильно.

Вы говорите неправильно.

Меня неправильно поняли.

Вы, пожалуйста, не думайте только что-нибудь про меня неправильно. (А. П. Платонов. «Котлован»)

Если неправильно выберешь вино, весь обед покатится под откос, и все вы через два часа будете выглядеть, как свиньи. (Василий Аксенов. «Остров Крым»)

Но самая главная ошибка, ошибка роковая – неправильно выбранная главная задача в жизни. (Д. С. Лихачев. «Письма о добром и прекрасном»)

Я неправильно выразился. Значит ли это, что этот момент, эта граница между прошлым и будущим, и есть дверь в вечность? (Виктор Пелевин. «Чапаев и пустота»)

Наличие или отсутствие зависимых слов не отменяет слитного написания.

«Не правильно». Исключения – когда пишется раздельно

«Не правильно» пишется раздельно в нескольких случаях:

  • Если есть или подразумевается противопоставление с союзом «а»:
    Нет, это было не правильно, а ошибочно.
    Он произносил слова не правильно, а с ужасным акцентом.
    ― Правильно все. ― Нет, не правильно, ― торжествующе сказал я.
    (Борис Минаев. «Детство Левы»)
  • Если перед наречием есть слова-усилители — другие наречия или отрицательные местоимения: далеко не, отнюдь не, вовсе не, нисколько не, никак не.
    ― Ну, это ― напрасно, человека убивать никогда не правильно. (Максим Горький. «В людях»)
  • В вопросах с частицей «ли» или словом «разве»:
    Читатель, скажи, не правильно ли ее рассуждение?
    (Н. И. Новиков. «Живописец»)
    Так не правильно ли я говорю, пусть все одинаковую прибыль получают, что Алафузов, что я? (П. Д. Долгоруков. «Великая разруха»)
    Разве не правильно? Какие же государственные деятели из купцов? Мошенники они все, а не государственные деятели! (А. Б. Мариенгоф. «Мой век, мои друзья и подруги»)
    И никуда этот человек не девался. Разве не правильно говорю? ― Оно, пожалуй, так… ― Вот и ты так же, баню сделал, про жизнь рассказал. (Василий Белов. «Плотницкие рассказы»)

Впрочем, и при наличии этих усиливающих слов раздельное написание не обязательно. Это зависит от смысла, который вкладывает в предложение автор. Если логически подчеркивается отрицание — пишется раздельно: совсем не правильно = совсем не является правильным. Если подчеркивается утверждение (совсем неправильно = является совсем ошибочным), автор выбирает слитное написание:

Вот так примерно ― не знаю уж, правильно или не совсем правильно, а может быть, и вовсе неправильно, ― я его понял. (Аркадий Стругацкий, Борис Стругацкий. «За миллиард лет до конца света»)
― Дорогой мой, где же здесь решение? Ты ― просто ответы написал! ― Разве неправильно? ― удивился Славка.

(Владислав Крапивин. «Трое с площади Карронад»)

  • Если «не» относится не к слову «правильно», а к другой конструкции. Например, «если бы не»:
    Если бы не правильно тесаные камни, их бы признал за природный туннель. (Е.Л. Марков. «Очерки Крыма»)

    Здесь речь идет не о «неправильно тесаных камнях», а о «правильно тесаных» — так что присоединять наречие к «не» нельзя, это нарушит смысл высказывания.

«Не правильно» или «неправильно» — как правильно пишется, слитно или раздельно?

«Неправильно ты, дядя Федор, бутерброд ешь!» — говорил в известном мультфильме всеми любимый кот Матроскин. Да что греха таить: в нашей жизни мы делаем неправильно многие вещи, в том числе и пишем с ошибками слова из родного языка. Так, на просторах Рунета зачастую встречаются варианты неправильного написания наречий, в том числе и того, о котором сегодня пойдет наш разговор, — «неправильно».

Вообще правописание наречий, особенно тех, перед которыми стоит частица «не», — дело довольно сложно. Вот и «не_правильно» — не исключение. Напишешь его раздельно — выяснится, что сделал ошибку; в следующий раз, памятуя об этом, напишешь наречие слитно и вновь ошибешься. Почему? Дело в том, что, согласно правилам русской орфографии, оба варианта написания — и «неправильно», и «не правильно» — официально возможны, а их использование зависит исключительно от контекста. Давайте же разберемся, в каких случаях интересующее нас слово пишется слитно, а в каких — раздельно.

Наречие или краткое прилагательное «неправильно»

Как вы и сами можете убедиться, полистав книги и журналы, в подавляющем большинстве случаев наречие (или краткая форма прилагательного — в зависимости от предложения) «неправильно» пишется слитно. Как понять, что у вас как раз такой случай? Попробуйте заменить «неправильно» другим синонимичным словом без приставки «не-» так, чтобы смысл сказанного или написанного не изменился. Например, для замены можно использовать синоним «ошибочно».

Давайте рассмотрим несколько примеров:

Твое решение уравнения неправильно (= ошибочно). Он знал, что поступает неправильно, но ничего не мог с собой поделать (= ошибочно). Все ее существо восстало против подлого поступка, настолько это было неправильно (= ошибочно).

Если вам удалось провести перестановку без потерь, смело пишите «неправильно» слитно.

Наречие с отрицательной частицей «не правильно»

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

если в контексте присутствует противопоставление, обычно выраженное при помощи союза «а»: Твое решение уравнения не правильно, а ошибочно. если в предложении присутствуют слова «отнюдь», «вовсе», «далеко»: То, что она говорила, было отнюдь не правильно, но очень слаженно. Решать подобным образом свои проблемы было вовсе не правильно. Он поступил со своими коллегами совсем не правильно. если в предложении фигурируют местоимения или наречия с отрицанием: Бросать все и без предупреждения уезжать в другой город было ничуть не правильно. Нисколько не правильно так поступать. Никак не правильно звонить незнакомым людям в шесть утра!

Правильное написание:

если наречие «неправильно» можно заменить синонимом без «не», например словом «ошибочно», без искажения смысла, следует писать его слитно — «неправильно»; если наречие с частицей «не правильно» фигурирует в предложении с противопоставлением, рядом стоят слова «отнюдь», «вовсе», «далеко» или местоимения либо наречия с отрицанием («ничуть», «никак», «нисколько»), слово пишется раздельно – «не правильно».

«Абсолютно не правильно», 777NADIA777 — Advego.com

Тип текста: ЛюбойКопирайтингРерайтинг без источникаПеревод

Язык: ЛюбойRussian — РусскийEnglishGermany — DeutschSpanish — EspañolFrench — FrançaisChinese — 中国Ukrainian — УкраїнськаJapanese — 日本のPortuguese — PortuguêsPolish — PolskiItalian — ItalianoTurkish — TürkArabic — العربيةVietnamese — tiếng ViệtKorean — 한국의Urdu — اردوPersian — فارسیHindi — हिन्दीDutch — HollandskFinnish — suomalainenAnother language — другой язык

Тематика: ЛюбаяБез тематикиIT, софтАвиация, военная техника, ГОАвто, мотоАзартные игры, казино, покерБытовая техникаДизайн и предметы интерьераДомашние животныеДомашние растения, цветы, растительный мирЗакон и ПравоИгрушки, товары для детейИнтернет-маркетинг, SEO, SMM, создание сайтовИстория, религия, традиции и обрядыКиноКомпьютерные игры, видеоигры и приставкиКрасота и здоровье, питание, диеты, фитнесКулинарияКультура и искусствоЛандшафтный дизайн и архитектураМатериалы 18+Мебель и аксессуарыМедицина, лечение и профилактика болезнейМобильные игры и приложенияМода и СтильМузыкаНаука, открытия, высокие технологииНедвижимостьНепознанное: фэн-шуй, астрология, гороскопыОбразование, учеба, тренингиОтдых, активные игры, охота и рыбалкаОтношения, знакомства, личная жизньПолиграфия, рекламная продукция, маркетингПолитика: аналитика и обзорыПраздники и торжества, свадьбаПрирода и экологияПромышленность и оборудованиеПсихологияРабота и карьера, фрилансРемонт и обустройствоРукоделие, хобби, handmadeСад и огород, сельское хозяйствоСемья, воспитание детей, беременность и родыСобственный бизнес, ForexСпорт и спортивный инвентарь, велотехникаСтихи и поздравленияСтроительный инструмент и материалы, садовая техникаСтроительство домов, дачное хозяйствоТуризм, достопримечательностиУслуги и сервисФинансы, банки и кредиты, экономикаФототехника, искусство фотографииЭлектроника: гаджеты, мобильные телефоны, компьютеры, телевизорыЮмор

наречия и прилагательные с не.

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

Часть речи

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

Наречие «неправильно» обычно выступает в предложении в роли обстоятельства, отвечающего на вопрос «как?»:

  • Он тебя неправильно понял.
  • Обрати внимание на неправильно решенную задачу.

«Неправильно» как краткое прилагательное среднего рода (от полного «правильное») встречается в предложениях в роли сказуемого в полном предложении:

  • Их мнение неправильно.

Если «неправильно» входит в состав сказуемого, то оно является словом-состоянием:

  • Было бы неправильно ожидать быстрого результата.

Полные прилагательные с «не»

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

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

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

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

«Неправильно»: различные части речи с «не»

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

  • «Ты все понял неправильно». — Пишется слитно, так как «неправильно» тождественно по значению «ошибочно».
  • «Ты все понял не правильно, а ошибочно». — Пишется раздельно, так как есть противопоставление.
  • «Ты все понял совсем не правильно». — Пишется раздельно, так как есть усилительное слово.

Зависимость написания от смысла высказывания

На самом деле, при выборе верного написания «неправильно» или «не правильно», имеет большое значение смысл, вложенный автором в это слово.

Если «неправильно» употребляется как антоним слову «правильно», то слитное написание верно. В случае, когда полной противоположности слову «правильно» нет, требуется писать раздельно.

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

Более точно сказать, что в данном примере возможны оба варианта — «неправильно» и «не правильно». Раздельное написание будет верно, если автор вкладывает, например, такой смысл: «суть моих слов ты понял не правильно и не ошибочно, просто ты мыслишь немного иначе». Прямого указания на ошибку собеседника в таком предложении нет.

Таким образом, выбирая между слитным и раздельным написанием, важно обратить особое внимание на контекст.

вы делаете это неправильно / Хабр

Сегодня очень многие в разработке используют

ревью кода

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

На рынке есть куча инструментов для ревью кода с готовыми сценариями использования, рекомендациями и правилами. GitHub, Phabricator, FishEye/ Crucible, GitLab, Bitbucket, Upsource — список можно долго продолжать. Мы в Badoo тоже в своё время с ними работали: в своей предыдущей статье  я рассказывал нашу историю ревью кода и о том, как мы пришли к изобретению собственного «велосипеда» — решения Codeisok.

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

Именно поэтому другую часть айсберга можно и не заметить.

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

После прочтения этого вступления у вас может возникнуть вопрос: а что сложного в ревью кода? Дело-то плёвое. Тем более что большинство инструментов, перечисленных выше, сразу и флоу ревью предлагают (из коробки: поставил, закоммитил/ запушил — и вперёд!).

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

Когда-то давным-давно, когда я работал в другой компании, мне в память глубоко запала беседа о ревью кода с одним из ведущих разработчиков.
Это был p1lot. Возможно, кто-то из читателей знаком с ним (p1lot, привет :)). Сейчас он работает с нами в Badoo, и это здорово.

Так вот, PILOT тогда сказал: «Самое сложное для меня в процессе ревью — пойти на компромисс и пропустить готовую и корректно работающую задачу дальше, даже если я знаю другой способ её решения и даже если мой способ мне нравится больше». На мой взгляд, эта мысль является ключевой. И основной посыл всей моей статьи так или иначе вертится вокруг этого постулата.


У вас в компании есть ревью? Правильно ли вы его делаете? У меня есть тест, который, возможно, заставит вас усомниться в этом.

Нужно ответить всего на три вопроса:

  1. Сколько времени занимает ревью кода для средней (сферической в вакууме) задачи?
  2. Как вы минимизируете время ревью?
  3. Как вы определяете, что ревью конкретной задачи сделано правильно?

Если у вас нет внятных ответов на некоторые (или на все) вопросы, если вы сомневаетесь в своих ответах, то осмелюсь предположить, что что-то идёт не так.

Если вы не знаете, сколько времени потребуется на ревью, и не минимизируете его постоянно, то как вы осуществляете планирование? Возможна ли ситуация, когда исполнитель, который делал ревью четыре часа, не пил чай половину этого времени? Можно ли быть уверенным в том, что от задачи к задаче время на чаепитие не увеличивается? А, может, ревьюер вообще не смотрит код, а просто нажимает «Code is OK»?

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

Если же ответ на третий вопрос сразу не приходит в голову, то есть смысл задаться ещё одним. Знаете ли вы, зачем вам на самом деле нужен этот процесс? Потому что «так принято у всех больших ребят»? Может быть, он вам и не нужен вовсе?

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

Помните про готовые инструменты для ревью кода, предлагающие свои подходы и флоу? Мне, например, интересно, как бы ответили на вопрос разработчики этих инструментов. Будут ли коррелировать их ответы о «правильности» ревью с ответами ваших сотрудников? Не уверен. Иногда я грустно наблюдаю, как кто-то внедряет у себя инструменты ревью, ни на минуту не сомневаясь, что они необходимы. То ли люди делают это «для галочки», то ли чтобы отчитаться, что «ревью кода внедрили, всё хорошо». И в итоге забывают про это.

Не хочу быть Кэпом, но тем не менее. Общаясь с сотрудниками, обращайте внимание на ответы вроде «Потому что так заведено» или «Это же best practice, все так делают». Вы и сами отлично знаете, что не нужно бездумно внедрять какой-то процесс, не понимая, зачем он нужен. Любой процесс должен быть оправдан и внедрён (если необходимо) с поправкой на нужды бизнеса и проекта, а также на проблемы, которые действительно существуют и которые действительно хочется решить.

Карго-культу

в компании с хорошей инженерной культурой не место.

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

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

Тем же, кто остался, говорю спасибо и тем не менее предлагаю определить правильность ревью самостоятельно, исходя из нужд вашего проекта, тщательно всё обдумав. А я лишь попробую вам в этом помочь.

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

Обмен знаниями

На вопрос «Зачем нужен процесс ревью кода?» я очень много раз слышал ответ «

Для обмена знаниями

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

Я не раз спрашивал людей, что они имеют в виду под «обменом знаниями». И в ответ слышал разное.

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

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

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

Давайте пройдёмся по всем пунктам и попробуем оценить, насколько они уместны в процессе ревью.

Code review как инструмент обучения новичков

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

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

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

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

Например, если в компании нет отлаженного процесса обучения и коучинга, менеджер вынужден «бросить в воду» новичка. У последнего при этом не остаётся выбора: нужно либо «плыть», либо уходить из компании. Кто-то реально учится на таких ситуациях, а кто-то не выдерживает. Думаю, многие сталкивались с подобным на протяжении своего профессионального пути. Мой же посыл в том, что драгоценнейшее время может тратиться неоптимально из-за такого явления. Равно как и процесс адаптации нового сотрудника в команде может выполняться неоптимально. Просто потому, что ни у кого руки не дошли организовать эффективный процесс внедрения новых сотрудников в команду, и менеджер подумал, что новичок всему научится на этапе ревью кода. А на самом деле это два разных процесса, очень нужных и важных.

Конечно, даже при условиях, что правила изначально объяснены новичку и что в компании существуют другие процессы обучения, процесс адаптации новичка нужно как-то контролировать. Ревью — это один из процессов, который может помочь. Но контроль и обучение — это разные вещи, не так ли? Тем более что в контроле нуждаются все члены команды, а не только новички. Ведь все мы можем делать ошибки, забывать о договорённостях и так или иначе влияем на ту часть системы, которой владеет вся команда (в данном случае на код).

Какой можно сделать вывод? Описанный выше процесс направлен на достижение иной цели: не на обучение, а на контроль. И этот самый контроль необходим не только новичкам, а команде в целом.

Всё это легко формулируется в такой тезис: «Ревью кода необходимо, чтобы контролировать соблюдение договорённостей и общих правил всеми членами команды«. А обучение новичков в этом случае будет не чем иным, как искусственной подменой цели, которая только запутает людей и направит процесс в другое русло.

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

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

Продолжая разговор об обучении новичков в процессе ревью кода, проведём аналогию. Допустим, вы производите какой-то товар, например, торты. Допустим, вы получили заказ на торт для свадьбы VIP-персоны. Доверите ли вы «ревью» готового торта новичку? Готовы ли вы к тому, что новый кондитер возьмёт на себя ответственность за позор или успех всей пекарни на этой свадьбе? А может, вы хотите, чтобы он на этом этапе познакомился с правилами, принятыми в команде (как выпекать коржи, готовить крем и настаивать клюкву на коньяке)? Очевидно, что и процесс знакомства новичка с правилами, и контроль с его стороны — довольно странные вещи на данном этапе: торт-то уже испечён. Так почему же с фичами и кодом мы можем поступать по-другому? Или фичи, которые мы запускаем, не несут за собой позор или успех нашей команды в глазах пользователей и заказчиков?

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

Но во-первых, чему новичок научится на пустяковых задачах, в которых мало изменений кода (и эти изменения не в критичных местах и для бизнеса наверняка не столь важны, раз задача несрочная)? Как он может научиться печь торты, если всё время взбивает сливки? Переход от простого к сложному, конечно, нужен. Но делать это необходимо, тщательно контролируя процесс. Новичков нужно учить, а не бросать учиться самостоятельно.

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

Представим, что мы открыто заявляем, что задачи, которые нам даёт продакт-менеджер, нужны для обучения новичков. Почему? А так же, как с ревью кода: мы ведь поручаем некоторые простые и несрочные задачи новичкам, чтобы они научились работать так, как у нас принято.

К чему это может привести в итоге? Ретивый исполнитель, который добросовестно делает своё дело и считает, что всё, что он делает, должно быть сделано максимально хорошо, примется за процесс обучения. Он может поставить задачу сделать несколько реализаций вместо одной, чтобы потом показать обучаемому недостатки и преимущества разных подходов. Он может читать лекции, сравнивая подходы и best practices, применяемые в компании и за ее пределами. Он может много чего ещё предпринять, чтобы обучить новичка. В результате время, требуемое на реализацию задачи, будет всё увеличиваться, ведь вместо разработки мы фокусируемся на обучении.

В случае ревью кода такой ретивый сотрудник инициирует длинную дискуссию в комментариях к ревью о пользе и вреде тех или иных реализаций, постит куски кода со Stack Overflow, показывая, что в других головах бывают другие идеи, даёт ссылки на статьи и книги, которые обучаемый должен прочитать, чтобы понять, что его реализация неидеальна.

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

Если ваша компания — это не институт, не школа, не техникум и не какое-либо другое образовательное учреждение, то обучение — не ваша прямая обязанность. Бизнес нанял вас для решения других задач и достижениях других результатов.

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

Code review как свежий взгляд на код

Идём дальше. Следующий сценарий «обмена опытом» такой: мы в команде что-то делаем, соблюдая внутренние договорённости, и у нас замылился глаз, а тут пришёл новый человек (из другой компании или из другого компонента) — и, возможно, он увидит недостатки в нашей организации работы.

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

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

Очевидно нет, так как: 1) мы всегда делали без соды, и результат был неплохим; 2) возможно, покупатели берут торты именно у нас, а не в другой пекарне, потому что им не нравится привкус соды; 3) торт уже готов, свадьба сегодня вечером, а новый торт испечь мы не успеем.

Тогда зачем это всё? Делиться опытом надо. Свежий взгляд нужен. Но, как мне кажется, на другом этапе. Например, перед тем как печь коржи, можно уточнить у новичка: «А как вы делали это раньше? А почему этот способ лучше?» И, наверное, стоит испечь пару тортов по-старому и по-новому, чтобы дать нашим постоянным клиентам попробовать и узнать их мнение.

Бездумное внедрение best practices, увиденных в статьях или докладах, может нанести вред компании и продукту. «Соду добавляют в коржи все крупные игроки: „Бугл“, „Трейсбук“, „Райл.ру“, „Юмдекс“. Все так делают». И что? Из-за этого Петя должен немедленно взяться за переделку задачи, которая уже готова?

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

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

Ведь мы говорим об этапе ревью. Ревью кода, который уже написан и готов к переходу на следующий этап. Этот код ждёт нажатия ревьюером кнопки «Code is OK». И ваши заказчики совсем не готовы к тому, что вы будете препарировать испечённый торт с новым поваром, чтобы показать ему, как вы печёте торты и выслушать его критические замечания.

Code review как знакомство с частью кода

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

bus factor

: если разработчик уйдёт, другие смогут успешно работать с его кодом. А также мы готовы к тому, что в следующий раз этот код может «потрогать» кто-то другой, и в этом случае он уже будет знать, как с ним работать.

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

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

Допустим, он изобрёл какой-то крутой алгоритм сортировки (может, давно уже изобрёл и постоянно использует, а может быть, только что). Нужно ли, чтобы об этом знали все члены команды? Конечно, да. Нужно, чтобы люди узнали, что крутой программист Вася создал нереально быстрый и эффективный алгоритм сортировки, который будет полезен всем.

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

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

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

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

Чувствуете? То, что я описываю, это не процесс ревью кода — это процесс создания и одобрения общих практик и подходов. Совершенно иной процесс.

И на этом этапе снова могут всплыть best practices от коллег и «В моей прошлой компании это делали по-другому» или «Я читал, что это делают иначе». И что? Best practices в общем случае, для сферической компании в вакууме, могут быть подходящими. Означает ли это, что все они будут полезны в вашей компании? Как минимум не всегда. И уж точно это не значит, что кто-то должен немедленно переписать свой код, на написание которого уже потрачено время.

Соответствие любым абстрактным или внешним best practices, гайдлайнам, модным тенденциям и т. д. — каким-то правилам, которые оторваны от компании/ контекста — ради самого соответствия никому не нужно. «Статические методы считаются плохим тоном», «Такое теперь надо выносить в трейты», «Синглтон — плохая практика, лучше использовать фабрику и DI». Кому надо? Кем считается?

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

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

Во-первых, мало кто готов «прямо сейчас» отвлечься и оценить «грязность» хака, ведь все заняты своими задачами. А во-вторых, никто ничего не запомнит. Да и люди в команде меняются, и, если кто-то в будущем наткнётся на этот хак, у человека так или иначе возникнет вопрос: почему сделано именно так? И оптимальным решением будет добавление комментария прямо в код. Комментария, объясняющего причину, которая вынудила прибегнуть к такому хаку (вспоминаем правила хорошего тона при комментировании кода: мы описываем в комментариях не что мы делаем в коде, а почему мы делаем именно так).

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

Третий случай — это когда в задаче ничего супернового и грязных хаков нет. Она базируется на всех принципах и правилах, принятых в команде, оформлена в соответствии с общими стандартами и т. д. Так зачем же тогда на неё отвлекаться всей команде? Ведь никакого bus factor нет, и, если кому-то другому придётся работать с этим участком кода в будущем, он без труда в нём разберётся.

Ну и, наконец, если мне всё ещё не удалось вас убедить, то у меня вопрос: как понять, что обмен знаниями в процессе ревью произошёл?

— Петя, ты прочёл код, который написал Вася?
— Прочёл.
— Всё понял?
— Всё понял.

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

Более того, где уверенность в том, что в следующий раз работать с этим участком кода будет именно Петя, который делал ревью, а не Эдуард, который сейчас делает ревью задачи Арсения с совсем другим компонентом?

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

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

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

Code review как документация

Ещё один вариант ответа на вопрос «Зачем нужно ревью кода?» был про документирование. Тут может быть не совсем очевидно, что имеется в виду, поэтому поясню.

Сценарий подразумевается такой: разработчик и ревьюер кода о чём-то договорились в комментариях к ревью, и в будущем, если у кого-то возникнет вопрос о том, почему в данном месте сделано именно так, информацию об этом можно будет найти в ревью. То есть по git blame найти коммит, по коммиту найти тикет, по тикету найти ревью, в ревью найти обсуждение, изучить его и понять, почему сделано именно так.

Получается, что разработчик, у которого и так много источников информации — стандарты и соглашения, техническое задание, тикет в багтрекере, сам код (с комментариями или без) — должен лезть ещё в один. И читать весь тред, пытаясь уловить нить беседы и понять причины, побудившие сделать именно так. Причём мнения сторон в этом треде могут измениться  несколько раз. Звучит странно, не правда ли?

Но вопросы

действительно

могут возникнуть. Что делать в этом случае?

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

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

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

Даже если возникла ситуация, когда комментарии нужны и будущим поколениям стоит о них знать, в этом случае лучше оставлять их в коде или тикете — в тех источниках информации, которые у разработчика уже есть. Зачем вводить новый (тем более со всей историей переписки)?

В тикете можно написать «Решили сделать так-то по таким-то причинам» как итог всех обсуждений. Так и читать понадобится меньше, и много времени у интересующегося разработчика не отнимет. Ну и информацию при необходимости разработчик сможет получить.

Вывод напрашивается сам собой: использовать ревью кода как источник документации не стоит. Этот процесс нужен для другого.

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

мнений

.

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

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

Следовательно, я бы выделил следующие моменты, которые обязательно должны быть проконтролированы на этапе ревью:

Архитектура и дизайн решения

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

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

Также стоит иметь в виду, что это один из самых сложных, ответственных и трудоёмких моментов в ревью кода. Человек, выступающий в роли ревьюера, должен быть готов идти на компромиссы и помнить о том, что идеальных решений не бывает. И если он видит в задаче решение, которое по тем или иным причинам считает неидеальным, то он должен в первую очередь примерить его на нужды бизнеса, а не на свой перфекционизм.

Ревьюер может предложить свою реализацию, которую он считает более правильной с точки зрения best practices, паттернов и других вещей. Но тут очень важно понимать, что решение, которое он видит в коде, лучше его собственного уже одним лишь тем, что оно готово. Оно уже написано. Разработчик потратил своё время на реализацию, интеграцию этого куска кода с другими элементами, тестирование и написание автотестов и так далее. И исправлять код следует только в том случае, если решение заведомо неправильное.

Соблюдение правил и соглашений, принятых в команде

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

Чтобы это не сказывалось на ежедневных задачах, чтобы любой участник команды мог как можно быстрее вникнуть в код и задачу другого, устанавливают командные соглашения. Начиная со стандартов оформления кода, структуры папок и файлов проекта и заканчивая формализацией API-методов и запретами на использование тех или иных конструкций языка. Таким образом обеспечивается и поддерживаемость кода, и уменьшение риска возникновения bus factor, и много что ещё.

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

Корректность решения

Имеет ли решение какие-то недостатки? Опечатки в коде,

магические числа

и другие неопределённые константы.

Магические строки

и другие неожиданные данные, которые программист не учёл при решении задачи.

Проверки на null

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

информационной безопасности

и так далее.

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

Тестируемость кода и наличие юнит-тестов

Данный этап проверок также очень важен, ведь он направлен на улучшение той самой пресловутой

поддерживаемости

кода.

Многие понимают, что означает термин code maintainability, но далеко не все могут объяснить, что это такое. А раз так, то как тогда ставить задачу команде на поддержание этой самой maintainability? Поэтому я считаю, что разработчик, подумавший о том, как его код будет тестироваться, а уж тем более тестирующий собственный код и написавший автотест для автоматизации тестирования, естественным образом будет стремиться к тому, чтобы его код удовлетворял большинству критериев code maintainability. Ведь без этого написать автотест практически невозможно.

Общей рекомендацией к любому изменению кода также может быть правильная декомпозиция задач. Чем меньше объём кода, проходящего через конвейер всех процессов от идеи до продакшена, тем легче этот код проверять на соответствия, тестировать, объединять с кодом других задач и выкладывать. Ревью кода — не исключение. Задачу с большим количеством изменённых строк во многих файлах очень тяжело читать и понимать (и удерживать в голове зависимости). Риск и цена исправления недочётов могут быть очень высокими.

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

И напоследок дам ещё несколько советов.

Важно помнить, что любой возврат кода на доработку не лучшим образом сказывается на качестве реализации. Даже если все действуют из лучших побуждений. В случае ревью кода это работает так: разработчик правит код, но тестирует его уже не так тщательно, как в первой итерации (зачем? Ведь он уже всё проверил, а изменил совсем чуть-чуть). Опыт показывает, что большинство таких ситуаций оборачивается багами именно в тех местах, где были правки по результатам ревью кода. Так работает человеческая психология.

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

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

Есть и ещё один важный момент: те процессы, правила и ценности, которые справедливы для одной компании, могут быть не столь полезными и работающими в другой. То, что я описал как примеры правильного ревью, работает в нашей компании. Мы пропагандируем быструю разработку, частые релизы и делаем ревью для каждой задачи. Подумайте о том, насколько это применимо к вашему проекту, и о том, что ревью — это один из тех процессов, которые пускать на самотёк нельзя.

Но решение, конечно, остаётся за вами.

Если iTunes не может подключится к серверу обновления ПО для iPhone, iPad или iPod

Узнайте, что делать, если iTunes не может подключиться к серверу обновления ПО, когда вы пытаетесь восстановить или обновить iPhone, iPad или iPod.

Когда вы используете iTunes для обновления или восстановления iPhone, iPad или iPod, может появиться предупреждение о том, что iTunes не удалось подключиться к серверу обновления ПО, так как отсутствует подключение к Интернету. Будет рекомендовано проверить активность подключение к Интернету и повторить попытку. Для устранения неполадок при вызовах выполните указанные ниже действия.

Обновление или восстановление устройства iOS без использования iTunes

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

Если такая ситуация не возникла, можно обновить или восстановить устройство iTunes, выполнив следующие действия.

  1. Отключите устройство iPhone, iPad или iPod touch от компьютера. 
  2. На устройстве включите Wi-Fi. Рекомендуется подключится к сети, а не к персональной точке доступа пи загрузке обновлений ПО.
  3. Обновите устройство, выбрав «Настройки» > «Основные» > «Обновление ПО».  

Если это не устранит проблему, перейдите к следующему решению.

Подключение к Интернету и iTunes Store

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

  • Если не удается подключиться к Интернету, обратитесь за помощью к администратору компьютера или к интернет-провайдеру. Или попробуйте использовать другой компьютер или сеть.
  • Если удается подключиться к Интернету, но появляется сообщение об ошибке при попытке подключиться к iTunes Store, поищите решение возможных проблем iTunes Store.
  • Если удается подключиться к Интернету, но iTunes Store показывает пустую страницу, определите и удалите ПО многоуровневого поставщика услуг (LSP).

 Если эти решения не устраняют проблему, отредактируйте или сбросьте файл hosts.

Изменение или сброс файла hosts

Файл hosts может блокировать доступ к серверу обновления ПО. Ниже описан порядок редактирования и сброса файла hosts.

На компьютере Mac

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

  1. В Finder выберите «Программы» > «Утилиты» > «Терминал» в строке меню.
  2. В программе «Терминал» введите следующую команду и нажмите клавишу «Ввод», чтобы открыть файл hosts:
    sudo nano /private/etc/hosts
  3. Когда появится запрос, введите пароль пользователя. Обратите внимание, что в окне программы «Терминал» ничего не отображается при вводе пароля.
  4. Используйте клавиши со стрелками на клавиатуре для навигации по файлу hosts.  
  5. Если какая-либо строка включает apple.com, добавьте символ номера (#) и пробел в начале этой строки.
  6. Чтобы сохранить файл hosts, нажмите клавиши Control-O.
  7. Когда появится запрос имени файла, нажмите клавишу «Ввод». 
  8. Чтобы выйти, нажмите клавиши Control-X.

Если это не решит проблему, возможно, устарело или неправильно настроено ПО безопасности. Можно устранить проблемы между iTunes и ПО безопасности.

На компьютере с ОС Windows

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

Дата публикации: 

Если это бесплатно, это может быть неправильно написано

        Вы получаете то, за что платите. Я обвиняю The Free Dictionary в неправильном написании слова «звукоподражание» (две недели назад; может быть, вы заметили).

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

        Затем я провел поиск в Интернете с одним из моих случайных вариантов написания. Бесплатный словарь появился в верхней части списка поиска и дал определение «онамонапии». Мне даже не пришлось заходить на сайт. Ошибка.

        Вот как они вас втягивают. Они принимают необычное написание и сразу же дают базовое определение. Вам кажется, что вы правильно написали слово. Они надеются, что вы зайдете на их сайт (и прочитаете их рекламу).Тогда и только тогда вы «перенаправляетесь» к правильному написанию слова.

        После того, как один из моих лучших критиков (сам ужасный орфограф) спросил меня о моем варианте написания «онамонапия», я проследил свои шаги и пошел еще дальше:  Я посетил сам сайт The Free Dictionary. Вы получаете не только правильное написание (слишком поздно, чтобы помочь мне), но и определения из нескольких словарей. Я насчитал пять, и ни один из них не был «Свободным словарем». Эти люди, очевидно, не видят смысла собирать словарь самостоятельно — слишком много работы — когда можно цитировать другие онлайн-словари.Это граничит с плагиатом, но это не так. Это бесплатно для всех.

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

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

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

        Нехватка сложных кухонных работ, вероятно, является причиной того, что манго так популярны, как никогда. Это кулинарный эквивалент похода в спортзал. К тому времени, когда вы очистите и отрежете одно от этого чудовищного несговорчивого семени, вы почувствуете, что чего-то достигли. Давай манго.

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

        Да, жизнь становится настолько простой, что у The Free Dictionary возникнут проблемы с поиском определений слова «работа», особенно после того, как McDonald’s будет автоматизирован, а роботы возьмут на себя и все остальное.

        Я рад, что помню работу.

        Заключительное задание:

        Поищите слово «wirk», пока это слово все еще трудно найти. Это будущее.

Ханаба Манн Уэлч, корреспондент Times Record News, которая делит свое время между Абилин и фермой к северу от Вернона, появляется по понедельникам.Ее колонки, как дань уважения Чайлдрессу Engine 501, всегда содержат, как ни удивительно, 501 слово.

       

Как пишется?

Никто на самом деле не уверен — Каддафи, Каддафи, Каддафи?

ДЖИЛЛ КАЛАС

Как насчет политики нулевой терпимости к орфографическим ошибкам? Слова должны быть написаны правильно, все это понимают, за исключением, может быть, всех юнгстеров, переписывающих свои миниатюры, или даже тех, кто отправляет электронные письма и чаты из своих чатов, все эти LOL, OMG и Cuz, которые удешевляют язык.Теперь проще с проверкой орфографии и всем остальным, но у проверки орфографии есть свои ограничения. Одна из проблем заключается в неправильном написании слова, которое оказывается правильным написанием другого слова. Представьте себе следующую несколько некорректную расшифровку разговора по мобильному телефону: Я слышу вас громко и ясно — я вас очень хорошо понимаю, ясно, и я буду их рыцарем вторника… а пока оставайтесь грубыми. Либо так, либо я свяжусь с тобой по мужской линии.

Такое письмо может начинаться: Deer, John (или John Deere).
Кроме того, часто встречаются слова, которые не распознает проверка орфографии, поэтому выход из ситуации — выйти в Интернет и посмотреть, как пишутся слова в Интернете.Проблема в том, что вы получаете все неправильные варианты написания вместе с правильными, а затем должны решить, что есть что, и иногда это не вопрос правильного или неправильного, правильности конкретного написания, а то, что никто не может договориться о том, как слово пишется в первую очередь. Это лингвини или лингвини? Кажется, никто не знает, уж точно не итальянские рестораны. А как же Ханука — или это Ханука? (Спросите своего раввина). А что такое Chautauqua? У вас также есть все эти иностранные топонимы — что наводит на мысль, почему они называют это уткой по-пекински, если сейчас это Пекин или это Пейчин.или, вернее, Пипинг — неужели они не могут решиться? А как же Мумбаи — что не так с Бомбеем? Или Калькутта, теперь Калькутта? Никогда не было возможности посетить, и они уже изменили название. Кошмар, если вы путешествуете со старой картой.
В английском языке один и тот же звук часто пишется по-разному, это еще одна проблема. Двойной звук Е (ее), например, может быть записан (или написан по буквам, но это тоже крупица): казаться или шов, команда или кипеть, а затем безмятежный, морской, белок вместе со словами, такими как она, лыжи, обломки. , и ключ, не говоря уже обо всех иностранцах, или, вернее, о людях, вместе с вами и мной, которые должны помнить, какое написание правильное.Сводя с ума.

Английский также по-разному пишет другие звуки в разных словах. Рассмотрим звук SH, как в обуви, но тогда у нас есть тот же звук в аукционе, профессии, отпуске и вкусняшке. Как насчет того, чтобы начать тренд прямо сейчас, написать его по буквам «восхитительный» и посмотреть, приживется ли он?

Однако при этом вы можете не добиться успеха или превзойти ожидания, и это проблема, потому что, если вам нужно написать эти слова, это заставляет вас неправильно писать другие слова, например, предшествовать (не предшествуть), и то же самое касается замены.
С большими пальцами и всем остальным есть вероятность, что будут напечатаны ошибки, которые вызовут путаницу. Кто-то может отправлять текстовые инструкции о том, что правильно носить, и это может сводиться к разнице между одеждой и шиной — вы рисуете мысленный образ? Если вам говорят надеть шину, выберите белые стены, очень стильные, например, базовый черный цвет с жемчугом.

И, кстати (разберитесь с этим), если вы считаете, что эти текстовые и орфографические вещи не являются проблемой, загрузите эту запись из Патентного ведомства США с пометкой Исправление ошибок коротких текстовых сообщений для программного продукта, который предоставляет исправление для те, кто все пальчики оближется при наборе:

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

Когда дело доходит до орфографии, громадным словом на все времена является имя будущего бывшего диктатора Муамара Каддафи — я имею в виду Муаммара Каддафи, или, скорее, Муаммара аль-Кадафи, или Муммара аль-Кадаффи? Или, в капюшоне, просто Мо Даффи (после ухода из диктатора, позора для человеческой расы, которым он является, и становления исполнителем хип-хопа, такой же позор — и поэтому он позже меняет свое имя на I Be Daffy, а впоследствии Я Мо Даффи).

Другие варианты написания имени диктатора включают: Salt Water Taffy, Ricki Tiki Tavi, Moe Larry Curly, Daffy Duck и Won’t Somebody Please Off This Guy.

Как вести себя, когда люди неправильно называют ваше имя

После последнего занятия в выпускном классе профессор Мары Холландер спросил ее, как правильно произносить ее имя. Неважно, что они вместе четыре года учились на курсах, и никто в этих комнатах по-прежнему не произносил это неправильно. Буквально через несколько дней он вручил ей награду и сказал это неправильно, при всех. Поздравляем.

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

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

Что же делать людям, когда случается неизбежное?

Предотвратите ошибки

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

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

Вы также можете включить фонетическое написание или другой забавный совет в свою биографию на платформах социальных сетей. Дюран указывает на Селесту Нг, например, автора книг «Все, что я никогда не говорил вам » и «Везде тлеют пожары », чей псевдоним в Твиттере — @pronounced_ing. Ива Диксит, координатор социальных сетей The New Yorker , пишет в своей биографии в Твиттере, что «это произносится Диксит как в Fix-it; ива как в Gen-eva.

Не бойтесь исправлять людей

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

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

Muse Карьерный тренер Элоиза Эоннет использует несколько иной подход, когда дело доходит до электронной почты. Она говорит, что вы, возможно, захотите пропустить первую ошибку, если это опечатка, оплошность автокорректора или просто честная ошибка со стороны занятого человека. Если это произойдет снова, вы можете добавить скобки (например, «Элоиза (с буквой S!)») или постскриптум («PS Мое имя часто автоматически исправляется на букву Z, но я хочу убедиться, что вы знаете, что оно пишется с буквой S. »).

Вы можете использовать ту же стратегию, если хотите, чтобы кто-то знал, что вы идете по прозвищу, говорит Эоннет, вспоминая электронное письмо, которое она получила от Роберта, которого она встретила, который подписал его: «Роб (я Роберт, когда я м в беде).

Используйте повторение и совет, чтобы помочь людям запомнить

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

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

Итак, они работали над вступлением, которое звучит примерно так: «Привет, меня зовут Джулия, я из Испании, так что скажи это с буквой Н впереди, Джулия». (Если вы все еще пытаетесь представить это, подумайте, как Хулио или Хосе.)

Практикуйтесь в исправлении людей

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

Не сдавайся

Если вы не набрались смелости, чтобы исправить кого-то в первый раз, или вы сделали, но они все еще ошибаются, надежда еще не потеряна. Дюран призывает людей быть настойчивыми, обращаясь к ним примерно так: «Эй, ничего страшного, но ты трижды произнес мое имя и все еще ошибаешься.

Eonnet рекомендует использовать формулировку «Я заметил». Чтобы вернуться к Джулии, она могла сказать: «Я заметила, что ты называешь меня Джулией. На самом деле, это Джулия, вы говорите это с небольшой буквой «Х» впереди, Джулия». Вы также можете попробовать: «О, черт возьми, ты знаешь, я не нашел времени, чтобы сказать тебе, что на самом деле меня зовут Джулия».

Сделайте глубокий вдох

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

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

Не забывай, когда ты на другой стороне

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

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

«Мне нравится, когда люди спрашивают меня, как произносится мое имя, даже если я знаю их целую вечность, потому что это показывает мне, что правильное произношение имеет для них значение», — говорит она.«Мне потребовалось некоторое время, чтобы понять, что я должен применять это и в противоположном направлении (жаль, что у меня не было этого прозрения десять лет назад…). Так что теперь я иногда прошу людей, которых знаю некоторое время, заново научить меня их именам, если я чувствую, что могу лучше».

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

В эпоху проверки орфографии и автокоррекции имеет ли значение, что мой сын не умеет писать?

Однако по дороге в среднюю школу произошел забавный случай. Хотя я думал, что его пристыдят за его отвратительное правописание, и боялся, что будущие работодатели будут сторониться его, я заметил, что он не одинок. Некоторые умные друзья также плохо писали. Раздаточные материалы с домашним заданием от учителей содержали орфографические ошибки. Мы видели, как многие компании допускают большие шутки, а орфографические ошибки правительства стали настолько частыми, что новостные агентства отслеживают их, как бегущую ленту. (Неужели всего поколение назад Дэн Куэйл мог потерять шанс стать президентом из-за неправильного написания слова «картошка»?)

История продолжается под рекламой

В эпоху, когда мы LOL и ROFL, где вместо этого мы передаем через Siri и Alexa набора текста, где автокоррекция исправляет и создает ошибки в нашей письменной работе, мы должны задаться вопросом: может ли кто-нибудь писать больше, и имеет ли это вообще значение?

Похоже, что ответ меняется со скоростью — ну, со скоростью нового поколения.

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

В начальных школах государственные тесты на знание «редко включают прямые измерения правописания», хотя это считается частью общей оценки письма, говорит Роберта Прайс Гарднер, доцент кафедры чтения и грамотности в Университете штата Кеннесо и председатель начальной школы. руководящий комитет Национального совета учителей английского языка.

История продолжается под рекламой

Мы определенно не преподаем правописание в школах так, как раньше, отчасти из-за национальных стандартов Common Core, выпущенных в 2010 году.

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

Хорошо, в этом традиционном списке-запоминание оказалось не так хорошо. (Хотел бы мы знать это в первом классе.)

Но это плохо в других отношениях.

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

История продолжается под рекламой

«Правописание — это способ доступа к смыслу», — сказала она.Он связан с частями мозга, отвечающими за исполнительные функции и самоуправление.

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

Большинство детей теперь изучайте орфографию в детском саду и до второго класса в рамках более крупных тем, таких как фонетика и чтение.В этом есть смысл: хорошие читатели обычно хорошо пишут.Однако многие дети нуждаются в более целенаправленных подходах, в том числе многие из примерно 1 из 5 учащихся с нарушением обучаемости. При ограниченном школьном бюджете и естественной тенденции избегать преподавания того, что мы не проверяем, орфография не имеет большого значения.

Плохая орфография имеет на удивление мало значения для некоторых вещей. По данным Совета колледжей, который проводит экзамен, орфографические ошибки не засчитываются учащимся в части эссе SAT. Саша Фаваз из Kaplan Test Prep сообщила в электронном письме, что он мало учитывает другие стандартизированные тесты, хотя студенты ошибочно полагают, что это не имеет значения в других частях заявлений в колледж, включая личные эссе, где ошибки могут реально снизить их шансы.

Продолжение истории под рекламой

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

Алекса, автокоррекция букв

Больше всего на свете технологии меняют все.

В средней и старшей школе учащиеся начинают говорить что-то вроде «Мне не нужно тратить на это время, потому что я могу спросить Siri», — сказал Гарднер.«Я даже виноват в этом. Я использую Grammarly. … Мы с меньшей вероятностью будем самостоятельно контролировать свое правописание, потому что знаем, что компьютер сделает это за нас».

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

Продолжение истории ниже объявления

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

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

История продолжается под рекламой

Технологии приводят к новым моделям поведения: «Поведение, которое мы наблюдаем в отношении орфографии, — это сокращение», — сказал Уобброк. Люди знают, что если они наберут первые несколько букв слова, оно будет завершено. Интеллектуальное письмо, когда вы можете одобрить предложенное компьютером предложение, также развивается.

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

Преобразование речи в текст «всегда будет подвергаться определенным социальным ограничениям, ограничениям конфиденциальности. . . . Я не верю, что наступит день, когда мы будем говорить только со своими машинами», — сказал он.

«Я не уверен, что есть хороший способ говорить об этих вещах вне контекста, в котором мы находимся. Я не думаю, что мы когда-либо захотим быть в каком-то месте — и я не думаю, что люди в месте — где формальное общение… [прощается] за проблемы, опечатки и ошибки».

История продолжается под рекламой

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

Возможно, это планка, которая снижается, и задача состоит в том, чтобы научить детей достаточному количеству базовых навыков правописания, чтобы использовать технологии. (Хотя, как сказал Уобброк: «Ожидания пользователей меняются. И есть небольшая гонка, поскольку технологии улучшают, наши ожидания растут, и тогда мы становимся немного неряшливее».)

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

История продолжается под рекламой

Боюсь спросить, может ли он написать слово «картошка», но — даже без орфографического трофея — он все еще может однажды стать президентом.

Ребекка Денн — писатель-фрилансер из Сиэтла. Найдите ее в Твиттере @RebekahDenn .

Написано aria-labelby | Статьи

Это просто небольшое замечание по правописанию. Спецификация для aria-labelledby определяет правильное написание атрибута как «aria-labelledby», в отличие от ожидаемого U.S. Английское правописание, «ария-помечено». Судя по всему, одобренное написание было выбрано для того, чтобы минимизировать трудности для разработчиков . Однако видя, как легко найти примеры в дикой природе, где атрибут пишется как «aria-labeledby», можно предположить, что, возможно, некоторые трудности для разработчиков остаются.

Поддержка браузера и специальных возможностей API

Internet Explorer 8 поддерживает оба варианта написания, т. е. «aria-labeledby» и «aria-labeledby». Независимо от написания атрибута, IE8 передает значение атрибута в MSAA специальных возможностей API , что позволяет поддерживать вспомогательные технологии, такие как программы чтения с экрана, для создания доступного имени соответствующего компонента с использованием этого значения.

Обновление

(7 марта 2011 г.): Спасибо Стиву Фолкнеру за то, что он все прояснил (см. комментарий Стива ниже). На самом деле оказывается, что IE не поддерживает неправильное написание «aria-labeledby», а вместо этого, в отсутствие надлежащей метки, строит доступное имя компонента, используя любой текст, существующий внутри компонента. Вы можете прочитать мой ответ Стиву, в котором объясняется, как я пришел к этому ложному выводу об IE. Это хорошая новость, в конце концов.

Firefox 3.6, с другой стороны, поддерживает атрибут только в том случае, если он правильно написан в соответствии со спецификацией. Значение атрибута передается как в MSAA, так и в API специальных возможностей IA2 , которые Firefox поддерживает только в том случае, если атрибут записан как «aria-labelledby». В противном случае, если атрибут написан как «aria-labeledby», вспомогательные технологии, работающие поверх Firefox, не смогут создать доступное имя для связанного компонента.

Это в правописании

Если вам нужна дополнительная причина для написания атрибута в соответствии со спецификацией, пусть это будет то, что Firefox поддерживает его только тогда, когда он написан как «aria-labeledby».Если он написан как «aria-labeledby», любые преимущества доступности, предполагаемые с помощью атрибута, будут потеряны для тех, кто использует Firefox, который является предпочтительным браузером для многих, особенно для тех, кто использует программу чтения с экрана NVDA .

Эта разница в поведении двух браузеров и информации, которую они предоставляют API доступности, также помогает объяснить результаты двух приведенных ниже тестов.

Тест №1:

aria-labeledby написано правильно

Ниже приведен ARIA alertdialog , на метку которого ссылаются с помощью aria-labelled by , написанного в соответствии со спецификацией.

Этот пример alertdialog требует, чтобы JavaScript был включен.

Открыть диалоговое окно предупреждений #1

метка диалогового окна предупреждений № 1

Закрывать

Результаты теста №1

  • В Firefox 3.6 программы чтения с экрана NVDA 2011.1b2 и JAWS 12 объявляют упомянутую метку «alertdialog #1 label» при чтении диалога.
  • В IE8 JAWS 12 объявляет метку, на которую указывает ссылка, при чтении диалогового окна, но NVDA 2011.1b2 не объявляет ни метку диалогового окна, ни его текстовое содержимое.

Тест №2:

aria-labeled by написано неправильно

диалоговое окно предупреждений , метка которого упоминается с использованием aria-labeled by , написана неправильно в соответствии со спецификацией.

Этот пример alertdialog требует, чтобы JavaScript был включен.

Открыть диалоговое окно предупреждений № 2

метка диалогового окна предупреждений № 2

Закрывать

Результаты теста № 2

  • В Firefox 3. 6, NVDA 2011.1b2 и JAWS 12 не произносят метку, на которую делается ссылка, «метка диалогового окна предупреждений #2» при чтении диалогового окна.
  • В IE8 JAWS 12 объявляет метку, на которую указывает ссылка, «метка диалогового окна предупреждения #2», в то время как NVDA 2011.1b2 не объявляет ни метку диалогового окна, ни его текстовое содержимое. Обновление (7 марта 2011 г.): на основе тестов Стива Фолкнера стало ясно, что JAWS в IE считывает текст метки только как часть большей последовательности всего текста, содержащегося в диалоговом окне, и не объявляет его как явная метка, как таковая.

Напишите как указано

Несмотря на то, что в некоторых случаях aria-labelledby поддерживается, когда пишется как «aria-labelledby», вероятно, лучше просто перестраховаться и написать «aria-labelledby», как определено в спецификации.Вы не только будете следовать стандарту, но и, что более важно, пользователи Firefox со вспомогательными технологиями, поддерживающими ARIA, выиграют. Обновление (7 марта 2011 г.): вопреки моему первоначальному заключению, IE не поддерживает написание «aria-labeledby». Однако, по-видимому, разрабатываемая версия Google Chrome поддерживает оба варианта написания. Я не смотрел на это, но на данном этапе поддержка специальных возможностей Chrome все еще находится в разработке.

5 слов со странным написанием, потому что кто-то ошибся в этимологии

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

На заре книгопечатания правописание сильно различалось. Поскольку стандарт начал развиваться в 16 веке, мода на все классические вещи заставила некоторых людей обратиться к латыни и греческому языку для вдохновения в написании орфографии. Так, например, слово долг , которое записывалось как dette с тех пор, как оно было таким образом заимствовано из французского языка, было заменено молчаливым b , чтобы лучше показать его окончательное происхождение от латинского debitum. .

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

1. Ножницы

Откуда взялись эти sc в ножницы ? Раньше мы писали это sissors или sizars . Классификаторы 1500-х годов думали, что это слово восходит к латинскому scindere , разделять, но на самом деле оно пришло к нам (через французский язык) от cisorium , «режущий инструмент». То же предположение превратило сайт в косу .

2. Остров

Ненужный s был дарован iland для того, чтобы сделать более понятной связь с латиницей insula .Только остров произошел не от insula , а от древнеанглийского íglund .

3. Ache

Ache происходит от древнеанглийского глагола acan . Было родственное существительное atche (другие такие пары включают говорить/речь, ломать/нарушать, пробуждать/смотреть). Правописание остановилось на аче из-за ошибочного предположения, что оно связано с греческим ахос (горе, боль).

4. could

В староанглийском прошедшем времени can не было l , но should и would (как прошедшее время will 900) сделал. l втыкали в can в 15 веке по аналогии с двумя другими.

5. Sovereign

Когда английский заимствовал soverain из французского, у него не было g . Слово образовано от латинского superanus , «высший» (от super , «выше»). Слово царствование , однако, происходящее от латинского regnare , имело в себе g , и оно очень легко превратилось в соверен .

«Дилемма» или «Дилемна»? | Grammar Girl

У вас есть проблемы с правописанием слова «дилемма»?

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

Неправильное написание («дилемна») встречается в нескольких книгах в Google Book Corpus — не во многих книгах — оно достигло своего пика примерно в 1980 году и с тех пор снизилось, но это то, что я могу назвать только «серьезными публикациями»: судебные отчеты, книги, которые выглядят так, как будто они вышли из академических изданий, журнальные статьи и так далее. Это те вещи, которые, вероятно, написаны хорошо образованными людьми, но также, вероятно, не подвергались тщательному редактированию.

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

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

Эффект Манделы

Купить сейчас

Как партнер Amazon и книжный магазин. org, QDT зарабатывает на соответствующих покупках.

Если мы все ошибаемся — а мы можем ошибаться, поскольку я никогда не видел доказательств того, что меня учили неправильному правописанию, и никто другой, похоже, тоже не приводил доказательств — это может быть примером того, что называется эффектом Манделы. . Это форма коллективного неправильного запоминания: когда многие люди помнят одно и то же, но все они ошибаются. Явление получило свое название, потому что оно было впервые описано в 2010 году, когда многие люди утверждали, что помнят похороны Нельсона Манделы по телевизору.Проблема была в том, что он был на самом деле все еще жив. Он умер в 2013 году.

Как что-то подобное могло произойти с написанием слова «дилемма»?

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

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

Майкл Куинион на своем веб-сайте World Wide Words предполагает, что это также может быть опечатка по сравнению с менее щекотливыми словами «mn», такими как «осень», «торжественный» и «колонна». И он нашел примеры в респектабельной литературе, начиная с 1700-х годов, и отмечает, что, поскольку «мм» и «мн» выглядят так похоже на странице, было бы особенно трудно заметить эту конкретную орфографическую ошибку или опечатку.

И затем, независимо от того, как опечатка засела в нашем сознании, может быть, когда мы сталкиваемся с другими людьми, которые пишут слово с такой же ошибкой, мы создаем настоящие воспоминания о том, что нас неправильно учили в школе. Должно быть, так и произошло, верно? Как еще мы оба могли ошибаться одинаково? Это одно из возможных объяснений нашего коллективного неправильного запоминания, но я все еще надеюсь, что кто-нибудь найдет доказательство того, что нас всех учили неправильному правописанию!

И еще одна проблема со словом «дилемма»:

«Дилемма»: выбор между двумя плохими вариантами?

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

Префикс «ди-» в слове «дилемма» означает «два» или «двойной», что поддерживает идею о том, что «дилемма» должна использоваться для описания выбора между двумя и только двумя альтернативами. Associated Press и журнал Garner’s Modern American Usage поддерживают это ограничение и идут дальше, заявляя, что «дилемма» должна использоваться только для выбора между двумя плохими вариантами.

Тем не менее, Гарнер также признает, что другие варианты использования «повсеместны». В Словаре английского языка Merriam-Webster и в Руководстве Колумбийского университета по стандартному американскому английскому говорится, что слово «дилемма» можно использовать для описания любого серьезного затруднения, а Руководство по современному использованию и стилю американского наследия занимает промежуточную позицию.Что делать писателю? (Это дилемма?)

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

Чтобы помнить, что слово «дилемма» лучше всего используется для выбора между двумя вещами, и помнить, что оно пишется с двумя М в середине, подумайте об идиоме «на рогах дилеммы» и представьте себе талисман Университета Техас — длиннорогий бык с двумя огромными одинаковыми рогами, как две буквы «М» в слове «дилемма» и два неверных выбора, с которыми вы сталкиваетесь.

Вы видите дилемму , не так ли? Если вы меня не убьете, предсказатели ошиблись, и с предварительным преступлением покончено.Если ты убьешь меня, ты уйдешь, но это доказывает, что система работает. Предсказатели были правы. Итак, что ты собираешься делать сейчас? [Особенно красивое использование слова «дилемма».]

— Том Круз в роли Джона Андертона в фильме «Особое мнение»

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

Добавить комментарий

Ваш адрес email не будет опубликован.