プログラマーとしての私の世界観は、コンソールアプリケーションとテキストユーザーインターフェイスの時代に形成され、それらはグラフィカルウィンドウGUIに置き換わりました。今では、グローバルネットワークに接続された第3ラウンドのテクノロジーをすでに目撃しています。 もちろん、毎回、お気に入りのプログラミング言語だけでなく、技術スタック全体も変更する必要がありました。現在、フレームワークと呼ばれている開発済みのプレハブのかなり広範なライブラリがあります。 私はそれを無慈悲にそして断固として生きたまま切らなければなりませんでした。
最近、Webブラウザーはユーザーインターフェイスの同義語になりつつあり、パーソナルコンピューターにインストールされた従来のウィンドウアプリケーションが既に過去のものであることを疑う人はいません。 彼らはまだわずかなソフトウェアしか持っていませんが、コンソールアプリケーションの背後に永遠に留まりました。
私の記憶、技術と専門家の世代における第3の形成を見て、私は「自転車」と「熊手」の両方が繰り返されていることに気付くことができます。 そのため、この記事を書くことができませんでした。 非常に詳細に目を向けて、いくつかの現代の言語と技術の歯車、それらの組み合わせとドッキングの機能を見てみたいという大きな誘惑を持っていますが、これを他の記事に残して、情報システムのすべての化身で変わらない原則に集中しましょう。 すでにWebに関連付けられているいくつかの例を使用して、各原則を説明します。
1.簡単に実行できるトリックを考案する必要はありません。
1.1。 たとえば、古き良き手続き型プログラミングがより高速で効率的なOOPを自由に放棄してください。 アプリケーションインスタンスが少なくともしばらくの間存続する場合、そのようなタスクでメモリにクラスとオブジェクトをデプロイするのは理にかなっています。 また、スクリプトを起動して一瞬でリソースを提供する場合、分岐した概念クラスはまったく役に立ちません。 最終的に、Webサーバーによるリソースの発行はstdoutに似たものであり、発行された部分は変更できなくなります。 ただし、デーモン、バッチおよび遅延処理、クローラー、計算などのサーバータスクでは、OOPが必ず必要になります。
1.2。 誰が継承と再定義のためにオブジェクトが必要だと言ったのですか？ 階層ファイル構造または階層データベースクエリが非常に適しています。
1.3。 コードがクールに見えないが、非常に単純でさえあるが、それが正確にすべてを行うのではないかと心配している場合は、プログラミングに関するアイデアを再検討する必要があります。 1つのプロジェクトですべての既知のパターンと概念を適用する必要はありません。
1.4。 ほとんどのスクリプト化されたWeb言語はそれ自体がテンプレートエンジンであるため、テンプレートエンジンに対する一般の執着は私には完全に明確ではありません。 最も顕著な例はPHPです。変数を置換し、ループと分岐があります。最も重要なことは、テンプレートの追加の解析を必要としないことです。 アクセラレータを実装するとき、テンプレートはプログラムの他のすべての部分と同じ方法でバイトコードにプリコンパイルされます。
1.5。 現在、多くの人は「インターネットからダウンロードして固定する」という原則に導かれていますが、十分な時間がない場合でも、少なくともダウンロードされたコードを見ると、同じことをより簡単に行う方法のアイデアにつながる可能性があります。 結局のところ、ダウンロードしたコードの作成者があなたよりも多くの経験、才能、時間を持っていたという保証はありません。 そしてもちろん、あなたが書いているシステムについて真剣に考えているなら、その中のすべてのコード行を知り、理解し、感じる必要があります。
2.さまざまな機能が必要な場合は、ツールキットを長期間選択して修正します。
これは経験的な原理ですが、常に機能します。 おそらく、一部の学者は彼を宇宙の基本法則から導き出すかもしれませんが、今のところ、誰も私たちが直感的なレベルでそれを使用するのを止めません。 より明確で厳格な言語と技術がより多様なソフトウェアのプラットフォームになると、あなたの多くは多くの例を挙げることができると思います。 小規模では、企業の標準、内部仕様、フォーマット、およびプロトコルを簡単に導入できます。
3.ツールの不適切で不適切な使用は、悪いツールよりも一般的です。
各言語とテクノロジーには、理想的な範囲のタスクがあり、他のタスクには、独自の適切な解決手段が確かにあります。
4. 1つの抽象化層でデータ、ロジック、表現を分離することは不可能であり、必要ではありません。
これは驚くべきことですが、MVCが発明される前でさえ、さらに大規模な実装の前に、プログラマーは各モジュールに常に3つの部分があることを理解していました：ロジック、データ、マッピング（またはコード、メモリ構造、インターフェース）。 しかし最近、私はこの原則の乱用を観察しており、「彼らは共有すると言って、それから共有する」と言っています。 しかし、共有は常に成功するとは限りません。 プレゼンテーションレイヤー（表示）を選択した場合でも、表示ロジック、表示データ、表示テンプレートの3つの部分すべてに常に場所があります。 したがって、あなたは永遠に共有することができ、蛇ゴリニッチはまだ約3頭です。 状況は、モデルとコントローラーを選択した場合と同じです。これらの場合も、3つのコンポーネントすべてを選択できます。 この事実との頑固な闘争は、多くの人が信じられないほどの量のコード、クラス、デザイン、ローションを生成することにつながります。 MVCが機能しないと言っているわけではありません。MVCをそれほど熱狂的に、普遍的かつ精力的に使用する必要はありません。 問題との闘いはそれを悪化させるだけであり、この事実を受け入れ、さらには使用するのがより良いことではないことを忘れないでください。 最終的に、問題を正しく理解することで、DBMS、アプリケーションサーバー、GUIなどのシステムクラスが生まれました。 言葉遣いで正確に「抽象化の1つの層」に書いたことに注意してください。 説明させてください：DBMSは、リレーショナル抽象化（または他の情報モデル）のレベルでデータとロジックとマッピングを操作し、アプリケーションサーバーはドメイン抽象化のレベル（またはメタプログラミングのレベル）で操作し、ユーザーインターフェイスは同じタスクのまったく異なる側面で操作します。 つまり、カットする必要があるのはデータ、ロジック、表現ではなく（カットではなく、それらを分離する必要がある）、タスクの抽象化または側面です。
5.完全なコードはありません。ある程度の汎用性を備えたコンテンツである必要があります。
理想主義者および完璧主義者として、それを実現することは私にとって最も困難なことでした。 私は自由で、プログラムが考えられないすべてのタスクを解決し始め、単に「プログラム」と呼ばれるまで、プログラムコードは狂気の点まで改善されます。 不条理をもたらすことは無限の時間の間だけ完了することができ、コード最適化はその長さをゼロにする傾向があります。 このようなプログラムは、すべてのプログラミングの問題を一度だけ解決する義務があります。 しかし実際には、完全に異なるコードが必要です。つまり、適用された問題を解決するためには、実際には完璧なコードは必要ありません。 もちろん、コードはその美しさに満足するはずですが、夢中にならないでください。
6.過激主義はすべて悪い。
間違っている人を助け、そのエラーを不条理のポイントに持って行けば、彼自身が合理的を支持してそれを拒否するでしょう。 単純なものは複雑なものよりも信頼性が高く、良いものは悪いものよりも収益性が高く、最終的には高品質は低品質よりも安価です。 誇りと恐れだけでは、簡単な方法を見ることができず、目標を達成するために余分な努力をする必要はありません。間違いを捨てたほうがよく、望みは現実と一致します。
7.システムの開発は、その制限につながります。
開発のための情報を含むシステムは、意思決定を必要としますが、各決定は機能の出現だけでなく、制限の作成にもつながります。 したがって、仮定を立てて決定を下す（仮定）ときは、これがどのような制限につながるのか、そしてそれらの準備ができているかどうかを常に考えてください。
以上です。 誰かが将来のためにそれをすることを願っています。
これらの無数のパラダイム、概念、ツール、およびフレームワーク
All Articles