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

"Оценка уровня потенциального усложнения кода открытых проектов"	+/–
Сообщение от opennews (??), 21-Май-21, 10:07
Мартин Шлейс (Martin Schleiss) попытался сравнить различные открытые проекты с точки зрения усложнённости кода и понимания как код работает и какие действия выполняет. Например, проект становится более сложен для понимания при применении сложных абстракций, таких как распределённое взаимодействие компонентов по сети, или использовании большого числа вложенных модулей и классов... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=55187
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 21-Май-21, 10:07	+52 +/–
Ещё тупее критерий придумать не смогли?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #16, #30

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

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

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

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

6. Сообщение от Аноним (6), 21-Май-21, 10:24	+/–
ну ты если такой умный то предложи
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #9, #14, #65, #66, #67, #92, #104

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

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

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

10. Сообщение от Аноним (10), 21-Май-21, 10:35	+4 +/–
> констатация факта неадкватного критерия оценки означает обязательное наличие более адекватного критерия? для местного диванного эксперта -- да
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

11. Сообщение от Аноним (10), 21-Май-21, 10:37	+1 +/–
4-5
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

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

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

14. Сообщение от Аноним (1), 21-Май-21, 10:54	+3 +/–
Сложно кода это сложнее, чем считать кол-во включений файлов. В целом надо смотреть на каждый проект, смотреть на его структуру. Модульный проект чаще будет более усложнённым, но его будет легче разрабатывать и сопровождать. Надо смотреть на саму кодовую базу, она большая? Проект сложнее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #90

15. Сообщение от InuYasha (??), 21-Май-21, 10:54	–2 +/–
Согласен, критерий странный. Не сказал бы что адекватный. Если развернуть все инклюды в какой-нибудь Кваке, то их будет по 10-20шт на один .c, не? Или даже в простом хеллоуворлд-подобном проекте будет с десяток стандартных хедеров на всякие printf.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #27, #37

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

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

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

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

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

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

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

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

24. Сообщение от Аноним (24), 21-Май-21, 11:23	–1 +/–
>Visual Studio Code - 60.3%. Это высер Майкрософт? Тогда не нужно.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #40

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

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

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

28. Сообщение от Леголас (ok), 21-Май-21, 11:31	+/–
> Исследование не стоит затраченного на него электричества. как и поддержка комментариев здесь
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

29. Сообщение от Crazy Alex (ok), 21-Май-21, 11:31	+1 +/–
Неужели так сложно понять? Для того, чтобы усложняющийся проект жил и поддерживался, его сложностью надо управлять. Как один из инструментов - разбиение на файлы. В итоге количество файлов становится метрикой сложности. Грубо говоря, если ты ещё можешь тянуть проект без модульности - значит он совсем простой. Усложнился - пришлось разделить, выделить какую-то общую функциональность для реюза. Ещё усложнился - берём фреймворки и так далее. Ну или там берём фреймворк изначально для хелловорлда и получаем кучу притащенной сложности - что прекрасно отразится метрикой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #34, #112

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

31. Сообщение от Аврилий (?), 21-Май-21, 11:52	+2 +/–
1 сложность - файл локализация 2 сложность - файл конфигов 3 сложность - подключение stdlib У вас остался один файл на подключение или ваш проект обосрут на опеннете. P.S. ruby, python, etc... смеются в сторонке храня все в глобальных переменных
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #35, #48

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

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

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

35. Сообщение от Аноним (35), 21-Май-21, 12:01	+1 +/–
> P.S. ruby, python, etc... смеются в сторонке храня все в глобальных переменных Ты упоролся или да?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

79. Сообщение от freecoder_xx (?), 21-Май-21, 20:22	+/–
С одной стороны, критерий действительно отражает сложность *отдельно взятого* проекта. Но в реальности разбиение на модули - хорошая практика именно *борьбы* со сложностью, просто учитывать проекты нужно в совокупности, а не по отдельности. Например, если есть два проекта A и B, которые оба зависят от модулей C и D, то получится, что каждый по отдельности проект имеет сложность 3 (A, C, D и B, C, D), но все вместе они имеют сложность 4, а не 6.
Ответить | Правка | Наверх | Cообщить модератору

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

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

82. Сообщение от Ан Онто Им (?), 21-Май-21, 20:47	+/–
И как быстро нубы сведут всё в ноль.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81 Ответы: #88

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

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

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

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

87. Сообщение от Аноним (87), 21-Май-21, 21:32	+1 +/–
И веб админку
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53

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

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

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

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

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 В общем сложность нужно держать под контролем автоматизированными инструментами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

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

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

95. Сообщение от Bdfybec (?), 22-Май-21, 07:29	+1 +/–
Барака Обаму и Нельсона Манделу?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

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

