枠組み
「エレメンタリーから始めましょう」と書きたいと思ったのですが、すでに誰かが始めたプロジェクトを受け入れたときに、フレームワークを数回見たことがわかりました。 前任者には運がありません。ほとんどのプログラマーはフレームワークを使用しないようにしています。 「フレームワークはラマー向けで、すべてを手で書きます。」という声明も聞きました。 フレームワークを使用する理由は少なくとも2つあります。
- アプリケーションフレームワークと、生活を楽にして時間を節約するライブラリがたくさんあります。
- 遅かれ早かれ、新しいプログラマーがチームに現れ、アプリケーションがどのように機能するかを既に知っていれば、プロジェクトにもっと早く参加できるようになります。 極端な場合、それはあなたを苦しめることはありませんが、フレームワークの文書化は、あなたの時間を節約します。
個人的には、Zend FrameworkまたはCodeIgniterの2つのフレームワークのいずれかを常に使用していますが、これは好みと個人的な好みの問題です。 これらのフレームワークによると、CIはリソースの点でははるかに簡単であり、学習の点ではZFよりも簡単ですが、ZFはより多くの機能を提供します。 フレームワークを使用したことがなく、MVCが何であるかわからない場合は、CIから始めてください。
まあ、少しボーナス 。 ご存じのとおり、ZFの最も重要な欠点は、強力なリソース要件です。 重いZend、それは本当です。 そして、中国の同僚たちに、Zend Frameworkを... Cで書くようになりました。 そして、彼らはそれをやった、Yaf、またはYet Another Frameworkと呼ばれる。 これは、CでYafによって作成され、モジュールとしてApacheに接続します。 もちろん、ZFのすべての機能が含まれているわけではありませんが、そこには、中国語のドキュメントがありません。さらに、英語のドキュメントはほとんどありません。ロシア語のドキュメントはありません。 確かに、多くのクラスはZFでよく知られていますが、多くのクラスは異なっており、入力するか、Cソースを掘り下げて調べます。 確かに、Yafは非常に高速ですが、開発プロセス中に緊張します。 一般的に、耐えられないほど退屈し、chtoliを運転したい場合にのみアドバイスします。
CodeIgniterに関するロシア語のドキュメントはこちら：
http://code-igniter.ru/
またはここ：
http://cidocs.ru/210/index.html
そしてもちろん、公式ウェブサイトのオリジナル：
http://codeigniter.com/user_guide/
Zend Frameworkについては、ここで英語で読むことができます：
http://framework.zend.com/docs/overview
ロシア語はこちら：
http://framework.zend.com/manual/en /
そして、確かに、あなたはそれに最も近い本屋でそれに関する2、3の本を見つけるでしょう。
Yafのドキュメントはここで読むことができます：
http://www.php.net/manual/en/book.yaf.php
そしてここに：
http://www.php.ru/manual/book.yaf.htm l
そして、ここの中国の愛好家のために：
http://yaf.laruence.com/manual/
バージョン管理システム
「VCS」、「バージョン管理システム」、「リポジトリ」、「SVN」、「Git」、および「このゴミはプログラムのメインコピーが保存される場所」とも呼ばれます。 バージョン管理システムは多数ありますが、私の考えでは、主なプレーヤーはSubversion（SVN）とGitです。 何を選択しますか？ 私はGitを使用していますが、正直なところ、SVNはすべての点で私に適しています。 両方のシステムの支持者間の聖戦で多くの血が流されたので、選択はあなた次第です。 ネット上の記事を読んで、両方のシステムを試してください。幸いなことに、それは非常に簡単です。 リポジトリへのアクセスを提供する多くのオンラインサービスがあります。 多くの場合、異なるVCSを切り替えることができます。 個人的には、最近得られたGitHubの非現実的な人気を使用しています 。 Googleサービスのファンには、 Googleコードがあり、かつては非常に人気がありましたが、今では完全に散らかっていて、 sourceforgeをわずかに抑制しています。
ただし、ほとんどのサービスは公開リポジトリによってのみ無料で提供されることを覚えておく価値があります。 オープンソースプロジェクトを開発している場合、これは良いことです。 商業プロジェクトの場合、コードを輝かせたくない場合は、拒否を支払う必要があります。
それでも、非常に重要なニュアンス。 神のために、config.phpをデータベースに実際にアクセスできるパブリックリポジトリにコミットしないでください！ 面白いと思う？ 私はそのような人々に会った...
VCSを使用するには、コンソールコマンドが最もよく使用されます（私の選択）。GUIクライアントまたは一般的なIDEのプラグインもあります。
コードの特定のホスティングの選択を決定するには、 Linux Formatの5月号の 「Comparison：Project Hosting」という優れた記事を読んでください。
Gitの非常に視覚的なガイド
http://rogerdudler.github.com/git-guide/
2つのすばらしいgit記事
http://habrahabr.ru/post/60030/
http://habrahabr.ru/post/60347/
まあ、github.com自体で、ドキュメントはかなりよく説明しています
https://help.github.com/
データベースの移行
ああ、だれがdump.sqlファイルがどれほど厄介なのか知っているだけです！ プロジェクトファイルのバージョン管理システムが、少なくとも開発者の間で定着し始めている場合、データベースのバージョン管理システムは非常にまれです（Ruby on Railsをカウントしません）。
実際、複数の人がプロジェクトで作業している場合、データベース構造を変更することは非常に困難です。通常、それらは特別なファイルに書き込まれ、メールで各チームメンバーに送信されます。データベースの1つまたは別の部分の「悪意のある」組織のために、どの開発者が手を引き離すべきかわかりません。 開発者の1人がデータベース構造をローカルで（たとえば、phpmyadminを介して）変更し、チームの他のメンバーにこのことを伝えるのを忘れたときの状況については話していません。 一般的に、このアプローチにはあまりにも多くのボトルネックがあり、遅かれ早かれ、別の解決策があるはずだと私は考えていなかっただろう。 そして確かにそうです。
移行を使用して得られるもの：
- データベースへの変更は、sqlコマンドを含むファイルの形式で表示されます。つまり、変更をVCSに直接コミットできます（メールでgoodbye dump.sql）。
- データベースの現在のバージョンが表示され、他のバージョンにロールバックできます。
- 誰がいつ変更したかがわかります。
- 競合状況は除外されます。 競合が見つかった場合、システムは移行を許可しません。
まあ、など これらのプラスは、移行システムについて真剣に考える価値があります。 CodeIgniterには、このための特別なクラスがあります。ZendFrameworkには、残念ながら、この種のものはありませんが、たとえば、私は独自の小さなシステムを作成しました（原則として、1日に最大の作業があります）。 また、移行はdoctrineでよく表されており、ZFと組み合わせたときによく使用します 。もちろん、 サードパーティのモジュールもあります 。
上記のリンクに加えて、優れた記事「 データベースバージョン管理 」も読むことができます。
PS
さて、結論として、この記事を読み直したとき、それは多少しわくちゃになったことがわかったのですが、フレームワークを使用してプログラミングする方法を教えようとはしませんでした。VCSでコミットを教えようとはしませんでした。 これらの技術について話し、それらを示し、何を読むべきかをアドバイスしたかっただけです。