web-dev-qa-db-ja.com

大規模なPHPプロジェクトの書き換えを計画するためのヒント?

私は何年にもわたって取り組んできたPHPフレームワーク(MVCを使用))を完全に書き直すことにしました。アイデアを付けて、チケットとしてTracに投入し、後で追加します。フレームワーク自体の設計について心配する必要はありません。これにより、問題が発生し、書き換えが役立つと思いますが、どこから始めればよいかわかりません。 Tracを使いたくないことはわかっています。チケットとマイルストーンだけでなく、他に何が必要ですか?

この書き直しを徹底的に計画したいのですが、必要なすべての機能、それがどこに行くのか、そしてそれが他のすべての部分にどのように接続するのかを詳しく説明したいのですが、このレベルの計画の経験はありません。何かアドバイス?役立つプログラムはありますか? Tracに飽きてきました。本当に気に入りませんでした。

設計ドキュメントが必要になることはわかっていますが、従わなければならない特定のレイアウトはありますか?バグ追跡、チケット、マイルストーンなども必要になりますが、Trac以外では何が良いのかわかりません。まだまだ必要なことはあると思いますが、何なのかわかりませんので、よろしくお願いします。

13
Jon

大きなプロジェクトを開発するときに私が行ういくつかのことを以下に示します。

1-OpenProjなどの計画ツールを使用して、タスクとして含めたいすべての機能を追加します。たとえば、現在、ユーザーがサイトに登録した後、ユーザーが自動的にログオンできるようにする機能に取り組んでいます。 「feature-autologin」のようなタスクが計画にあります。

2-私は1人で開発を行っているため、通常は機能を切り替えます。私の計画は、すべての機能がシーケンシャルになるように作成されています。各機能に必要な時間を見積もるのにあまり時間をかけません。私は通常、一人一人が成長するのに一日かかると思います。それ以上かかる場合は、計画を更新するだけで、今後のすべてのタスクがそれに応じて移動します。

3-私はgitを多用しています。各機能はブランチです。各機能を完了したら、それを開発ブランチにマージして戻し、次の機能の新しいブランチを作成します。

4-ソフトウェアのバグを見つけたら、小さなgitブランチを作成して修正し、解決したらマージして戻します。開発ブランチと現在作業中の機能ブランチの両方を確実に更新します。ちなみに、バグは私のOpenProj計画の別のタスクになります。 「バグ-間違ったアドレス」のようなもの。そして、それを挿入すると、他のすべての機能がタイムラインに戻ります。

5-開発中、新しい機能について考える場合は、それを計画に含めて、それが最適であり、タイムラインを再度調整すると思います。

これがお役に立てば幸いです。あなたの前には刺激的なプロジェクトがあるようですね。幸運を!

7
jdias

代わりに大幅にリファクタリングすることをお勧めします

ここで予想される問題:

この書き直しを徹底的に計画したいのですが、必要なすべての機能、それがどこに行くのか、そしてそれが他のすべての部分にどのようにつながるのかを詳しく説明したいのですが、このレベルの計画の経験はありません。何かアドバイス?役立つプログラムはありますか? Tracに飽きてきました。本当に気に入りませんでした。

本当に難しいものです。それは基本的に Waterfallモデル であり、すべての醜さを伴います。ここにいくつかの anecdotical証拠 「大規模な書き直し」アプローチの問題があり、結論に達します。おそらく問題を正しく予測できず、最初から書き直したい別の混乱に終わるでしょう。あなたが悪いからではなく、一発で大きなものを正しく得ることが不可能だからです。

代わりにリファクタリングを開始すると、個々のチケットを書き込むことができ、プロジェクトを引き続き使用できます。ここでの秘訣は、全体的に優れた設計につながる小さな変更を特定することです。

たとえば、MVCはありませんが、したいということです。最初のステップとして、単一のPHPファイルを取得し、通常の取り違えを想定してそれを並べ替え、上部にすべてのdb-access、計算などがあり、下部に「テンプレート」があるようにします(各ファイルの最初のチケット)。 2番目のステップとして、これらすべてのテンプレートパーツを関数にカプセル化して、パラメーターを渡すことができます。 (もっとたくさんのチケット)。できた?おめでとうございます。MVCでVを完成させました。

10
keppla

完全に書き直す場合は、phpを使用する必要があるかどうかも検討してください。テクノロジーの変更/アップグレードは、設計/スケーラビリティ/保守性などを改善したい触媒になるかもしれません...

10
NWS

既存のフレームワークの使用を検討してください。 CakePHP、Zend Framework、CodeIgniter、Symfonyは、PHPで知られているものです。彼らが数百人または数千人のユーザーのニーズに応えるのであれば、きっとあなたのニーズに応えることができるでしょう。

PHP-Django(Python)and Rails(Ruby)以外の何かを学び/使用したい場合従来のWebアプリケーションのほとんどの主要なフレームワークです。

もちろん、これは経験が必要でない限りcreatingフレームワーク-これは、私が追加するかもしれませんが、(既存のサポートされているフレームワークの使い方をよく知っているのではなく)市場での価値ははるかに低くなります。

3
Yam Marcovic

私が使うのが好きなのは Redmine をスケジュールトラッカーとして使うことです。 ITはこれらの各項目を非常にうまく処理し、tracよりもはるかにユーザーフレンドリー(私の意見では)です。

書き直しに関しては、最初に、登場する可能性のあるすべての機能や新しい拡張機能を予期しないことを理解し、できるだけ柔軟にアプリケーションを記述してみてください。 PHPにある多くのMVCフレームワークを使用すると、これを活用できますが、DBアーキテクチャが最初から柔軟でない場合、これらのフレームワークの一部はPidginに穴を開けます(Cake)。できる限り抽象化することに焦点を当て、ハードコーディングされたものを見るときはいつでも、それが何のためであり、なぜそれをDBに格納できないのかを自問してください。

本当にDBの設計は、非常に多くの質問と問題への回答に役立ち、アプリケーションがどのように相互作用するかについての主な重要性を私が見るところです。したがって、データの格納方法とDBの構造を分析するために、大部分の時間を費やすことをお勧めします。

1
Petrogad