Поради щодо планування переписування великого проекту 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). Я б дійсно зосередився на тому, щоб зробити речі настільки абстрактними, наскільки ви можете, і кожного разу, коли ви побачите щось важко закодоване, запитайте себе, для чого це потрібно, і чому його не можна зберігати в БД.

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

Як програмне забезпечення для відстеження проблем, JIRA - це чудово, але це дуже дорого. Ще одним хорошим інструментом, який я використовую, є Eventum. Це безкоштовно.

Але найважливіша частина - це добре уявити, що вам потрібно. Спочатку ви повинні зібрати вимоги до своєї заявки, щоб мати загальне відчуття того, чого ви хочете і якнайповніше.

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

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

Сподіваюся, це допомагає