Но и в целом, мне кажется в подобной статье лучше не полениться и привести саму инструкцию в виде текста, а не просто ссылки на сторонний сайт. Если не прямой цитатой, то хотя бы в кратком пересказе.
И как соотносится нападение на соседнюю страну с потенциальным нападением другой страны на вас? Вот были силы ядерного сдерживания с обеих сторон, был даже миф про "вторую армию в мире". Теперь сдерживающих факторов стало даже меньше.
Не вижу ни одной причины поддерживать то что вы называете "СВО".
Речь не о голосах - до честных выборов, к сожалению, ещё очень далеко.
Речь о том, что для автократии и для демократии фраза "уровень поддержки действующей власти 80%" значит очень разные вещи. И если в демократических странах со своей линейкой начинают измерять поддержку войны россиянами, легко могут прийти к неверному выводу, что подавляющее число людей в РФ - кровожадные дикари и имперцы.
Если же мы когда-нибудь доберёмся до честных выборов, до которых будут допущены все желающие кандидаты - я ничего против принципа "один гражданин - один голос" не имею. Он не идеален, но другие альтернативы ещё хуже (имущественный или образовательный ценз, или уже упомянутое "качество поддержки" - сразу встаёт вопрос, кто будет определять эти критерии и оценивать людей).
Думаю я не до конца раскрыл свою мысль. Окей, если опросить людей, вполне можно получить и 50, и 80 процентов. Но я имею в виду скорее качество этой поддержки. Многие из "поддерживающих" ответят так не потому что глубоко и искренне убеждены в правильности происходящего, а потому что начальство так сказало - в лице ли пропагандиста на ТВ, или буквально в лице непосредственного начальника. Кроме того, одной из задач пропаганды как раз и является убедить людей в том, что всё вокруг "в едином порыве" за, что тоже делает для человека некомфортным высказывание каких-то сомнений - "я что, не такой как все?".
Так что речь не о конкретном числе - доле поддерживающих. Речь о том, что этот процент довольно бессмысленный, и вполне вероятно, что он рассыпется, как только ситуация всерьёз изменится, а пропаганда прекратится или сменит вектор.
Нет никакой поддержки 86%, даже 50% нет. Вспомните июнь 2023 года, хотя бы одна сутулая собака вышла на митинг в поддержку Путина во время мятежа? И не выйдет, как только произойдёт какая-то ситуация, при которой его власть зашатается.
Если в задаче что-то слишком обширное, возможно следует заняться декомпозицией, чтобы привязанный к ПР/коммиту тикет был достаточно конкретным.
В популярных системах управления задач можно либо создавать дочерние таски, либо как минимум привязывать задачи друг к другу, чтобы можно было легко ориентироваться в их иерархии.
Допускаю, что в каких-то специфических ЯП, например в VBA, подход может быть оправдан, так как в них проблематично использовать систему контроля версий. Но во всех мейнстримных языках можно использовать git, где будет сохранено достаточно информации о том, с чем было связано каждое изменение конкретного файла и даже конкретной строки.
Поиск подходящей заявки в соответствии с ТЗ номер, правила параграфа...
Всё это должно быть описано в задаче в жире (или другой системе). Пулл-реквест привязан к задаче, которая является источником правды для кода. Комментарий в коде с дублирующим текстом излишний, вся информация будет в системе контроля версий (как минимум, номер задачи в commit message).
Как именно комментарий предоставляет инструмент ручной проверки кода? Сам код вне зависимтости от наличия комментариев должен быть настолько простым для чтения, насколько это возможно: понятные имена переменных, методов и классов, минимальное количество ветвлений и циклов, оптимальный размер методов и ограниченная вложенность кода.
При соблюдении этих принципов, комментарий просто дублирует логику кода, не добавляя вообще никаких преимуществ, а только вводит риск расхождений кода и комментариев.
Пока что все разработчики без исключения - люди. Люди имеют свойство ошибаться, быть невнимательными (особенно в спешке, исправляя супер-срочный баг). Чем больше автоматических проверок, которые не зависят от человеческой внимательности, стоят на пути бага до продакшна - тем лучше, и наоборот.
На мой взгляд, при проектировании систем (не только приложений, но и сред разработки, и языков программирования, и coding conventions на проекте) нужно учитывать, что ими пользуются люди, которые обладают недостатками. Конечно, можно сказать, что если пользователь ввёл некорретный имейл, из-за которого система работает некорректно, то он сам виноват. Но хорошо спроектированное приложение должно быть устойчиво к таким ошибкам и предусматривать логику валидации и подтверждения почты, например.
Так же и с соглашениями по кодстайлу: разработчики это тоже люди, и тоже склонны ошибаться, быть невнимательными, особенно в спешке - а компилятор и кодстайл могут и должны помочь в предотвращении этих проблем.
Возьмём приведенный пример с методом парсинга: SomeValidator.TryParseInt("3"); со списком выбрасываемых исключений в xml-документации. Хорошо, если этот метод был реализован один раз и почти никогда не меняется, но что если вдруг нужно исправить срочный баг? Например, при передаче в тексте числа, выходящего за границы int32, происходит переполнение - и при фиксе бага разработчик добавил там проверку, которая может выбрасывать ArgumentOutOfRangeException. Конечно же, документацию в xml-комментах обновить забыли. Теперь доки не просто бесполезны, а даже вредны - потому что врут.
Альтернатива исключениям в бизнес-логике
Даже если бы не забыли обновить доки - как в этом случае убедиться, что все кто использует этот метод, учли новый тип исключения наряду с уже описанным ранее CustomException?
На днях пришла хорошая новость: в C# появился пропозал о добавлении Type Unions, так что теперь, надеюсь, получится написать метод так:
public static (int or ParseError) TryParseInt(string input)
{ /*...*/ }
Таким образом, уже в самой сигнатуре метода определены варианты того, что можно вернуть. При таком подходе компилятор может проверить, что вызывающий код гарантированно предусматривает вариант для каждого из возможных возвращаемых типов:
var x = result switch
{
int a => x,
ParseError err =>
{
Console.WriteLine(err.Message);
throw new Exception("Parse failed: " + err.Message);
}
};
И при добавлении третьей опции в сигнатуре метода этот switch просто не скомпилируется, так как не хватает третьей ветви.
Комментарии в коде, как часть системы, должны быть устойчивыми к слабостям разработчиков. А дублирование логики кода в комментарии (как в примере - список выбрасываемых исключений) - это уязвимость к человеческим ошибкам, которая может выстрелить при частых изменениях кода и недостаточном процессе код-ревью.
Я считаю, главная цель комментариев - не описывать, что делает тот или иной фрагмент кода, а для чего он предназначен, и почему он реализован именно так. Ответ на первый вопрос ("что") должен давать сам код, через понятные имена методов, классов и переменных. А информацию по другим вопросам ("для чего" и "почему") может быть намного сложнее получить из самого кода, и для них комментарии - хороший источник ответов.
Ага, и в итоге фермеру вместо того чтобы пойти на ближайший рынок удобрений, нужно будет на своём грузовике поехать за полтысячи километров до производителя, который обрадует его тем, что "нам не выгодно продавать тебе одну тонну, мы готовы продавать от тысячи тонн".
Рынок играет важную роль в экономике - перераспределение благ, наряду с их производством и потреблением.
Ещё попробуйте сообщение от ошибке из графического окна скопировать - удачи, почему-то до сих пор в 90% случаем не копируемые.
Кстати, в стандартном виндовом MessageBox текст как раз копируемый (хотя его нельзя выделить курсором, просто Ctrl-C копирует его содержимое). Вот тут пример.
Так и работа с фиксированной зарплатой тоже разная бывает - где-то дикие переработки и авралы, а где-то расслабон и work-life balance, не вижу принципиального отличия в сравнении с "повремёнка/фиксированная зарплата".
Если они - единственный продавец билетов на концерт Вашей любимой группы, то выбора особо нет. Не все готовы ради бойкота одной дурацкой IT-компании лишать себя возможности посетить долгожданное мероприятие.
Осмелюсь предположить, что можно брать сколько в среднем выходит за месяц. Тогда получится значение, которое можно сравнивать с другими результатами этих опросов.
Со времён самой первой гта, которая была обнаружена на каком-то
пиратскомCD-сборнике "250 русских игр" =)У меня ссылка не работает, редиректит на главную.
Но и в целом, мне кажется в подобной статье лучше не полениться и привести саму инструкцию в виде текста, а не просто ссылки на сторонний сайт. Если не прямой цитатой, то хотя бы в кратком пересказе.
Не знаю, есть ли аналогичная возможность. Возможно, придётся потрудиться чуть больше и вручную открыть диалог с автором.
Для подобных замечаний на хабре есть удобная фича - выделяете фрагмент и нажимаете Ctrl-Enter, чтобы отправить информацию об опечатке в ЛС автору.
И как соотносится нападение на соседнюю страну с потенциальным нападением другой страны на вас? Вот были силы ядерного сдерживания с обеих сторон, был даже миф про "вторую армию в мире". Теперь сдерживающих факторов стало даже меньше.
Не вижу ни одной причины поддерживать то что вы называете "СВО".
Речь не о голосах - до честных выборов, к сожалению, ещё очень далеко.
Речь о том, что для автократии и для демократии фраза "уровень поддержки действующей власти 80%" значит очень разные вещи. И если в демократических странах со своей линейкой начинают измерять поддержку войны россиянами, легко могут прийти к неверному выводу, что подавляющее число людей в РФ - кровожадные дикари и имперцы.
Если же мы когда-нибудь доберёмся до честных выборов, до которых будут допущены все желающие кандидаты - я ничего против принципа "один гражданин - один голос" не имею. Он не идеален, но другие альтернативы ещё хуже (имущественный или образовательный ценз, или уже упомянутое "качество поддержки" - сразу встаёт вопрос, кто будет определять эти критерии и оценивать людей).
Думаю я не до конца раскрыл свою мысль. Окей, если опросить людей, вполне можно получить и 50, и 80 процентов. Но я имею в виду скорее качество этой поддержки. Многие из "поддерживающих" ответят так не потому что глубоко и искренне убеждены в правильности происходящего, а потому что начальство так сказало - в лице ли пропагандиста на ТВ, или буквально в лице непосредственного начальника. Кроме того, одной из задач пропаганды как раз и является убедить людей в том, что всё вокруг "в едином порыве" за, что тоже делает для человека некомфортным высказывание каких-то сомнений - "я что, не такой как все?".
Так что речь не о конкретном числе - доле поддерживающих. Речь о том, что этот процент довольно бессмысленный, и вполне вероятно, что он рассыпется, как только ситуация всерьёз изменится, а пропаганда прекратится или сменит вектор.
Нет никакой поддержки 86%, даже 50% нет. Вспомните июнь 2023 года, хотя бы одна сутулая собака вышла на митинг в поддержку Путина во время мятежа? И не выйдет, как только произойдёт какая-то ситуация, при которой его власть зашатается.
С именем Мерседес мимо, там компания была названа именем человека, а не наоборот.
Если в задаче что-то слишком обширное, возможно следует заняться декомпозицией, чтобы привязанный к ПР/коммиту тикет был достаточно конкретным.
В популярных системах управления задач можно либо создавать дочерние таски, либо как минимум привязывать задачи друг к другу, чтобы можно было легко ориентироваться в их иерархии.
Допускаю, что в каких-то специфических ЯП, например в VBA, подход может быть оправдан, так как в них проблематично использовать систему контроля версий. Но во всех мейнстримных языках можно использовать git, где будет сохранено достаточно информации о том, с чем было связано каждое изменение конкретного файла и даже конкретной строки.
Всё это должно быть описано в задаче в жире (или другой системе). Пулл-реквест привязан к задаче, которая является источником правды для кода. Комментарий в коде с дублирующим текстом излишний, вся информация будет в системе контроля версий (как минимум, номер задачи в commit message).
Как именно комментарий предоставляет инструмент ручной проверки кода? Сам код вне зависимтости от наличия комментариев должен быть настолько простым для чтения, насколько это возможно: понятные имена переменных, методов и классов, минимальное количество ветвлений и циклов, оптимальный размер методов и ограниченная вложенность кода.
При соблюдении этих принципов, комментарий просто дублирует логику кода, не добавляя вообще никаких преимуществ, а только вводит риск расхождений кода и комментариев.
Пока что все разработчики без исключения - люди. Люди имеют свойство ошибаться, быть невнимательными (особенно в спешке, исправляя супер-срочный баг). Чем больше автоматических проверок, которые не зависят от человеческой внимательности, стоят на пути бага до продакшна - тем лучше, и наоборот.
На мой взгляд, при проектировании систем (не только приложений, но и сред разработки, и языков программирования, и coding conventions на проекте) нужно учитывать, что ими пользуются люди, которые обладают недостатками. Конечно, можно сказать, что если пользователь ввёл некорретный имейл, из-за которого система работает некорректно, то он сам виноват. Но хорошо спроектированное приложение должно быть устойчиво к таким ошибкам и предусматривать логику валидации и подтверждения почты, например.
Так же и с соглашениями по кодстайлу: разработчики это тоже люди, и тоже склонны ошибаться, быть невнимательными, особенно в спешке - а компилятор и кодстайл могут и должны помочь в предотвращении этих проблем.
Возьмём приведенный пример с методом парсинга:
SomeValidator.TryParseInt("3");со списком выбрасываемых исключений в xml-документации. Хорошо, если этот метод был реализован один раз и почти никогда не меняется, но что если вдруг нужно исправить срочный баг? Например, при передаче в тексте числа, выходящего за границы int32, происходит переполнение - и при фиксе бага разработчик добавил там проверку, которая может выбрасыватьArgumentOutOfRangeException. Конечно же, документацию в xml-комментах обновить забыли. Теперь доки не просто бесполезны, а даже вредны - потому что врут.Альтернатива исключениям в бизнес-логике
Даже если бы не забыли обновить доки - как в этом случае убедиться, что все кто использует этот метод, учли новый тип исключения наряду с уже описанным ранее
CustomException?На днях пришла хорошая новость: в C# появился пропозал о добавлении Type Unions, так что теперь, надеюсь, получится написать метод так:
Таким образом, уже в самой сигнатуре метода определены варианты того, что можно вернуть. При таком подходе компилятор может проверить, что вызывающий код гарантированно предусматривает вариант для каждого из возможных возвращаемых типов:
И при добавлении третьей опции в сигнатуре метода этот switch просто не скомпилируется, так как не хватает третьей ветви.
Комментарии в коде, как часть системы, должны быть устойчивыми к слабостям разработчиков. А дублирование логики кода в комментарии (как в примере - список выбрасываемых исключений) - это уязвимость к человеческим ошибкам, которая может выстрелить при частых изменениях кода и недостаточном процессе код-ревью.
Я считаю, главная цель комментариев - не описывать, что делает тот или иной фрагмент кода, а для чего он предназначен, и почему он реализован именно так. Ответ на первый вопрос ("что") должен давать сам код, через понятные имена методов, классов и переменных. А информацию по другим вопросам ("для чего" и "почему") может быть намного сложнее получить из самого кода, и для них комментарии - хороший источник ответов.
Голоса некоторых участников сообщества (видимо, старожилов с большим рейтингом) считаются с бОльшим весом.
Ага, и в итоге фермеру вместо того чтобы пойти на ближайший рынок удобрений, нужно будет на своём грузовике поехать за полтысячи километров до производителя, который обрадует его тем, что "нам не выгодно продавать тебе одну тонну, мы готовы продавать от тысячи тонн".
Рынок играет важную роль в экономике - перераспределение благ, наряду с их производством и потреблением.
Кстати, в стандартном виндовом
MessageBoxтекст как раз копируемый (хотя его нельзя выделить курсором, просто Ctrl-C копирует его содержимое). Вот тут пример.Так и работа с фиксированной зарплатой тоже разная бывает - где-то дикие переработки и авралы, а где-то расслабон и work-life balance, не вижу принципиального отличия в сравнении с "повремёнка/фиксированная зарплата".
Если они - единственный продавец билетов на концерт Вашей любимой группы, то выбора особо нет. Не все готовы ради бойкота одной дурацкой IT-компании лишать себя возможности посетить долгожданное мероприятие.
Осмелюсь предположить, что можно брать сколько в среднем выходит за месяц. Тогда получится значение, которое можно сравнивать с другими результатами этих опросов.