The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



"Оценка уровня потенциального усложнения кода открытых проектов"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Оценка уровня потенциального усложнения кода открытых проектов"  +/
Сообщение от opennews (??), 21-Май-21, 10:07 
Мартин Шлейс (Martin Schleiss) попытался сравнить различные открытые проекты с точки зрения усложнённости кода и понимания как код работает и какие действия выполняет. Например, проект становится более сложен для понимания при применении сложных абстракций, таких как распределённое взаимодействие компонентов по сети, или использовании большого числа вложенных модулей и классов...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=55187

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Оценка уровня потенциального усложнения кода открытых проект..."  +51 +/
Сообщение от Анонимemail (1), 21-Май-21, 10:07 
Ещё тупее критерий придумать не смогли?
Ответить | Правка | Наверх | Cообщить модератору

6. "Оценка уровня потенциального усложнения кода открытых проект..."  +1 +/
Сообщение от Аноним (6), 21-Май-21, 10:24 
ну ты если такой умный то предложи
Ответить | Правка | Наверх | Cообщить модератору

9. "Оценка уровня потенциального усложнения кода открытых проект..."  +5 +/
Сообщение от Фотошоп лучше (?), 21-Май-21, 10:32 
На каком основании вы требуете от собеседника что-то предлагать? Он высказался в том, что исследование нУжно? Или Вы считаете, что констатация факта неадкватного критерия оценки означает обязательное наличие более адекватного критерия?
Ответить | Правка | Наверх | Cообщить модератору

10. "Оценка уровня потенциального усложнения кода открытых проект..."  +3 +/
Сообщение от Аноним (10), 21-Май-21, 10:35 
> констатация факта неадкватного критерия оценки означает обязательное наличие более адекватного критерия?

для местного диванного эксперта -- да

Ответить | Правка | Наверх | Cообщить модератору

100. "Оценка уровня потенциального усложнения кода открытых проект..."  –2 +/
Сообщение от Аноним (100), 22-Май-21, 09:29 
Потому что: критикуешь - предлагай, предлагаешь - делай, делаешь - отвечай. А иначе ты, дядя, 3,14-ун просто.
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

101. "Оценка уровня потенциального усложнения кода открытых проект..."  +1 +/
Сообщение от z (??), 22-Май-21, 09:37 
отвечая - критикуй. goto start.
Ответить | Правка | Наверх | Cообщить модератору

105. "Оценка уровня потенциального усложнения кода открытых проект..."  –1 +/
Сообщение от Всем Анонимам Аноним (?), 22-Май-21, 11:21 
99% коментариев на Opennet это все вокруг дураки, а я то умный такой (как в прямой, так и непрямой форме). Аргументы не принимаются, все-равно все дураки, а я то прямо орел.
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

108. "Оценка уровня потенциального усложнения комментариев на opennet"  +3 +/
Сообщение от Michael Shigorinemail (ok), 22-Май-21, 13:01 
Да это не комментарии виноваты -- это мы с вами, братцы, порой зачем-то друг перед дружкою выпендриваемся (и то не тем, чем хоть стоило бы; а некоторые так вовсе перед собой любимым с одного адреса переписываются).

Так что кому опеннет не тот -- предлагаю вооружиться зеркалом.  Да и сам пойду-ка рожу в нём изучу на предмет углов и радиусов, что ли.

Ответить | Правка | Наверх | Cообщить модератору

120. "Оценка уровня потенциального усложнения комментариев на opennet"  +/
Сообщение от Аноним (120), 22-Май-21, 23:16 
В коей то веке здравая мысль от Шигорина ))
Ответить | Правка | Наверх | Cообщить модератору

14. "Оценка уровня потенциального усложнения кода открытых проект..."  +3 +/
Сообщение от Анонимemail (1), 21-Май-21, 10:54 
Сложно кода это сложнее, чем считать кол-во включений файлов.

В целом надо смотреть на каждый проект, смотреть на его структуру. Модульный проект чаще будет более усложнённым, но его будет легче разрабатывать и сопровождать. Надо смотреть на саму кодовую базу, она большая? Проект сложнее.

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

90. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от макпыф (ok), 21-Май-21, 23:03 
но тут субьективно достаточно получаеться, а по поводу кодовой базы - она может быть поделена на модули так, что работая над одним, не нужно даже названия других знать не надо (драйвера в ядре)
Ответить | Правка | Наверх | Cообщить модератору

65. "Оценка уровня потенциального усложнения кода открытых проект..."  +2 +/
Сообщение от VladSh (?), 21-Май-21, 17:29 
Большое количество подключаемых файлов косвенно может говорить о том, что в данном файле кто-то пытался скрестить ежа и ужа. То есть нарушен паттерн - одним куском кода решать одну задачу (в идеале).
Но любой нормальный програмер и так всегда стремится уменьшить количество подключаемых файлов.

Было бы здорово увидеть в отчёте места в проекте, где найден совпадающий либо похожий код, это гораздо важнее. Если свести "велосипедостроение" к минимуму, то это сильно понизит количество и сложность кода, и повысит управляемость проектом.

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

93. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от Bdfybec (?), 22-Май-21, 07:20 
> Большое количество подключаемых файлов косвенно может говорить о том, что в данном файле кто-то пытался скрестить ежа и ужа. То есть нарушен паттерн - одним куском кода решать одну задачу (в идеале).

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

Ответить | Правка | Наверх | Cообщить модератору

66. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от Аноним (66), 21-Май-21, 17:54 
Он же не тупой, зачем ему предлагать ещё тупее критерии? Странный вопрос.
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

67. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от Аноним (-), 21-Май-21, 18:18 
Следует согласиться, критерий слегка некорректный. Ссылки на файлы... Можно было бы проанализировать количество строк в функциях, модульность — как-то более в человеческом ключе.
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

92. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от Dmitry (??), 22-Май-21, 00:58 
Вообще есть инструменты автоматического котроля "сложности". Хорошее правило - если код сложным - сборка в CI ломается.
Есть много метрик:
https://checkstyle.org/config_metrics.html#ClassFanOutComple... (что описано в этом посте)
https://checkstyle.org/config_metrics.html#CyclomaticComplexity - кличество ветвистых "if'ов"

Другие виды сложностей https://checkstyle.org/config_metrics.html
В общем сложность нужно держать под контролем автоматизированными инструментами.

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

104. "Оценка уровня потенциального усложнения кода открытых проект..."  +2 +/
Сообщение от svsd_valemail (ok), 22-Май-21, 10:44 
Предлагаю индусский вариант... самый бесполезный и очевидно равный предложенному выше =)
С тем же успехом можно считать количество объектов, количество присвоений и количество ветвлений.

По факту если рассмотреть код в котором включений будет меньше и код в которых их будет больше, в первом случае можно будет сломать голову от кода, лямда функций и за каждым деревом будет ещё дерево и за ним будет ещё а за ним будет ещё и так далее пока человек не потеряет нить. А вот модульный код, даже с большим количеством включений будет понять легче.

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

16. "Оценка уровня потенциального усложнения кода открытых проект..."  +5 +/
Сообщение от Онаним (?), 21-Май-21, 10:54 
Чем он тупой-то?
Оверинженеринг и овердекомпозиция - бич современных "прожектёров".
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

33. "Оценка уровня потенциального усложнения кода открытых проект..."  +1 +/
Сообщение от Анонимemail (1), 21-Май-21, 11:56 
Тем, что не показывает ничего. Кто-то включил не один а 2 файла, какой ужас.
Ответить | Правка | Наверх | Cообщить модератору

43. "Оценка уровня потенциального усложнения кода открытых проект..."  +1 +/
Сообщение от Урри (ok), 21-Май-21, 13:14 
Зачем так примитивно лгать? Не "не один, а два", а "больше пяти".
Ответить | Правка | Наверх | Cообщить модератору

45. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от Аноним (45), 21-Май-21, 14:17 
Речь не про include заголовочных файлов, как я понял, а про связи между модулями. Хотя тут тоже тот ещё вопрос: в тех же проектах на C может быть всего 2-3 заголовочных файла на пачку модулей...
Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

83. "Оценка уровня потенциального усложнения кода открытых проект..."  +2 +/
Сообщение от Аноним (83), 21-Май-21, 21:00 
Вместо того, чтобы написать строку со сложением двух величин, вызвали хелпер, который обратился к сервису, тот через провайдер создал колбек обработчик, который передал менеджеру очередей, из которой задание извлек обработчик и вызвал таки этот колбек, что и привело к сложению двух исходных величин.
Зато избавились от дублирования кода, и складывать теперь умеем хоть через mssql, хоть на гпу.
Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

86. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от Онаним (?), 21-Май-21, 21:25 
Проблемы начнутся, когда это счастье окажется в inner loop, а величин будет море.
В итоге оно потребует фермы из 20 64-ядерных обработчиков и полдня для того, что нормально написанное приложение сделает на i386 за минуту.
Ответить | Правка | Наверх | Cообщить модератору

30. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от Анто769ним (?), 21-Май-21, 11:33 
https://singaporedatacompany.com/blog/more-developers-more-p...
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

2. "Оценка уровня потенциального усложнения кода открытых проект..."  +6 +/
Сообщение от Леголасemail (ok), 21-Май-21, 10:08 
усложнение кода есть одна из современных тенденций, к сожалению
Ответить | Правка | Наверх | Cообщить модератору

18. "Оценка уровня потенциального усложнения кода открытых проект..."  –2 +/
Сообщение от Аноним (18), 21-Май-21, 10:55 
Усложнение неизбежно для относительно крупного проекта. А серебряной пули до сих пор нет.
Ответить | Правка | Наверх | Cообщить модератору

25. "Оценка уровня потенциального усложнения кода открытых проект..."  +10 +/
Сообщение от Crazy Alex (ok), 21-Май-21, 11:24 
Решение очевидно, особенно для опенсорса - жёстко очертить задачи и область применимости продукта и не пытаться сделать всё. В пределе - то самое "делать что-то одно и делать это хорошо" из юникс-вэя.
Ответить | Правка | Наверх | Cообщить модератору

47. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от Жироватт (ok), 21-Май-21, 14:43 
Ты только что изобрел философию Unix из 80х.
Ответить | Правка | Наверх | Cообщить модератору

109. "Оценка уровня потенциального усложнения кода открытых проект..."  +2 +/
Сообщение от Michael Shigorinemail (ok), 22-Май-21, 13:04 
Он только что сам на неё и сослался (а не претендовал на изобретение).  Ну, _включил_ по упоминанию. :-)
Ответить | Правка | Наверх | Cообщить модератору

