На загруженность ревьюеров больше всего влияет количество неодобренных PR. Каждый отклоненный реквест — это новая доработка и новое ревью в ближайшем будущем. На мой взгляд, именно здесь наибольший потенциал для оптимизации. Хотя, в Яндекс.Деньгах, возможно, ситуация иная.
Я в свое время, чтобы разгрести завалы code review, составил чек-лист, чего я смотрю в коде. Получилось где-то 100 пунктов. Попросил всех разработчиков перед передачей кода мне на ревью прочекать этот чек-лист и проставить напротив каждого отметку вида Соблюдается/Не применимо/Нарушается там-то по тому-то по согласованию с тем-то.
После этого процесс ревью у меня выглядел так:
Чек-лист заполнен? Нет — PR на доработку, минус в карму.
Смотрю, где в чек-листе отмечены отклонения от требований, и иду туда смотреть
Если автор имеет низкую карму, тщательно просматриваю весь код.
Если автор имеет хорошую карму, выборочно просматриваю самые интересные файлы.
Если нашел косяк, предусмотренный чек-листом, — PR на доработку, минус в карму.
Если нашел что-то новенькое, тщательно просматриваю весь код, обновляю чек-лист. Создаю задачу на доработку. Если проблема не очень критична, ставлю approve. Если проблема критична, то PR отправляю на доработку.
Поначалу пришлось повозиться, отсмотреть все замечания по всем ревью за последний год, прочитать комментарии по всем зарегистрированным дефектам, затем скомпилировать это все в чек-лист. Самое сложное было — уговорить команду использовать этот чек-лист. Зато потом трудоемкость code review сократилась в разы, и, самое главное, сократилось количество повторных ревью.
Я вообще ни с чем собираюсь спорить.
Вы уже сами все подтвердили, уточнив, какие
условия должны выполняться для сохранения зрения.
Эти условия обеспечить на мониторе без адаптивной
регулировки яркости невозможно.
Всегда удивлялся тому, что стандартом де-факто является черный текст на белом фоне. Нам ведь реально приходится часами смотреть на горящую лампочку. Это вредно и неудобно. Думаю, это все началось с Microsoft Word, который воплощал концепцию what you see is what you get. Чтобы сымитировать видимость белой бумаги стали всюду клепать белый фон. К сожалению, никому не пришло в голову, что на листе бумаги мы видим отраженный рассеянный свет, а на мониторе — прямое излучение. И только сейчас до разработчиков интерфейсов начало доходить, что до сих пор мы двигались не туда.
Тема важная, однако в ней имеются некоторые аспекты, о которых в статье не упоминается. Например, при обсуждении технических вопросов бывает необходимо многократно повторять одни и те же размерности. Это не очень удобно и, зачастую, бессмысленно, поскольку все участники обсуждения (ха-ха) и так знают, какая у кого размерность. Поэтому в разговорной речи допускается опускать некоторые слова, если из контекста и так понятно, о чем идет речь, и не может возникнуть неоднозначного толкования.
Так, к примеру, яндекс.навигатор говорит: «Впереди камера на девяносто», — а не: «Впереди ограничение скорости до девяноста километров в час». Так и инженеры в разговоре могут ограничиться ваттами без часов. Например: «Семья за месяц потратила 200 киловатт». Это нормально. Но в письменной форме допускается только точная запись, если, конечно, передается информация о физической величине, а не прямая речь.
Только надо наоборот: У вас 3 письма (и еще 1489 какой-то мути). Причем 3 письма не должны входить в число 1489. Чтобы, когда нажмешь на 1489, был бы показан чистый спам, без примесей.
Похоже, в этот список попадают письма, которые уже другим алгоритмом отфильтровываются как спам, потому что я ни одного письма из многих перечисленных рассылок в глаза не видел.
Очень хорошее предложение. Достаточно будет просто отдельно выделять письма, отправители которых есть в контактах. Плюс те письма, отправители которых ранее присылали сообщения, отмеченные получателем как важные. Плюс те отправители, которым пользователь сам что-то писал.
Только я бы в скобках ставил количество мусора. У вас 1 письмо (и еще 20 каких-то мутных сообщений). И можно отдельно нажать на 1 и отдельно нажать на 20.
Сейчас уже не актуально протягивать индекс в цикле. Уже можно спокойно обойтись конструкциями типа array.foreach() или for (v: array). Вам не нужно беспокоиться о том, какой там индекс. Индекс нужен не для работы со всеми элементами массива, а для работы с отдельными элементами.
Основная фишка здесь в переходе от дискретных элементов к составным или нецелочисленным. Предположим, имеем массив элементов, каждый из которых занимает s байтов. Я имею ссылку на n-й байт в этом массиве. Мне нужно узнать:
номер элемента массива K, в который входит этот байт
номер байта k внутри этого элемента
Если считать от 1, то формулы будут такими:
K = (n - 1) / s + 1
k = (n - 1) % s + 1
Если считать от 0, то формулы будут такие:
K = n / s
k = n % s
С того момента, как сталкиваешься с этой арифметикой, все становится очевидно. Операции с временем — действительно хороший пример, потому что всем понятен.
Вот кстати за реформу исчисления времени ему большое спасибо. Понятно, что на пояса нормально разделить не получится. Как ни распредели, одним обязательно будет плохо зимой, а другим — летом. Но вот отмена летнего времени, это безусловная правильная мера. Устранили анахронизм, унаследованный с XIX века.
Я в свое время, чтобы разгрести завалы code review, составил чек-лист, чего я смотрю в коде. Получилось где-то 100 пунктов. Попросил всех разработчиков перед передачей кода мне на ревью прочекать этот чек-лист и проставить напротив каждого отметку вида Соблюдается/Не применимо/Нарушается там-то по тому-то по согласованию с тем-то.
После этого процесс ревью у меня выглядел так:
Поначалу пришлось повозиться, отсмотреть все замечания по всем ревью за последний год, прочитать комментарии по всем зарегистрированным дефектам, затем скомпилировать это все в чек-лист. Самое сложное было — уговорить команду использовать этот чек-лист. Зато потом трудоемкость code review сократилась в разы, и, самое главное, сократилось количество повторных ревью.
Вы уже сами все подтвердили, уточнив, какие
условия должны выполняться для сохранения зрения.
Эти условия обеспечить на мониторе без адаптивной
регулировки яркости невозможно.
Выжигает, еще как.
Так, к примеру, яндекс.навигатор говорит: «Впереди камера на девяносто», — а не: «Впереди ограничение скорости до девяноста километров в час». Так и инженеры в разговоре могут ограничиться ваттами без часов. Например: «Семья за месяц потратила 200 киловатт». Это нормально. Но в письменной форме допускается только точная запись, если, конечно, передается информация о физической величине, а не прямая речь.
Только я бы в скобках ставил количество мусора. У вас 1 письмо (и еще 20 каких-то мутных сообщений). И можно отдельно нажать на 1 и отдельно нажать на 20.
Если считать от 1, то формулы будут такими:
Если считать от 0, то формулы будут такие:
С того момента, как сталкиваешься с этой арифметикой, все становится очевидно. Операции с временем — действительно хороший пример, потому что всем понятен.
P. S. Я не из мира С, так что сильно не критикуйте, если что-то не в кассу.
Рассказ интересный. Спасибо.
Расскажите, пожалуйста, как поддерживаете адекватность конфигурации стендов.