LINUX.ORG.RU

защита от дурака в коде

 , ,


0

4

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

Пока что есть такая идея. (на примере Java, но язык не принципиален):

Все внешние объекты языка (интерфейсы, классы, методы) помечаются аннотациями @Trusted/@Suspected/@WTF/@DefaultTrust.

@WTF
public String getUserName(String userName){...formatHomeDrive(userName)...}

Аннотации выставляются ревизором.

Аннотации могут храниться не только непосредственно в коде, но и в отдельном текстовике как мапы (полное имя/путь объекта языка -> уровень доверия) и во время кодинга графически отображаться только непосредственно в IDE, а во время сборки вставляться препроцессором в реальный код (это легко накодить для идеи и эклипсы). Таким образом, каждый ревизор может иметь отдельное частное мнение. Хранение «мнений» в текстовом формате может использоваться для формирования «общественного мнения» (текстовым мерджем между несколькими «мнениями»)

Смысл в том, что если в коде используются только Trusted код, и из Trusted кода используется только Trusted код (вызываются только Trusted методы только Trusted классов из только Trusted пакетов), то тогда «зеленая полоска», код готов для продакшена. Иначе желтая полоска и процент (или какое-то другое количество) Suspected/DefaultTrust кода. Любой WTF - красная полоска, на доработку.

Как вам идея? Говно или отлично? Вы используете что-то подобное? Подкиньте хороших мыслей

★★★★☆

Последнее исправление: stevejobs (всего исправлений: 2)

Неплохо.

anonymous
()
Ответ на: комментарий от sanaris

Знатно вбросил.

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

alex_custov ★★★★★
()

Много затрат. Это не намного экономичнее прямой ревизии, кто-то должен эти trusted и WTF выставлять. Тогда уж лучше замутить цифровую подпись ревизора на каждый файл исходника. Кто-то изменил файл, ревизия слетела. А при компиляции делать сводку, какие файлы прошли ревизию, какие нет.

pathfinder ★★★★
()
Ответ на: комментарий от pathfinder

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

есть подозрение, что обычный код всегда будет находиться в «желтом» виде. Большую часть кода будет либо некому ревизировать, либо она вся будет под @Suspected/@DontUnderstand, потому что ревизор не смог понять, как работает метод по имени mtd13, содержащий внутри себя двадцать вложенных циклов с переменными i,j,k,i2,j8,a,b,c.

По этой причине полупроверенный код, наверное, лучше сделать зеленым :3 Желтое — это когда ошибок слишком много. А full-trusted код сделать анимированной золотисто-бело-сверкающей-искрящейся полоской — редкой как единорог :3 Ради такого можно даже лунчеры интеграции junit похакать.

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от stevejobs

C радугой же и rainbow dash над началом метода, класса. Что бы хэйтеров порадовать.

anonymous
()
Ответ на: комментарий от Harald

1) вся «внешняя» инфа (пришедшая непосредственно из кода) имеет своего автора. Конкретная реализация пока ХЗ. Но смысл в том, что у ревизора есть список людей, которым он доверяет. Trusted выданные недоверенным автором не считаются.

2) все ходы всё равно записаны в Git'е. Никто не мешает впоследствии применить терморектальный метод убеждения к нужному поциенту.

А чтобы поциент не подписался чужим именем (для параноиков, дислектиков и контор с текучкой двести человек в день) — сделать проверку ключей, например если в гит коммитится @Trusted(by=«Петя») с аккаунта Вася, то включается сирена, зажигаются аварийные лампы-мигалки, и Васе в жопу медленно и вальяжно вкатывается раскаленный паяльник.

stevejobs ★★★★☆
() автор топика

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

Я придерживаюсь правила: если код работает верно (пока работает, предполагается, что будет работать), он никак не помечается; если в нем что-то не так, перед функцией ставится комментарий «NOTE: описание проблемы»; если чего-то не хватает, «TODO: что нужно сделать»; если выявлен баг (глобальный или на определенном наборе входных данных), «FIXME: описание бага». Некоторые IDE/редакторы из коробки умеют подсвечивать такие комментарии, некоторые можно настроить, остальные нинужны!11. Также многие IDE/редакторы при дополнении вызова функции выводят комментарий к ней — мою метку. И конечно код легко прогрепать на предмет проблемных участков. В общем этот метод легко применять без необходимости доработок в существующих средствах разработки.

Из минусов — нет разноцветных рюшечек.

staseg ★★★★★
()
Ответ на: комментарий от staseg