124. "Оценка уровня потенциального усложнения кода открытых проект..."  –1 +/
Сообщение от Аноним (124), 23-Май-21, 09:29 
Какой ты умный. А мы то и не догадались без твоего комментария. Как у тебя дела-то, много продал дистрибутивов за 100 рублей?
Ответить | Правка | Наверх | Cообщить модератору

71. "Оценка уровня потенциального усложнения кода открытых проект..."  –1 +/
Сообщение от Тот_Самый_Анонимус (?), 21-Май-21, 19:11 
Т.е. вместо файлового менеджера — куча программ. Как-то не нужно.
Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

89. "Оценка уровня потенциального усложнения кода открытых проект..."  +1 +/
Сообщение от Аноним (89), 21-Май-21, 22:17 
Файловый менеджер сегодня это обёртка над другими утилитами. Ну это если нормальный файловый менеджер.
Ответить | Правка | Наверх | Cообщить модератору

94. "Оценка уровня потенциального усложнения кода открытых проект..."  –1 +/
Сообщение от Bdfybec (?), 22-Май-21, 07:25 
вот и выходит, что философия "делать что-то одно и делать это хорошо", применима только к утилитам, а не к "обёрткам".
Ответить | Правка | Наверх | Cообщить модератору

111. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от Аноним (89), 22-Май-21, 13:22 
> вот и выходит, что философия "делать что-то одно и делать это хорошо",
> применима только к утилитам, а не к "обёрткам".

Ну почему же. Хорошо оборачивать чужой код тоже нужно уметь.

Ответить | Правка | Наверх | Cообщить модератору

54. "Оценка уровня потенциального усложнения кода открытых проект..."  –2 +/
Сообщение от z (??), 21-Май-21, 15:40 
Усложнение есть одна из тенденций эволюции, всего живого
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

59. "Оценка уровня потенциального усложнения кода открытых проект..."  –1 +/
Сообщение от Аноним (59), 21-Май-21, 17:08 
И неживого. Рекомендую почитать работы некоторых Нобелевских лауреатов.
Ответить | Правка | Наверх | Cообщить модератору

95. "Оценка уровня потенциального усложнения кода открытых проект..."  +1 +/
Сообщение от Bdfybec (?), 22-Май-21, 07:29 
Барака Обаму и Нельсона Манделу?
Ответить | Правка | Наверх | Cообщить модератору

91. "Оценка уровня потенциального усложнения кода открытых проект..."  +1 +/
Сообщение от Dmitry (??), 22-Май-21, 00:44 
если что то усложняется -  "это эволюция свойство всего" и становится всё понятно что так и должно быть :)
а если код рефакторят и упрощают - это свойствор мёртввого?
Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

110. "Оценка уровня потенциального усложнения кода открытых проект..."  –1 +/
Сообщение от Michael Shigorinemail (ok), 22-Май-21, 13:05 
Обычно мёртвого, усердно косящего под живое.  А действительно живое -- оно простое и красивое, и остаётся таковым.
Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

125. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от Аноним (124), 23-Май-21, 09:34 
> А действительно живое -- оно простое и красивое, и остаётся таковым.

Но ты может и простой, но совсем не красивый.

Ответить | Правка | Наверх | Cообщить модератору

129. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от www2 (??), 26-Май-21, 08:03 
Я бы не согласился, в ДНК может быть много мусора, который не используется, но является пространством для возможной дальнейшей эфолюции или защитой от неудачных реверсивных мутаций или обмена фрагментами между парными хромосомами.

В организме целом может быть множество рудиментов и неудачных "решений", появившихся эволюционным путём.

Например, человеческий глаз имеет слепое пятно, т.к. "вывернут наизнанку": у него светочувствительные клетки находятся снаружи, а нервы внутри. У моллюсков наоборот и зрение у них острее.

У жирафа возвратный гортанный нерв проходит от мозга через всю шею до сердца, огибает какую-то артерию и возвращается обратно в гортань.

Просто эволюция не умеет выбираться за пределы локального максимума.

Ответить | Правка | К родителю #110 | Наверх | Cообщить модератору

68. "Оценка уровня потенциального усложнения кода открытых проект..."  –1 +/
Сообщение от Аноним (-), 21-Май-21, 18:19 
Усложнение кода сигнализирует о его неоптимальности.
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

3. "Оценка уровня потенциального усложнения кода открытых проект..."  –3 +/
Сообщение от Иванemail (??), 21-Май-21, 10:20 
Никто не запрещает не пользоваться ООП в PHP.
Ответить | Правка | Наверх | Cообщить модератору

4. "Оценка уровня потенциального усложнения кода открытых проект..."  +4 +/
Сообщение от Леголасemail (ok), 21-Май-21, 10:24 
в списке сам PHP, а не проект, написанный на нём с использованием ООП
Ответить | Правка | Наверх | Cообщить модератору

61. "Оценка уровня потенциального усложнения кода открытых проект..."  +1 +/
Сообщение от Иваня (?), 21-Май-21, 17:10 
Чел открой глаза, там Laravel...
Ответить | Правка | Наверх | Cообщить модератору

63. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от Леголас (ok), 21-Май-21, 17:25 
твоя правда, но чувак выше не про него явно писал
Ответить | Правка | Наверх | Cообщить модератору

38. "Оценка уровня потенциального усложнения кода открытых проект..."  –1 +/
Сообщение от Аноним (38), 21-Май-21, 12:34 
Для одной странички приемлемо.
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

