#php #python #project-management
#php #python #управление проектами
Вопрос:
Я до сих пор не получил ответа, которым я доволен. Пожалуйста, отправьте несколько ответов, если у вас есть хорошая система для ваших проектов на Python или PHP.
У меня возникла проблема с управлением моими проектами на PHP и Python. У них обоих есть два вида файлов кода: файлы, которые должны запускаться в консоли или веб-браузере, и файлы, которые должны быть включены из других файлов для расширения функциональности. После того, как мои проекты вырастают в большие пространства имен или деревья модулей, начинает казаться дезориентирующим, что «исполняемые» файлы и файлы библиотеки лежат бок о бок с одинаковыми расширениями файлов во всех моих папках. Если бы PHP и Python были языками предварительной компиляции, это были бы файлы с main функцией.
Например, представьте, что у меня есть пространство com.mycompany.map.address имен, которое содержит несколько файлов .py или .php в зависимости от проекта. Он будет содержать модели для разных типов адресов и множество функций для работы с адресами. Но, кроме того, он будет содержать некоторые исполняемые файлы, которые запускаются с терминала, предоставляя пользователю инструменты для поиска адресов и, возможно, добавления и удаления адресов из базы данных или тому подобное.
Мне нужен способ отличать такие исполняемые файлы от тонны и тонны файлов кода в моих деревьях имен
Если бы файлы имели отдельные расширения, это не было бы проблемой. Но поскольку они этого не делают, я думаю, мне следует разделить папки или что-то в этом роде, но я не знаю, как их назвать. В PHP я мог бы выполнить хакерское решение по настройке PHP для анализа различных расширений файлов, чтобы мой проект мог содержать phps phpx , например, файлы or .
Если у кого-нибудь есть какие-то независимые от языка советы о том, как справиться с этой проблемой, я был бы признателен. Это также может относиться к таким языкам, как C, где один проект может компилироваться во множество исполняемых файлов. Как следует отделять исходные файлы, содержащие main функции, от остальных?
Комментарии:
1. Обычно я помещаю все свои файлы библиотеки php в
incкаталог, который находится где-то за пределами комнаты документов сайта, и даю имена неисполняемым файламwhatever.inc. Достаточно просто добавить этот каталог в путь включения PHP, а .inc означает, что они не предназначены для прямого запуска (и поскольку они находятся вне корня документа, их также нельзя запускать / просматривать удаленно).2. Будьте осторожны с соглашением об именовании *.inc .. плохо настроенный сервер может просто обслуживать необработанное содержимое файлов. Если вы можете сохранить для них имена * .php, это, как правило, безопаснее с точки зрения утечки информации.
Ответ №1:
Разделите их как-нибудь (по имени, по расширению, по местоположению).
Пример:
Вот макет нашей системы автоматизации тестирования (выходные данные отсортированы вручную для наглядности):
$ ls -1 automation
atf two major homebrew libraries, with many submodules
atflib /
atfconfig configuration files in .py form
configuration configuration files in .ini form
res_manager /
test_scripts - scripts to be invoked directly
Затем мы помещаем automation папку в PYTHONPATH и можем import atf.<smth> где угодно.
Для запуска тестов мы переходим в test_scripts .
Комментарии:
1. Как насчет исполняемых файлов, связанных с конечным продуктом, а не только с тестовыми сценариями?
2. То же самое. Создайте папку, скажем, «bin», и сделайте ее доступной для вашего кода любым разумным способом.
Ответ №2:
Для своих PHP-проектов я придерживаюсь соглашения об именовании в стиле Java (мой опыт):
index.php
/classes/{тип организации: net, org, com}/{название организации}/{компонент}
/includes/ <- общая конфигурация и т. Д.; Все неисполняемые;
/lib/ <- сторонние библиотеки, привязанные к конкретным выпускам; не модифицируются, исправляются / обновляются по мере необходимости;
/modules/ <- место для расширений, написанных в партитуре проекта