Анализируем размер проекта⁠⁠

Понятность во главе угла, конечно. Я не про хаки уровня 0x5F3759DF в quake III, а про способность разработчика за счёт более удачной абстракции писать меньше кода. Код при этом должен оставаться понятным и поддерживаемым

О, спасибо за развёрнутый ответ

1. Про логарифм - интересная идея. Но я бы лучше смотрел на диапазоны, это проще и понятнее. Типа до 1к, 1-10к, 10-100к. Блин, вот он и логарифм) но звучит проще всё же. Занятно, кстати, что студенты очень сильно не понимают про проектную работу в целом. Интересно, где-нибудь учат программированию через относительно большие проекты?

2. Предлагаю смотреть на динамику. Деление по языкам в целом нужно для фана. Дальше смотрим либо на общую сумму, либо на нужных язык (условно, трекаем python только). Что смотрим? На прогресс. В январе было 15к, в феврале 16к, в марте 17к, а в апреле снова 17к. Почему? В чём причина?

3. Про размер проекта в контексте команды совершенно согласен. Если на 50к строк у вас один Вася - быть беде)

4. С последним тейком про оценку производительности не соглашусь. Самое полезное - удалять код. Второе по полезности - реализовать фичу за меньшее количество кода, чем коллега. Для оценки разработчика я бы смотрел на связку закрытых задач и изменений кода (см. удаления и добавления в гите). Код же не самоцель, а то будем поэмы в комментариях писать, как индусы в своё время, когда их оценивали по строчкам кода. Или как Маяковский писать)

Основная часть - это бэк на питоне (FastAPI). Плюс есть небольшой фронт (html на jinja2), который выдан "как есть" и его можно расширять. Кто хочет - делает отдельный фронт для красоты. Есть кусочек bash для демонстрации отдельного контейнера с заполнением базы. В этом году экспериментировали с интеграцией java-приложения готового, разработанного на другом курсе. Понятно, что ещё compose. Итого должны быть python, html, yaml, css, javascript, bourne shell, dockerfile, markdown. Остальное - какие-то вспомогательные мелочи. А, ini, наверное, для alembic миграций

И для поставленного через apt это очень критично. А для запущенного докер контейнера - поверхность атаки только в выдаваемом конкретном каталоге, что не очень критично. Точнее менее критично, чем доступ к хосту

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

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

Интереса ради посмотрел, как у моих студентов. По-моему, достойный проект на выходе командной работы из 4 человек. Мне кажется, что у меня диплом примерно такой был по размеру)

Собственно, где та грань? Вон у django больше 1кк строк)

А в чём проблема? Докер как раз тем и славен, что меня могут атаковать в пределах выданных данных, в данном случае - каталога с проектом. То есть его могут удалить или отправить кому-то. Удаление меня на смущает - всё в локальном гитлабе. Отправить кому-то? Ну, если паранойя, запускайте на машине с выключенной сетью)

Установленный софт, даже прошедший через модерацию ОС, гарантий также не даёт. Забыл, как назвали практику, когда софт смотрит ip или локаль, и если из РФ, то начинает делать плохие вещи. Только уже с доступом ко всему хосту без ограничений

Можно и так. Но я не люблю на хост систему тянуть что попало. Зачем, если есть докер?

К тому же сам автор пишет

Note: I don't control any of these packages. If you encounter a bug in cloc using one of the above packages, try with cloc pulled from the latest stable release here on GitHub (link follows below) before submitting a problem report.

Конечно, что в реальности мне прям важна последняя версия этой вспомогательной тулзы

Вроде никто в строках стоимость не считает. Или у вас есть опыт?

Более того, строчки уже есть, то есть нельзя заранее оценить стоимость разработки. Если речь именно про стоимость готового продукта, то тут тоже из строчек кода непонятно, как сделать вывод. Я в институте ещё с помощью модели COCOMO2 считал стоимость разработки notepad++ и word. Получившиеся цифры оказались близки, что явно противоречит здравому смыслу. Либо COCOMO бестолковая, либо я неверно применил методологию

Глобально, никак. Просто красивое

Если чуть больше подумать, можно чуть повысить управляемость. В плане, если у вас 100кк строк кода, а занимается этим один Вася, то вас ждут проблемы. Плюс при возникновении идей "давайте всё перепишем" очень легко проиллюстрировать, почему так делать не надо, и не стать очередным умершим Netscape navigator

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