Весь код в одном файле
После запроса организация моего проекта Python, а затем вызов из родительского файла в Python мне пришло в голову, что будет намного проще поместить весь мой код в один файл (данные будут считываться извне).
Я всегда думал, что это плохая организация проекта, но, похоже, это самый простой способ справиться с проблемами, с которыми, как мне кажется, я столкнусь. Я просто ошибся с подсчетом файлов или не видел какого-нибудь отличного руководства по большим (для меня) проектам?
Да, поэтому мне приходит в голову, что это может быть работоспособная идея. Если бы был еще один человек, я бы не рассматривал этот вариант.
Ответы 6
Если вы планируете использовать какой-либо SCM, тогда вам будет плохо. Наличие одного файла - это гарантированный способ столкнуться с множеством коллизий и слияний, с которыми со временем будет сложно справиться.
Придерживайтесь соглашений и разбивайте файлы на части. Если не более чем спасти парня, которому однажды придется поддерживать ваш код ...
+1 - Я согласен с точкой зрения СКМ. Это компромисс или долгосрочные инвестиции. Программные проекты - это не наследие одного программиста. Используйте ярлык сейчас, и вам придется заплатить позже. Так что лучше сейчас прими трудное решение и немного боли. В любом случае, это добавление к вашим навыкам организации кода.
Гм, любой приличный SCM должен быть в состоянии комфортно обрабатывать изменения в одном и том же файле, особенно когда есть только человек, который собирается его редактировать. Даже самый старый из известных мне - RCS - хорошо работает с одним файлом.
"есть только человек, который будет редактировать это", будет ли это так в будущем? Разве это не внушительное предположение? если это не проект колледжа, который закончится после подачи.
Это хобби-проект, я не думаю, что в нем когда-либо будет задействовано более одного человека.
нет, Godfile ужасен по многим причинам, SCM большой, и хобби-проекты не оправдывают этого - не практикуйте вредные привычки только потому, что они удобны
Если ваш код в любом случае будет работать вместе и по отдельности бесполезен, нет ничего плохого в том, чтобы хранить все в одном файле. Я могу вспомнить хотя бы популярный пакет (BeautifulSoup), который это делает. Конечно упрощает установку.
Конечно, если в будущем вам покажется, что вы могли бы использовать часть своего кода в другом проекте, или если обслуживание начинает быть проблемой, тогда беспокойтесь об организации вашего проекта по-другому.
Из вопросов, которые вы задаете в последнее время, мне кажется, что вы беспокоитесь обо всем этом немного преждевременно. Часто для меня такие проблемы лучше решать немного позже. Моя цель, особенно для небольших проектов, - получить правильное решение с оптимальным тогда.
Я подхожу к завершению проекта, который весит 11 тыс. Строк кода и был таким легким только потому, что я с самого начала очень хорошо его организовал. Это было на PHP, я подумал, что должен сделать то же самое здесь, чтобы облегчить задачу :)
Emerge, основная программа диспетчера пакетов Gentoo Linux, представляет собой один файл, состоящий из ~ 7000 строк кода Python.
Это всегда споры сейчас, стихи, потом. Если вы находитесь под прицелом, чтобы сделать это, сделайте это. Управление исходным кодом станет проблемой позже, так как на многие вещи нет черно-белого ответа. Вы должны нести ответственность как за срок, так и за долгосрочное обслуживание кода.
Хорошая сводная фраза! Практики, которые упрощают быстрое выполнение первого реза, часто не обеспечивают долгосрочное обслуживание и возможность повторного использования.
Если это лучший способ организовать это, возможно, вы делаете что-то не так.
Если это больше, чем просто игрушечная программа или простой скрипт, вам следует разбить его на отдельные файлы и т. д. Это единственный разумный способ сделать это. Когда ваш проект станет настолько большим, что вам понадобится помощь кого-то другого, SCM станет намного проще.
Кроме того, рано или поздно вам понадобится добавить в проект отдельную утилиту, для которой потребуется общий код / структуры. Это намного проще сделать, если у вас есть отдельные исходные файлы, чем если бы у вас был только один большой.
Поскольку Вызов из родительского файла в Python указывает на серьезные проблемы дизайна, я бы сказал, что у вас есть два варианта.
Если у модуля библиотеки нет, попробуйте вызвать обратно в main. Чтобы это исправить, вам придется что-то переписать.
[Импортированный компонент, вызывающий основную программу, является неправильной зависимостью. И Python не поддерживает его, потому что это плохой дизайн.]
Поместите все это в один файл, пока не найдете лучший дизайн с правильными односторонними зависимостями. Затем вам придется переписать его, чтобы исправить проблемы с зависимостями.
Модуль (отдельный файл) должен быть логическим фрагментом связанного кода. Не все. Ни одного определения класса. Есть золотая середина в модульности.
Кроме того, должен существовать правильный односторонний граф зависимостей от основной программы к компонентам (которые НЕ зависят от основной программы), библиотекам утилит и прочим (которые не знают о компонентах ИЛИ основной программе.
Круговые (или взаимные) зависимости часто указывают на проблему дизайна. Обратные вызовы - это один из способов решения проблемы. Другой способ - разложить круговые элементы, чтобы получить правильный односторонний граф.
Глядя на ваши предыдущие вопросы, я бы сказал весь код в одном файле будет хорошим промежуточным состоянием на пути к полный рефакторинг вашего проекта. Для этого вам понадобится набор регрессионных тестов, чтобы убедиться, что вы не сломаете проект во время его рефакторинга.
Как только весь ваш код находится в одном файле, я предлагаю повторить следующее:
Определите небольшую группу взаимозависимых классов.
Выделите эти классы в отдельный файл.
Добавить модульные тесты для нового отдельного файла.
Повторно протестируйте весь проект.
В зависимости от размера вашего проекта, это не должно занимать слишком много итераций для вас, чтобы достичь чего-то разумного.
Вы единственный человек, который будет работать над кодом одновременно?