言語/フレームワーク/テクノロジーが「将来性がある」かどうかの判断

私はPHP開発者で、最近CodeIgniterを使い始めました。CodeIgniterに関連する何かを検索するときはいつでも、ブログの投稿と通常は'09または'10のものではないので、考えさせられました。それに代わる別のフレームワークはありますか？

他の言語やフレームワークについても同様です。特定の言語またはフレームワークの学習をどの時点で中止しますか？新しく登場し、取り上げる価値のあるものを見つける簡単な方法はありますか？

これは正確な科学ではないので、5年以上前のテクノロジー環境の将来の傾向を確実に予測できるとは期待しないでください。

しかし、私は次のすべてを探します。

• インストールベース - インストールベースが大きくなると、多くの企業がテクノロジーとそのメンテナンスに投資し続けることになります。つまり、テクノロジーを使用するために開発者が必要になります。正のサイクルが続きます。たとえば、以前のCOBOLと同様に、Javaは非常に長い間なくなることはありません。
• 幅広い業界のサポート -テクノロジーを後押ししている有名企業が複数いますか？1つのコミットされたバッカーだけが警告サインです-戦略を1回変更するだけでいつでもドロップまたはサイドライン化される可能性があります。
• オープンソース -主要なオープンソース製品は非常に長期的な賭けであることが証明されています（たとえば、Linux、Apache、Red Hat、JBoss、Eclipseなどを見てください）。一方、独自の製品は、製造中止、価格の上昇、「次の大きなもの」への移行を強いられる単一のベンダーの気まぐれです。
• 品質 -人々が望むため、高品質の製品は単に長持ちします他のものに切り替えるのではなくそれらを使います。逆に、より良いものが来るとすぐに、低品質の製品は放棄されます。
• イノベーション -テクノロジーはイノベーションの最先端に向かっていますか？もしそうなら、それはより革新的な企業やユーザーの間で採用とサポートを得る可能性が高いです。これは最終的に主流になり始めます（たとえば、ScalaやClojureなどの新しい言語がこのカテゴリに含まれると思います）
• コミュニティー -テクノロジーに関して、前向きで、オープンマインドで、実用的で、献身的で、役立つコミュニティーはありますか？これらは最終的にそれが未来であることを保証する人々である.....

何かが将来の証拠になるかどうかを知る方法はありません。むしろ焦点を当てたいと思いますが、テクノロジーは今日の問題を解決するのに役立ちます。特定の言語またはフレームワークが問題を解決するために機能しなくなったら、学習を中止します。

あなたがしていることを表すコミュニティに参加し、何が起こっているのかを理解することができますが、それでも私は仕事のための最高のツールで時間を過ごすのが好きです今から1年か2年。

何かが将来の証拠であるかどうかを明確に判断する方法はありません。最も近いのは、特定の言語またはフレームワークに関するアクティビティのレベルを決定することです。多くの開発者アクティビティがある場合、通常、言語/フレームワークの人気が高まっており、しばらくの間実行可能であることを示す良い兆候です。逆は、興奮が少なく、サポート（開発者フォーラム経由）を利用するのが難しいことを示しています。

選択した言語/フレームワークが解決しようとしている問題を解決する限り、死にかけているテクノロジーを明確に使用しているのでない限り、将来の保証について心配する必要はありません。テクノロジーは変化し続けています。できることの1つは、業界のトレンドを追跡することです。このスレッドに記載されているように、新しいプログラミング言語/フレームワークを学ぶことは、トレンドに追いつくのに役立ち、新しいツールを継続的に評価する機会を与えてくれます。

「将来性」は意志力と頑固さについてであると同時に、より実用的な懸念についてです。

極端な例はこれです。Sparkle Filtersは、40代後半のIBM 402コンピューターを会計システムとして引き続き実行しています。これは、「ファイル」ではなく電気プラグボードを使用してプログラムされたマシンです。

