Всем привет! Это подкаст Дотнет не только. С вами Саша Кугушев из JetBrains. И у нас сегодня очень крутой выпуск, потому что... Так, блин, я как-то запутался. Обычно я представляю всех. Так, начнем заново. Всем привет. Это подкаст «Дот и не только». С вами и у нас крутые ребята. Дима Головинов из... из JetBrains. Всем привет. Ваня Крючков из DataArt. Всем привет. И Саша Кукушев из JetBrains. И сегодня мы будем продолжать говорить про метрики.
Причем не просто про метрики, а вот у нас есть Дима, который эти метрики сам в свое время впиливал. Вот знаешь, ты заходишь, когда вбиваешь слово метрики, у тебя первое, что выпадает, там, сонар, там... где-то на какой-то там дополнительной стречке Кадана. Это все Дима делал. Так что, если вам кажется, что метрики это говно, плюйте ровно в центр экрана.
Ну, немножко не так. В Кадане я стоял сбоку. У нас был проект интернашипа. И наш интерн запиливал механизм метрик, потому что... Когда ты деливируешь утилиту для статического анализа, для код-квалити, оно, конечно, с одной стороны, чисто теоретически хорошо девелоперам, то, что ты там сделал пол-реквест, пытаешься замерзнуть, и тебе там по рукам надавалось... написал или тестами не покрал вот с другой стороны менеджеры тоже хотят видеть и допустим
перед релизом смотреть, насколько там хороший код. Ну, так считается, что менеджеры хотят смотреть, ассессить код, то есть они не особо разбираются в программировании.
Но им нужен какой-то механизм, когда они могут сказать, что код хороший, код плохой. Вот эти вот программисты наработали хорошо, столько плохо. И с этой точки зрения, когда у тебя утилита... представляет дэшборды, то на этих дэшбордах все можно увидеть, что работает, и менеджер может посмотреть в циферки и сказать, вот циферки хорошие, вот циферки плохие.
И, собственно, в кодании пока такой дешбарды нет, но они работают над этим, и вот будет продукт, называющийся код Horizon, куда будут входить, соответственно, репорты и куда будут входить вот эти вот метрики. Вот, я сам механизм метрик в кодане реализовывал параллельную вещь, то есть мы сейчас делаем тент-анализ, и в рамках этого тент-анализа я его считал его метрики, но...
У меня было достаточно времени посмотреть, как они эти метрики реализовали, и я с удовольствием об этом расскажу. Ну и как бы в Сонаре я тоже разными вещами занимался и представляю, как оно работает. Поэтому с точки зрения того человека, который к этому имел отношение, я с удовольствием сегодня приму участие в этом стриме. Отлично. И давай начнем с самого первого. как человек, который сам пилил метрики. Нахрена они нужны? Мы обсуждали...
Мы два выпуска с вами обсуждали вопрос, зачем нужны эти метрики. В среднем пришло что-то среднее между, ну, типа, можно смотреть по прогрессу, менеджерам повтыкать, показывать дашборды. И нахер не надо. Нет, ты забыл пункт, что как третейский судья в разрешении споров. Кому-то что-то не нравится в коде, можно сослаться на метрику, как на объективную величину.
На самом деле, у меня двоякое отношение к метрикам. Я, например, везде топлю за метрику код кавериджа. Потому что код каверидж – это тоже такая себе метрика, которая… Когда ты приходишь на проект… Ты первый можешь понять, там есть тест или нет теста. А если есть тест, ты можешь понять с код кавериджем вообще, какой кусок продукта тестится. И я, собственно, в JetBrains...
В Кадане разработал инспекции, которые меряют код каверич для большого количества языков. И мы сейчас полномерно вот эту метрику развиваем. На самом деле код coverage, с одной стороны, он очень хороший. То есть ты, допустим, написал, я не знаю, 10 тысяч строк кода, запустил тест, говорит, что тестами покрыт весь твой код. А берешь метрика, у тебя выходит, что у тебя 10% покрытия. И тут даже на самом деле возникают разные вопросы. На самом деле, а все ли ты протестировал?
Как бы нет ли у тебя какого-то лишнего куска в проекте. И код каверидж метрика, она очень полезная, чтобы с этим работать. Однако, если... Извини, пожалуйста, перебил. Сразу могу сказать, смотри, у меня есть код кавердж 10% на весь проект. При этом это вполне себе валидный кейс, при котором 10% код кавердж. Это покрыты все бизнесовые части, потому что у тебя там, он же может не учитывать, просто проперти.
куча кода, который является, вот если у тебя просто бешеное количество кода, который является интеграционным кодом, то есть кодом для взаимодействия с какими-то там базами данных и прочее, и в итоге на непосредственно бизнес-логику остаются те самые 10%. Все так. Где? Какая цифра-то? Какую взять цифру? Поэтому, понимаешь, когда я подходил к вопросу разработки инспекции Code Coverage и как ее вообще делать в Кадане, там был...
У меня есть некий флажок, который мы не активируем обычно, считать код каверидж по всему проекту. На самом деле я отталкиваюсь от того, что если мне пришел файл с кавериджем, и там есть какие-то данные, то... Я буду смотреть, отталкиваться от того, что написано в этом файлике.
И в саппорте мы отвечаем так же. То есть приходит человек, говорит, что вот как и так настраивать каверидж. У нас в документации написано, что вот так и так настраивать каверидж, а дальше то, что вы хотите, чтобы покрывала инспекция кавериджа, вы устанавливаете фильтрами. В вашей утилите, которая делает каверидж. Вот, я не помню, к сожалению, как это делается в дотнете, мы там каверяли джаву совершенно недавно, да. Для GVM. Там сейчас в Gradle плагин до кавера написывали.
Но мне кажется, что человек, настраивая coverage, может учесть твой момент. То есть, допустим, он может учесть момент, что у меня в этом модуле есть бизнес-логика, поэтому я буду собирать coverage только с него. Потому что coverage — это же про инструментацию, и, соответственно, если у тебя есть способ уменьшить количество инструментированного кода, ты, во-первых, себе будешь ускорять тесты.
Ну и во-вторых, если от этого отталкиваться, то там действительно можно из твоих 10% превратить в 100%, когда ты именно настроил каверидж на этой части. Поэтому вполне валидный консерв. То есть у тебя еще может быть какой-нибудь там дурацкий совершенно фреймворк, который тебе кучу стабов нагенерит, который тебе вообще никогда в жизни не понадобится, но просто нужно, чтобы оно там было. Да, валидно, поэтому к этой метрике надо относиться с умом, но один раз ты ее настроил, дальше она работает.
Вот, за тебя. И если она настроена правильно, она не будет дальше мешать. И дальше, смотри, собственно, дальше у тебя код каверидж тоже разные есть. У тебя есть total код каверидж. Вот, то есть это ты... Берешь весь проект, прогнал и получил. А есть еще, как мы называем в Кадане, фреш-код каверидж. То есть фреш-код — это ты открыл pull request, поменял там 100 строчек, мы еще тебе померили код каверидж на этих 100 строчках.
То есть, допустим, ты добавил в эту бизнесовую часть код, но, допустим, не покрыл его тестами, а тесты там есть. Это хороший знак для тебя, чтобы ты этого не протестировал. Кстати, вот это одна из самых классных метрик. Я в свое время, мне очень радовало нас, там, на одном из старых проектов, сонровская такая метрика использовалась. Возможно, ты ее распилил.
Нет, она была, это старая какая-то вещь была, я к ней не имел отношения. Ну, то есть идея тут такая, что чем это удобно? Просто прийти на проект и сказать, а теперь давайте сделаем... чтобы у нас был хороший каверидж, ну, камон, никто так делать не будет. А так, заходишь в этот проект, настраиваешь фильтры, получаешь, что у вас, ну, покрытие пиццы с логики, что порядка там 10-15%, окей.
Но потом начинается добавляться фичи, у вас начинается снижаться покрытие бизнес-логики, а это уже quality gate. То есть можно это рубать на CI. Все так, у тебя есть, вот как в Кадане, Total coverage и Fresh coverage. То есть ты можешь поставить, например, по-моему, Sonor 80% на Fresh coverage по умолчанию. Не помню, я просто помню, как там работали, там, по-моему, 80% было.
Вот. И total coverage. То есть даже при том, что у тебя может пройти треш-холл по fresh coverage, по total coverage ты можешь упасть. Ну, то есть, допустим, у тебя 99% threshold по total coverage, он у тебя стоит в quality gate, и 80% по fresh coverage. Соответственно, на коммите под 80% ты можешь уронить total coverage и...
При этом запретить межевать, пока не устранить проблему с твоими тестами. И это хорошо тем... что на самом деле, ну то есть как ты пишешь код, ты пишешь какой-то код, ты пишешь обработку каких-то вот ситуаций, какие-то обрастаешь какими-то дополнительными кейсами. Если код достаточно большой, то можно пропустить набор каких-то кейсов, которые ты не обработал. Вот, например, вчера из моей практики у нас...
Мы пилили протобуф. Уменьшаем размер протобуфа, чтобы юзерам, конечно, не замусоривать. И там достаточно большое определение протобуфа, примерно где-то тысяча строчек. Для меня достаточно большое, так вложенное. Саппортится там тремя-четырьмя, не даже больше тысячи, саппортится тремя-четырьмя девелоперами. Я перековыривал тесты и потом задался вопрос, те оптимизации, которые я сделал, хорошие они или нет.
И ради этого полез в code coverage. Залез я в code coverage, то есть я запустил code coverage на полученном тесте и увидел, что на самом деле code coverage у меня 60%. Потом оказалось, что добавили новые части.
на которой вообще нет тестов. И когда я стал добивать все тестами, я обнаружил, что кусок мы в протобуф кладем правильно, а не вычитываем из протобуфа. И это опять же без код кавериджа, когда у тебя там просто... огромное количество положить сообщения считай сообщение огромное количество типов сообщений но не проверишь если ты этим не завидуешь
Вот, и как бы код кавридж с этой точки зрения это та метрика, за которую я всегда адвокатирую. Вот, то есть если вот у тебя есть логика, ее можно проверить, вот код кавридж, он тебя спасет. Ну вот тут я всегда... подмечаю что сам код каверидж он очень сильно именно конкретно все шарпи Галлюцианирует, фликает, в общем, сильно зависит от того, от непосредственно этих самых строчек кода. То есть, грубо говоря, там ты нафигачил кучу пропертей, у тебя ковердж упал.
Ты добавил, там, не знаю, DTO-шку, которая в Entity Framework'е автоматически пробрасывается. И у тебя, получается, коврид шипал. Ты такой, а, ну я же, в принципе, так как бы бизнес-логику не вносил. У меня просто ДТОшка появилась, она прокидывается в эти фреймворки. У меня куча пропертий, у меня коверч упал, что делать? Я поэтому всегда больше адвокатировал за бранч коверч.
Бранч каверидж тоже хорошая штука, да, да, да, все с тобой согласен, но однако бранч каверидж, допустим, на каких-то ошибках, ну то есть на каких-то сложных паттернах. Достаточно сложно его обработать. Я помню, в Сонаре как-то branch coverage поддерживался на паттернах, но было не так просто. Я ищу, то есть я не знаю, устранили это они или нет, там был, короче, где-то был автомат по разбору какой-то грамматики. Ну, то есть у тебя есть грамматика, есть какой-то автомат по ее разбору.
Вот, и каждый раз, как я лез, что-то в том, мне приходилось идти за опробом к лету, потому что кавер считал его неправильно. То есть, как бы там были кейсы. Вот. Эти кейсы отрабатывали, но как раз их не считал. Почему-то показал, что они покрыты. И там падало покрытие. Поэтому я понимаю твою боль. В таких случаях, да.
Но в других случаях, ну вот как я у тебя обозначил, да, то есть у тебя какой-то есть код с кучей-кучей кейсов, и без кавериджа ты не поймешь, что у тебя, допустим, что-то просто не тестируется, потому что, опять же, когда у тебя много разработчиков... Вот мне приходит pull request, да?
Я этим никогда не занимался, меня попросили посмотреть. Но я смотрю, ну да, хороший код. Вот здесь можно что-то улучшить, вот здесь можно что-то улучшить. Если начать смотреть, то там может быть какая-то огромная подсистема, естественно, я не знаю. Как бы что и как. А вот если бы считался с ним код каверич, я бы мог посмотреть, ага, вот тут вот ты, короче, что-то протестировал, вот тут не протестировал.
А сидеть с дебаггером, знаешь, ставить бряки и смотреть, а зашло сюда, а протестировало, чтобы просто понимать, что теста человека достаточно и недостаточно, на большие изменения. Но мне не хочется. Это экономит мое время. Но это именно от Flex. То есть не сама абсолютная циферка, а именно Flexible. То есть как она работает в динамике, и снижается она или повышается у нас coverage. Окей.
Пойдем тогда дальше, потому что, собственно, хотелось бы больше в деталях поговорить о том, как, собственно, эти метрики считаются, как реализовываются, потому что как-то в голове формируется какое-то абсолютно странное представление, что у нас есть код. И есть что-то, что собирает эти метрики. Метрики кавериджа, метрики цикломатик комплексити, комплексити, метрики все что угодно. Как?
Очень просто. Смотри, на самом деле я расскажу, начиная с каверидж моего любимого, как оно работает. То есть у нас все продукты основаны на основе IntelliJ продуктов. Вот, то есть все наши линтеры. Вот, и, соответственно, если ты работаешь с IntelliJ-продуктами, ты можешь, там у тебя идея Ultimate есть, ты там решил Java-программистом стать.
запустил, то может тест запустить с поддержкой кавериджа. На самом деле он запускает какой-то забандленный каверидж-агент, генерирует трассу, а потом говорит идея. А открой, пожалуйста, отчет coverage tool. Извини, пожалуйста. А вот эти самые tool, как они отрабатывают? Какой там у них принцип? Реально интересно. Слушай, ну, Тулы, скажем так, я занимался похожим в ходе, ну, я работал в России в сертификации. а вот сертификация
И мы занимались трассировкой программного обеспечения. То есть там по RDN-DV уровня 3 тебе нужно было поставить датчики на входе и на выходе из функции. Вот, PRD-NDV2 тебе нужно было поставить там перед каждым ветвлением. То есть в этом случае я писал parser. который расставлял в коде, менял код, расставлял в коде датчики трассировки, потом писал модуль.
трассировочный и он складывал это в отдельные файлы получались трассы исполнения когда ты пишешь ну то есть вот утилиты сборки каверджа работают примерно так же то есть они используют некие возможности по инструментации кода, и они меняют код так, что в рантайме производится вот эта вот трассировка. К сожалению, ни одной утилиты я сам не писал. Вот, но, например, вот сейчас вот с кавером возимся, то есть там настраиваются фильтры на инструментацию, производится инструментация байт-кода.
Вот, и на выходе собирается трасса. То есть плюс-минус все утилиты по кавериджу работают так. То есть они расставляют некие метки каким-либо своим механизмом, потом собирается файл, и файл выдается тебе на выходе. Вот. И представить это просто, то есть если у тебя есть какой-то сложный код, ты сам можешь сесть, расставить какие-то вызовы специальные, а потом тебе нужно понять, ага, вот, например, ты расставил 100 вызовов, а вызвалось только 80.
В случае, допустим, у тебя есть branch coverage, но у тебя нет condition coverage. Ты можешь посчитать, ага, у меня, например, 80%. Если ты начинаешь работать с кондишенами, то есть смотреть, если у тебя A или B, то тебе нужно if A или B. То есть тебе if A или B нужно разбить на два ifа и вставить дополнительные метки.
В конце концов результаты этой трассировки обрабатываются и составляется отчет кавериджа. Отчеты кавериджа, соответственно, бывают просто lines of code, бывают lines of code, привязанные к тестам. Бывает вот эти вот branch coverage, бывает statement coverage. Statement coverage это вот сколько statement из тех statement, которые у тебя есть, они выполнились.
И в конце, в самом конце у тебя обычно есть бинарный файл, чаще всего бинарный файл, который содержит во внутреннем формате этой утилиты данные о каверидже. И все, кто дальше работает с каверджем, умеют этот формат читать. Есть какие-то стандартизованные форматы на ряду языков, типа ботельков. Есть какие-то внутренние форматы. Например, DotCover свой внутренний формат, но бенефит этого внутреннего формата в том, что...
Он, например, может говорить, вот эта вот строчка кода покрывалась вот такими вот тестами. Ну, это круто, когда ты можешь в Туле показать, ага, вот у меня вот эта строчка покрылась, да, и чем же она была на самом деле покрыта. Вот. А утилита, которая дальше в итоге считает твой total coverage, она открывает этот отчет и дальше все работают по-разному. То есть как оно работает в кадании.
Есть два режима исполнения. Есть режим исполнения на всем проекте, есть режим исполнения на изменениях. При режиме исполнения на всем проекте ты запускаешь анализ каждого файла. То есть вот у тебя есть локальная инспекция, которая дергается просто по каждому файлу. В файле ты получаешь, анализируя файл, ты получаешь STH, высчитываешь имена классов.
И дальше идешь в репорт, спрашиваешь, у тебя есть такое имя класса? Он говорит, у меня есть такое имя класса. И выдает тебе информацию по этому имени класса, в котором в этой информации может содержаться информация о методах. И там же содержится информация о номерах строчек и в том, покрыты они или нет. То есть, допустим, строчка может быть не покрыта.
Строчка может быть покрыта полностью, строчка может быть подкрыта частично, и в зависимости, если там есть вот эти вот branch slash condition coverage, там могут быть какие-то дополнительные циферки. Вот, и дальше... В случае, когда мы пока считаем просто line coverage, ты делаешь нехитрую математику, смотришь количество строчек с нулями, и смотришь количество строчек не с нулями. Суммировал, разделил, получил процент покрытия. Но, к сожалению, бывает так, что...
Когда я начал это реализовывать, у меня начали появляться очень странные цифры покрытия. Например, для PHP отчеты по покрытию включали в себя... Сигнатуру функции. Если у тебя сигнатура функции четыре строчки, тело ее одно, он включал вот эту вот всю сигнатуру почему-то. Она у тебя не вызывается, у тебя на самом деле не минус одна строчка, а минус пять строчек. И вот эту проблему я решал. То есть я на st смотрел, где функция начинается, где функция заканчивается.
И где функция начинается, если там после открывающейся скобки идет newLine, я это тоже не считал, потому что зачем его считать? Ну, то есть какой смысл? У тебя же еще wetspace могут быть. У тебя же еще white space могут быть. Так вот, я искал до первого statement. До первого не комментарного statement. И дальше вниз идешь, тоже так ищешь. Секундочку. Можно тогда вопрос?
Получается такая вещь. Я очень часто люблю разбивать код на несколько строчек. Я не люблю вордфрапы делать. Я знаю человека, который обожает вордфрапы. Ты его тоже знаешь, скорее всего. Но мы не скажем, про кого я там говорю. Вот вы не знаете его. Или, может, знаете. Ну, короче говоря, есть люди, которые любят вордврапы. То есть, они пишут длинные-длинные. У них метод называется...
Название методов 50 Characters и еще 50 параметров. Вот это будет длинная-длинная одна строчка. С точки зрения метрики CodeCoverage замечательная одна строчка. Может все-таки тогда мерить, раз у нас есть нормальный доступ к АСТ, может тогда мерить не сколько line coverage, сколько statement coverage.
То есть по statement? Это правильная метрика, да. То есть вот, например, .cover, насколько я понимаю, что у них есть вот это statement coverage. Однако не везде он есть. И, соответственно... понимаешь когда ты делаешь конечный продукт и ты пытаешься ну то есть вот сложность реализации этого в когда не было следующее У тебя есть различные импортеры различных форматов, которые писались в течение последних больше 10 лет, поддерживающие разные фичи этих форматов.
И потом тебе нужно свести это к какому-то общему знаменателю. Поэтому ты делаешь вот этот общий знаменатель настолько тупым, чтобы оно везде работало одинаково. Естественно, приходят пользователи и говорят, а у меня вот в этой дуле там есть еще, например, бранч кавердж. А почему у вас нету? Ну, как бы у меня нету бранч каверджа, потому что вот в общем случае тут и вот тут вот.
Вот тут его не завезли. Естественно, очень хорошо, если Тула очень умная, дает тебе очень умный репорт, это все показывать. Но с той же самой стороны... В дашборде, если у тебя много языков, ты это не потянешь, потому что, допустим, если у одного языка есть, допустим, у утилиты какие-то там фичи statement coverage, а у другого нету. Вот. И как ты это в DashBar тебе будешь объединять? А если ты сидишь на моноязыке, то вот тебе .cover, по-моему, этот statement coverage вытянет и работай. Вот.
Но тут уже кому что. Если ты, конечно, хочешь заморочиться по кавериджу, да, и прям вот хочешь на максимум, есть утилиты, которые нацелены чисто вот на работу по кавериджу, да, и тогда это может быть твой выбор. А если ты не такой адепт каверидж, и тебе хватает лайн кавериджа, ты можешь работать с более широким набором утилит. Окей. Насчет кавериджа, у меня была интересная история с Rust. Там с кавериджом не очень хорошо, но, по-моему, Tramplin не умеет бранч каверидж, а LLVM...
По-моему, тоже не умеет. По-моему, только line coverage. В общем, очень интересный каверидж, когда у тебя фактически есть, как ты говоришь, multi-line statement. Потому что в Rust вообще форматер любит длинную строку разбивать на несколько линий, особенно если у тебя несколько дженериков вложенных, там будет здоровая такая портянка, но фактически это один стейтмент.
И самое страшное, когда ты смотришь в результате, ну, в репорт, и у тебя у этого одного стейтмента половина покрыта, половина зеленая, половина красная. И ты такой, и как это считать вообще? Потому что он, видимо, там расставил как-то так метки. Своеобразно. Или потом тулай, когда все превращало в репорт. Может, репорт тулай просто плохая.
Но и то же самое, допустим, в JavaScript. Особенно если ты с TypeScript, там все вот эти вот, Истамбул и прочее, там тоже ужас, на самом деле, с каверджем. Потому что я как адепт каверджа могу сказать, что точный кавердж можно получить, наверное, только в .NET, но может... В дот-камере. На самом деле, кроме дот-камера больше нет улов. Есть еще какая-то. Коверлет. Коверлет.
Я помню, Саш, у нас была проблема, когда мы новые фичи не могли вязать, потому что совсем новые фичи шарпа, потому что у нас они в кавриж, в общем, плохо открывались. Коверлет тогда не успел доработать, а я тогда был маньяком и делал плохие вещи. Утилиты в основном не работают с исходным кодом, они не расставляют вот эти вот метки в исходный код, поэтому обратно сделать обратное преобразование, а где же это было в исходном коде?
Скорее всего, там можно пофейдиться, особенно если у тебя идут какие-то оптимизации. Поэтому... там действительно могут возникать вот такие вот артефакты. Я вот думаю, что тот кейс, который я наблюдал на PHP-шном наборе, где мне пришлось писать логику уточнения, тоже проблема. именно того, как сработала инструментация и обратное отображение. Все так, да. То есть полностью вводить какие-то строгие критерии на эту метрику, наверное, не стоит.
Но использовать ее, допустим, в качестве... Понятие в качестве какого-то опорного пункта на ревью, когда ты смотришь в код, который тебя попросили посмотреть, чтобы вообще понять, что происходит, что покрыто, что не покрыто, я считаю, что это просто must have. Но при этом есть действительно бесполезные метрики. Давай поговорим. Бесполезная метрика – это lines of code. Мы тут немножко обсуждали больную историю с Lines of Code. Что такое метрика Lines of Code? Ее можно мерить по-разному.
Способ измерения метрики Lines of Code заключается в следующем. Ты берешь файл. Ты знаешь, сколько в файле строчек. Дальше ты вычитаешь из него whitespace строчки. И вычитаешь строчки с комментариями. Вот. И, соответственно, все оставшееся — это lines of code. Дим, можно я тебя перебью? Специально для людей, которые...
нас слушает, и в этот момент, когда Дима начал говорить про бесполезные метрики, он заблюрился. То есть... Понимаете, он сейчас говорит что-то настолько секретное, настолько серьезное, что решил, чтобы его потом не зарекогнизили. Все зависит от того, кто как пишет код. Вот, допустим, кто-то пишет код, сколько там? 86 или 92? Ну, вот сколько вот это вот, черта, я забыл, сколько всего? Да-да-да. Там зависит от... 80, вот кто...
Погоди, а почему ее туда пихают везде? Я везде... Это размер терминала. Это размер терминала, да. И вот... Есть 3 нового, есть там до 120, по-моему, там зависит. Зачем метрику везде пихают? Ну, на самом деле, смотри, если у тебя есть врапер какой-нибудь, ну, то есть автоматический форматер, ну, много кто любит эти автоматические форматеры, да, они делают тебе...
этот код так, чтобы он помещался. То есть вот ты делаешь отрезку, у всех в проекте код будет помещаться в такой монитор. Потому что кейс, допустим, у тебя вышел разработчик с 13-дюймовым макбуком. да и у него маленький монитор там да там очень тяжело считать я я проклинал джаву когда мне нужно было у меня был у меня был и у меня
Я когда работал на штате, у меня был Air 11, по-моему. Как можно работать на Air? Так вот, ну, работал. И, короче, когда я открывал... И у меня, то есть я тогда еще на пыхе сидел, корячился. Я открывал, и у меня просто часто не хватало экрана для просмотра кода. Ты постоянно туда-сюда, туда-сюда. Голишь нормально. Глаза-то жалко, ты тоже маленький не поставишь. Чуть-чуть увеличил, и все.
скролить но это тяжело вот но при этом с другой стороны я просто закончу я в эпоху сертификации сертифицировали мы пост фикс Вот. И у PostFix в тех исходниках, которые нам дали, там прям даже, мне кажется, не 80 было, там вот такая вот просто была батарея кода. где они абсолютно пренебрегали нью-лайнами, и это просто было реально как том войны мира. Ты просто читаешь, и это совершенно невозможно было читать. То ли разрабы его подредактировали, то есть он...
То ли он действительно такой был, но это просто было невозможно считать. Мы там авторизацию что-то копали, смотрели, как она устроена, вообще невозможно было. То есть вот растяните вы, сделайте большие линии. А кому-то нравится сидеть в маленьком мониторе. Может, у человека просто зрение маленькое, плохое. Так нет, а я все-таки хотел понять. Ну, я согласен, что lines of code это метрика, которая, ну, типа, из метрики code coverage можно в динамике что-то понять.
то из лайнцев в код нельзя понять ничего. А почему ее вообще куда-то пихают? Вообще, зачем считают это метрикой? Ну, слушай, ты знаешь, вот... Мы сейчас какие-то вещи разбираем. Вот тут у нас перформанс плохой. Меня спрашивают, а какого размера этот проект? И как ты скажешь, ну вот смотри, под какого размера этот проект? Ты можешь сказать, хорошо, я скачал с гитхаба, размер репозитория составляет 400 мегабайт. Скажет тебе что-то об этом размере проекте? Ничего. Это включает Node Modules.
Если их закоммитили, то да, включай. Да, там, то есть смотри, ты скачал, там может быть вообще, во-первых, большая история гитар скачаться с этим, да? Во-вторых, могут доехать какие-то...
дополнительные бинарные файлы. Может что-то через git.lfs вкачаться. Поэтому ты не можешь сказать, какого размера этот проект без того, что ты... относительно можешь оценить его по лайнсов код да то есть проект может быть весит там 200 мигов вот а лайнсов код у него там будет пару тысяч то есть ты понимаешь тебя приехал какой-нибудь game devs куча сетов
Вот, какой-то совершенно простой проект, там, Ragdoll, может быть, да, на этот Ragdoll тебе положили столько эсеров, что, ну, просто вот, вот. И Lines of Code, в принципе... Наверное, она хороша, когда тебе нужно просто прикинуть размер проекта. Но я себе слабо могу представить, что в Long Run эта метрика имеет какой-то смысл для тебя как разработчика. Вот, ну то есть, ну вот было у нас там до релиза 100 тысяч строк кода, потом на следующем релизе было 98 тысяч строк кода, а потом стало 102.
Но вот когда у тебя было 100 тысяч строк-кода, стало 98, какой вопрос? То есть ты либо зарефакторил, либо выкинул кучу фичей, либо, ну, как бы заменил один компонент на другой компонент фичей. Ну, то есть что она показывает? Я знаю хороший пример, когда эта метрика и метрика количества коммитов помогали. У одной команды был спор. По поводу 6 миллионов рублей, которые заказчик считал, что потратили нецелевым опытом. И там реально пошли в бой нотариально заверенные распечатки кода.
Ну, SVN-логи. И тогда чем больше, тем лучше. Реально это как бы... Ну, люди работали, они не потратили деньги в никуда. Просто как бы заказчик не понимал ни черта вообще в разработке. Ну вот, такой Russian business классический. И это помогло. Так что Linus Scott в таких случаях решает. Лучше стандартный индусский прием разбивать все совсем по максимуму. Ты хороший пример метрики сказал. Эту метрику обычно никто не считает. Я не видел.
Метрика количества коммитов, она тоже на самом деле очень хорошая. То есть у меня вот был коллега, с которым я одно время работал, он там сидел, использовал GitKraken. Почему на всю жизнь запомню это? Вот, и он, короче, каждый, у него был принцип такой, если он редактирует блок кода какой-то, да, то есть у тебя там функции, цикл форм, он там что-то поредактировал, он делает это в одном коммите.
То есть он все несколько строчек, измененные в каждом блоке, всегда коммитил. Коммитов просто там прилетало на куче. И в этом случае метрика не говорит ничего. А почему он это делал так? Потому что не пользовался идейными продуктами, и у него не было доступа к local history.
Вот, собственно, наличие Local History, это была единственная причина, большая серьезная причина, почему я дропнул студию с ReSharper и пришел в Rider. Потому что... Можно сидеть в local history и вот такой вот отпатывать назад. Ребята, а как? В смысле вы не работаете так, как этот чувак? Я обычно коммичу по несколько раз в день, потому что это же охрененно. Ты сидел, сделал, закоммитил. Потом что-то сломал.
Ну, тем-то, не знаю, откатился до предыдущего коммита. Как вообще работать можно, не делая коммита каждый день? Пользоваться продуктами Intelligent. Не, ну Local History нормально. Local History, да, используется. Все. Вот. Ты сидишь в local history, отматываешь. Нет, понимаешь, у него доходило до того, что вот у тебя идет один цикл for, другой цикл for. Он в одном поменял, сделал один комит, в другом поменял, сделал другой комит. Вот. И на самом деле в итоге...
Он не давал к этим коммитам нормального какого-то сообщения, потому что ты рехнешься на каждый блок писать какое-то сообщение. Сейчас всякие copilot помогут писать такую здоровую портянку. Кстати, мне понравилось. Разбирали ребята AI Assistant, которые вместе с райдером... приходит. И там самая популярная фича, которую люди используют, это как раз сгенерирует коммит-месседж. Прям люди, вот маленькие коммитами, все нормально. Слушай...
Я вот тоже, это отдельная тема, но я не понимаю вот этот срач. Люди говорят, типа, ты делаешь сквош коммитов, зачем ты делаешь какие-то вещи? Камон, у тебя, если ты делаешь какие-то... оправданный коммит-месседжи, то ты просто, ну, подразумевается, что ты, скорее всего, мастер, будешь заливать чинжи мержом. То есть, если ты черепикаешь, то это отдельный момент.
Но, так сказать, вы будете заливать мержом. А если ты будешь заливать мержом, и тебе нужно посмотреть полную историю изменений в мастере, то First Parent тебе в помощь. Есть команда git fastpart, которая тебе показывает в GitLog не все коммиты, которые связаны, а только конкретные коммиты для этой бранши. Так что все хорошо. Ладно, слушайте.
Я хочу поговорить про метрику, которая самая главная, и про которую все всегда говорят. Заходишь в раздел метрики, и это всегда самое первое. А именно, цикломатика комплекции. Мы же о ней говорили. Мы уже про нее говорили, и мы поговорим про нее еще раз.
Ну ты в курсе, что это за метрика такая, да? И даже те наши зрители, которые смотрели до этого, они в курсе об этом еще третий раз уже, потому что мы как-то ее разбирали, и хотелось бы уже немного в деталях поговорить, что это, как она считается. что там у нее внутри и так далее. Ну, на самом деле метрика достаточно бесполезная, с моей точки зрения. Ну, то есть смотри, у тебя на каждое ветвление делается плюс один.
И, соответственно, в итоге у тебя появляется цифра, сколько у тебя появилось светлений. А что она говорит в случае свеча?
Вот, допустим, у тебя есть свитч. Кейс, кейс, кейс, кейс, кейс, кейс. Как ты его будешь считать? На каждый кейс единичку? А вот если тебе просто нужно вот так вот разобрать, да? Поэтому вот ты получаешь в конце число, и оно... на самом деле не говорит ничего вот то есть когда ты видишь сколько из ветвлений с одной стороны да допустим для одной функции ты можешь увидеть что у тебя там куча
Ветвлений, куча вложенных циклов, ты можешь увидеть, что вот у тебя страшное число получилось. Да, у тебя функция не какая-то простая, вообще без ифов, венов. Но, а есть ли такой алгоритм? Вот такой у тебя алгоритм, и ты там как-то хитро еще рекурсию к этому приплел. Вот, ну да, вот у тебя такой алгоритм. На самом деле эту метрику попытались спасти. То есть я не читал саму исходную работу, но у Sonora, если погуглить, есть статья на основании статьи Complexity Measure. Они сделали...
Cognitive Complexity, то есть они попытались, то есть они посмотрели, то есть для чего Cyclomatic был введен, для того, чтобы ты, насколько легко ты можешь понять. код который написан да но Отражает ли количество ифов то, насколько ты его легко действительно можешь понять? Вот я как раз вот тот вопрос, который всегда я говорю, что ну как бы я бы не сказал, что количество ифов это является прям ключевой причиной того, что ты смотришь на код и говоришь, что это за хер...
Да, да. Ну, то есть смотри, у тебя есть два примера. Один пример у тебя там свитч с, допустим, четырьмя кейсами. А другой пример, у тебя есть метод, в котором есть пару форов и if. Да, и все вложено. Cyclomatic Complexity у них один и тот же. Но когнитив комплексити совершенно другой. То есть если у тебя в методе один свитч с парой кейсов, его очень легко понять, что он из себя представляет.
А если в методе у тебя два обложенных цикла и еще какие-то внутри понасованные… А еще рекурсия. Да, но это не всегда хорошо. И, кстати, вот в случае рекурсии… Cyclomatic Complexity тебе вообще никак не помогает. А в тот концепт Cognitive Complexity, который, собственно, ввел Sonar, они добавляют на каждый... Они по единичке на каждый метод, который исполняется в этой рекурсии, рекурсивно они еще по единичке добавляют, чтобы ухудшать метрику.
Формально там вот в чем. То есть у тебя есть No Coalessence. Не помню, как тут, короче. Ну да, да. Вот. Короче, когда у тебя, допустим, есть LVS оператор, Cyclomatic тебе сделает плюс один. Ну, потому что if. Cognitive Complexity тебе этого не будет делать. Когда у тебя есть switch... Когнитив комплекситет, который они предлагают, оно тоже не будет делать. Когда у тебя есть, например, читабельность выражений...
То, о чем я говорю, это можно посчитать в статье, потому что я вдохновился. А можешь скинуть ее? Да, конечно. Я добавлю шоу-ноуты. Вот. Я могу ее... Давай после этого скину. Соответственно, дальше, если у тебя есть А равно-равно Б равно-равно С, если язык такое позволяет, то, или, например... А равно равно Б равно равно С или Б равно равно С равно равно Е, то оно тоже это по-разному учитывает. То есть оно смотрит, например, на последовательность операторов одного типа.
И начинает тебя постоянно увеличивать на единицу. И, соответственно, за счет комбинации упрощений... То есть с одной стороны они уменьшают penalty, то есть в случае свеча. С другой стороны, например, в случае рекурсии они увеличивают penalty. За счет этого они действительно пытаются этой метрикой построить какую-то чиселку, которая тебе говорит, насколько сложно понять этот метод. Вот. И на самом деле, понимаешь, я, скажем так, я когда эту метрику видел...
Для меня эти чищники мало коррелировали. Когда я посидел, почитал статью, я такой, ага, вот она на самом деле что значила. Только у меня образования хватит почитать и разобраться в статье. Однако, я уверен, мы всегда спорим, насколько умный менеджер. С моей точки зрения, не всегда менеджеры обладают достаточной квалификацией.
Я обладаю достаточной квалификацией, чтобы разобраться в каких-то технических вещах, типа как строится вот эта метрика, почему она строится вот так, почему она строится не так. Могут быть крутые метрики. Мы опять же обсуждали с каверджем, что у нас может полстейтмента подкраситься. Но менеджер может сказать, что это плохо. Давай фиксим. А менеджер, который технически подкован, который может разобраться, почему так, он тебе таких вопросов не задаст.
Поэтому, наверное, в случае с Cognitive Complexity эта метрика тебе хороша, когда ты разбираешься и можешь получить сам фидбэк на свою работу. спорить относительно вот этих вот чисел с теми людьми, которые, допустим, не разбираются, откуда взялась эта чиселка, ну, как-то не очень бы хотелось. Вот. Но на самом деле есть еще перцы... Для объектно-ориентированного программирования есть набор метрик. И набор метрик это, я могу неправильно прочитать, вот Chedaber и Kemmerer.
То есть у них есть набор метрик, которые позволяют понять с точки зрения объектно-ориентированного программирования, насколько там хорош или плох твой класс. Простые метрики, да? Начнем с самых простых. Например, есть Deep Inheritance. То есть ты берешь какой-то класс и смотришь. От скольких классов он отнаследован до кончая системных классов. Ну, дальше ты не хочешь внутрь идти. И, соответственно, эта метрика тебе может показать...
Ну, то есть, вообще, насколько здесь ООП пользуются? Или тут ООП просто взяли, распилили все на отдельные классы, и на этом ООП закончилось? И отлично. Опа, так, все нормально. Значит, это хорошее применение ООП. Ну, а как же Dog Cat Animal? Как же этот пример? Давайте так, DogCatAnimal это замечательно, а теперь если мы разрабатываем игру или мы разрабатываем, допустим, интернет-магазин, нам нахрен это не надо.
Но нам надо найти Дох и Кэт, это самое сложное. Эскаватор – земля копать или... Земля копаться – эскаватор. Слушайте, ребят, я хотел сказать, у меня просто через 10 минут занятие. Я могу отвалиться, а вы как раз продолжите. Вы как? что прям тема идет хорошая, интересная. Мы можем продолжить потом. В смысле... А, нет-нет-нет, у нас уже классика. Я сейчас раздам админские права, и вы просто когда заканчиваете, вы такие типа, ну все отлично, и закончить. Вань, ты как норм?
Да, норм, но я еще час могу, да, где-то. Ну, где-то полчасика у меня есть. А, ну вот, да, да, да. Все, давайте я плавненько утеку. Да, вот. Всем пока, всем спасибо. Давай. Соответственно, вот это одна метрика. Есть еще метрика number of children. Я подсмотрю вспомогательные материалы. Митрико Наборов Чилдрен — это когда ты берешь какой-то абстрактный класс и смотришь, сколько у него непосредственных детей.
Вот. Тоже достаточно хорошая метрика, которая позволяет тебе посмотреть ширину твоего наследования. То есть не глубину, а ширину. Ну, когда такая метрика может быть полезна... Ну, наверное, она может быть полезна при рефакторинге. Я решил потрогать какой-то абстрактный класс. Скольким людям прилетит, если я там что-то сломаю. Но опять же менеджеру эта метрика, ну, наверное, бесполезна. То есть я не могу представить...
Как менеджер мог бы пользоваться такой метрикой, если бы мы ему эту метрику насчитали. Потом есть всякий ряд метрик а-ля каплинг. Между классами, то есть, допустим, когда у тебя есть два класса, то есть ты перебираешь пару классов и смотришь, как часто один класс использует другой. И по поводу этого выставляешь score. Ну, с точки зрения объектного ООП, я вообще стремя сказать, насколько эта метрика разумная, как бы я ее мог применять. Вот, поэтому...
И, собственно, на самом деле у этого, вот этот набор метрик, тоже в ссылке потом выложим, там много и много всяких версий. То есть каждый может найти что-то для себя. Но мне кажется, что вот эти метрики, они скорее девелопер-ориентированные, то есть если я работаю с какой-то кодобазой, да, и хочу сделать как-то получше, я могу на них ориентироваться в ходе какого-то рефакторинга. Но предоставлять такую метрику менеджерам, да не в жизни. Еще, я могу еще рассказать про метрики. Есть еще метрики.
Код duplication. Это на самом деле достаточно интересная метрика. Я не помню, старая студия одно время поддерживала код duplicates, потом перестала. Вот. Потом они опять сейчас его возвращают. Не суть. Давно уже в студию не заходил. Вот. И то есть это что, о чем говорит эта метрика, да? То есть ты берешь... находишь в разных местах кода повторяющийся код. То есть ты как-то токенизируешь код, а потом ищешь одинаковые последовательности токенов, начиная от какой-то длины.
Естественно, если в каждой функции ты объявляешь переменную integer и присваиваешь ей значение 42, ты не будешь говорить, что это код-дупликейт. Потом разные действия. там, допустим, 3-4 строчки одинаковых везде раскопировал, то да, такая метрика дальше тебе показывает, что вот у тебя есть дубликаты. Вот, и эта метрика... полезно с точки зрения с точки зрения разработки мне кажется здесь трудно отрицать что она
Бесполезно. Трудно говорить, что оно бесполезно, потому что ты хотя бы сам можешь увидеть, ага, вот я написал код, но на самом деле это полный дубликат того, что уже было написано. Или, например... у тебя junior разработчик взял откуда-то скопировал просто огромный кусок кода вставил а вот и ты можешь пойти тому поголовину давайте попросить его все-таки как-то
использовать какие-то более общие подходы. Вот. С этой точки зрения, ну, она вполне хорошая, и менеджер тоже может посмотреть, увидеть, что, ага, вот тут вот как бы люди просто копируют код. Вот, и если менеджер опытный, он может понять, что на самом деле потом в каком-нибудь куске кода что-то поменяют, в других кусках кода не поменяют, и все может развалиться. Вань, ты работал с такой метрикой раньше?
Нет, я помню, когда какая-то IDE, по-моему, студия подсвечивала это, это я помню. Но мы никогда их так специализированно не считали, просто это помогает самому. На самом деле, по поводу менеджеров, конечно, отдельный вопрос, какие метрики стоит им давать, какие нет. Я помню, я QA менеджеру презентовал, собственно говоря, каверидж, когда мы его добавили. Я 150 раз сказал, что не стоит...
Ну, ориентироваться на эту метрику и требовать, чтобы она была стопроцентная, то есть я беру что-то косвенная метрика. Вот результат в качном счете на каком-то там следующем созвоне был вопрос, а почему у нас типа упала... Покрытие упало. Вот я увидел в репорте, что у вас упал каверидж, и почему это произошло. Поэтому это такое оружие, которое ты даешь, и оно обязательно в тебя выстрелит.
Это да. На самом деле еще глупее метрик, ну, то есть, опять же, не все метрики глупые, но некоторые есть бесполезные, ну, с моей точки зрения, опять же. Бывает, ну, то есть, смотри, у тебя, если у тебя есть статического анализа, который в конце выдает тебе по код quality, по security vulnerability, по прочему, он выдает тебе какой-то scoring.
Что может являться этим скорингом? Что тоже являются метрики? Это может просто чиселки. Он может сказать, что у тебя столько годсмелс, у тебя столько vulnerabilities, у тебя там... Выдать тебе набор чисел и сказать, что я так их подразделил. И с этим еще можно жить. Ну, то есть, допустим, код смелс, можно сказать менеджеру, вы не смотрите код смелс, код смелс это как бы у нас 10 лет назад работал разработчик Ваня, он пришел, построил себе, ну...
Он сделал вот такие вот настройки, их никто не трогал, а все стали писать по-другому, и поэтому тут считают, что это код смелс. Или кто-то там пришел, установил Airbnb профиль.
Начали под этот Airbnb профиль писать, потом решили больше не писать, у нас остался код, и там вылезли код смелс. И здесь интересно скорее серьезные ишуи, типа, допустим... то есть ты видишь что у тебя допустим какие-то зависимости вам да и ты можешь ну и как такая метрика считается потому что это все-таки метрики изнутри Все это считается инспекцией или рулами. вот и соответственно анализаторами просто анализаторы вот и пишешь некий анализатор который
смотрит либо на АСТ, либо начинает залезать в семантику и пытается найти какие-то паттерны. И по этим паттернам ты, соответственно, генерируешь шишую, и в конце концов у тебя... Все эти ишуи суммируются, выдаются разом, и утилита как-то их категоризирует. В случае security ишуи, да, там бывают разные механизмы. То есть, соответственно, часть механизмов ты можешь пойти в базу данных, то есть есть база данных уязвимости.
Есть у Google база данных уязвимостей, есть у вендоров разных базы данных уязвимостей, например, Chipmarks. Есть другие вендоры, там open source, не open source, если кто-то ставил... Если кто-то работает с MPM-пэккеджем, и там постоянно сделаешь MPM-инстал, и тебе там начнет вопить вот столько там еще vulnerable пакетов, там еще что-нибудь. Вот.
Соответственно, в такие базы данных ходят и узнают, там есть у тебя какие-то иши, нету, ну, то есть есть уязвимости, нету, показывают. Есть там тейнт аналайзера, да, то есть это где смотрится.
Если путь между непроверенным юзером импутом и какими-то сенситив участками кода, например, запрос... SQL, да, или, например, вывод каких-нибудь данных в response, вот, и проанализировали, нашли такой путь, подняли шуи, и в итоге построили, у тебя есть количество и шуи x. С одной стороны, это тоже сама по себе метрика, но с другой стороны, менеджер хочет понять, а как из этого получить какие-то action points, кроме того, что это нужно пофиксить.
И тут они додумались до такого. Давайте мы скажем, что у нас есть метрика, а сколько нам нужно времени. чтобы это все пофиксить. Не забыл, как она называется. Техдок. Короче, она меряет техдок в часах. То есть у тебя пришла еще я. Кто-то, кто сидел, писал эту инспекцию, написал, что вот это вот еще я ее устранять 10 минут, а вот это еще я ее устранить 2 часа.
И когда я набирался вдохновение в интернете перед нашей трансляцией, я набрал на один некропост, где... Ребята в течение пары минут набросали код на Java, которые ничего не делают, просто ООП. Вот, и одна из, ну, то есть, и Сонар, короче, насчитал там тех долго на несколько часов. То есть, ты написал код, да?
Короткий, который вполне возможно решать твою задачу, больше тебе ничего не надо. А тебе нарисовали, что у тебя там несколько часов или даже несколько дней теперь тех долго, чтобы убрать все вот эти вот эшуи. И с одной стороны, то есть менеджер может сказать, ага, вот это значит, хороший менеджер может сказать, то есть вот у нас есть финансирование проекта, тут есть техдолг, допустим, на две недели.
Значит, мы умножаем 2 недели на 2, вы все равно не справитесь. Еще добавляем 10-20% на издержки тестирования, получаем полтора месяца, допустим. И мы закладываем бюджет проекта полтора месяца, чтобы вы будете сидеть, короче, и работать над этим тем долгом. А другие могут сказать, ага, вот вы тут, короче, тут посидел программист Петя.
За неделю написал утилиту. Эта утилита, короче, начала нам там зашибать, я не знаю, по миллиону рублей в месяц просто за счет того, что он молодец написал такую утилиту. Но техдолго там, короче, на... Там тоже на месяц. Поэтому Петя плохой программист, потому что программист Вася рядом посидел и, короче, написал утилиту с техдолгом в 3 часа. А его утилита может вообще ничего практически не делать, да, или там не зарабатывать денег, там еще чего-то. Ну да. Да, говори.
Тут такой вопрос, это классическое, что человек, который ничего не делает, он не совершает ошибок, ему меньше прилетает по голове, чем команда, которая делает критический компонент системы, понятное дело, там будут проблемы. И он будет выглядеть в корпоративном мире нелицеприятно, на самом деле, хотя толку от этого больше. Да, и поэтому смотри, мы опять же говорим корпоративный мир. Когда ты приходишь в Enterprise,
Я работал в интерпрайсах, это отдельная история, может когда-нибудь расскажу. Ты приходишь в интерпрайс, ты садишься за код, который иногда писали еще раньше, чем ты из универа выпустился. У меня самый старый код, с которым я работал, был написан 13 лет назад. В 1997 году, а я в 2010 пришел и увидел это счастье на сях плюс ассемблер. У меня был код, то есть вот на предыдущем месте работы, да, то есть там ребята сидели, писали на большом телекоме.
Писали код еще с 90-х, потом часть сначала она мигрировала на Visual Basic, потом она мигрировала на C Sharp. На C Sharp оно осталось. И когда я сел за этот некропроект... И мне надо было что-то поправить, то есть я взял, скачал проект с репозитория, да, попытался его сбилдиться, оно не сбилдилось, мне выдали папочку, сказали, вот это вот, короче, папочка, ты, короче, ее положи в репозиторий.
Ну, тут что-то заработало. Потом я начал как бы разбираться, а там просто куски некомпилированного кода. И, в принципе, как оно собралось и начало работать, у меня тоже возникли большие вопросы. Вот. И я к чему веду? Я веду к тому, что когда у тебя есть такой большой некропроект, такие метрики, как техдолг, не имеют никакого значения. То есть там не имеет техдолг метрика.
Бесполезно. Lines of code, ну, просто чтобы ужаснуться и там хвастаться перед друзьями, что я работаю там в проекте, в котором строк больше, чем в Linux kernel, да, допустим. Вот. И, соответственно, coverage вообще забыл. там никакого камера потому что я и есть тест я есть прод вот и как бы вроде
Когда метрики делают для таких больших менеджеров в интерпризе, вот ровно там они становятся бесполезными, потому что у тебя есть продукт, на котором держится там core business. Этот продукт имеет там огромную value. И ты ничего не можешь с ним сделать. В интерпрайзах обычно бывает как? Они нанимают соседнюю команду, соседняя команда говорит, что у вас решение говно, мы начинаем пилить свое решение. И конкретно в этом телекоме случалось так, что там SEO менялся раз в 4 года.
Вот, то есть работает команда при текущем SEO, SEO сменяется, эта команда дальше работает, приходит новая команда. смотрит, как-то оценивает имеющийся ПО, говорит, ваше ПО говно, начинает пилить, короче, ПО, и если оно за следующие 4-5 лет не успели от него запилить, это ПО летит на помойку и работает вот дальше. Вот, и поэтому не все проекты там удавались, просто из-за смены руководства менялся менеджмент, и как бы менеджмент говорил, ну, как бы тут недопильно, а вот это еще работает.
А потом этот же менеджмент возвращался, начинал оценивать это по каким-то внутренним метрикам, по каким-то внутренним стандартам, говорил, нет, это же все-таки говно, давайте перепишем. И цикл начинался заново. больших таких старых интерпрайзах то есть но и раньше понятий код колись вообще не было как такового а вот в таких интерпрайзах
Нет никаких метрик, и если где они появляются, то, скорее всего, на новых продуктах, а на старых они абсолютно бесполезны. Но это не говорит о том, что, допустим... Так везде. То есть я, когда копал темы анализа, то есть есть вот американская компания TNT. Ребята пытались делать какие-то анализаторы своего кода, искать там ошибки, что-то там считать на этом. То есть некоторые компании, то есть приходили хорошие умные технари, которые говорили, а давайте мы...
Поймем вообще, что у нас там за объемы кода, давайте мы их как-то попробуем причесать. С этой точки зрения, с точки зрения рефакторинга, ну, метрики оказываются полезными. Если ты берешься за рефакторинг и переписывание старого кода, то единственное, что у тебя есть, это метрики. Потому что чаще всего люди, которые могли как тебе помочь, они либо уволились, либо умерли.
Вот, у тебя кроме метрик и тестов или, не знаю, там, тест-кейсов или еще что-то, хотя бы сообщение компилятора, что оно компилируется, у тебя больше ничего нет. У меня тоже прикол был как раз с этим. Когда мне дали код на сях, его неизвестно чем было компилировать, я нашел какой-то компилятор. Это был под микроконтроллер. Я скомпилировал этим компилятором, взял то, что заливается в девайсы, посчитал чек суммы, а они не совпадают.
там она заливалась но как команда которая разработала давно уволилась меня отправили к ним чтобы я спросил как она работает я пришел они говорят что все еще этим говном пользуетесь они просто уже как бы той развили вперед там ну понятно за 13 лет у них все там ушло вперед ну вот в общем то было весело и и и вот так когда ты сталкиваешься старым кодом то у тебя кроме 3 больше ничего нет это можешь
Что-то посчитать. Хорошо, если есть тесты, если ты можешь кавереж посчитать и вообще понять, насколько ты этим тестам можешь доверять. Потому что если они практически ничего не покрывают, то у тебя нет тестов. Поэтому такая... Они действительно бесполезны в рамках интерпрайза, но не бесполезны для менеджмента, а для разработчиков, тем более нового.
На Legacy Project это может даже и спасением будет в каком-то роде. Ориентиры какие-то, потому что действительно, когда ты приходишь, новый код видишь. Вот, ты его открываешь, ну ты открыл его, посмотрел, как-то непонятно что-то. А то ты можешь запустить какой-то анализатор и какую-то картину получить. Так что, мне кажется, менеджменту бесполезно. Наверное, так. Чем новее проект, тем больше для менеджмента увеличивается ценность метрика, а чем старше для разработчиков. Да.
Тут ты прав. И на самом деле, когда мы продаем свой продукт, когда он к нам приходит, то есть у нас периодически есть созвоны с кастерами. И у нас есть с тема. Иногда, ну, то есть этой сервис-тиме нужно подкрепление, да, чтобы вышел технарь, и технарь уже говорил с кастерами на их языке. Поэтому я как бы слышу, о чем идут разговоры, и очень часто...
На самом деле кастомеры спрашивают, а у вас есть дешборды? И дальше уже начинаются какие-то разговоры, а что должно быть в дешборде? То есть люди на самом деле, менеджеры, да? И технари тоже, в принципе, ледовые инженеры тоже спрашивают, где это же порты. Они хотят что-то померить. То есть, допустим, наверное, они хотят видеть, сколько и шуй на проекте.
То есть ты можешь увидеть, что, например, проекты. И тут на самом деле метрики, на самом деле, они могут быть интересны с точки зрения, смотри, у тебя есть два проекта, оба 10 тысяч строк-кода. Но в одном каверидж, допустим, всего проекта, допустим, 70% и шуй 100%. В другом каверидж 5%. И там ИШУИ столько, что у тебя просто репорт не открывается. У нас были такие клиенты. У меня клиент приходил в саппорт, говорил, вот у меня 2 гигабайта файл с репортами ИШУИ.
Просто пришел такой, 2,2 гигабайта файл, а мы не можем эти файлы получать от них, мы не можем кастомерский файл. Он говорит, у меня не открывается в веб-браузере этот отчет. Я говорю, да ладно? Ну вот мне надо, я там пытался придумать. Как же уменьшить этот отчет, чтобы хотя бы посмотреть в браузере. В итоге что-то придумали, он посмотрел, и даже не знаю, чем эта история закончилась. Ну, в общем, ты можешь отобрать одинаковые проекты по размеру.
Тут тебе поможет lines of code. А дальше ты сможешь как менеджер посмотреть, какой проект паршивый овца, какой нет. И дальше ты сможешь понять. Вот тебе нужно что-то запилить. Ну, то есть тебе на совещании сказали, мы хотим там рефакторить вот этот вот проект. Ты как менеджер открыл дешбанку, увидел, о, в этом проекте нет кавериджа, куча и шуй, и они туда еще хотят лезть. Нет, мы им не дадим лезть. А вот в этом проекте и кольте гейты настроены.
И coverage есть, и шуй не так много, и коммитов там, допустим, туда часто какие-то коммиты вливают. Значит, проект это не некропроект, его можно потрогать, да, и скорее всего там... Соблюдаются определенные стандарты и, скорее всего, достаточно безопасно. С этой точки зрения эта метрика действительно полезна менеджеру. Это обычная проблема. Например, надо посмотреть сервис другой команды. Есть же команды, которые, например, пользуются райдером, решарпером и исправляют все ворнинги.
Есть команды, которые этим не пользуются, не смотрят, ты просто выкачиваешь сервис. А там пару тысяч. Все желтенькое. А потом смотришь на баг, а там просто null reference exception, там, где райдер вот так вот желтеньким подсвечивает, что там надо проверить на null у вас. Это действительно хороший метрик. Можно увидеть, насколько у тебя люди... Понятно, что можно увидеть, что они душнилые, если у них ноль абсолютно.
Какие-то конченые душнилы. Либо что им вообще пофигу, они просто write-only код, который пишут. Про большой код у меня есть история, когда у нас автотесты были именно write-only, когда просто большой файл... дописывается в конец. И потом человек его решил зарефакторить и разделить. И этот дифф, он не влезал, ну, собственно, вот этот...
Я забыл, Bitbucket, по-моему, он не мог показать этот див слишком большой, и он ломался. И там, в общем, в результате ручным пушем это все решали в репозитории, в обход. бакета, чтобы потом можно было нормально рефакторить. У меня, похоже, на самом деле опыт был. Допустим, смотри, одна и та же команда. Кто-то сидит на студии. Без Решарпера. Кто-то сидит на студии с Решарпером. Я сидел с райдером. Вот у меня тиммейты что-то коммитят.
Вот, например, оно сонар проходило, то есть я когда в сонаре работал, да, оно сонар проходило quality gate, а райдер подчеркивал, и я вот какие-то вещи хотел править, потому что я вижу, ага, вот райдер считает, что здесь это ошибка. Я на самом деле тоже согласен. Но у меня очень большой бэкграунд по разработке анализаторов, по сертификации, по тому, насколько это вообще крутился.
И я толерантно отношусь к тому, что анализатор может сказать, что у вас здесь большая беда и вам нужно что-то исправить. Но на самом деле у разработчиков же нервный тик. То есть если кто-то... Мешает запушить их драгоценный код в бранчу, вот ровно в мастер, в мейн, как вы там не называете сейчас. Если вы не можете запушить в мейн, разработчик начинает орать, вот, плохая тула нам насчитала, или, например, кавридж упала, мы там не можем.
замерзать и когда ты сначала поработаешь в команде где сверху допустим лид решил кольце гейтом быть тестом быть ковриджи быть вот таким метриком быть и ты не умею как бы за любой исключительной ситуации ты можешь там идти и просить разрешение у лида это замерзнуть он нажимает клавишу она между все хорошо все рады и тогда у тебя есть какая-то гарантия того что
Ну, ход, с которым ты работаешь, во-первых, как ты сказал, да, он не будет подчеркиваться желтеньким цветом, показываться, что здесь ошибка, да, во-вторых, скорее всего, какие-то... Тупые ошибки будут пойманы. Есть же тупые линтеры на АСТ, а есть ДФА. То есть Data Flow Analysis. И там, например, какие-то хитрые инспекции, которые могут тебе какие-то кондишены почитать и сказать, а вот это у тебя никогда невыполнимо. А тут у вас, ребята, нул придет, и всем будет плохо.
Естественно, языки имеют некий синтекс Sugar. Для трека вот этой новобилити и прочего, да, но как бы есть еще ошибки, которые, то есть, допустим, ты в дикшнере положил по ключу 2, а достал по ключу 3.
Вот, и, соответственно, DFA движок позволяет тебе такие вещи потрагать. Вот, и наличие метрики Quality Gate по метрикам, оно тебе позволяет гарантировать, что... Тупые ошибки до какого-то уровня, все зависит от того тулас, которым ты пользуешься, на этом проекте будут отсутствовать, либо минимизированы.
А потом ты можешь прийти, вот у меня так было, потом я пришел в компанию, где нет ни тестов и ничего, и я просто, вот я просто, это было ужасно. То есть на самом деле у тебя нет тестов, у тебя... Деплой заключающийся в том, что ты копируешь папочку, то есть ты заходишь на продакшн сервер, копируешь, останавливаешь там EIS, копируешь папочку.
Потом копируешь на нее другое, копируешь на нее свой результат со своей машины, запускаешь, проверяешь, работает, не работает, и все, пошел. Вот такие компании тоже есть. И вот, ну, они платят много. Они действительно платят тебе много просто за счет того, что у тебя есть экспертиза разрулить, если что-то пойдет плохо. Но при этом у тебя есть нервы, что в любой момент что-то может отломаться.
то, чего даже ты не знал. И вот если в твоей новой команде совершенно нет тестов, нет каких-то метрик, нет статического анализа, Но ты можешь получить бомбу замедленного действия. То есть, с одной стороны, там может сидеть какой-то умный лид, который просто не будет пропускать говно в пол-реквестах. Но часто там даже бранчи не бывает. Все коммитят в мейн. Все. Да, так многие работают. И, соответственно, работать в такой команде не очень.
Вот совсем не очень. И это говорит о культуре. Но при этом иногда общаешься с сеньорными разработчиками, которые работают в таких известных конторах. и ты им начинаешь говорить о код-квалити, а они обозлены. То есть человек, который пишет крутые сервисы, говорит, что я прям придерживаюсь высоких стандартов код-квалити. Обычно кто-то хочет в компании купить решение.
Потом они подтягивают людей, которые также отвечают за принятие этих решений, а они уже не согласны. Они говорят, что нет, я считаю, что они мешают. Я не согласен с их результатами. Поэтому что-то одно, что может быть полезно в одном месте, допустим, какие-то решения поискать. Это хорошо, но с другой точки зрения, сереньорным программистам действительно могут какие-то вещи мешать, потому что они говорят, что вот это я считаю, что это false positive.
А вот это вот неприменимо, потому что у нас другой стандарт, то, как мы работаем. У нас был, когда в Sonore в комьюнити приходил... А, там у Sonore можно, короче, Ишую в гитхабе поднять. Вот, если у тебя там, у .NET, если тебя там что-то не устраивает. Там пришел дядечка. Я не помню, что точно инспекция. Короче, он просил, чтобы инспекция а-ля типа там if что-то не равняется true. if что-то равняется true, перепилили, if что-то не равняется false.
Ну, то есть там была что-то инспекция, типа там и что-то равняется, равняется труб, просто что труб можно убрать и просто if. Да, ну да, просто. Да. А он говорит, а вот мы, типа... Аматер-девелоперы со стажем дохрена лет. Мы вот любим писать не равняется false, и вы нас не убедите, поэтому переписывайте инспекцию, чтобы она везде ставила, саджетила не равняется false. Вот, то есть как бы у людей с опытом может быть свой взгляд на вещи, и они будут против.
Тут такая история, на самом деле, это как с Rast, допустим, и C++. Да, я достаточно много читал споров с Rache по поводу Rast и C++. Я понимаю, что люди, в основном, да, как раз... Плюсовики говорят, что мы лучше знаем, чем ваш статический анализатор.
чем все что угодно, чем ваши метрики. Но статистика ошибок, статистика проблем, она на стороне метрик. Она на стороне тупой машины, которая анализирует. Например, у нас есть... Достаточно мерзкая штука, которая блокирует коммит, если ты коммичишь секреты.
И у нее часто очень много срабатываний, когда она какую-то строку, константу начинает считать секретами. Я вот в тестах пишу, там просто абракадабру написал, да, вот мне просто надо, чтобы оно было. А эта штука считает это секретом, мне надо как-то... переписывать чтобы убедить это бесит с другой стороны если я нечаянно в конфиг заливаю секреты
и начинаю это коммитить, допустим, в development файл я там коннектился к чему-то, она этому мешает. То есть, в принципе, наверное, 50 на 50, ну, от нее польза есть, 50% срабатывания. Ну, так ведь у нас же проблема, очень большая проблема, что... github в публичных репозиториях или еще в каких-то очень много секретов закомичено то есть понятно да она как мешает но статистика все-таки на стороне анализаторов поэтому ну
Я считаю, что надо анализировать. С другой стороны, нужно, чтобы была конфигурируемая. Или ты хотя бы мог какие-то ворнинги закомментировать, прагмы закрыть или еще чем угодно. Вот это, конечно, самое главное, чтобы можно было обойти. То есть, если ты используешь какой-то репорт, тебе нужно... В тех местах, где ты не согласен, уметь это обойти. Иначе это заставляет тебя, как пример у нас с Сашей, анализатор заставлял нас не использовать паттерн-матчинг, потому что его не поддерживаем.
Вот, к сожалению, да. Поэтому нам приходилось там свечки списать или еще что-то там, где паттерн матчинг. То есть получается, как бы, не надо быть рабом тула, инструмент. Это тоже тут, это ссылы Харибы, где надо, между ними надо пройти. И это все так. Вот, например, про пароли ты поднял достаточно интересную тему. У нас вот недавно, в прошлом релизе мы зарелизили hardcoded passwords.
242 в Кадане. На самом деле, как считается инспекция по паролям? В общем случае, ты просто считаешь энтропию по строке. Потом дальше смотришь на ее значение и дальше можешь предположить, ага, вот это пароль, а вот это нет. И дальше ты начинаешь, вот ты посчитал энтропию, тебе помачило все гуиды в программе. Молодец. Вот это пароль, вот это пароль, вот это пароль. Хорошо. Думаешь, ладно, ну.
Фигня вопрос. Я, короче, возьму гуиды, короче, запрограммирую, что если вот строка имеет вот такую длину, там столько-то черточек, вот так вот они расположены, я их регекс вам, короче, все гуиды выключу. Хорошо, Гуиды выключил, начали бить какие-то хэши внутренние. Починил хэши. И на самом деле, в итоге, даже если ты пытаешься очень сильно сделать из этого крутую инспекцию...
которая тебе начинает помогать, она либо будет выдавать тебе много false positives, либо не будет искать какие-то результаты. Как сейчас работают вообще open-source куча анализаторов на хабкод и пароли? То есть они берут... Самые популярные сервисы. смотрят токены, как устроены от этих сервисов, да, там обычно какой-нибудь префикс, либо там какая-то длина, вот, и дальше пытаются в виде RegExpo вписать эвристики на Detect.
тех или иных секретов. И потом в итоге за счет этого пытаются сделать какую-то дополнительную фильтрацию. Че, проще всего сделать эту инспекцию, сейчас мы быстренько посчитаем, короче, энтропию, включим эти эвристики, посчитали, включили, начали гонять на реальных проектах, и там жуть просто, там флос-позитив за флос-позитивом. Потом у нас другой разработчик взял и уже сидел, смотрел результаты, докручивал, чего-то отключал, и вышла очень хорошая инспекция. Респект, Миша.
Но люди все равно жалуются, а вот тут вот false positive пришел. Ну да. Ну, как бы, ну, ты как разработчик инспекции, ты не можешь сделать идеальную инспекцию. Так же с метрикой. То есть, инспекция — это тоже метрика, да? То есть, вот эти hardcoded passwords — это тоже hardcoded пароль, это тоже какая-то метрика. И вот разработчики вложили там кучу времени, там...
кучу спринтов угрохали, сделали тебе такую метрику, и дальше как бы пришел пользователь и сказал, да, вот у меня вот false positive понадавал, поэтому это говно, ваш анализатор, я бы не буду пользоваться. Может быть, может быть. И тогда, на самом деле... Встает вопрос, вот у тебя есть команда, ты с благими побуждениями пришел, попытался потестить какой-то анализатор в команде, который тебе стал выдавать эти метрики, какие-то иши.
Качество метрики, когда мы говорим об ишуе, бывает, ну, то есть у тебя есть следующая метрика. У тебя есть true positive, false positive. А еще, когда копнешь глубже, у тебя есть еще, допустим... false negative, да, то есть когда ты должен был поднять шишую и не поднял. Вот когда ты начинаешь оперировать в таких понятиях, на самом деле из-за большого шума... Вот, у тебя false positive начинает быть критически много, и поэтому tool могут отбросить. Вот, и дальше уже вопрос к тому...
готова команда с этим уживаться или не готова команда с этим уживаться. Потому что если команда выберет путь, мы готовы с этим уживаться? то оно, естественно, в long run принесет им пользу, то есть какие-то банальные вещи, какие-то даже не банальные вещи, если у вас есть DFA-анализы, оно отловит. Но что в случае с сишниками произошло, но это опять же мои какие-то ничем не подкрепленные умозаключения, то есть эти языки существуют давно.
Подходы к тому, чтобы давайте попробуем что-то проанализировать и чем-то помочь, тоже попыток было много. И качество анализаторов было такое себе. Вот. И я уже не помню, мы с какими-то сишными анализаторами в процессе... Ну, и ПВС-студия, он самая известная такая. А ПВС-студии, кстати, прикольные... У них прикольные посты бывали, как они разбирали, да, какие-то еще... Я также уверен, что у них и хлам много приходило, который они просто, допустим, не светили, но и зачем его светить.
Если ты постоянно работаешь с анализаторами, которые тебе генерят кучу мусора, естественно, у тебя нет никакого желания. То есть у нас, например, вопрос. анбординга в анализатор приходит клиент мы ему говорим вы пришли запустили на вашем проекте вас большой проект вас нашел 100000 шуй не паникуйте не волнуйтесь Вы берете их и помещаете в бейзлайн и забываете. Все. Дальше вот с этого момента вы новый человек, вы работаете. С учетом этого тала и дальше не вносите ошибки.
И вот мне кажется, что если ты подходишь с такой мантрой, это более правильный путь внедрения. То есть ты не пытаешься искать какие-то старые ошибки, ты говоришь, что с этого момента я тебе буду писать только хорошие.
код который будет удовлетворять это туле но и даже если ты с таким сеттингом подходишь от ула тебя начинает только false positive каждый раз приносить но когда ты ты от этого станешь вот мне пришел например человек сейчас принес есть кланк тайди анализатор плюсовый берет там вот или есть класс там определены какие-то поля они инициализируются в конструкторе издаются ошибки не инициализировано поле
У класса один конструктор, да, вот тут происходит инициализация, он прямо на этой инициализации говорит что-то от поля не инициализирован. А как? И человек меня спрашивает, почему? Я так думаю, и почему? Я тоже вижу, что это ошибка, но анализатор написан не наш. Вот мы как бы просто это с комьюнити части прилетело. Я тебе ничем не могу помочь, извини. И поэтому потом люди говорят, да, вот тут качество анализатора плохое.
Вот так они были написаны. Такой тогда был state of art, что не могли написать чего-то лучше. И поэтому люди могут обозлиться на тулик и забросить. Поэтому в проекте может быть все плохо. Тут еще такой момент, что, как говорится, качество кода зависит от агримента, подписанного с пользователем. Вопрос цены ошибки с теми же утекшими паролями. Да, будет много false positive срабатываний, но главное, будет мало false negative.
Деньги-то компания сэкономит в качественном счете. Если бестерли в качестве ухода. Ну да, да. То есть, если инвестировать в качество кода, зависит, конечно, от соглашения с пользователем, какие там контракты подписываете. Если упавший сервис – это не проблема, то можно не смотреть на качество кода. То есть, ну, зависит там даже, условно говоря, количество девяток.
то можете заключить соглашение с пользователем и сказать, мы вам будем писать дерьмовый код, он там будет поднимать 100 тысяч шуй, и кто-то под этим подпишется. Никто не будет под этим подписываться. То есть это заранее умалчивают. Не, ну тут такой момент, то есть подписывать сколько сервис будет работать, сколько он не будет работать. Сколько будет? Такие, да, там. То есть есть у многих компаний стоимость рекламации.
Если пользователь им пишет, как я помню, история была, когда один технический менеджер, в общем, проблема была у клиента. Он поехал к ним, потом приехал, такой говорит, мы им поставляем. роутеры за 100 баксов, а у нас, говорит, одна рекламация стоит 1000. Просто там некачественная сеть была, надо было подороже оборудование поставить и все. Вот стоимость именно рекламации, поэтому...
Но тут менеджмент может убедить команду, потому что действительно есть куча тупых ошибок, которые находит анализатор, и у этой тупой ошибки у него может быть цена. Цена может быть тысячу, а может быть как...
Господи, ну с антивирусом недавно была вот эта вот история, я забыл, как он назывался, вот этот антивирус, но там буквально не работали аэропорты. Аспирский? Не-не-нет-нет-нет-нет-нет, там как Орда, в общем, ну... Господи, я забыл, только что нашумевшая история была, она из головы вылетела название этого антивируса.
Но из-за них сломалась куча систем. Ошибка там, как я понял, была тупая. Но там ходили разные случаи. А, все, я вспомнил, да, вспомнил, да, да, да. Вот, то есть цена ошибки очень высокая. И в таком случае, может быть, вы готовы мириться с тем, что вам придется писать. В общем, сопрессить каждый ворнинг, но зато тот ворнинг, который вы...
Ну, будет нормальным, который будет указывать какую-то проблему, но вам сэкономишь и компании пару миллиардов, например. И здесь уже такой трейд-off, что лучше вы будете писать много... Ну, с другой стороны, тоже, опять, если ты запросишь warning, это такой commitment, знаешь, что ты, типа, говоришь, что здесь нет ошибки. И потом тебе по голове может пролететь, то, что сказать, она на самом деле была. Смотрю, ты вот null reference здесь.
Ты поднял две интересные темы. Первая тема по поводу SLA. Я в этом году в марте ездил, по-моему, в марте или в феврале в марте на GDC. Я летал на GDC Game Developer Conference в Штаты, и там я пытался рекламировать, продвигать, рассказывать о своем продукте, о Кадане. Ко мне пришел, ну, то есть там ходили и народ, часть народа приходит именно попартнериться с кем-то, узнавать про новый продукт, а часть народ приходит собирать мерч. И вот пришел ко мне такой чувак.
Я, ну то есть у меня скрипт, я обязан с ним поговорить, я обязан, там была такая стена, я стоял с клубком шерсти, мы эту шерсть разматывали по стене, на стене были гвоздики, типа какими технологиями ты пользуешься. И потом в итоге получалась карта технологий. Большинство вообще не понимало, о чем мы говорим, но не суть.
Приходит ко мне чувак, я его начинаю и говорю, что ты получишь наклейку только после того, как ты выполнишь мой квест. Пошли выполнять квест и пошли, короче, к этой стене. Я ему рассказываю, втираю про код quality. Он такой говорит, вы знаете, мне вообще пофигу на код квалити. Я говорю, как так?
Он говорит, вот, знаете, я разработчик, типа, одному из самых популярных Майнкрафт-серверов. К сожалению, я не в теме, я не понимаю, о чем я там говорил. Вот, короче, вот Майнкрафт-сервер, самая популярная. И у меня, типа, аптайм одни девятки. Я говорю, и как? Он говорит, ну вот я вот пишу.
И дальше говорит, мне тестирование не нужно. Ну, то есть, мне тестирование quality ничего не нужно. Как бы я проверяю, оно либо работает, либо не работает. Вот если оно работает, то оно работает. Не работает, это плохо. Работает хорошо. кольте мне не нужен и салай у меня там самый шикарный Не знаю, как он этого добивается. Я слабо верю, что эти майнкрафтовые серверы, те, которые ты сам делаешь, ты можешь поднимать, убивать. Может, он смог это как-то настроить.
Но чел не выглядел так, чтобы он там сделал одни девятки. Но при этом человек говорит, что у него там самый популярный Minecraft сервер и ему не нужен код quality. И такие тоже бывают. Я, кстати, не помню, кто купил Minecraft. Microsoft, да. Они сначала были маджанки, и у меня на это просто зуб. То есть я во время студенчества, я помню, короче, я... Там стипендия какая-то копеечная была.
И мне не хватало денег на лицензию Майнкрафта, там джавовая еще программа когда была. Я в ВКонтакте списался с кем-то, мне кто-то там за 500-500 рублей. Продал какой-то инвайтовый ключ, я с ним зарегистрировался, получил аккаунт, поиграл в Майнкрафт, потом забросил, потом у меня вырос уже ребенок и такой ребенок говорит, папа, я хочу поиграть в Майнкрафт на компьютере.
А у меня же есть аккаунт Mojang. Я на нем захожу, а он не подходит. А вы, если хотите, вы можете восстановить ваш аккаунт. Обратитесь в Microsoft службу поддержки. Я обращаюсь. Там было много этапов, но меня, короче, послали, сказали, покупай чувак заново. Вот, и все. Ну, как бы такая вещь. И поэтому людям здесь некоторые говорят, у меня все работает. И поэтому код quality мне не нужен. Я не делаю деньги. А некоторым, да, некоторым нужно...
Если ты действительно можешь терпеть, то ты улучшаешь код-квалити продукта. И в этом метрике тебе действительно могут помочь. Ну а тут скорее надо понять, для чего они нужны. То есть можно подрежимировать. То, что мы сегодня говорили. То есть смотри, вот у нас есть код каверидж. Что мы говорили о код каверидж? Код каверидж бывает разный, во-первых. То есть у тебя бывает line код каверидж, бывает branch каверидж, бывает с condition, бывает statement каверидж.
Разные утилиты, соответственно, генерят разные типы coverage, собирают разные типы coverage. Где-то может быть доступен statement coverage, где-то нет, где-то доступен branch coverage, где-то нет. И это метрика, которая хорошо позволяет тебе понять, покрыта ли у тебя бизнес-логика тестами или не покрыта бизнес-логика тестами на все приложение. Вопрос в том, что вы подняли с Сашей хороший концерт, что наверное ее как...
Quality gate обязательно устанавливать не особо полезно, потому что, как ты говорил, строчка наполовину размечена, statement наполовину не размечен. И это может быть проблемой. Действительно, с такими проблемами сталкивался. И эта метрика полезна при ревью, чтобы посмотреть, что покрыто тестами, что не покрыто тестами. Особенно если ты над этим кодом конкретно не работаешь, хочешь вообще понять, что сделано.
Сложный код, то есть там не что-то тривиальное, и тебе надо понять. Это хорошая метрика. Lines of code, но метрика спорная. То есть эта метрика хорошо позволяет понять, с чем ты связался, с каким объемом проекта. Но дальше, наверное, она бесполезна. Как минимум для девелопера и менеджера тоже она мало. Зависит от контракта. Если платят за количество строк, то максимально полезные метрики. Какие мы еще метрики? Давай.
Так, еще одна была метрика, я ее загуглил, это Technical Depth Ratio. Вот это была метрика у нас. Потом, что еще было? Ну, опный, скажем так, метрики по опу и код duplication. Но по опу я считаю... Этот Саша согласен, что он должен быть как можно проще. Если он проще, то тебе не нужны метрики. А если тебе нужны метрики связанности, то у тебя проблемы уже, наверное.
в данный момент таймлайна, считается, что надо проще опный код писать. Много лет назад, когда людей кусал Александреску и прочее, я достаточно старый, я помню время, когда... Архитектурой считалось количество огромного. Вот эти слои, все это на слои разделить, много классиков, все цепочки наследования и так далее. Это считалось правильным, красивым, наверное, на тот момент это правильная была метрика.
ну то есть наверное как вот это все рассчитывать час как люди не очень любят я считаю слава бог мы от этого шли но тем не менее ночью опны и метрики у нас еще были ООД, ООП, как их назвать-то? Наверное, ООД все-таки метрики для дизайна больше. Ну да. И когнитивная комплексити, вот мы как раз рассказали, что у тебя есть декламатические, и были какие-то труды.
по пути того, как сделать ее более применимой. То есть берут какую-то метрику и пытаются сделать так, чтобы из нее что-то можно было понять, насколько... То есть метрика цикломатическая, она вообще была сделана для того, чтобы понять, насколько код... Но, к сожалению, из-за наличия определенных концепций, определенных стейтментов, она была достаточно бесполезна. Со свечом пример.
И поэтому люди попытались адаптировать, получили когнитивную комплексити. И да, ты правильно говорил, что у нас есть обные метрики, метрики дубликации. Есть метрики, о которых мы не говорили, например, метрики мертвого кода. Ну да, вот еще есть там, можно сказать, что вот это вот issue есть, да, там разных типов, это тоже метрики. Бывают там метрики самого анализатора, true positive, false positive, false negative.
Вот это все есть, но на самом деле бездумно в это нырять не стоит и скорее всего стоит почитать. вообще историю вот этой метрики, ну, то есть, schooler.google.com помощь, вот, или что-то подобное, да, и посмотреть. для чего она использовалась, и не просто посмотреть, а еще дать почитать, наверное, своему project-менеджеру, чтобы он больше разбирался в том...
Ну или объяснить ему, чтобы он больше разбирался, что это за метрика, что показывает эта чиселка, как он ее может использовать. И ни в коем случае... Не стоит слепо давать менеджерам бить вас за какие-то метрики. То есть бить за lines of code вы на самом деле получите тогда... Мой лид послал сегодня как раз под эту тему. Получите вот это вот «Рязанское чудо». Если начнете бить лайнцев котла, «Рязанское чудо» — это когда Хрущев захотел...
А, да, вот я запустил суточку. Хрущев захотел поднять нормы забоя с Катай, чтобы эти нормы выполнили. Они в один год стали... Убили весь приплод, взяли у частных хозяйств, взяли у крестьян. Взяли тоже скот, тоже его убили. И выполнили план, чуть-чуть даже перевыполнили план. А в следующем году все, сейчас дохло, потому что они весь переплод убили, и просто не было с кого еще дальше мясо брать.
Такой вольный перевод, можно почитать. Ну да, кстати, это еще, по-моему, даже есть книга «Русская модель управления», там говорится, что, условно говоря, руководство одной метрика, а дел, например, увеличение продаж. Он может работать... То есть, грубо говоря, в один месяц ты получишь рекордные продажи, но люди выгорают, уходят там, увольняются, и в следующем месяце у тебя продажи падают.
В течение одного месяца ты король. Потом все. Все падает, люди уходят. В какой-то мере можно вспомнить того же Видимо Ка-3. Например, после которого... Ну, правда, они выпустили «Киберпанк», но у них тоже большое выгорание было, и многие люди, которые приходили работать над «Киберпанком», их отправляли работать на «Ведьмака».
Вот если они приходили в компанию, да, их, в общем, подправляли на другое, они выгорали, увольнялись, у них была тоже с этим проблема. И также, да, также, наверное, с метриками, что ты можешь руководствоваться. На самом деле... Код каверидж, условно говоря, если ты запрессишь все, то у тебя будет шикарный код каверидж. Если ты исключишь из кавериджа все, у тебя будет 100%.
Но при этом, условно говоря, лучше иметь 70%, но, честно, 100% где-то все засопрессил. Поэтому, да, метрика, слепое следование метрики может привести в очень... Страшная ситуация, когда у тебя... Ну или поставите мне чиселку, я буду работать под эту чиселку. Вот у вас будет норма, допустим, что я месяц должен коммитить, я не знаю, 2000 строк кода. Мало.
10000 строк хода да я вам буду короче писать и буду все строчки делать где возможно новые строчки кода я буду писать под метрику станет лучше проекта не станет да допустим или например Вы поставите мне целью code coverage. Начну писать умные кейсы, то есть я вместо тогда бизнес-кейса буду тестировать подход каверидж. Тестировать бизнес-кейсы и тестировать подход каверидж – это абсолютно две разные вещи. Я там буду сидеть, извращаться, как-то писать.
странные фреймворки, которые будут подсовывать разные значения, чтобы этот код кавердж вам появился. Я буду бивать на это время, а какие-то важные вещи я не затестирую.
Вот, и мои тесты не будут показательны. То есть мои тесты перестанут быть контрактом к реализации моей, да, а мои тесты начнут... просто документировать вот у меня есть и вот в этих строчках у меня эти покрыты да вот и то же самое применительно к ко всем другим метриком И поэтому очень бы хотелось, чтобы менеджеры все-таки думали, как ассессить. качество кода с этими метриками, но все-таки не превращали их в какой-то инструмент принуждения.
чтобы и программисты не начинали эти метрики использовать. То есть, коль на выдумке хитро, мы всегда придумаем, как войти одну или другую циферку. Но только полезным это не будет. Как была известная история по тестировщикам и программистам, когда программистам поставили, по-моему, сайт, чтобы у них было меньше багов, а тестировщикам, чтобы...
Они больше багов находили. И там был сговор между программистами и тестировщиком, когда они нашли оптимальное сочетание, когда одним и другим не урезали премию. Отлично. не очень хорошая метрика нравится перебазироваться в тестер и короче все лопать если поэтому за это бонусы будут больше платить да но мне кажется мы обсудили пока
Много по метрикам. Я предлагаю, если у кого-то есть какие-то интересы, как реализована та или более подробно, как реализована та или другая метрика, либо, допустим, люди хотят разобраться. Как вопрос поднимал Саша, поднимал вопрос, как работает инструментация кода для каверджа. Можем попытаться подготовиться к этому и рассказать людям.
Всем спасибо большое за то, что послушали. А нас сегодня... Вообще, очень интересно было. Да ладно. Нет, правда, очень... Я еще обещался как-нибудь почитать, как анализаторы делают, то есть мы хотели обсудить, как делают там Roslin анализаторы, как делать анализаторы. шарпер а вот поэтому по всему меня вот есть статьи можем что-то посидеть подписать а вот поэтому по качеству кода по метрикам всегда с удовольствием приду расскажу
Супер. Ну, кстати, можно устроить, попробовать воркшоп по написанию анализаторов под свои какие-то нужды. Может, не просто анализаторы, а можно попробовать написать анализаторы при помощи AI. И у нас один товарищ писал целый блокпост. Он захотел написать какой-то анализатор. Сел, короче, в чат ГПТ и начал чат ГПТ мучить, чтобы чат ГПТ ему сделал анализатор. Я не помню, чем оно закончилось, но тогда там, так скажем, не все очень просто пошло.
Можно посмотреть, что стало с этим сейчас, и посмотреть, как можно самим написать вот эти анализаторы. Тем более, наверное, иногда хочется в своем проекте что-то... что-то поискать и от чего-то избавиться. Вот, например, у меня там было, когда мы писали на Дотнете один проект. Я пытался, писал некая инспекция, что я пытался искать мутабельный стейт.
чтобы его извести, чтобы проект нормально работал. Ну и какие-то более мелкие, более крупные вещи. Например, на ГДЦ люди хотели, подходили, спрашивали, мы хотим, чтобы у нас... Мы Unreal-программисты, мы хотим, чтобы у нас там асеты или переменные в зависимости от контекста по-разному назывались, как написать вот такие вот вещи. То есть у людей на самом деле есть запрос на...
Обеспечение определенных стандартов качества и на ассессмент кода своего путем того, что это инспекции, путем того, что это какие-то метрики. Но не все не всегда знают. как их получить, как их использовать, как их готовить, как написать свои. И с этим я с удовольствием помогу, расскажу. Чего знаю, чего не знаю, почитаю, подготовлюсь, тоже расскажу. Ну, супер. Спасибо тебе большое. Было приятно провести время. Тоже истории. Еще увидимся. Все, ребят. Всем пока.