私はSenchaのProfessional Servicesチームのメンバーとして、ほとんどの時間は直接大企業のお客様とやりとりしています。 我々のチームは様々な 専門的なサービス を提供していますので、 多くの場合は何週間も開発者のグループと一緒に働いて、 彼らがSencha製品を利用した素晴らしいアプリケーションの開発、ビルド、デプロイするのをアシストしています。

最近我々の一つの企業クライアントと一緒に仕事をするチャンスがあって、彼らの組織内でのSenchaの利用法を定義するお手伝をしました。 いくつかのレッスンやエンタープライズアーキテクチャのハイレベルなコンセプトを紹介したいと思います。

企業とともに働く

エンタープライズレベルで働くことは、良いこともありますし非常に欲求不満がたまることもあります。 とても挑戦的なアプリケーションを開発できる一方、エンタープライズのアプリケーションではよくレガシーブラウザーをターゲットにしているので、最先端のテクノロジーが利用できません。

とは言うものの、多くのエンタープライズのクライアントは徐々に開発戦略とITインフラを考え直し始めています：ワークステーションはWindowsの最新バージョンにアップデートされて、社員がもう少し自由にWebブラウザーを選べるようになりました。時としてIE6とIE7のサポートが完全に終了されている場合もあります！

もっと重要なことは、企業は開発プラットフォームを標準化して色々な開発者がメンテナンスできるアプリケーションのエコシステムを生成していることに気づきました。 Senchaのツールとフレームワークはこのエコシステムの開発プラットフォームにふさわしいものになってきたので、Professional Servicesチームはクライアントの内部ポリシー・研修手順・新しい標準へ移行するためのベストプラクティスを定義するサポートをしています。

なぜ開発基準が重要なのか

コンサルタントとして、私は常に保守性が高いコードの利点を説いています。

• アプリケーションがより速く開発できる
• アプリケーションがより簡単にデバッグできる
• 新しい機能が追加しやすい
• コードのバグがより少なくなる
• 新しい開発者もより速く修得できる

「時は金なり」という言葉が示すとおり、開発と保守にかかる時間が短いアプリケーションはその分コストがかかりません。 最終的にマネージャーも上層部も投資者も喜ぶことになります。 企業は同時に（内部と外部で）アプリケーション開発に関わっているため、予算内で時間通りにプロジェクトを終わらせるためにには、開発チームの誰もがどのプロジェクトにでも飛び込めるような環境にすることがとても重要です。

企業の開発チームは広い範囲に分散する様々なスキルを持つ大勢の開発者を雇用しています。 トレーニング・ツール・ベストプラクティスを標準化することによって、企業はアプリケーションの品質やライフスパンを高めつつ開発時間とコストを削減することを期待しています。

標準プラットフォームとしてのSencha

企業がSenchaのツールやフレームワークをアプリケーション開発の標準として決める場合によくあるのは、それはその企業の内外のアプリケーションに統一性が欲しいと言う場合です。 この統一性はUI（スタイル・ウィジェット・機能性）と基盤のコード（アーキテクチャ・ライブラリ・ベストプラクティス）の両方の意味です。

Senchaのツールやフレームワークを利用している各会社は開発チームのためにリソースとベストプラクティスの集中リポジトリを作ることを検討すべきです。 会社によってこのリソースの具体的な部分は異なるかもしれませんが、 開発者が開発を始めたりプロジェクト全体の統一性を保つために、フォローする範囲は明確にドキュメント化されるべきです。

開発者の新人研修とトレーニング

自分が企業で働いた経験から言うと、自分のパソコンに必要なツールをインストールするのが難しい場合があります。

ほとんどの企業のITインフラは高度に定義されているため、新しい開発者は全てのハードウェアとソフトウェアが認可されるまで待たされることになります。 この処理には何日間もかかることがあり、その後も開発者は追加のリソースをどうやって頼めば良いわからないままです。 要するに、新しい開発者は明確な新人教育のロードマップへのアクセスが不足しているのです。

Senchaのお客様にはこのプロセスをよりスムーズにするためにいくつかの新人教育手順を明確にドキュメント化することを提案しています：

• 必要な開発ツール
• ネットワーク証明をリクエストするプロセス
• 標準の開発ワークフロー
• Senchaのフォーラムやサポートポータルへのアクセス方法
• どのSenchaトレーニングを推奨・提供しているか

開発者は頻繁にこの情報を必要とするわけではありませんが、 重要なポイントは、この情報へのアクセス方法を知る必要があるということです。

サポートするプラットフォーム

企業で働く一つの利点は、開発者は通常サポート対象とする環境の細かな仕様がわかっているということですが、これまでこの環境はWebアプリケーションにとってはとてもやっかいでした。

企業がハードウェアとソフトウェアのアップデートを進めるので、開発者がサポートする環境のリストをしっかりとドキュメント化することが重要です。そこには次のようなものが含まれるでしょう：

• ブラウザ（例えばIE8、Firefox）
• OS (例えばWindows XP, 7)
• デバイス（例えばLenovo ThinkPad）

新しいプロジェクトを始める（あるいは過去のアプリケーションを保守する）前にこの知識が明確であったら、出荷する製品の精度も向上できるようになります。 また開発者がテスト用に新しいハードウェアやソフトウェアをリクエストする時間がつくれます。

“ 時としてIE6とIE7のサポートが完全に終了されている場合もあります！

一方この知識で潜在的な弱点を見つける事もできます。 例えば最新のFirefoxのバージョンは自動的にアートアップデートできるし多様なモダンWeb標準をサポートしていますが、IE8はしません。 その影響を理解している開発者は、サポートするプラットフォーム定義と衝突する可能性がある開発方法を避けることができます。

開発プロセスに利用されているプラットフォームや具体的な製品をドキュメント化することも重要です。このリストには次のようなものが含まれるでしょう：

• フレームワーク　（例：Ext JS 4.1.x、ASP.NET MVC 4）
• サードパーティのライブラリやコンポーネント（例：他のチャートパッケージ）
• サポートする技術（例SASS）
• 回避策（例：JSONPを利用する）

この補足リストは、どんな製品やプラットフォームが開発者に必要かという定義に役立つだけでなく、従業員の技能修得やトレーニングに必要なスキルを定義することもできます。

内部のベストプラクティス

開発チームはベストプラクティスも決めるべきです。そうすれば開発者全員が保守性を失わずにコードを提供できます。

ベストプラクティスのリストは短くハイレベルなものでも、長く細かいものでも良いです；この選択はあなたの開発チームの大きさや開発者の役割の整理のされ方によります。

例えば ハイレベルなベストプラクティス には次のようなものが含まれます：

• 全体のアーキテクチャの策定（例：名前空間・ファイル構造）
• セキュリティの実装
• エラーハンドリング
• 共有ライブラリやカスタムコンポーネント（UX）
• ドキュメント
• テスト・ビルド・デプロイ

…また 低レベルのベストプラクティス には次のようなものが含まれます：

• 空白の使い方
• コミットのやり方
• コンソール使い方
• ブラウザーはStrictモードかQuirksモードか

私の経験で言うと、強制的なコードレビューがないと低レベルのベストプラクティスを実現するのは難しいと思います。 コードレビューは新人の開発者に教えたり、コードの質を保守したり、創造性を刺激したりすることに対して素晴らしいやり方ですが、通常は企業では行っていません。

いかがですか？

この記事は大きな組織で開発標準を実施するアイデアにハイライトしていますが、完璧なプランではありません。 Sencha Professional Services チームはハイレベルなアーキテクチャのレビュー、アプリケーションのパフォーマンスの細かな分析、カスタムなUX開発と関連することなど様々なサービスを提供しています。 また、お客様のそれぞれの特定の需要に合わせた契約にすることができます。 ここで述べたコンセプトは始めやすく、どの企業にでも簡単に対応できるはずです。

もしあなたの会社で開発標準を実施したら、その経験などを紹介してください！