Есть ли негативные побочные эффекты от разделения больших модулей? [закрыто]

Я просматривал проект GitHub и нашел этот модуль, который имеет более 10 тысяч строк.

Является ли обычной практикой иметь столько кода в одном модуле?

Мне кажется, что это должно быть разделено на несколько модулей. Может быть один для каждого двигателя дб.

Какую выгоду получает разработчик от создания такого огромного модуля, как этот (кроме «все в одном месте»), или какой минус от его разделения (кроме «сложности»)?

Вы столкнулись с так называемым « объектом Бога », потому что он делает все или знает все. Убегайте от него (если сможете).

Для каждого модуля не существует определенного числа LOC, но это должно быть то, что облегчает просмотр кода и позволяет легко понять, что делают методы. Исходя из моего личного опыта, если ваш модуль выходит за рамки 1 КБ ^* , вы делаете что-то не так.

^{* Даже линейный модуль 1 КБ очень большой.}

Похоже, это модуль, где типичные ограничения по размеру могут не применяться. Большая часть функциональности находится в первых 2 тысячах строк кода и комментариев. Остальная часть файла, по-видимому, содержит множество классов адаптеров и других классов поддержки, которые, по-видимому, тесно связаны с модулем. На других языках классы будут в отдельных файлах разумного размера.

Еще несколько строк документации могут быть полезны, но они увеличат размер и без того большого модуля. Код ясен и понятен с соответствующими комментариями, где это необходимо.

Конечно, фактический «предел» зависит от вашего проекта и множества факторов.

Но я согласен с эмпирическим правилом: 200 строк приличного Python. То есть, нет кода C или Java, написанного на Python, но хороший Python на Python.

Вау.

Думаю, я не знаю полного ответа на этот вопрос, но мне нравится думать как ответ на заглавный вопрос "Насколько большим должен быть модуль Python?" как понятие парны, скрывающее секрет. В этом случае модуль, кажется, делает это правильно (и это такой большой секрет, который он скрывает).

Позже я копался в бумагах, в которых много говорится о связях и сплоченности. Может быть, наличие большого количества модулей БД вызовет слишком много вызовов между модулями, что приведет к увеличению того, что считается плохой практикой, то есть к снижению когезии и повышению связи?

Я видел экспериментальные данные, говорящие о том, что программисты решили пожертвовать хорошей практикой ради простоты и понимания, несмотря на то, что диктует хорошая практика. На самом деле, между хорошей практикой также может возникнуть конфликт. Скажем, производительность обычно не делает людей, которые занимаются техническим обслуживанием, счастливыми позже. Я не совсем уверен, как будет улучшена разборчивость в этом случае с таким большим модулем.

Еще одна вещь, которую я заметил, заключается в том, что часть кода указана как общая, а остальные базы данных расширены. Я не программист на Python, но, возможно, это могло бы чем-то оправдать?

Итак, у меня нет окончательного ответа, но я надеюсь, что кто-то также выделит эти моменты!