Из минусов еще и то, что неизвестно, используются ли FIXME где-то в настоящем коде. Если у тебя пол-кода FIXME, но при этом main состоит только из «hello world, return», ничего плохого такая программа не сделает -)

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от sanaris

Я тебя полностью поддердживаю ( c forewer), но пацаны с явами сейчас будут ругаться. :)

hbars ★★★★★
()

аннотации

а причем тут кресты?

x0r ★★★★★
()
Ответ на: комментарий от staseg

Это опять же вопрос культуры, которая присутствует только в комьюнити, где принято читать коды, то есть Си+Ассемблер. Проблема не в крестах, проблема в том, что основная масса дураков думает, что знает кресты. Раньше на месте крестов был Паскаль. Так что не хейтте)

sanaris
()

то, что одному Trusted, другому может быть совсем WTF.

и вопрос: какие видятся преимущества перед статическим тестированием (с автоматизированным code review, оценкой цикломатической сложности и т.д.) с «почти полным» покрытием юнит-тестами?

kvitaliy
()
Ответ на: комментарий от kvitaliy

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

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от stevejobs

преимущество перед ненаписанными unit-тестами имеется.

а что с автоматизированным code review? его же не супер сложно внедрить при наличии системы CI.

аннотации в данном случае это «задокументированное» экспертное мнение - с ним всегда проблема: а кто сказал, что Вася действительно эксперт? должны ли мы to trust его @Trusted? Если вдруг Вася проявил некомпетентность, надо пройтись по коду всех проектов и превратить его аннотации в «незаслуживающие доверия»? Я к тому, что эта система не дает уверенности в том, что зелёная полоска обозначает уверенность в качестве. Зелёная полоска и при наличии unit-тестов не обозначает этой уверенности, но unit-тесты все таки более однозначны в интерпретации разными людьми, чем мнения экспертов (вчера пивших абсент).

kvitaliy
()
Ответ на: комментарий от kvitaliy

1) на один метод можно иметь мнения более чем одного эксперта (@Trusts({@Trusted(bar=«Вася»), @WTF(bar=«Петя»)})
2) не доверяешь Васе - не включай его в список доверенных. Твой личный список. Это так же как с гитом: твой локальный репозиторий — это только твой локальный репозиторий, твои хуки типа post-commit — это только твои хуки. Список доверенных лиц тоже только твой. Никто не может заставить тебя доверять главному архитектору проекта, например.
3) можно вообще запретить делать аннотации в коде напрямую, либо игнорировать все такие аннотации. Для этого нужно иметь отдельный репозиторий для метаинформации и делиться ей только с теми, с кем хочется (например, как описано в посте — текстовый мап [объект языка -> уровень доверия], лежащий в git/mercurial).

но unit-тесты все таки более однозначны в интерпретации разными людьми

unit-тест, возможно, придется писать несколько часов, а аннотация типа @WTF или @DontKnow ставится за мгновение. Ничерта не понял пока читал код метода? Ставь @DontKnow(desc=«не понимаю как это работает, даже не понимаю что он делает»). Пара секунд.

stevejobs ★★★★☆
() автор топика
Последнее исправление: stevejobs (всего исправлений: 1)
Ответ на: комментарий от stevejobs

ты придумал юниттестирование, но индусскими шаманами

Deleted
()
Ответ на: комментарий от stevejobs

все круто, но получается, что на одну и ту же сборку у тебя полоска будет зелёная, а у меня красная - и как мы решим, выдавать код в эксплуатацию или нет? будем должностями меряться?

вообще, то что ты описываешь, это форма взаимного «ручного» code review - дорого, долго, не очень надёжно, потому что субъективно и неоднозначно.

kvitaliy
()
Ответ на: комментарий от kvitaliy

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

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от sanaris

Почему бы просто не использовать сознательно язык, в котором нет идиотов? Просто Си.

А вы батенька оптимист однако. Вон Линус недавно жаловался что я Ядро комитят люди не осилившие указатели.

urxvt ★★★★★
()
Ответ на: комментарий от m0rph

А еще в ейфеле «штота похожее»(ТМ) было... Контрактное программирование, называется. «Эй ты, птица, слушай сюда... Давай притворимся, что все путем»... Но «Большинство реализаций Eiffel генерирует код Си» (с) Массовый фейспалм, занавес.

slackwarrior ★★★★★
()
Последнее исправление: slackwarrior (всего исправлений: 1)

Геморрой вырастет. Инфа100%

Deleted
()

изобретаем новую утилиту для code review?

предлагаю переименовать тред в «защиту от дурака в проекте»

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.