Советы по планированию переписывания большого проекта PHP?

Я решил полностью переписать PHP-фреймворк (с использованием MVC), над которым я работал много лет. До сих пор моя проблема заключалась в том, что я просто придумывал идеи, добавлял их в Trac как билеты и добавлял их позже - не беспокоясь о дизайне самой платформы. Со временем это вызвало некоторые проблемы, и я думаю, что переписывание было бы полезно, однако я не уверен, с чего начать с его планирования - я знаю, что не хочу использовать Trac, и я знаю, что мне нужно больше, чем просто билеты и вехи - но что еще мне нужно?

Я действительно хочу тщательно спланировать это переписывание, я хочу детализировать каждую функцию, которую я хочу, куда она пойдет и как она будет соединяться с любой другой частью - но у меня нет опыта с этим уровнем планирования. Любой совет? Какие программы помогут? Я устал от Трэка, мне это никогда не нравилось.

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

Ниже приведены некоторые вещи, которые я делаю при разработке большого проекта:

1 - Я использую инструмент планирования, такой как OpenProj, и добавляю все функции, которые я хочу включить в качестве задачи. Например, сейчас я работаю над функцией, позволяющей моим пользователям автоматически входить в систему после регистрации на моем сайте. У меня в плане есть задача типа «функция-аутологин».

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

3 - Я широко использую Git. Каждая функция - это ветка. После завершения каждой функции я объединяю ее с веткой разработки и создаю новую ветку для следующей функции.

4 - Если я нахожу ошибку в программном обеспечении, я создаю небольшую ветку git, чтобы исправить ее и объединить обратно после ее устранения. Я проверяю, обновляю ли я ветку разработки и мою текущую ветку функций, над которой я работаю. Кстати, ошибка становится еще одной задачей в моем плане OpenProj. Что-то вроде "ошибка-неправильный адрес". И когда я вставляю его, все другие функции возвращаются на временную шкалу.

5 - Пока я занимаюсь разработкой, если я думаю о новой функции, я просто включаю ее в план, где, как мне кажется, она будет наилучшим образом соответствовать и снова корректировать график.

Надеюсь, это поможет. Похоже, у вас впереди захватывающий проект. Удачи!

Если вы собираетесь полностью переписать, почему бы не подумать, стоит ли вообще использовать php? Изменение / модернизация технологии может стать катализатором, который вы хотите улучшить в своем дизайне / масштабируемости / ремонтопригодности и т. Д ...

Я бы предложил вместо этого сильно рефакторинг

Проблема, которую вы ожидаете здесь:

Я действительно хочу тщательно спланировать это переписывание, я хочу детализировать каждую функцию, которую я хочу, куда она пойдет и как она будет соединяться с любой другой частью - но у меня нет опыта с этим уровнем планирования. Любой совет? Какие программы помогут? Я устал от Трэка, мне это никогда не нравилось.

очень сложный В основном это модель Водопада со всем его безобразием. Вот некоторые анекдотические свидетельства о проблемах с подходом «великого переписывания», который приходит к выводу: вы, вероятно, не будете правильно предвидеть проблемы и в итоге получите еще один беспорядок, который хотите переписать с нуля. Не потому, что ты плохой, а потому, что невозможно сделать что-то большое правильно за один выстрел.

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

Например: вы упоминаете, у вас нет MVC, но вы хотите. В качестве первого шага вы можете взять один PHP-файл и, при обычном смешивании, отсортировать его так, чтобы в верхней части у вас был весь db-доступ, вычисления и т. Д., А в нижней части у вас был «шаблонизатор» ( первые билеты, для каждого файла). В качестве второго шага вы можете инкапсулировать все эти шаблонные части в функции, которые передают свои параметры. (много больше билетов). Выполнено? Поздравляю, вы закончили свой V в MVC.

Рассмотрите возможность использования существующего фреймворка. CakePHP, Zend Framework, CodeIgniter и Symfony являются известными для PHP. Если они удовлетворяют потребности сотен или тысяч пользователей, я уверен, что они могут удовлетворить ваши.

Если вы готовы изучать / использовать что-то кроме PHP - Django (Python) и Rails (Ruby) в значительной степени являются ведущими фреймворками для обычных веб-приложений.

Это, конечно, если вам не нужен опыт создания фреймворков, который, я мог бы добавить, имеет гораздо меньшую ценность на рынке (вместо того, чтобы знать, как правильно использовать существующие, поддерживаемые фреймворки).

Что мне нравится, так это Redmine в качестве трекера. ИТ очень хорошо справляется с каждым из этих вопросов, и, на мой взгляд, гораздо более удобен для пользователя, чем trac.

Что касается вашего переписывания, важно сначала понять, что вы никогда не будете предвидеть каждую возможную функцию / новое расширение, поэтому постарайтесь написать свое приложение максимально гибко. Использование многих MVC-фреймворков, которые есть в PHP, может помочь в этом; однако некоторые из этих фреймворков также пробуждают вас, если ваша архитектура БД не является гибкой с самого начала (Cake). Я бы действительно сосредоточился на том, чтобы сделать вещи как можно более абстрактными, и всякий раз, когда вы видите что-то жестко запрограммированное, спросите себя, для чего оно и почему оно не может быть сохранено в БД.

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

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

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

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

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

Надеюсь, это поможет