The OpenNET Project / Index page

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

Оценка уровня потенциального усложнения кода открытых проектов

21.05.2021 10:01

Мартин Шлейс (Martin Schleiss) попытался сравнить различные открытые проекты с точки зрения усложнённости кода и понимания как код работает и какие действия выполняет. Например, проект становится более сложен для понимания при применении сложных абстракций, таких как распределённое взаимодействие компонентов по сети, или использовании большого числа вложенных модулей и классов.

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

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

  • Elasticsearch - 77.2%
  • Visual Studio Code - 60.3%.
  • Rust - 58.6%
  • Ядро Linux - 48.7%
  • PostgreSQL - 46.4%
  • mongoDB - 44.7%
  • Node.js - 39.9%
  • PHP - 34.4%
  • CPython - 33.1%
  • Django - 30.1%
  • reactJS - 26.7%
  • Symfony - 25.5%
  • Laravel - 22.9%
  • nextJS - 14.2%
  • chakra-ui - 13.5%


  1. Главная ссылка к новости (https://schleiss.io/measuring-...)
  2. OpenNews: Линус Торвальдс выразил опасения в связи со стремительным усложнением ядра Linux
  3. OpenNews: Вектор развития Linux: легковесность против усложнения
  4. OpenNews: Роб Пайк заявил, что Java и C++ слишком усложнены для промышленных языков
  5. OpenNews: Оценка числа примечаний TODO и FIXME в коде ядра Linux
  6. OpenNews: Оценка влияния на производительность популярных дополнений к Chrome
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/55187-code
Ключевые слова: code
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (114) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 10:07, 21/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +51 +/
    Ещё тупее критерий придумать не смогли?
     
     
  • 2.6, Аноним (6), 10:24, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ну ты если такой умный то предложи
     
     
  • 3.9, Фотошоп лучше (?), 10:32, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +5 +/
    На каком основании вы требуете от собеседника что-то предлагать? Он высказался в том, что исследование нУжно? Или Вы считаете, что констатация факта неадкватного критерия оценки означает обязательное наличие более адекватного критерия?
     
     
  • 4.10, Аноним (10), 10:35, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > констатация факта неадкватного критерия оценки означает обязательное наличие более адекватного критерия?

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

     
  • 4.100, Аноним (100), 09:29, 22/05/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Потому что: критикуешь - предлагай, предлагаешь - делай, делаешь - отвечай. А иначе ты, дядя, 3,14-ун просто.
     
     
  • 5.101, z (??), 09:37, 22/05/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    отвечая - критикуй. goto start.
     
  • 4.105, Всем Анонимам Аноним (?), 11:21, 22/05/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    99% коментариев на Opennet это все вокруг дураки, а я то умный такой (как в прямой, так и непрямой форме). Аргументы не принимаются, все-равно все дураки, а я то прямо орел.
     
     
  • 5.108, Michael Shigorin (ok), 13:01, 22/05/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Да это не комментарии виноваты -- это мы с вами, братцы, порой зачем-то друг перед дружкою выпендриваемся (и то не тем, чем хоть стоило бы; а некоторые так вовсе перед собой любимым с одного адреса переписываются).

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

     
     
  • 6.120, Аноним (120), 23:16, 22/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    В коей то веке здравая мысль от Шигорина ))
     
  • 3.14, Аноним (1), 10:54, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Сложно кода это сложнее, чем считать кол-во включений файлов.

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

     
     
  • 4.90, макпыф (ok), 23:03, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    но тут субьективно достаточно получаеться, а по поводу кодовой базы - она может быть поделена на модули так, что работая над одним, не нужно даже названия других знать не надо (драйвера в ядре)
     
  • 3.65, VladSh (?), 17:29, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Большое количество подключаемых файлов косвенно может говорить о том, что в данном файле кто-то пытался скрестить ежа и ужа. То есть нарушен паттерн - одним куском кода решать одну задачу (в идеале).
    Но любой нормальный програмер и так всегда стремится уменьшить количество подключаемых файлов.

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

     
     
  • 4.93, Bdfybec (?), 07:20, 22/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Большое количество подключаемых файлов косвенно может говорить о том, что в данном файле кто-то пытался скрестить ежа и ужа. То есть нарушен паттерн - одним куском кода решать одну задачу (в идеале).

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

     
  • 3.66, Аноним (66), 17:54, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Он же не тупой, зачем ему предлагать ещё тупее критерии? Странный вопрос.
     
  • 3.67, Аноним (-), 18:18, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Следует согласиться, критерий слегка некорректный. Ссылки на файлы... Можно было бы проанализировать количество строк в функциях, модульность — как-то более в человеческом ключе.
     
  • 3.92, Dmitry (??), 00:58, 22/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Вообще есть инструменты автоматического котроля "сложности". Хорошее правило - если код сложным - сборка в CI ломается.
    Есть много метрик:
    https://checkstyle.org/config_metrics.html#ClassFanOutComplexity (что описано в этом посте)
    https://checkstyle.org/config_metrics.html#CyclomaticComplexity - кличество ветвистых "if'ов"

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

     
  • 3.104, svsd_val (ok), 10:44, 22/05/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Предлагаю индусский вариант... самый бесполезный и очевидно равный предложенному выше =)
    С тем же успехом можно считать количество объектов, количество присвоений и количество ветвлений.

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

     
  • 2.16, Онаним (?), 10:54, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Чем он тупой-то?
    Оверинженеринг и овердекомпозиция - бич современных "прожектёров".
     
     
  • 3.33, Аноним (1), 11:56, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тем, что не показывает ничего. Кто-то включил не один а 2 файла, какой ужас.
     
     
  • 4.43, Урри (ok), 13:14, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Зачем так примитивно лгать? Не "не один, а два", а "больше пяти".
     
  • 4.45, Аноним (45), 14:17, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Речь не про include заголовочных файлов, как я понял, а про связи между модулями. Хотя тут тоже тот ещё вопрос: в тех же проектах на C может быть всего 2-3 заголовочных файла на пачку модулей...
     
  • 4.83, Аноним (83), 21:00, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вместо того, чтобы написать строку со сложением двух величин, вызвали хелпер, который обратился к сервису, тот через провайдер создал колбек обработчик, который передал менеджеру очередей, из которой задание извлек обработчик и вызвал таки этот колбек, что и привело к сложению двух исходных величин.
    Зато избавились от дублирования кода, и складывать теперь умеем хоть через mssql, хоть на гпу.
     
     
  • 5.86, Онаним (?), 21:25, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Проблемы начнутся, когда это счастье окажется в inner loop, а величин будет море.
    В итоге оно потребует фермы из 20 64-ядерных обработчиков и полдня для того, что нормально написанное приложение сделает на i386 за минуту.
     
  • 2.30, Анто769ним (?), 11:33, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    https://singaporedatacompany.com/blog/more-developers-more-problems
     

  • 1.2, Леголас (ok), 10:08, 21/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    усложнение кода есть одна из современных тенденций, к сожалению
     
     
  • 2.18, Аноним (18), 10:55, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Усложнение неизбежно для относительно крупного проекта. А серебряной пули до сих пор нет.
     
     
  • 3.25, Crazy Alex (ok), 11:24, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +10 +/
    Решение очевидно, особенно для опенсорса - жёстко очертить задачи и область применимости продукта и не пытаться сделать всё. В пределе - то самое "делать что-то одно и делать это хорошо" из юникс-вэя.
     
     
  • 4.47, Жироватт (ok), 14:43, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Ты только что изобрел философию Unix из 80х.
     
     
  • 5.109, Michael Shigorin (ok), 13:04, 22/05/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Он только что сам на неё и сослался (а не претендовал на изобретение).  Ну, _включил_ по упоминанию. :-)
     
     
  • 6.124, Аноним (124), 09:29, 23/05/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Какой ты умный. А мы то и не догадались без твоего комментария. Как у тебя дела-то, много продал дистрибутивов за 100 рублей?
     
  • 4.71, Тот_Самый_Анонимус (?), 19:11, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Т.е. вместо файлового менеджера — куча программ. Как-то не нужно.
     
     
  • 5.89, Аноним (89), 22:17, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Файловый менеджер сегодня это обёртка над другими утилитами. Ну это если нормальный файловый менеджер.
     
     
  • 6.94, Bdfybec (?), 07:25, 22/05/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    вот и выходит, что философия "делать что-то одно и делать это хорошо", применима только к утилитам, а не к "обёрткам".
     
     
  • 7.111, Аноним (89), 13:22, 22/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > вот и выходит, что философия "делать что-то одно и делать это хорошо",
    > применима только к утилитам, а не к "обёрткам".

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

     
  • 2.54, z (??), 15:40, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Усложнение есть одна из тенденций эволюции, всего живого
     
     
  • 3.59, Аноним (59), 17:08, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    И неживого. Рекомендую почитать работы некоторых Нобелевских лауреатов.
     
     
  • 4.95, Bdfybec (?), 07:29, 22/05/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Барака Обаму и Нельсона Манделу?
     
  • 3.91, Dmitry (??), 00:44, 22/05/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    если что то усложняется -  "это эволюция свойство всего" и становится всё понятно что так и должно быть :)
    а если код рефакторят и упрощают - это свойствор мёртввого?
     
  • 3.110, Michael Shigorin (ok), 13:05, 22/05/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Обычно мёртвого, усердно косящего под живое.  А действительно живое -- оно простое и красивое, и остаётся таковым.
     
     
  • 4.125, Аноним (124), 09:34, 23/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > А действительно живое -- оно простое и красивое, и остаётся таковым.

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

     
  • 4.129, www2 (??), 08:03, 26/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Я бы не согласился, в ДНК может быть много мусора, который не используется, но является пространством для возможной дальнейшей эфолюции или защитой от неудачных реверсивных мутаций или обмена фрагментами между парными хромосомами.

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

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

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

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

     
  • 2.68, Аноним (-), 18:19, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Усложнение кода сигнализирует о его неоптимальности.
     

  • 1.3, Иван (??), 10:20, 21/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Никто не запрещает не пользоваться ООП в PHP.
     
     
  • 2.4, Леголас (ok), 10:24, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +4 +/
    в списке сам PHP, а не проект, написанный на нём с использованием ООП
     
     
  • 3.61, Иваня (?), 17:10, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Чел открой глаза, там Laravel...
     
     
  • 4.63, Леголас (ok), 17:25, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    твоя правда, но чувак выше не про него явно писал
     
  • 2.38, Аноним (38), 12:34, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Для одной странички приемлемо.
     

  • 1.5, Аноним (5), 10:24, 21/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    Если константы вместо того чтобы хардкодить их прямо в коде вынести в отдельный подключаемый файл constants, то код становится проще и понятнее, а не сложнее.
     
     
  • 2.8, Аноним (8), 10:29, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это один подключаемый файл. У вас осталось еще 4.
     
     
  • 3.11, Аноним (10), 10:37, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    4-5
     
  • 2.26, Crazy Alex (ok), 11:25, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Если у тебя столько констант, что их надо выносить в отдельный файл и использовать из разных мест - это и есть показатель сложности кода.
     
     
  • 3.31, Аврилий (?), 11:52, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    1 сложность - файл локализация
    2 сложность - файл конфигов
    3 сложность - подключение stdlib

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

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

     
     
  • 4.35, Аноним (35), 12:01, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > P.S. ruby, python, etc... смеются в сторонке храня все в глобальных переменных

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

     
  • 4.48, Жироватт (ok), 14:52, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Сложность 0 - стандартные "общеобязательные" инклюды
    Сложность 1 - 0 + стандартные "редкие" инклюды
    Сложность 2 - 1 + 1 инклюд с иерархией рабочих объектов
    Сложность 3 - 2 + 1 инклюд с самописным внешним коннектором
    Сложность 4 - 3 + 1 инклюд фалов служебных объектов или констант или функций работы с UI
    Сложность 5 - 4 + 1 инклюд библиотеки ресурсов или локали
    ---- < здесь какой-то хрен-с-горы сказал, что твой код слишком сложен для пятиклассника (по мозгам) с гитхаба
    ...
    ---- < Здесь находится код с гитхаба уровня /б
    ...
    ---- < Тихий Кит и Синий Дом
    ...
    ---- < Сверхсущества
    ...
    ---- < Б-г
     
  • 3.39, Аноним (38), 12:39, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Представим себе физико-математическую вычислительную прогу. Скорость света, элементарный заряд, h, могут потребоваться в разных модулях программы. Не вбивать же их значения каждый раз в нужных местах?
     
     
  • 4.49, Жироватт (ok), 15:00, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем, есть 'rand = srand(nullptr); double h = rand.next();' ?
     

  • 1.7, myhand (ok), 10:27, 21/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    По одному критерию оценивать подобные вещи - это даже хуже чем глупо.
     
     
  • 2.13, Аноним (13), 10:54, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Выкатите-ка своё исследование по иным критериям - мы оценим. Вот это будет конструктивно.
     
     
  • 3.21, InuYasha (??), 10:58, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А какой, простите, кафедрой вы заведуете, чтобы оценивать? Если дадите мне повышение степени, я могу написать.
     
     
  • 4.57, Аноним (13), 16:48, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А ты всё ещё не догадался? Кафедрой оценок уровня потенциального усложнения кода открытых проектов.
     
  • 3.98, myhand (ok), 07:47, 22/05/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Почему в ответ на публикацию в бложеке я должен запилить целое исследование?

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

     

  • 1.12, Онаним (?), 10:53, 21/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хороший критерий.
    Загляните в любой код хипстерских проектов на модных язычках.
    Да и в код хипстерских проектов на менее модных язычках.
    Какая-нибудь простейшая библиотечка может содержать 50 файлов с разными классами из пяти строчек, часть из которых НЕЯВНО (автозагрузка, фиг ли) ссылается на половину оставшихся.
    По опыту - зачастую проще выкинуть и/или переписать самому максимально просто, с меньшим числом багов и большим числом функций. Причём это времени занимает меньше, чем пытаться поддерживать это оно, которое тянется из разных источников, постоянно меняется и начинает кривить-косить.
     
     
  • 2.17, Аноним (1), 10:55, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Загляни в старый проект на сишке --- а там инклюды.
     
     
  • 3.19, Онаним (?), 10:56, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    PHP - достаточно старый проект на сишке?
    Ну так вот, он далеко не в начале списка.
     
     
  • 4.20, Онаним (?), 10:57, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    (и про недостаточную его сложность тоже ничего рассказать не получится, шах и мат)
     
  • 2.52, Жироватт (ok), 15:08, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Заглянул. Эти пять строчек (для virtual/abstract блюпринтов) или 1500 строчек (если уже работа с sealed/final классом идет) легко читаются, позволют сконцентрироваться на самом классе или конкретной задаче. Константы не размазаны по всему коду, а поименованы и всунуты там, где им и место. Никаких магических чисел. Читать удобно, раскуривать еще удобнее.

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

     
     
  • 3.122, Онаним (?), 09:19, 23/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Ты не понял.
    По пять строчек кода, НЕ описания класса. Куча коротких бессмысленных методов, в т.ч. однострочников.
    Вызовы ради вызова.
    Никаких virtual/abstract я не упоминал.
     
  • 3.123, Онаним (?), 09:20, 23/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    (больше лефтпадов, хороших и разных, если упростить)
     
  • 2.114, pin (??), 16:55, 22/05/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > переписать самому максимально просто,

    в результате

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

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

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

     
     
  • 3.117, Онаним (?), 20:48, 22/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    В результате переписывания подобной хреноты вместо (реально) 10-20-30 файлов получается 1-2-3, со стройной структурой и очевидным кодом.
     

  • 1.15, InuYasha (??), 10:54, 21/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Согласен, критерий странный. Не сказал бы что адекватный.

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

     
     
  • 2.27, Crazy Alex (ok), 11:27, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну вот потом сравниваем сколько инклудов в кваке и холловорде - и получаем неплохое приближение к соотношению их сложности.
     
  • 2.37, Nathan Bedford Forrest (?), 12:33, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    зато квака вполне себе комфортна жила на 8 мегабайтах оперативки часть из которых еще жрала системаа
     

  • 1.22, Псевдоним (??), 11:21, 21/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Странный критерий или нет, но похоже на правду.
     
  • 1.23, Орк (?), 11:23, 21/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +16 +/
    Господа, нас обманули, расходимся. Посыл статейки ясен: пишите все программы одним файлом и не будет усложнения кода. На модульность программ и разделение ответственности Мартин клал. Исследование не стоит затраченного на него электричества.
     
     
  • 2.28, Леголас (ok), 11:31, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Исследование не стоит затраченного на него электричества.

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

     
  • 2.29, Crazy Alex (ok), 11:31, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Неужели так сложно понять? Для того, чтобы усложняющийся проект жил и поддерживался, его сложностью надо управлять. Как один из инструментов - разбиение на файлы. В итоге количество файлов становится метрикой сложности.

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

     
     
  • 3.34, Клавдий (?), 11:56, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Бьем проект на 100500 микросервисов и ваша логика относительно количества файлов и сложности разбивается об стенку намазаную йодом.
     
  • 3.112, Tishka17 (?), 14:19, 22/05/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не так: если вы разделили код на модули, вы снизили его сложность, а не повысили. Если вы этого не сделали, возможно вы просто в состоянии это сделать из-за сложности существующего кода.

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

     
     
  • 4.128, Crazy Alex (ok), 13:29, 25/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Если вам пришлось это делать - то значит у вас уже сложный проект
     

  • 1.24, Аноним (24), 11:23, 21/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    >Visual Studio Code - 60.3%.

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

     
     
  • 2.40, Аноним (38), 12:41, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тут не учтены зависимости зависимостей. Зависимости самого Electron чего стоят.
     

  • 1.32, Аноним (32), 11:55, 21/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Ну им ничто не мешало, откровенно говоря, ещё пройтись и посмотреть цикломатическую сложность функций и методов как минимум.
     
     
  • 2.84, Аноним (84), 21:00, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А зачем?
    Ведь любая проблема имеет очевидное, простое и да, неправильное решение.
     

  • 1.41, Nathan Bedford Forrest (?), 12:42, 21/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    джаваскрипт - дерьмо
     
     
  • 2.69, Аноним (-), 18:23, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Не поспоришь.
     
  • 2.72, Петух (?), 19:27, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Зачем его придумали и почему до сих пор не заменили?
     
     
  • 3.85, Аноним (84), 21:01, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Гугл все устраивает?
     

  • 1.42, Аноним (42), 12:47, 21/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Очень странный критерий Изначально похоже сделано было допущение, что модульнос... большой текст свёрнут, показать
     
     
  • 2.51, Жироватт (ok), 15:03, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Не. Просто очень жёлтый критерий. Выделенный для громкого заголовка и месяца вялых бурлений.
     

  • 1.44, НяшМяш (ok), 13:24, 21/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Замечательный критерий, надёжный как швейцарские часы. Вот хочу я, например, написать программу, пусть для работы с JSON.

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

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

     
     
  • 2.50, Жироватт (ok), 15:02, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ты забыл про i/o (+1) и создание асинхронного потока для парса (+1).
    И это даже без привязки к системным либам, тянущимся со всеми ими.
     
     
  • 3.53, Анонимоваттчас (?), 15:31, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А потом юзеры ещё и ГУЙ захотят…
     
     
  • 4.87, Аноним (87), 21:32, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И веб админку
     

  • 1.46, Аноним (46), 14:27, 21/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Поглядел по ссылке, да я не Ъ, только для линуксового ядра. Интересно что это там за 16,8% магических сишных файлов без единого #include? Заголовочные файлы с константами?
     
     
  • 2.70, DontTreadOnMe (?), 18:52, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Там походу ещё и не учли, что некоторые заголовочные файлы всегда инклюдятся самим kbuild'ом, без явного #include.
     

  • 1.55, mumu (ok), 16:15, 21/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Критерий - помёт.
     
     
  • 2.121, Аноним (-), 06:30, 23/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    причем тут ты?
     
  • 2.126, Герасим (?), 15:41, 23/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Будешь выделываться - утоплю.
     

  • 1.56, Mike Lee (?), 16:40, 21/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Т.е. простыня на 10000 строк проще чем 100 файлов по 100 строк? Ну ок.
     
  • 1.64, Аноним (64), 17:28, 21/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Зато Хруст на 3-м месте!
     
     
  • 2.80, freecoder_xx (?), 20:23, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не удивительно: в Rust поощряется модульность и используется на всю катушку.
     
     
  • 3.102, Анончик (?), 10:20, 22/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    еще реализация этих модулей не была похожа на ребенка в инвалидной каляске.
     

  • 1.79, freecoder_xx (?), 20:22, 21/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    С одной стороны, критерий действительно отражает сложность *отдельно взятого* проекта. Но в реальности разбиение на модули - хорошая практика именно *борьбы* со сложностью, просто учитывать проекты нужно в совокупности, а не по отдельности.

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

     
  • 1.81, Gogi (??), 20:29, 21/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Самый простейший и работающий критерий - это количество коммитов ОТ НОВИЧКОВ. Если нуб открыл проект и смог разобраться - это годный проект! :)
     
     
  • 2.82, Ан Онто Им (?), 20:47, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    И как быстро нубы сведут всё в ноль.
     
     
  • 3.88, Gogi (??), 22:11, 21/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    На это есть управляющий проектом - оценивать и принимать код. Главное - что нуб может разобраться в структуре кода. Неважно, сколько там классов, подключенных либ и т.п.
     
     
  • 4.99, Аноним (99), 08:30, 22/05/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Брэд.
     
  • 4.113, funny.falcon (?), 15:47, 22/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    В целом я поддержу Gigi с одной оговоркой:
    - сложный проект может все ещё доступен для понимания новичка, если хорошо написан и хорошо документирован комментариями.

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

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

     

  • 1.115, Ordu (ok), 19:00, 22/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    В целом, вопрос о том, как померять сложность довольно любопытен Более того это... большой текст свёрнут, показать
     
     
  • 2.118, Онаним (?), 20:57, 22/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    -- я могу быть уверен что вне вызовов метода этого массива всегда выполняются инварианты "arr->len <= arr->size", "arr->buf != NULL" и "для любого i (0 <= i < arr->len) arr->buf[i] -- не UB"

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

     
     
  • 3.119, Ordu (ok), 21:43, 22/05/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > В случае васян-библиотеки или просто соседнего индуса (не путать с национальностью) я
    > бы не был так уверен и налепил assert'ов (exception'ов) и прочих
    > аналогов в критичных местах.

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

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

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

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

     

  • 1.116, iZEN (ok), 20:24, 22/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ещё бы LLVM/Clang исследовали.
     
  • 1.127, Аноним (127), 10:58, 24/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    ELASTIC - та еще помойка говнокода, тромозящая и неповоротливая как и все их продукты.
    Показательно, что бывает, когда смузихлебам ставят ТЗ.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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