Ну да, ну да, кто-то пишет if(!result) вместо `if (result != http::ok)`, чтоб потом узнать, что http::ok внезапно 200, а не 0. Не надо так.
Но вот чем принципиально для вас отличается `if (opt.has_value())` от `if (vec.isEmpty())`? Лично для меня при чтении особенно не отличается - проверяем какое-то состояние объекта (я тут не рассматриваю вопрос happy/unhappy path, он немного в другой плоскости лежит).
Можно ещё сравнить std::optional и std::any.Оба типа имеют метод `has_value`, который (цитирую) "checks if object holds a value". При этом один тип имеет каст в бул, а второй нет. Вас не смущает использовать разные способы проверки одного и того же?
В чистом виде дело привычки. Рассмотрим, например, такие варианты:
if (optValue) {doSomething();}
if (optValue != std::nullopt) {doSomething();}
if (optValue.has_value()) {doSomething();}
Является ли какой-то из них уменьшающим/увеличивающим когнитивную нагрузку по отношению к другим? Мне нравится вариант с has_value как соответствующий тому, что я хочу проверить, есть ли в optional значение или нет (поэтому думать при чтении надо меньше). Есть люди, которым нравится вариант со сравнением, потому что похож на сравнение указателя с nullptr, поэтому думать при чтении надо меньше. Есть люди, которые любят буквы экономить, поэтому для них первый вариант - самое оно (потому что думать при чтении надо меньше). Не думаю, что кто-то из нас прав, а остальные нет.
Код ревью это как чистка зубов — занимает немного времени каждый день, но позволяет оставлять код в здоровом (поддерживаемом) состоянии. Ошибочные комментарии, именования, понятные только автору, нетривиальные циклы в месте, где достаточно стандартного алгоритма. Примеров масса, иногда даже можно увидеть фактическую ошибку, хотя отлов багов целью ревью не является. Бонусом — обучение команды и приведение кода к единому стилю.
Для гладкого процесса у нас есть несколько разумных принципов:
1. Ревью должны быть маленькими. Во-первых, большое изменение очень сложно читать; во-вторых, автор, пиливший код две недели, с меньшей охотой что-то будет переделывать. Если фича предполагает большой объем, то делать предварительный дизайн ревью решения и промежуточные патч-сеты.
2. Замечание — это не приказание исправить. Это мысль, что читающему что-то непонятно или не нравится, причём желательно эти ситуации явно разделять. Поэтому комментарии типа «почему ты здесь использовал А? » хуже, чем «А работает медленно, используй Б».
3. Если приходится писать второй комментарий на одно замечание, то подойди, обговори голосом. Ситуаций вида:
— «А плохо, потому что Б»
— «нет, А хорошо, потому что не только Б, но и В»
— «нет, ты не учел Г»
быть не должно, потому что они слишком быстро ведут к переходу на личности и озлобленности.
4. Если что-то обговорил голосом, допиши резюме обсуждения в комментарий, другим тоже может быть интересно.
5. Если три человека из команды просят переделать одно место, а ты не можешь объяснить, почему твоё решение лучше, переделай как просят.
И максимум того, что можно вынести на автоматическую проверку, надо выносить на автоматическую проверку — наличие интернализации и док блоков (увы, не содержание), проверка на дублирование кода, оформление комит мессаджа по стандарту, прогон статического анализатора, выполнение тестов. На дженкинс разработчику сложно обижаться, даже если он ставит -2 на ревью.
В мутных задачах и разбираться долго и мутно. Точно не стоит вешать на себя, если ты тимлид. Потому что становишься бутылочным горлышком, а тебе ещё на остальные свои дела время надо. Лучше выделить достаточно умного разработчика с предложением решить как-нибудь, а в процессе решения добавить ясности.
Это был июнь 2019 года и всё было просто забито беженцами из Венесуэлы. Сама граница проходилась легко, потому что была отдельная очередь для не венесуэльцев, но в Ипиалесе был трешняк. Нас даже в гостинице после 9 вечера запирали на решетку с просьбами никуда не выходить в центр потому что вероятность гоп-стопа зашкаливала. Возможно, с тех пор всё поменялось к лучшему (я на это сильно надеюсь).
Был как в Южной Америке (почти вся), так и в Африке (ЮАР, Намибия, Танзания, Кения, Эфиопия). И автостоп, и публичный транспорт, и аренда авто были. Плюс-минус одинаково. В любом большом городе есть места, куда ну не ходи вообще. Также есть места, где гуляй хоть всю ночь - ничего тебе не будет.
При этом есть лично знакомые, которых грабили в Бразилии. И те, которых грабили в Танзании. И в ЮАР. Правда все эти варианты - шли поздно вечером там, где надо было сесть на такси и доехать до дома.
Самые стрёмные места по ощущениям - трущобы Вальпараисо, центр Сан-Паулу в Бразилии, граница Колумбии и Эквадора и тауншипы в ЮАР.
Ездил год назад от Кейптауна через Драконовы горы до Лимпопо и обратно на арендованной машине, вполне безопасно. Пингвины, киты, винодельни, водопады и каньоны + сафари.
О, да. Кейптаун и вообще вся Западная Капская провинция это цивилизация, относительная безопасность (лучше всё таки не забредать куда не следует) и вообще шикарное место. Йоханнесбург сильно хуже в этом отношении. Я бы вообще выбрал Херманус на пожить подольше - винодельни, проплывающие киты и в целом тишь да гладь.
Палка о двух концах тут. С одной стороны, прекрасно, когда начальник понимает, может подсказать и направить, но иногда ситуация несколько другая: начальник думает, что понимает, нахватавшись по верхам, а потом начинает продавливать своё неэкспертное мнение, как рабочее решение. В лучшем случае просто не сработает, в худшем - как-то сработает, но его будет сложно поменять на хорошее.
Практика показывает, что один цикл до постановки заявки это 12-16 ms, из которых примерно 12-16 ms уходит на получение фида по сети. Что за этом фоне единицы наносекунд? Если вы в рамках этого цикла выигрывали сотню наносекунд, то прям терзает смутное сомнение, что это оказывало какое-то заметное влияние.
Практика показывает, что в 50% случаев спрашивающий только думает, что знает разницу между абстрактным классом и интерфейсом. В принципе, если обе стороны не очень деревянные, то может выйти занимательная дискуссия, но иногда все заканчивается на "ага, понятно" и пометкой в блокноте.
Интересно, в её названии есть слово mac? С другой стороны, всегда можно воспользоваться методом техасского стрелка: взять сотню ноутов, попробовать поставить туда какой-нибудь вменяемый линукс, отобрать те из них, которые не требуют бубна, и потом сказать, что вот это вот "предназначенные для него" устройства.
Если подходить строго, то факт проблем при установке не опревергает то, что на этот же ноутбук можно поставить linux. Возможно, более грамотный инженер с этим справится на ура. Опровергается факт, что любой человек может поставить linux на любой ноутбук.
Какая разница ради чего он существует? Я привожу пример того, что я (и не только я) получаю от деятельности банка. Опять же, если существуют кредиты, значит они кому-то нужны. Есть много примеров того, как кредит помагает людям жить, банальная ипотека, например. В целом, существование банков облегчает жизнь, а не усложняет. Поэтому мнение "работать на банк зашквар, он загоняет людей в долги и наживается" ну не очень умное на мой взгляд.
Или банк даёт людям возможность не тащить с собой пачку наличных на отдых. Или возможность заплатить за онлайн-кинотеатр в пятницу вечером не выпуская пивко из рук.
Ну да, ну да, кто-то пишет
if(!result)вместо `if (result != http::ok)`, чтоб потом узнать, чтоhttp::okвнезапно 200, а не 0. Не надо так.Но вот чем принципиально для вас отличается `if (opt.has_value())` от `if (vec.isEmpty())`? Лично для меня при чтении особенно не отличается - проверяем какое-то состояние объекта (я тут не рассматриваю вопрос happy/unhappy path, он немного в другой плоскости лежит).
Можно ещё сравнить
std::optionalиstd::any.Оба типа имеют метод `has_value`, который (цитирую) "checks if object holds a value". При этом один тип имеет каст в бул, а второй нет. Вас не смущает использовать разные способы проверки одного и того же?В чистом виде дело привычки. Рассмотрим, например, такие варианты:
Является ли какой-то из них уменьшающим/увеличивающим когнитивную нагрузку по отношению к другим? Мне нравится вариант с has_value как соответствующий тому, что я хочу проверить, есть ли в optional значение или нет (поэтому думать при чтении надо меньше). Есть люди, которым нравится вариант со сравнением, потому что похож на сравнение указателя с nullptr, поэтому думать при чтении надо меньше. Есть люди, которые любят буквы экономить, поэтому для них первый вариант - самое оно (потому что думать при чтении надо меньше). Не думаю, что кто-то из нас прав, а остальные нет.
clang-tidy, наоборот, против: https://clang.llvm.org/extra/clang-tidy/checks/readability/implicit-bool-conversion.html
Для гладкого процесса у нас есть несколько разумных принципов:
1. Ревью должны быть маленькими. Во-первых, большое изменение очень сложно читать; во-вторых, автор, пиливший код две недели, с меньшей охотой что-то будет переделывать. Если фича предполагает большой объем, то делать предварительный дизайн ревью решения и промежуточные патч-сеты.
2. Замечание — это не приказание исправить. Это мысль, что читающему что-то непонятно или не нравится, причём желательно эти ситуации явно разделять. Поэтому комментарии типа «почему ты здесь использовал А? » хуже, чем «А работает медленно, используй Б».
3. Если приходится писать второй комментарий на одно замечание, то подойди, обговори голосом. Ситуаций вида:
— «А плохо, потому что Б»
— «нет, А хорошо, потому что не только Б, но и В»
— «нет, ты не учел Г»
быть не должно, потому что они слишком быстро ведут к переходу на личности и озлобленности.
4. Если что-то обговорил голосом, допиши резюме обсуждения в комментарий, другим тоже может быть интересно.
5. Если три человека из команды просят переделать одно место, а ты не можешь объяснить, почему твоё решение лучше, переделай как просят.
И максимум того, что можно вынести на автоматическую проверку, надо выносить на автоматическую проверку — наличие интернализации и док блоков (увы, не содержание), проверка на дублирование кода, оформление комит мессаджа по стандарту, прогон статического анализатора, выполнение тестов. На дженкинс разработчику сложно обижаться, даже если он ставит -2 на ревью.
В мутных задачах и разбираться долго и мутно. Точно не стоит вешать на себя, если ты тимлид. Потому что становишься бутылочным горлышком, а тебе ещё на остальные свои дела время надо. Лучше выделить достаточно умного разработчика с предложением решить как-нибудь, а в процессе решения добавить ясности.
Это был июнь 2019 года и всё было просто забито беженцами из Венесуэлы. Сама граница проходилась легко, потому что была отдельная очередь для не венесуэльцев, но в Ипиалесе был трешняк. Нас даже в гостинице после 9 вечера запирали на решетку с просьбами никуда не выходить в центр потому что вероятность гоп-стопа зашкаливала. Возможно, с тех пор всё поменялось к лучшему (я на это сильно надеюсь).
Был как в Южной Америке (почти вся), так и в Африке (ЮАР, Намибия, Танзания, Кения, Эфиопия). И автостоп, и публичный транспорт, и аренда авто были. Плюс-минус одинаково. В любом большом городе есть места, куда ну не ходи вообще. Также есть места, где гуляй хоть всю ночь - ничего тебе не будет.
При этом есть лично знакомые, которых грабили в Бразилии. И те, которых грабили в Танзании. И в ЮАР. Правда все эти варианты - шли поздно вечером там, где надо было сесть на такси и доехать до дома.
Самые стрёмные места по ощущениям - трущобы Вальпараисо, центр Сан-Паулу в Бразилии, граница Колумбии и Эквадора и тауншипы в ЮАР.
Ездил год назад от Кейптауна через Драконовы горы до Лимпопо и обратно на арендованной машине, вполне безопасно. Пингвины, киты, винодельни, водопады и каньоны + сафари.
О, да. Кейптаун и вообще вся Западная Капская провинция это цивилизация, относительная безопасность (лучше всё таки не забредать куда не следует) и вообще шикарное место. Йоханнесбург сильно хуже в этом отношении. Я бы вообще выбрал Херманус на пожить подольше - винодельни, проплывающие киты и в целом тишь да гладь.
В Крюгер. 440 рандов билет на сутки, можно ездить на своей машине, есть кэмпсайты и бунгало. По животными очень богато.
& это address-of operator (взятие адреса). Разыменовывание это *
Простой способ подключать внешние библиотеки - через conan. Собирать каждый раз то, что не меняется, имхо, так себе удовольствие
Палка о двух концах тут. С одной стороны, прекрасно, когда начальник понимает, может подсказать и направить, но иногда ситуация несколько другая: начальник думает, что понимает, нахватавшись по верхам, а потом начинает продавливать своё неэкспертное мнение, как рабочее решение. В лучшем случае просто не сработает, в худшем - как-то сработает, но его будет сложно поменять на хорошее.
Практика показывает, что один цикл до постановки заявки это 12-16 ms, из которых примерно 12-16 ms уходит на получение фида по сети. Что за этом фоне единицы наносекунд? Если вы в рамках этого цикла выигрывали сотню наносекунд, то прям терзает смутное сомнение, что это оказывало какое-то заметное влияние.
Практика показывает, что в 50% случаев спрашивающий только думает, что знает разницу между абстрактным классом и интерфейсом. В принципе, если обе стороны не очень деревянные, то может выйти занимательная дискуссия, но иногда все заканчивается на "ага, понятно" и пометкой в блокноте.
Интересно, в её названии есть слово mac? С другой стороны, всегда можно воспользоваться методом техасского стрелка: взять сотню ноутов, попробовать поставить туда какой-нибудь вменяемый линукс, отобрать те из них, которые не требуют бубна, и потом сказать, что вот это вот "предназначенные для него" устройства.
Ну я не знаю ни одной ОС, которая ставится без бубна на любое железо. А вы?
Если подходить строго, то факт проблем при установке не опревергает то, что на этот же ноутбук можно поставить linux. Возможно, более грамотный инженер с этим справится на ура. Опровергается факт, что любой человек может поставить linux на любой ноутбук.
Какая разница ради чего он существует? Я привожу пример того, что я (и не только я) получаю от деятельности банка. Опять же, если существуют кредиты, значит они кому-то нужны. Есть много примеров того, как кредит помагает людям жить, банальная ипотека, например. В целом, существование банков облегчает жизнь, а не усложняет. Поэтому мнение "работать на банк зашквар, он загоняет людей в долги и наживается" ну не очень умное на мой взгляд.
Или банк даёт людям возможность не тащить с собой пачку наличных на отдых. Или возможность заплатить за онлайн-кинотеатр в пятницу вечером не выпуская пивко из рук.