5. "Оценка уровня потенциального усложнения кода открытых проект..."  +7 +/
Сообщение от Аноним (5), 21-Май-21, 10:24 
Если константы вместо того чтобы хардкодить их прямо в коде вынести в отдельный подключаемый файл constants, то код становится проще и понятнее, а не сложнее.
Ответить | Правка | Наверх | Cообщить модератору

8. "Оценка уровня потенциального усложнения кода открытых проект..."  +1 +/
Сообщение от Аноним (8), 21-Май-21, 10:29 
Это один подключаемый файл. У вас осталось еще 4.
Ответить | Правка | Наверх | Cообщить модератору

11. "Оценка уровня потенциального усложнения кода открытых проект..."  +1 +/
Сообщение от Аноним (10), 21-Май-21, 10:37 
4-5
Ответить | Правка | Наверх | Cообщить модератору

26. "Оценка уровня потенциального усложнения кода открытых проект..."  –3 +/
Сообщение от Crazy Alex (ok), 21-Май-21, 11:25 
Если у тебя столько констант, что их надо выносить в отдельный файл и использовать из разных мест - это и есть показатель сложности кода.
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

31. "Оценка уровня потенциального усложнения кода открытых проект..."  +2 +/
Сообщение от Аврилий (?), 21-Май-21, 11:52 
1 сложность - файл локализация
2 сложность - файл конфигов
3 сложность - подключение stdlib

У вас остался один файл на подключение или ваш проект обосрут на опеннете.

P.S. ruby, python, etc... смеются в сторонке храня все в глобальных переменных

Ответить | Правка | Наверх | Cообщить модератору

35. "Оценка уровня потенциального усложнения кода открытых проект..."  +1 +/
Сообщение от Аноним (35), 21-Май-21, 12:01 
> P.S. ruby, python, etc... смеются в сторонке храня все в глобальных переменных

Ты упоролся или да?

Ответить | Правка | Наверх | Cообщить модератору

48. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от Жироватт (ok), 21-Май-21, 14:52 
Сложность 0 - стандартные "общеобязательные" инклюды
Сложность 1 - 0 + стандартные "редкие" инклюды
Сложность 2 - 1 + 1 инклюд с иерархией рабочих объектов
Сложность 3 - 2 + 1 инклюд с самописным внешним коннектором
Сложность 4 - 3 + 1 инклюд фалов служебных объектов или констант или функций работы с UI
Сложность 5 - 4 + 1 инклюд библиотеки ресурсов или локали
---- < здесь какой-то хрен-с-горы сказал, что твой код слишком сложен для пятиклассника (по мозгам) с гитхаба
...
---- < Здесь находится код с гитхаба уровня /б
...
---- < Тихий Кит и Синий Дом
...
---- < Сверхсущества
...
---- < Б-г
Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

39. "Оценка уровня потенциального усложнения кода открытых проект..."  +1 +/
Сообщение от Аноним (38), 21-Май-21, 12:39 
Представим себе физико-математическую вычислительную прогу. Скорость света, элементарный заряд, h, могут потребоваться в разных модулях программы. Не вбивать же их значения каждый раз в нужных местах?
Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

49. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от Жироватт (ok), 21-Май-21, 15:00 
Зачем, есть 'rand = srand(nullptr); double h = rand.next();' ?
Ответить | Правка | Наверх | Cообщить модератору

7. "Оценка уровня потенциального усложнения кода открытых проект..."  +1 +/
Сообщение от myhand (ok), 21-Май-21, 10:27 
По одному критерию оценивать подобные вещи - это даже хуже чем глупо.
Ответить | Правка | Наверх | Cообщить модератору

13. "Оценка уровня потенциального усложнения кода открытых проект..."  –2 +/
Сообщение от Аноним (13), 21-Май-21, 10:54 
Выкатите-ка своё исследование по иным критериям - мы оценим. Вот это будет конструктивно.
Ответить | Правка | Наверх | Cообщить модератору

21. "Оценка уровня потенциального усложнения кода открытых проект..."  –2 +/
Сообщение от InuYasha (??), 21-Май-21, 10:58 
А какой, простите, кафедрой вы заведуете, чтобы оценивать? Если дадите мне повышение степени, я могу написать.
Ответить | Правка | Наверх | Cообщить модератору

57. "Оценка уровня потенциального усложнения кода открытых проект..."  +3 +/
Сообщение от Аноним (13), 21-Май-21, 16:48 
А ты всё ещё не догадался? Кафедрой оценок уровня потенциального усложнения кода открытых проектов.
Ответить | Правка | Наверх | Cообщить модератору

98. "Оценка уровня потенциального усложнения кода открытых проект..."  +1 +/
Сообщение от myhand (ok), 22-Май-21, 07:47 
Почему в ответ на публикацию в бложеке я должен запилить целое исследование?

Ты мне, может, хоть много денег даш сперва?  Вот это будет конструктивно.

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

12. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от Онаним (?), 21-Май-21, 10:53 
Хороший критерий.
Загляните в любой код хипстерских проектов на модных язычках.
Да и в код хипстерских проектов на менее модных язычках.
Какая-нибудь простейшая библиотечка может содержать 50 файлов с разными классами из пяти строчек, часть из которых НЕЯВНО (автозагрузка, фиг ли) ссылается на половину оставшихся.
По опыту - зачастую проще выкинуть и/или переписать самому максимально просто, с меньшим числом багов и большим числом функций. Причём это времени занимает меньше, чем пытаться поддерживать это оно, которое тянется из разных источников, постоянно меняется и начинает кривить-косить.
Ответить | Правка | Наверх | Cообщить модератору

17. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от Анонимemail (1), 21-Май-21, 10:55 
Загляни в старый проект на сишке --- а там инклюды.
Ответить | Правка | Наверх | Cообщить модератору

19. "Оценка уровня потенциального усложнения кода открытых проект..."  –2 +/
Сообщение от Онаним (?), 21-Май-21, 10:56 
PHP - достаточно старый проект на сишке?
Ну так вот, он далеко не в начале списка.
Ответить | Правка | Наверх | Cообщить модератору

20. "Оценка уровня потенциального усложнения кода открытых проект..."  –1 +/
Сообщение от Онаним (?), 21-Май-21, 10:57 
(и про недостаточную его сложность тоже ничего рассказать не получится, шах и мат)
Ответить | Правка | Наверх | Cообщить модератору

52. "Оценка уровня потенциального усложнения кода открытых проект..."  –1 +/
Сообщение от Жироватт (ok), 21-Май-21, 15:08 
Заглянул. Эти пять строчек (для virtual/abstract блюпринтов) или 1500 строчек (если уже работа с sealed/final классом идет) легко читаются, позволют сконцентрироваться на самом классе или конкретной задаче. Константы не размазаны по всему коду, а поименованы и всунуты там, где им и место. Никаких магических чисел. Читать удобно, раскуривать еще удобнее.

Где твой бох теперь?

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

122. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от Онаним (?), 23-Май-21, 09:19 
Ты не понял.
По пять строчек кода, НЕ описания класса. Куча коротких бессмысленных методов, в т.ч. однострочников.
Вызовы ради вызова.
Никаких virtual/abstract я не упоминал.
Ответить | Правка | Наверх | Cообщить модератору

123. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от Онаним (?), 23-Май-21, 09:20 
(больше лефтпадов, хороших и разных, если упростить)
Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

114. "Оценка уровня потенциального усложнения кода открытых проект..."  –1 +/
Сообщение от pin (??), 22-Май-21, 16:55 
> переписать самому максимально просто,

в результате

> Какая-нибудь простейшая библиотечка может содержать 50 файлов с разными классами из пяти строчек,

часть из которых НЕЯВНО (автозагрузка, фиг ли) ссылается на половину оставшихся.

Ох уж эти переписыватели.

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

117. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от Онаним (?), 22-Май-21, 20:48 
В результате переписывания подобной хреноты вместо (реально) 10-20-30 файлов получается 1-2-3, со стройной структурой и очевидным кодом.
Ответить | Правка | Наверх | Cообщить модератору

15. "Оценка уровня потенциального усложнения кода открытых проект..."  –2 +/
Сообщение от InuYasha (??), 21-Май-21, 10:54 
Согласен, критерий странный. Не сказал бы что адекватный.

Если развернуть все инклюды в какой-нибудь Кваке, то их будет по 10-20шт на один .c, не?
Или даже в простом хеллоуворлд-подобном проекте будет с десяток стандартных хедеров на всякие printf.

Ответить | Правка | Наверх | Cообщить модератору

27. "Оценка уровня потенциального усложнения кода открытых проект..."  +1 +/
Сообщение от Crazy Alex (ok), 21-Май-21, 11:27 
Ну вот потом сравниваем сколько инклудов в кваке и холловорде - и получаем неплохое приближение к соотношению их сложности.
Ответить | Правка | Наверх | Cообщить модератору

37. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от Nathan Bedford Forrest (?), 21-Май-21, 12:33 
зато квака вполне себе комфортна жила на 8 мегабайтах оперативки часть из которых еще жрала системаа
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

22. "Оценка уровня потенциального усложнения кода открытых проект..."  –1 +/
Сообщение от Псевдоним (??), 21-Май-21, 11:21 
Странный критерий или нет, но похоже на правду.
Ответить | Правка | Наверх | Cообщить модератору

23. "Оценка уровня потенциального усложнения кода открытых проект..."  +16 +/
Сообщение от Орк (?), 21-Май-21, 11:23 
Господа, нас обманули, расходимся. Посыл статейки ясен: пишите все программы одним файлом и не будет усложнения кода. На модульность программ и разделение ответственности Мартин клал. Исследование не стоит затраченного на него электричества.
Ответить | Правка | Наверх | Cообщить модератору

28. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от Леголасemail (ok), 21-Май-21, 11:31 
> Исследование не стоит затраченного на него электричества.

как и поддержка комментариев здесь

Ответить | Правка | Наверх | Cообщить модератору

29. "Оценка уровня потенциального усложнения кода открытых проект..."  +1 +/
Сообщение от Crazy Alex (ok), 21-Май-21, 11:31 
Неужели так сложно понять? Для того, чтобы усложняющийся проект жил и поддерживался, его сложностью надо управлять. Как один из инструментов - разбиение на файлы. В итоге количество файлов становится метрикой сложности.

Грубо говоря, если ты ещё можешь тянуть проект без модульности - значит он совсем простой. Усложнился - пришлось разделить, выделить какую-то общую функциональность для реюза. Ещё усложнился - берём фреймворки и так далее. Ну или там берём фреймворк изначально для хелловорлда и получаем кучу притащенной сложности - что прекрасно отразится метрикой.

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

34. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от Клавдий (?), 21-Май-21, 11:56 
Бьем проект на 100500 микросервисов и ваша логика относительно количества файлов и сложности разбивается об стенку намазаную йодом.
Ответить | Правка | Наверх | Cообщить модератору

112. "Оценка уровня потенциального усложнения кода открытых проект..."  –1 +/
Сообщение от Tishka17 (?), 22-Май-21, 14:19 
Не так: если вы разделили код на модули, вы снизили его сложность, а не повысили. Если вы этого не сделали, возможно вы просто в состоянии это сделать из-за сложности существующего кода.

Большое число файлов может означать, что за кодом следят и следуют определенному походу. Например, в джаве нормально на каждый класс создавать по файлу, просто так устроен язык. Даже если это класс из 10 строк. В пхп скорее всего так никто не будет делать. Можно упомянуть и обратную механику: в пределах пакета (файлы в папке) в джаве не обязательно что-то импортировать, а в питоне каждый файл независим и импорт придется добавить даже при такой же структуре файлов

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

128. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от Crazy Alex (ok), 25-Май-21, 13:29 
Если вам пришлось это делать - то значит у вас уже сложный проект
Ответить | Правка | Наверх | Cообщить модератору

24. "Оценка уровня потенциального усложнения кода открытых проект..."  –1 +/
Сообщение от Аноним (24), 21-Май-21, 11:23 
>Visual Studio Code - 60.3%.

Это высер Майкрософт? Тогда не нужно.

Ответить | Правка | Наверх | Cообщить модератору

40. "Оценка уровня потенциального усложнения кода открытых проект..."  +1 +/
Сообщение от Аноним (38), 21-Май-21, 12:41 
Тут не учтены зависимости зависимостей. Зависимости самого Electron чего стоят.
Ответить | Правка | Наверх | Cообщить модератору

32. "Оценка уровня потенциального усложнения кода открытых проект..."  +4 +/
Сообщение от Аноним (32), 21-Май-21, 11:55 
Ну им ничто не мешало, откровенно говоря, ещё пройтись и посмотреть цикломатическую сложность функций и методов как минимум.
Ответить | Правка | Наверх | Cообщить модератору

84. "Оценка уровня потенциального усложнения кода открытых проект..."  +2 +/
Сообщение от Аноним (84), 21-Май-21, 21:00 
А зачем?
Ведь любая проблема имеет очевидное, простое и да, неправильное решение.
Ответить | Правка | Наверх | Cообщить модератору

41. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от Nathan Bedford Forrest (?), 21-Май-21, 12:42 
джаваскрипт - дерьмо
Ответить | Правка | Наверх | Cообщить модератору

69. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от Аноним (-), 21-Май-21, 18:23 
Не поспоришь.
Ответить | Правка | Наверх | Cообщить модератору

72. "Оценка уровня потенциального усложнения кода открытых проект..."  +1 +/
Сообщение от Петух (?), 21-Май-21, 19:27 
Зачем его придумали и почему до сих пор не заменили?
Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

85. "Оценка уровня потенциального усложнения кода открытых проект..."  +1 +/
Сообщение от Аноним (84), 21-Май-21, 21:01 
Гугл все устраивает?
Ответить | Правка | Наверх | Cообщить модератору

42. "Оценка уровня потенциального усложнения кода открытых проект..."  +3 +/
Сообщение от Аноним (42), 21-Май-21, 12:47 
Очень странный критерий.
Изначально похоже сделано было допущение, что модульность это только про борьбу со сложностью и ничего другого. На этом всё и построено.
Но ведь модули могут создаваться для разделения поддержки разных архитектур, выделения подсистем с отдельным сопровождением, для удобства отключения не всегда нужного функционала и т.п. Также не заметил корреляцию с объёмом этих модулей.

Получается если большой модульный "переусложненный" проект слить в один единый файл, что он вдруг станет совсем не усложненным (никаких импортов совсем). Хотя по факту он сильно усложнится.

Возможно в рамках одного языка/платформы/подхода/функционала еще можно как-то сравнивать относительную сложность двух приложений, но например каждый язык исходя из своей выразительности и синтаксических возможностей накладывает свой отпечаток. Получается язык с плохой модульностью способствует написанию без усложнений. Типа на мотоцикле ездить безопаснее чем в машине, т.к. там нет ремней безопасности.

Ответить | Правка | Наверх | Cообщить модератору

51. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от Жироватт (ok), 21-Май-21, 15:03 
Не. Просто очень жёлтый критерий. Выделенный для громкого заголовка и месяца вялых бурлений.
Ответить | Правка | Наверх | Cообщить модератору

44. "Оценка уровня потенциального усложнения кода открытых проект..."  +3 +/
Сообщение от НяшМяш (ok), 21-Май-21, 13:24 
Замечательный критерий, надёжный как швейцарские часы. Вот хочу я, например, написать программу, пусть для работы с JSON.

- Импорт реализации строк (зачем свои велосипедить)
- Импорт реализации массивов
- Импорт реализации хешмапов
- Импорт библиотеки для парсинга JSON (если повезёт - она реэкспортит все нужные компоненты, перечисленные выше)

И это я ещё не начал саму программу писать.

Ответить | Правка | Наверх | Cообщить модератору

50. "Оценка уровня потенциального усложнения кода открытых проект..."  +3 +/
Сообщение от Жироватт (ok), 21-Май-21, 15:02 
Ты забыл про i/o (+1) и создание асинхронного потока для парса (+1).
И это даже без привязки к системным либам, тянущимся со всеми ими.
Ответить | Правка | Наверх | Cообщить модератору