私は個人的に、MS-DOSベースのマシンを何十年も動作するように設計された特殊な機器の内部に維持している会社での経験があります。私は、1997年の時点で、稼働中のPDPを廃棄しました。

あなたの会社がスパークルフィルターのようにコンピューター歴史博物館から訪問を受けた場合、それはあなた（またはあなたの祖先）がシステムの「将来の保証」に成功したことを示していると思います。

特定のテクノロジーが将来の証拠となるかどうか、私は答えることができます-これにタイムスケールを付けなかったので、答えはほぼ間違いなくノーです。

この質問に答えられるようにするには、要件にさらに詳細を追加する必要があります。例えば：

• 1年、3年、5年以上のどのタイムスケールについて話しているのですか？
• 5年後にはないものを選ぶコストはどれくらいですか？
• 「安全性の低い」オプションを選択することでどのような利点が得られますか。また、利点はリスクを上回りますか？

言語/フレームワーク/テクノロジーの選択は、プロジェクトのリスク管理の一部です。すべてのリスクと同様に、いくつかの要因（私はこれを短くするように努めています）を検討し、それを手元の状況に適したレベルに減らすための手順を実行する必要があります。

人生のほとんどのことと同様に、リスクが最も低い活動は実際には最良の選択ではないかもしれません。

要するに、プロジェクトの予想される耐用年数を超えて使用することで得られるメリットと比較して、どれだけの不確実性が生きる準備ができていますか。

未来を見つめたい時間が長くなるほど、確実性は低くなります。たとえば、今後2年間だけを心配することに満足している場合は、次の10年間必要なものを選ぶよりも、選択を行うのがはるかに簡単になります（そして、はるかに多くのオプションを開いたままにします）。

これには非常に多くの要因があり、不可能だと思います。うまくいかない可能性があるものには次のものがあります：

• ファッション。人々は興味を失い、そこに注目を向けて新しいより美しいプラットフォームに目を向けます。Perlは、2000年頃にWebアプリケーションをほぼ独占していました。そのことは今のところほとんど言及されていません。
• ベンダーの市場シェア。2000年頃にはC ++ / Sun Solarisは3000年まで良かったのですが。
• 企業のシェニガン。数年前、私は将来を保証するプラットフォームとしてJavaを選択しました。ORACLEがAPIを著作権で保護することで、他の言語フレームワークへの移行が見られると思います。
• 道の終わり。私はVisual Basicのようなものを考えています。それは、長くて立派な歴史の後で、ソフトウェア開発の最新の考え方に対応するためにこれ以上拡張することはできません。
• 敗者が勝ちます。PHP（私が好きです）は、開発者の間で美のコンテストに勝ったことはなく、決して勝ったことはありませんが、Webの議論の余地のない王として浮上しています。2004年に初めてphpを書いたとき、それをWeb開発のリンガフランカとして支持したことはなかったでしょう。
• 醜いアヒルの子。単一の構文を変更したり、単一のAPIを追加したりせずにJavascriptを使用すると、アニメーション化された迷惑なバナーがWeb 2.0の中心部分に追加されたHokeyスクリプト言語から突然移行しました。

結局それはそれほど重要ではありません。CodeIgniterはあなたのために働き、あなたが望むものを提供します。ブログの投稿が古いか、リリース率が低下しているため、何もしなくても機能しなくなります。したがって、私のアドバイスは、現在機能しているものを使用し、将来の問題に対処することです。

PHPフレームワークであるSymfonyは、サイトでこれを完全に説明しました。

正しいフレームワークを選択するための10の基準

あなたは進歩を遂げており、それは良いことです！フレームワークを使用してサイトまたはアプリケーションを開発することはすでに知っています。しかし、どれ？以下は、間違いを避けるために使用できるチェックリストです。

1.人気とコミュニティの規模

フレームワークがよく知られ、認識されるほど、それは「生きている」、進化する、そして完全なものになります。新しいアイデア、プラグインの数と品質などです。

2.哲学

