だから。 潜在的に高負荷（高負荷）向けに設計された技術的に複雑なプロジェクトに取り組んでいます。 そのため、Bitrixがこれまでに獲得したコンテンツ管理システムの中で勝ちました。 顧客は彼を望んでいます。 私たちの経験から判断すると、Bitrixの高負荷は、すべてを慎重に行うと非常に現実的なタスクです。
通常、多くのフォーム、個人アカウント、または何らかの複雑なロジックがあるプロジェクトで-クライアントにZend FramewokまたはBitrixでの実装の選択肢を提供しました。 ZendFrameworkの欠点は、管理パネルを作成する必要があることです。 Minus Bitrix-複雑なビジネスロジックを備えたプロジェクトにはあまり適合していません。実際にはMVCはなく、コードやAPIを不快にする場所もあります。 D7コアに関するバラライカのマーケティングは、すでに2年前です。考慮していません。
「話は安い。 コードを見せてください」（Linus）
そこで、Bitrix管理パネルからのデータ管理でZendFrameworkを使用するという複雑なプロジェクトのアイデアが生まれました。 Bitrixテンプレート内でViewHelperを使用するか、View内でコンポーネントを呼び出すことができるように、アーキテクチャを実装しました。 典型的なすべてのサイト（製品カタログ、テキストページ、ニュースなど）については、Bitrixが責任を負います。 複雑なフォーム、個人アカウント、プロファイルの場合-Zend。 その結果、高速で非常に柔軟なシステムが得られ、快適なコードを使用して、統合に約3日間を費やしました。
展開：
1.パイロットプロジェクト。 ZendFrameworkでScrumbanを実行することにしました。これは、構造化されたコードを作成したかったためです。 このプロジェクトで、実験の時間があり、統合の主要なポイントを見つけることができました。
- 合同セッション。
- データベースとの共同接続（ハハ、古いBitrixコードはMySQLiの操作方法を知りませんが、古いMySQLドライバーを使用します。ZendFrameworkはこのジャンクをサポートしないため、少しプログラミングしなければなりませんでした）。
- モデルを操作するための情報ブロックに結び付けます。
- ルーティング。
2.最も懐疑的な人の懐疑論を克服する。 既にバンドルの実際のプロトタイプが手元にあるので、コードについて話し合うことができました。 私は会社のある男の激しい抵抗に会いました。 約1時間、彼は実装に障害を発見しました。これは最終的にいくつかの間違いを見つけ、多くの改善を行うのに役立ちました。 その後、評論家には論理的な議論がなかったため、先に進むことができました。
3.パフォーマンス実験。 ZendFrameworkフレームワークをロードすると、かなりのシステム時間がかかるのではないかと本当に恐れていました。 一連の最適化の後、オートロードでのロードを慎重に実行しました。 きれいなbitrixとバンドルの開始の違いは0.033秒でした。これは、適切に構造化されたコードを迅速に開発する能力と比較して1ペニーです。
4.商業プロジェクトのパイロット。 それらの2つがありました。 Bitrixの標準ロジックをZFに書き直そうとすると、どの時点で手を打たなければならないかを明確に理解することができました。
5. cho-kavoの物語との一般会議。 これは定期的に行われ、HolyWarModeOnと呼ばれます。 集まって、議論した。 私は準備が不十分だったので、（興味を除いて）懐疑的な一群を捕まえました。 しかし、すでにいくつかの稼働中のシステムが手元にあり、そのコードは私を満足させました。 彼らのパフォーマンスが好きです。 したがって、私は確信していました：すべてがうまくいくでしょう。
6.根本原因分析。 ZFとの統合が必要な目的を明確に実証するように求められました。 根本原因の分析に約半日を費やし、原因ツリーを使用して半壁の印刷を行いました。 印刷物は数週間公開されました。バナー失明の良い例です。
私が手に入れたかった最も基本的なもの：
- 複雑なプロジェクトのコードの構造化と標準化。 MVC ORM。
- bitrixコプロコードを選択せざるを得ない開発者のモチベーションを高める必要性。
- 共同開発による開発の加速（たとえば、前回のリリース以降にデータベースがどのように変更されたかを確認できる優れたデータベース変更ロガーがあります）。
7. bitrixのクリーンアセンブリを準備します。 有効化されたNFRライセンスで1つのクリーンアセンブリを使用し、ベストプラクティスが統合されています。 原則として、すべての開発者はそこで何かをコミットする可能性があります。 新しいプロジェクトを作成するとき、特別なスクリプトがdevサーバーに新しいリポジトリとデータベースを作成します。 クリーンアセンブリ（trialochka）のコピーが新しいリポジトリに展開されます。
8. ZFのトレーニング。 ZFの知識が純粋にBitrixでサイトをリベットするよりも多くのスキルを必要とすることは秘密ではありません。 いくつかのホリバーを実施し、MVCアーキテクチャを詳細に分解し、基本的な用語を紹介しました。 その後、各開発者はテストタスクとそれを解決する時間を受け取りました。 実際には、コントローラー、フォーム、ヘルパー、バリデーターを感じる必要がありました。 私の意見では、それはドライブだった;）その時までに、すでに80％の開発者がZFの商用プロジェクトに参加していました。
9.私は個人的に正式な試験を実施しました。 しかし、理論の知識ではなく、最後のプロジェクトのコードを開発者と一緒に分析し、フィードバックを提供します。何を引き出すべきか、何が違う方がよいかなどです。 ほぼ1週間かかりました。 試験中だったので、実装が成功したことに気付きました。 懐疑論は完全に消え去りました。 それどころか、自分自身をさらに発展させ、さらに盛り上げたいという気持ちを感じました。
10.定期的なコードレビュープラクティス。 これはかなり難しい練習です。 忍耐と思慮が必要です。 率直なgovnokodや余分なスペースよりも深刻なものを見つけるには、頭を働かせる必要があります。 開発者と協力してコードレビューを実施することが理にかなっている場合があります。 特に、システムのアーキテクチャが重要な場合。 コードレビューは重要な学習プラクティスであると考えています。 プロジェクトの実際のコードを解析すると、開発者のフィードバックが得られます。 そして、私たち全員が、自分が正しく成長しているかどうかを理解することが重要です。
私たちは次の間に良いバランスを見つけたと思います。
- Bitrix Bydcodeを掘り下げて開発者をやる気にさせないでください。
- 高品質のアーキテクチャを作成します。
- CMSとMVCフレームワークを最大限に活用して車輪を再発明しないでください。
- 明確で簡潔で保守可能なコードを使用して、ハイテク製品を顧客に提供します。
もっと楽観的、友達。