OOPに別れを告げた男について聞いたことがありますか？
いえいえ もう一つ？ 彼は何と言いましたか？
彼は、すべてのOOPの約束、およびそれらのどれも実際に満たされていないこと、およびすべてのOOP機能が実際のコストよりも高価であり、関数型プログラミングの方が優れていること、および...
おお はい、私はこれをすべて前に聞いた...
このように、OOPはついに死に、私たちは先に進むことができます。
何に移動しますか？
何してるの？ もちろん、次の技術的ブレークスルーへ！
そして、これに...そして、私たちのラインの次は何ですか？
よくわかりませんが、マイクロサービスのアイデアに非常に惹かれています。 そして、私はElixrに非常に興味があります。 そして、Reactは本当にクールだと聞きました。 そして...
はい はい チャーン。 あなたはチャーンに巻き込まれています。
なに？ それはどういう意味ですか？ 今がエキサイティングな時間です。
私に関しては、むしろ憂鬱です。
なんで？ 毎週新しいテクノロジーが登場します！ 私たちはこれまで以上に高いところに登っています。
木！ 本当にやりたいのは、何度も何度も車輪を再発明することです。 そして、これに時間と多大な労力を費やしています。
おいおい！ プログレスを作成します。
進捗状況。 ほんと？ これは私が見るものではありません。
さて、あなたは何を見ますか？
無駄が見えます。 時間とお金の莫大な、計り知れない損失。 廃棄物に廃棄物を掛け、さらに大きい廃棄物を掛けます。
どうやってそれを言えますか？
さて、少なくともOOPではこの問題を考慮してください。 OOPは死んでいません。 OOPは生きていたことがありません。 OOPはテクニックであり、優れたテクニックです。 死んだと言うことは、良いドライバーが死んだと言うことです。 OOPに別れを告げるのは、良いドライバーに別れを告げるようなものです。 これは無駄です！
しかし、関数型プログラミングの方が優れています！
すみませんが、ハンマーはドライバーよりも優れていると言っているようなものです。 関数型プログラミングは、オブジェクト指向プログラミングよりも「優れた」ものではありません。 関数型プログラミングは、オブジェクト指向プログラミングと組み合わせて使用できる方法であり、非常に優れた方法です。
これは私が聞いたことではありません。 それらは相互に排他的であると聞きました。
いいえ、もちろんです。 それらは直交問題を解決することを目的としています。 すべてのプロジェクトに存在する問題。
見て、ソフトウェア開発は直線的な進歩を表していると思う人がいます。 たとえば、はしごの1ステップを何度も何度も登りますが、各「新しい」ステップは前の「古い」ステップよりも優れています。 しかし、それはそのようには機能しません。
そして、それはどのように機能すると思いますか？
ソフトウェアの進行は対数成長曲線に従います。 初期の段階では、進歩は鋭く印象的でした。 その後数年で、進歩はずっと緩やかになりました。 現時点では実質的に進展はありません。
見てください：アセンブラはマシンコードよりもはるかに優れていました。 Fortranはアセンブラよりもはるかに優れていました。 CはFortranよりもはるかに優れていました。 C ++はおそらくCよりも優れています。JavaはC ++よりも改善されました。 RubyはおそらくJavaよりも少し優れています。
カスケードモデル（滝）は、何もないよりもはるかに優れていました。 アジャイルは滝よりも優れていました。 リーンはアジャイルよりも少し優れていました。 かんばんは改善されているかもしれません。
毎年、私たちは多大な努力を払っていますが、1年前よりも進歩は少なくなっています。 毎年漸近線に近づくためです。
漸近線！？ ソフトウェア開発技術には上限があると思いますか？
きっと。 さらに、私たちは今この限界に近づいているので、それ以上の努力は無駄であると思います。 私たちはすでに効率の低下のラインを通過しました。
なに？ それはばかげて聞こえます！ そして憂鬱！
わかった。 しかし、これは急速な成長に慣れているためです。 これらは大変な日でした、そして我々はそれらを取り戻したいです。 しかし、それらはなくなっており、私たちはそれらを再作成しようとして大規模に時間と労力を浪費しているという事実を認識しなければなりません。
しかし、未来に拍車をかけなければ、決して未来を創造することはありません！
私を信じて、私は間違いなく未来に拍車をかけたいです。 しかし、それは私たちがやっていることではありません。 過去が恋しいだけです。
それでは、どのような未来を目指して取り組むべきでしょうか？
生産的に。 無駄な解約の対象ではない未来へ。
この文脈で「無駄」とはどういう意味ですか？
JavaでプログラミングするためにIntelliJまたはEclipseを使用したことがありますか？
もちろん。
これらは非常に強力なツールです。 経験豊富な専門家は、これらのツールを使用して非常に生産的です。 リファクタリング！ 提出！ 便利！ なんてこった、これらのツールは印象的です！
ただし、新しい言語が登場するたびに、次の新しい作品に進むための強力なツールを放棄します。 そして、新しいプログラミング言語のツールは、第三世界の国々の生活水準のように見えます。 神様、よくある「リネーム」リファクタリングさえありません！
適切なツールセットを作成するには時間がかかります。 ある言語から別の言語に切り替え続けると、信頼できるツールが提供されなくなります。
しかし、新しい言語の方が優れています。
おいおい！ それらは異なりますが、少なくともツールボックスを石器時代に戻すことを正当化するほどではありません。
そして、新しい言語に適応するための学習のコストを考えてください。 プログラマーが2週間ごとに新しい素晴らしいものに夢中になっているという理由だけで、組織が84の異なる言語を使用するのにどれだけの費用がかかるかを考えてください。
新しい光沢のあるもの？ なんとなく不快に聞こえますよね？
そうは思いますが、多くの場合、それだけになります。 新しい言語は優れたものではなく、すばらしいものです。 そして、新しい言語、新しいフレームワーク、新しいパラダイム、または新しいプロセスの形でのゴールデンフリースの検索は、プロフェッショナルではなくなった段階に達しました。
プロフェッショナルではない？
はい！ これは専門的ではありません。 漸近線に遭遇したことを認識する必要があります。 言語やフレームワーク、パラダイム、プロセスの無駄な泡立ちを止める時が来ました。
仕事を始めましょう。
言語を1つ、2つ、または3つ選択する必要があります。 シンプルなフレームワークの小さなセット。 次に、ツールを構築します。 プロセスを結晶化します。 そして、真のプロフェッショナルになります。