これがフレームワークの本質です：それはあなたのニーズを満たすことを保証するための基本的な基準です。自分たちのニーズのために専門家が開発したツールは、明らかに他の専門家の要求を満たします。

3.持続可能性

フレームワークを選択する前に、それがその間あなたに追いつくことができることを確認してください。これにより、アプリケーションのメンテナンスとアップグレードの両方が簡単になります。

4.サポート

見落としてはならないもう1つの基準は、質問への回答を見つけやすく、ヘルプを入手しやすいことです。利用可能なサポートを特定します：出版社から。コミュニティ（メーリングリスト、IRCなど）からですか？サービス会社から（開発、サポート、トレーニング）？

5.テクニック

迷路に閉じ込められないようにするには、相互運用可能なソリューションを選択することが常に望ましいです。開発の観点からベストプラクティスを尊重するもの（デザインパターン）

6.セキュリティ

どのアプリケーションも潜在的に脆弱です。リスクを最小限に抑えるには、セキュリティ機能（XSS管理など）を保証できるフレームワークを選択することを常にお勧めします。

7.ドキュメント

フレームワークに関する既存の文献の性質、量、品質を評価することは絶対に必要です。十分に文書化されたツールは、使いやすく、アップグレードも容易です。

8.ライセンス

ライセンスは、アプリケーションに大きな影響を与える可能性があるという理由だけで重要です。たとえば、GPLライセンスのフレームワークを使用して開発されたアプリケーションは、必ずGPLの対象となります。一方、これはMITライセンスのフレームワークには当てはまりません。

9.市場での資源の入手可能性

おそらく、メンテナンスとアップグレードの両方について、開発フェーズ中または長期的には技術チームに取り囲まれてもらいたいと思うでしょう。つまり、使用しているツールに必要なスキルが公開市場で利用できることを確認してください。

10.試してみよう！

それが鍵です！インターネットでのレビュー、コメント、噂の良し悪しに満足しないでください。それをテストすることで、あなたはあなた自身の決心をし、ツールに完全に慣れていることを確実にすることができるでしょう。

キーは忍耐です。忍耐、忍耐、忍耐。将来を確実に予測する方法はありません。（私はそれを書く必要さえありましたか？）しかし、もしあなたが新しい技術を数年与えて、それがどのように採用されるかを見れば、それが根付き、長期的なプロジェクト/時間への投資に適しているかどうかについての良い考えを持つでしょう。 。

したがって、NextNewThing（tm）が登場したら、最初の2、3年で重要なことは何もせずに、自由にバンドワゴンにジャンプしてください。

ミケラスの答えはかなりいいです。私は、将来を保証することは、一種のセキュリティまたはリスク管理であることを付け加えておきます。それは多くの場合、特定の便利さとコスト/生産性のメリットを放棄する必要があり、今の問題を回避するために、後で。私はかなり長い間、ほぼ将来を見据えた技術を作っています。役立つ特定のパターンがあります。ここにいくつかあります。

1. データは、後で簡単に抽出または変換できるオープンな形式で保存する必要があります。奇妙なファイル形式は、大きなロックイン手法であり、一般にトラップ領域です。また、XMLやWord 97形式などの複雑ながらくたよりも、CSV、ASN.1、JSONなどのより単純なアプローチを優先してください。考え方は、パーサーを自分で一緒にスローするのは簡単で、低レベル形式のパーサーはアプリ全体で再利用できるということです。

2. アプリケーションは、理想的には、ベンダが必要とハイテク中立のインターフェイスは、それらに組み込まれて、プラスの正確な記述どのような彼らが行います。何も壊さずに実装を変更または破棄できるようなものを設計する必要があります。また、プロシージャを呼び出したりデータを処理したりする方法がプラットフォーム間で機能していれば、新しいプラットフォームへの移行は簡単です。したがって、インターフェースは正しいものにするために最も重要なものです。インターフェースの実装方法は、よりシンプルで、高速で、オープンであるほど優れています。