53. "Оценка уровня потенциального усложнения кода открытых проект..."  +1 +/
Сообщение от Анонимоваттчас (?), 21-Май-21, 15:31 
А потом юзеры ещё и ГУЙ захотят…
Ответить | Правка | Наверх | Cообщить модератору

87. "Оценка уровня потенциального усложнения кода открытых проект..."  +1 +/
Сообщение от Аноним (87), 21-Май-21, 21:32 
И веб админку
Ответить | Правка | Наверх | Cообщить модератору

46. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от Аноним (46), 21-Май-21, 14:27 
Поглядел по ссылке, да я не Ъ, только для линуксового ядра. Интересно что это там за 16,8% магических сишных файлов без единого #include? Заголовочные файлы с константами?
Ответить | Правка | Наверх | Cообщить модератору

70. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от DontTreadOnMe (?), 21-Май-21, 18:52 
Там походу ещё и не учли, что некоторые заголовочные файлы всегда инклюдятся самим kbuild'ом, без явного #include.
Ответить | Правка | Наверх | Cообщить модератору

55. "Оценка уровня потенциального усложнения кода открытых проект..."  –2 +/
Сообщение от mumu (ok), 21-Май-21, 16:15 
Критерий - помёт.
Ответить | Правка | Наверх | Cообщить модератору

121. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от Аноним (-), 23-Май-21, 06:30 
причем тут ты?
Ответить | Правка | Наверх | Cообщить модератору

126. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от Герасим (?), 23-Май-21, 15:41 
Будешь выделываться - утоплю.
Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

56. "Оценка уровня потенциального усложнения кода открытых проект..."  +1 +/
Сообщение от Mike Lee (?), 21-Май-21, 16:40 
Т.е. простыня на 10000 строк проще чем 100 файлов по 100 строк? Ну ок.
Ответить | Правка | Наверх | Cообщить модератору

64. "Оценка уровня потенциального усложнения кода открытых проект..."  –1 +/
Сообщение от Аноним (64), 21-Май-21, 17:28 
Зато Хруст на 3-м месте!
Ответить | Правка | Наверх | Cообщить модератору

80. "Оценка уровня потенциального усложнения кода открытых проект..."  +1 +/
Сообщение от freecoder_xxemail (?), 21-Май-21, 20:23 
Не удивительно: в Rust поощряется модульность и используется на всю катушку.
Ответить | Правка | Наверх | Cообщить модератору

102. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от Анончик (?), 22-Май-21, 10:20 
еще реализация этих модулей не была похожа на ребенка в инвалидной каляске.
Ответить | Правка | Наверх | Cообщить модератору

79. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от freecoder_xxemail (?), 21-Май-21, 20:22 
С одной стороны, критерий действительно отражает сложность *отдельно взятого* проекта. Но в реальности разбиение на модули - хорошая практика именно *борьбы* со сложностью, просто учитывать проекты нужно в совокупности, а не по отдельности.

Например, если есть два проекта A и B, которые оба зависят от модулей C и D, то получится, что каждый по отдельности проект имеет сложность 3 (A, C, D и B, C, D), но все вместе они имеют сложность 4, а не 6.

Ответить | Правка | Наверх | Cообщить модератору

81. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от Gogi (??), 21-Май-21, 20:29 
Самый простейший и работающий критерий - это количество коммитов ОТ НОВИЧКОВ. Если нуб открыл проект и смог разобраться - это годный проект! :)
Ответить | Правка | Наверх | Cообщить модератору

82. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от Ан Онто Им (?), 21-Май-21, 20:47 
И как быстро нубы сведут всё в ноль.
Ответить | Правка | Наверх | Cообщить модератору

88. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от Gogi (??), 21-Май-21, 22:11 
На это есть управляющий проектом - оценивать и принимать код. Главное - что нуб может разобраться в структуре кода. Неважно, сколько там классов, подключенных либ и т.п.
Ответить | Правка | Наверх | Cообщить модератору

99. "Оценка уровня потенциального усложнения кода открытых проект..."  +1 +/
Сообщение от Аноним (99), 22-Май-21, 08:30 
Брэд.
Ответить | Правка | Наверх | Cообщить модератору

113. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от funny.falcon (?), 22-Май-21, 15:47 
В целом я поддержу Gigi с одной оговоркой:
- сложный проект может все ещё доступен для понимания новичка, если хорошо написан и хорошо документирован комментариями.

В этом смысле я бы всем рекомендовал поковыряться в PostgreSQL. Сложность там зашкаливает, но благодаря вылизанности и обилию комментариев, человек с мозгами (даже если он нуб) может всё-таки более-менее разобраться.

Не всегда, правда, достаточно хорошо, чтобы быть способным написать неглючный патч. Но хотя бы какой-нибудь написать.

Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

115. "Оценка уровня потенциального усложнения кода открытых проект..."  –1 +/
Сообщение от Ordu (ok), 22-Май-21, 19:00 
В целом, вопрос о том, как померять сложность довольно любопытен. Более того это не просто бесцельное любопытство, он обладает и практической полезностью: если бы у нас был бы критерий, то на этапе проектирования программы мы могли бы оценивать разные проекты и сравнивать их по сложности. Или после, оценивая разные подходы к решению, мы могли бы выбирать самый простой.