99. Сообщение от Аноним (99), 22-Май-21, 08:30	+1 +/–
Брэд.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88

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

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

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

104. Сообщение от svsd_val (ok), 22-Май-21, 10:44	+2 +/–
Предлагаю индусский вариант... самый бесполезный и очевидно равный предложенному выше =) С тем же успехом можно считать количество объектов, количество присвоений и количество ветвлений. По факту если рассмотреть код в котором включений будет меньше и код в которых их будет больше, в первом случае можно будет сломать голову от кода, лямда функций и за каждым деревом будет ещё дерево и за ним будет ещё а за ним будет ещё и так далее пока человек не потеряет нить. А вот модульный код, даже с большим количеством включений будет понять легче.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

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

108. Сообщение от Michael Shigorin (ok), 22-Май-21, 13:01	+3 +/–
Да это не комментарии виноваты -- это мы с вами, братцы, порой зачем-то друг перед дружкою выпендриваемся (и то не тем, чем хоть стоило бы; а некоторые так вовсе перед собой любимым с одного адреса переписываются). Так что кому опеннет не тот -- предлагаю вооружиться зеркалом.  Да и сам пойду-ка рожу в нём изучу на предмет углов и радиусов, что ли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105 Ответы: #120

109. Сообщение от Michael Shigorin (ok), 22-Май-21, 13:04	+3 +/–
Он только что сам на неё и сослался (а не претендовал на изобретение).  Ну, _включил_ по упоминанию. :-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #124

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

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

112. Сообщение от Tishka17 (?), 22-Май-21, 14:19	–1 +/–
Не так: если вы разделили код на модули, вы снизили его сложность, а не повысили. Если вы этого не сделали, возможно вы просто в состоянии это сделать из-за сложности существующего кода. Большое число файлов может означать, что за кодом следят и следуют определенному походу. Например, в джаве нормально на каждый класс создавать по файлу, просто так устроен язык. Даже если это класс из 10 строк. В пхп скорее всего так никто не будет делать. Можно упомянуть и обратную механику: в пределах пакета (файлы в папке) в джаве не обязательно что-то импортировать, а в питоне каждый файл независим и импорт придется добавить даже при такой же структуре файлов
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #128

113. Сообщение от funny.falcon (?), 22-Май-21, 15:47	+/–
В целом я поддержу Gigi с одной оговоркой: - сложный проект может все ещё доступен для понимания новичка, если хорошо написан и хорошо документирован комментариями. В этом смысле я бы всем рекомендовал поковыряться в PostgreSQL. Сложность там зашкаливает, но благодаря вылизанности и обилию комментариев, человек с мозгами (даже если он нуб) может всё-таки более-менее разобраться. Не всегда, правда, достаточно хорошо, чтобы быть способным написать неглючный патч. Но хотя бы какой-нибудь написать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88

114. Сообщение от pin (??), 22-Май-21, 16:55	–1 +/–
> переписать самому максимально просто, в результате > Какая-нибудь простейшая библиотечка может содержать 50 файлов с разными классами из пяти строчек, часть из которых НЕЯВНО (автозагрузка, фиг ли) ссылается на половину оставшихся. Ох уж эти переписыватели.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #117

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

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

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

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ообщить модератору
Родитель: #115 Ответы: #119

119. Сообщение от Ordu (ok), 22-Май-21, 21:43	–1 +/–
> В случае васян-библиотеки или просто соседнего индуса (не путать с национальностью) я > бы не был так уверен и налепил assert'ов (exception'ов) и прочих > аналогов в критичных местах. assert'ы должны быть внутри васян-библиотеки в виде тестов. Так что лучше лепить их не в свой код, а непосредственно в код васян-библиотеки тестами, и отправлять их ему патчами. Глядишь он меньшим васяном станет, а то и вообще имя сменит. Не все инварианты ты сможешь проверить assert'ами: как ты проверишь валидность указателя? Как ты проверишь размер выделенного куска памяти по адресу лежащему в указателе? И как часто проверять? Каждый раз, когда ты решил поработать с динамическим массивом? Или после каждого вызова каждого метода? Инварианты придумали как раз для того, чтобы разделить ответственность -- ответственность за поддержание инвариантов динамического массива лежит на разработчике динамического массива, если он с этой ответственностью не справляется, ищи другого разработчика. > Потому что завтра эта уверенность вылетит в трубу^Wуязвимость. Если тесты включены в код библиотеки, то, чтобы уверенность восстановить, можно прогнать юнит-тесты после обновления библиотеки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #118

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

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

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

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

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

125. Сообщение от Аноним (124), 23-Май-21, 09:34	+/–
> А действительно живое -- оно простое и красивое, и остаётся таковым. Но ты может и простой, но совсем не красивый.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110

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

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

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

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

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

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