3. スタックは完全にオープンソースで、自由に変更できる必要があります。GPL、LGPL、BSD、MITなどのライセンスは、この観点では問題ありません。アイデアは、コミュニティが消滅し始めたら、スタックを新しい[ハードウェア/ OS /プロトコル/ etc]に移動する必要があるかもしれないということです。そして、それを行うにはコードが必要です。

4. スタックの設計は、各モジュールが1人で理解できるように、非常にモジュール化されている必要があります。これにより、新しいグループがそれを取得して維持しやすくなります。ランタイムの最低レベルでさえも、ライブラリとコンパイラはうまく移植でき、移植する必要がある場合、大きな見返りを得ることができます。多くの場合、その一部だけを移植すれば、古いコードはすべて機能します。

5. アプリは、プラットフォームの詳細を除外してモジュール化された方法で作成し、その領域でのやり直しを最小限に抑える必要があります。また、可能であれば、関数を入力/処理/出力ブロックに構造化するのにも役立ちます。これは、ポートによって何が影響を受けるかを分析するのに役立ちます（一般に、la 'クリーンルームの方法論の正確性分析）。リスクが最も低いアプローチのプラットフォームは、それらを使用できる1つのインターフェイスで普遍的にサポートされている共通の最小機能を使用して、移植をさらに削減することです。（私はあなたが何かを失うと言った...）

6. 動的型付け、型推論、またはその他の柔軟な型付けアプローチが役立ちます。新しいプラットフォームへの移植により、基本タイプの定義が変更される場合があります。内部で強力なタイピングを行う言語は、このようなことを心配する必要がないことを意味します。

7. 同時実行モデルをシンプルに保ちます。イベント駆動型の明確なインターフェースを通過するメッセージは、基本的にすべてに移植可能です。コルーチンもあります。エラーと移植性の両方の問題が発生しやすいルートを回避したいだけです。

8. MozillaとApacheのポータブルランタイムを見てください。それらは、特定のインターフェースと実装の選択に関する多くのプラットフォーム固有の問題を除外します。彼らは、多くの問題に対する優れた解決策を提供するとともに、何を心配すべきかについてあなたを手がかりにすることができます。

完璧な例：Tcl。多くの人がそれを嫌い、私自身はめったにそれを使用しません。それでも、Tclは理解、実装（12の主要なルール）、およびコードインが非常に簡単な言語です。それは小さく、十分に高速で、Webサーバーと統合され、ネイティブアプリに埋め込まれ、多数のものに移植され、特定の安全機能を備えています、そしてそれが作られた80年代から定期的に更新されています。あなたまたは私は、コア言語のためのTCLランタイム全体をすぐに実装することができます。場合は、我々はポートに標準ライブラリを持っていた、それは、.NETやJavaを移植するよりも容易になるだろう。そして、そのために書かれた便利なコードがかなりあります。そして、Javaアプレットも狙った「モバイルエージェント」ブームまでWebテクノロジーで使用されています。たとえば、OpenACS Webフレームワークは1998年にさかのぼり、それより古いサーバーを使用しています。

その他の例：BASIC、COBOL、LISP（SchemeまたはCL）。これらの言語はすべて50年代または60年代にさかのぼります。それらは、理解、実装、および機械翻訳を容易にするのに十分なほど単純です。しかし、あなたはそれらを使って有用なものを構築することができます。COBOLは今でも世界のほとんどのトランザクション処理を強化しており、何度か更新されており、.NETでも実行されます。古いQBasic / QuickBASICアプリは現在でも、GAMBASやRealBASICなどのより優れたツールへの移植の可能性とともに、最新のプラットフォーム上のオープン/フリーツールで実行されます。LISPコーダーは当然、システムをモジュール化して機能的にし、移植を容易にします。何十年にもわたって、オープンで商用の実装の着実な流れがありました。

つまり、インターフェース、オープン性、シンプルさ、モジュール性、そしてプラットフォームに依存しないアーキテクチャー/設計/コーディングです。これらはあなたがあなたが必要とする将来の保証を得ます。とにかく、ほとんどの場合。