Сия статья, как бы там не писали анонимы выше, не претендует на изобретение финального критерия. Она просто берёт какой-то критерий, и показывает нам результаты применения этого критерия. Статья -- это в большей мере исследование критерия сложности, а не сложности опенсорц проектов. Все критицизмы выше -- это результат того, что в переводе акценты оказались смещены.

Скажем есть принцип DRY (Don't Repeat Youself[1]), но некоторые говорят, что DRY для сосунков, и правильнее следовать принципу WET (Write Everything Twice) -- Кармак как-то агитировал в эту пользу, говоря о том, что писать обобщённую реализацию на двух примерах использования, это кошмар и приводит в конечном итоге к невозможности дальнейшей поддержки, вот когда есть две реализации функции, и нужна третья, вот на трёх примерах уже можно.

Критерий, который статья описывает, по-сути, заявляет что WET проще, чем DRY. Но ситуация ведь сложнее DRY в некоторых случаях упрощает жизнь, с DRY реализацией динамического массива, например, я могу быть уверен что вне вызовов метода этого массива всегда выполняются инварианты "arr->len <= arr->size", "arr->buf != NULL" и "для любого i (0 <= i < arr->len) arr->buf[i] -- не UB". Это очень упрощает жизнь. (Хотя и усложняет тоже: если на стеке любого потока есть стековый фрейм любого из методов динамического массива, то все гарантии коту под хвост, любой из вариантов может быть нарушен в это время).

Короче, сложность -- это сложно, но такие статьи радуют: люди пытаются померять сложность, может когда-нибудь кто-нибудь и придумает, как её померять хорошо. Впрочем, мне кажется, что эта статья слишком простую модель психики программиста использует, уровня правила 7+-2[1]... Мне кажется, занятно было бы попытаться определить "сложность" как функцию символа кода, которая говорит о том, сколько инвариантов программисту надо держать в голове, чтобы написать следующий символ, не совершив ошибку. Ну, типа если я написал "(7+", то дальше должен быть аргумент совместимый с операцией +, первым аргументом которой является целое число, и ещё потом надо не забыть закрыть скобочку. Возможно при этом результатом сложения должно быть число, на которые накладываются ограничения типа 0<=x<=len, иначе будет ошибка выхода за границы массива. Затем сверху ещё требования к алгоритмической корректности кода, и бла-бла-бла... И если бы такую функцию определить, а затем ещё научится считать программно, то после этого можно было бы попробовать проинтегрировать эту функцию по всему коду, и получить оценку сложности программы, которая действительно будет отражать насколько сложно работать с таким кодом. Или может не будет отражать, но пока не посчитаешь для конкретных программ, не поймёшь.

[1] https://ru.wikipedia.org/wiki/Don%E2%80%99t_r...
[2] https://ru.wikipedia.org/wiki/%D0%9C%D0%...

Ответить | Правка | Наверх | Cообщить модератору

118. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от Онаним (?), 22-Май-21, 20:57 
-- я могу быть уверен что вне вызовов метода этого массива всегда выполняются инварианты "arr->len <= arr->size", "arr->buf != NULL" и "для любого i (0 <= i < arr->len) arr->buf[i] -- не UB"

Это пока весь код твой, и нет васян-библиотек xD
В случае васян-библиотеки или просто соседнего индуса (не путать с национальностью) я бы не был так уверен и налепил assert'ов (exception'ов) и прочих аналогов в критичных местах.
Потому что завтра эта уверенность вылетит в трубу^Wуязвимость.

Ответить | Правка | Наверх | Cообщить модератору

119. "Оценка уровня потенциального усложнения кода открытых проект..."  –1 +/
Сообщение от Ordu (ok), 22-Май-21, 21:43 
> В случае васян-библиотеки или просто соседнего индуса (не путать с национальностью) я
> бы не был так уверен и налепил assert'ов (exception'ов) и прочих
> аналогов в критичных местах.

assert'ы должны быть внутри васян-библиотеки в виде тестов. Так что лучше лепить их не в свой код, а непосредственно в код васян-библиотеки тестами, и отправлять их ему патчами. Глядишь он меньшим васяном станет, а то и вообще имя сменит.

Не все инварианты ты сможешь проверить assert'ами: как ты проверишь валидность указателя? Как ты проверишь размер выделенного куска памяти по адресу лежащему в указателе? И как часто проверять? Каждый раз, когда ты решил поработать с динамическим массивом? Или после каждого вызова каждого метода? Инварианты придумали как раз для того, чтобы разделить ответственность -- ответственность за поддержание инвариантов динамического массива лежит на разработчике динамического массива, если он с этой ответственностью не справляется, ищи другого разработчика.

> Потому что завтра эта уверенность вылетит в трубу^Wуязвимость.

Если тесты включены в код библиотеки, то, чтобы уверенность восстановить, можно прогнать юнит-тесты после обновления библиотеки.

Ответить | Правка | Наверх | Cообщить модератору

116. "Оценка уровня потенциального усложнения кода открытых проект..."  +/
Сообщение от iZENemail (ok), 22-Май-21, 20:24 
Ещё бы LLVM/Clang исследовали.
Ответить | Правка | Наверх | Cообщить модератору

127. "Оценка уровня потенциального усложнения кода открытых проект..."  +1 +/
Сообщение от Аноним (127), 24-Май-21, 10:58 
ELASTIC - та еще помойка говнокода, тромозящая и неповоротливая как и все их продукты.
Показательно, что бывает, когда смузихлебам ставят ТЗ.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру