効果的なデザインの幻想：デザイン

この投稿はフォローアップです： 効果的な開発の幻想：管理



私たちは全員プログラミングを学び、ほとんどすべての人がフォーラム、会議、そして時にはチームで質問する段階を経ました。 条件付きで、すべての回答者は2つのグループに分けることができます：あなたの質問への答えを知っている人と、正しい方法を知っている人。 彼らは標準の預言者であり、正当な理由の使徒であり、彼らだけが完璧なアーキテクチャとなめられたコードの後ろに隠れて、あなたのプロジェクトを恥知らずに引き締めることができます。 彼らはITの世界の舞台裏の世界であり、それを知らずに、今後数年で何がトレンドになるかを決定します。

あなたが読書にうんざりしているなら、私はこの投稿の本質はあなたがあなた自身の頭で考えることであると言うでしょう。 または、現在の場所で長く生産的に仕事をするつもりなら、彼らは自分の頭で考え、自分の考えを口に出さないようにしました。 猫の下で誰もが歓迎します。

パーフェクトコード教会

問題は世界と同じくらい古い-その意味を理解せずにアイデアを使用しています。 私たちの場合、すべては、人が必要な理由を理解するのに十分な経験を持たない、または業界の典型的なタスクと本に記載されているアプローチとの関係を定式化するのに十分な知識を持たない高度な設計技術を習得したときに始まります。 結果は1つです-提案されたアイデアは信仰で受け入れられます。 また、範囲の理解が不足しているため、これらのアイデアが適用できない場合もあります。

ITの世界は、勉強しない人が長い間そこにとどまらないという点で優れています。 そして、OOPが本当に必要な理由、パターンなどの段階的な理解 そのようなプログラマーにはまだ来ます。 何も理解していない人は、あらゆるアプローチを支持する強引な判断と、このアプローチに準拠していないすべての2年生の人々を認識する準備ができているため、非常に簡単に特定できます。 そして、これがヒンドゥー連隊の首謀者である場合、この行動はまだ何らかの形で説明することができますが、そうでない場合は、そのようなtimlidsは、すべての人を人にすることを促す不死の創造物Svetlana Baskovaの映画のヒーローから多くを学ぶべきだと思います。

特定のケースで使用するアプローチを適用する理由を毎回自問するのをやめないでください。 このアプローチが解決する問題に注意してください。 これらの問題がプロジェクトに存在することを確認してください。 この簡単な手順の結果として、「これはグッドプラクティスです」または「私の信仰は強い」という形式の最終的な正当化に至った場合、おそらくこれは、この場合に選択されたアプローチが適切ではないという間接的な兆候です。

紙飛行機からシャトルまで

まともな若いWebプログラマーの心は、「高負荷は何個の接続から始まるのか」という疑問を刺激します。 しかし、すべてのきちんとしたアーキテクトの心は、2つの質問で占められています：設計されたシステムでさらに拡張が地獄にならないようにするための最小レベルの抽象化と、開発とサポートが地獄にならないようにどれだけ高いレベルの抽象化を行うことができるかです。 そのような質問はたくさんありますが、それはすべて、特定の規模のプロジェクトに使用するパターンとアーキテクチャに帰着します。 多くの場合、開発の見通しやプロジェクトへの参加に関するアイデアが非常に曖昧である一方で、時間と予算が問題をすぐに完全に解決するわけではないという事実により、問題は複雑になっています。 同時に、建築家は相反するすべての要件を満たすものを作成する必要があります。

さまざまな人々がさまざまな方法でこの問題を解決します。 誰かが構造を気にしないと決めたのは、プロジェクトが成功した場合、最初から書き直すお金があり、成功しなかった場合、努力する必要はないと信じているからです。 何でもできるシステムを設計している誰かが、銃をスズメに向け始めますが、計算の繊細な精度にもかかわらず、指を指す時点で、スズメが飛び去り、時間と予算が倍になっていることがわかります。 誰かが絶望から酔ってしまい、問題の解決から遠ざかります。 そして、誰かが幸運にも、時間が設定されるシステムの要件を推測できれば、素晴らしいアーキテクチャを備えた優れた製品が得られます。 そして、誰かが現在の要件に従って、または少しの時間を失うように計算にわずかな余裕をもって設計しますが、少なくともさらなる拡張の可能性を残します。 原則として、最初と最後のアプローチが最も実行可能です。

私の意見では、今日、そのようなアーキテクチャのアプローチの適用がいつから正当化されるかを決定する明確な方法はまだありません。 つまり アプローチのコレクションがあり、アプリケーションのケースが説明されていますが、そのようなケースが始まる境界線は他の場所では説明されていません。 通常、いつ応募するかを理解するには経験が必要ですが、そのような経験を言葉で伝えるのは簡単なことではありません。 業界の詳細は、ほとんどすべての新しいアーキテクチャが既存のものと異なるため、古いアーキテクチャとビジネスをしていない人への新しいアーキテクチャに関するアドバイスは役に立たないほどです。

本でパターンがどれほどエレガントであっても、すべてのコードをテストでカバーするというアイデアがどれほど魅力的であっても、アーキテクチャを「保留」することがどれほどクールであっても、これはすべて最終的にあなたのプロジェクトの負担であり、援助ではないことがわかります。 あなたが必要とするものと犠牲にするものを自分で決めてください-通常のコードが考えられないように、常に無視することから遠く離れて、地獄の第9の輪にあなたを投げます。

ウォールバイク

現在、特定の言語のコードリポジトリはもちろん、github.com、sourceforge.netなどの多くの素晴らしいプロジェクトがあります。 そして、自転車が悪いという信念を植え付けるという点で重要な役割を果たしたのは彼らの存在であり、常に既製の解決策があるということです。 もちろん、Windows用のGUIツールキットまたはPHP用のテンプレートエンジンを作成することに決めた場合は、未完成のビジネスをすべて削除し、立ち上がってズボンを締めてフィールドから離れ、多数意見を表明します。

しかし、上記のものよりも少し非定型なものに取り組むとすぐに、アクセスしやすいと思われるこれらのライブラリの品質という全面的な問題に直面します。 品質とは、3つのことを意味します。

• 機能性-選択したライブラリに、プロジェクトの90％が保持される機能の10％がないことを発見した瞬間を個人的に感じる必要があります。 開発者はあなたのような人であり、通常、これらの非常に必要な10％には、誰もやりたくない最も汚い作業が含まれています。
• ドキュメンテーション-貧弱なドキュメンテーションはすべての若いプロジェクトの惨劇であり、それなしではコードへようこそ
• コード品質-不十分でドキュメンテーションが不足している場合に、APIを拡張したり学習したりする可能性を判断します

ライブラリの品質を真剣に見れば、アナログを自分で書く必要がある場合でもオプションを許可できます。 簡単だからといって。 より速く、より効率的になります。 だから間違っているでしょう。 そして、あなたの自転車は本当に特別なものになり得ます-想像上の豊富な解決策があったとしても、それらのどれもあなたに完全には合いません。 ただし、バージョンをgithubに投稿することで、この犠牲を免れることができます。 そのため、他の人がそれに火をつけたり、自分で書いたりします。 また、アプリケーションの展開時間は、それとともに展開する必要があるライブラリの数に直接比例します。

それとは別に、新しいプロジェクトを選択するか、既存のソリューションを開発するかの問題があります。 この選択はウェブプログラマーに重くのしかかります-ウェブ上のプロジェクトの大部分は非常に典型的であり、cms、ウェブショップ、ソーシャルネットワークなどのエンジンがあります。一見、ToRの要件に対する既存のソリューションを完成させることは常に論理的であるようですゼロから自転車。 これは、複数のプロジェクトが同じエンジンで連続して実行された後、迅速かつエレガントに実行された後、特に論理的に思えます。 ただし、アーキテクチャの制限や派手なレイアウト、または作業が完了した後にすべてが機能する速度にとどまって、やけどする可能性があります。 私の経験では、経験則から推測しました-私の推定によると、プロジェクトに1か月以上かかる場合は、ゼロから作成するか、一般的なフレームワークで作成する方が良いでしょう。 まあ、最高-私はより良いです、あなたはあなたが働いているものに応じてあなたのルールを導き出す必要があります。

libxmlへのバインディングを使用するよりも、正規表現でxmlを解析する方が好ましい場合があり、一見シンプルなオンラインストアを書くことは、PrestaShopに基づくよりもYiiの方が簡単であることを覚えておいてください。 もちろん、すべてが私たちの前にすでに発明されていますが、このすべてが便利に使用できるようにコードに組み込まれているわけではありません。

テクノロジーの最前線

ITの世界で信頼性を獲得する最も簡単な方法の1つは、トレンドに従うことです。 トレンドに参加するのは早ければ早いほど良いです。 トレンドが実際にどれほど効果的であるかを考えて確認すると、最前線にいることはできず、シニアブリードエッジデベロッパーの名誉称号は表示されません。 私は新しいものが悪いと言っているのではなく、新しい技術を適用することで競合他社を打ち負かすのに役立つと信じています（しかし、良いセールスマネージャーや優れたユーザビリティはあなたに大きなチャンスを与えると私は考えています）有能な建築よりもチャンピオンに勝つ）。 プロジェクトに新しいフレームワークを選択する前に、次のことを確認しておくと便利です。

• このフレームワークには、プロジェクトに本当に必要な機能の少なくとも一部があります
• ただし、この機能は適用できます-つまり 持って使うために、私はタンバリンと一緒に踊らないので、どういうわけかうまくいく
• あなたは自分自身と部下に非常に自信を持っているので、開発全体が立ち上がるために間違いに遭遇した場合、デバッグしてフレームワークの内部を掘り下げることでそれを排除できることを知っています
• 前の段落を実装する時間があります

繰り返しますが、すでに十分にテストされ、コミュニティがあり、一般的にどこでも使用されているXテクノロジーを使用している場合、新しいYテクノロジーを選択した理由に注意してください。

理論と実践

私は長い間ここに何を書くべきかを考えましたが、どういうわけかそれはあまりにボリュームがありすぎるか、あまりにも具体的であることが判明しました。そのため、多くの人は私がいくつかの技術とアプローチのイデオロギーの反対者であると考えていたでしょう。 したがって、私は自分自身を5点に制限します。

• あなたに非常に近いソリューションを作成することに基づいて得られたものであることが確実でない場合は、理論家の計算（例えば、この記事など）や他の人の経験を真実として受け取らないでください。
• ドキュメントの例がどれほど説得力があるとしても、それらはしばしば合成的なものであることを忘れないでください
• 一般に、問題または類似の問題のクラスを解決するために概念が考案されましたが、タスクがこのクラスに調和することを保証するものではありません
• 一見複雑になりますが、タスクに適用される概念は、ほとんどの田舎のコンピューターサイエンスの教師が理解できる2、3行になる可能性があります
• 「すべての人のためではない」または「彼らの時代の先」という概念に非常に注意してください。何年もの間、少数の人々の運命のままです。

必要に応じて理解してください。 そして、オリンピアードと産業用プログラミングの違いを覚えておいてください。

間違えないように

経験は難しい間違いの息子です。 そして、経験がないときに何をすべきか、しかしあなたは間違いを避けたいですか？ ここでは、ピックアップブックが使用されます。 そして、あらゆる種類のベストプラクティスをプログラミングする場合。 これを読んで、少なくとも優れたコードのルールのセットを覚えたら、コードを書いて、誰かが何かが間違って書かれていることをあえて非難しないようにすることができます。 これは素晴らしい。 同時に、すべてにお金を払わなければならないという事実を見逃しています。 テクニック（単純なテクニック以外）が必要になるまで、テクニックを効果的に使用することはできず、ほとんどの場合、時間がかかります。 数十のphpウェブサイトの構築に成功した昨日の学生が「Perfect Code」を読み、これをすべて実際に使用しようとすると、コードの品質は一部の場所で改善されますが、おそらく彼の作品は成功します。 そして、本からの抽象的な構成が実際の練習からの対応を見つけるまで、彼が大きなプロジェクトで熊手を自分で歩くまでです。 そうして初めて、何を、いつ、なぜ使用するのかが理解できます。

しかし、ルーツから戻らないでください。同じ学生の多くは、数年以上の経験を積んでおり、コピー＆ペーストや手続き型プログラミングは呼び出すことができないものの一つであると信じ始めます。 理由は同じです-間違いの恐れ。 残念ながら、今ではコミュニティはタスク用のツールを見つけるよりも適切なソリューションを使用する方が受け入れられています。

間違いをすることを恐れないでください。 あなたがそれがあなたに評判と仕事の損失を犠牲にしないと確信しているならば。

ティムリッド-私たちの王、父、神

当然のことながら、この記事全体は、チームリーダーが異なるチームで作業しなければならなかったという事実に触発されました。各チームリーダーは、コードを正しく記述する方法について独自のアイデアを持っていました。 それらはすべて詳細に正しいものでしたが、問題は、これらの詳細がそれぞれの詳細と大きく異なっていたことです。 さらに、パブの同じテーブルでそれらをすべてまとめてから、命令型プログラミングと関数型プログラミングの比較の行に会話を転送する場合、または依存性注入と古き良きファクトリーの違いについて話す場合は、ガードの介入なしでは行わないと想定するリスクがあります。

すべてのチームリーダーも人であり、プロジェクトのいくつかを実施することで得られた独自の信念と知識を持っています。 時にはそのような信念は真実であり、時にはそうではありません。 場合によっては、なぜそれを行う必要があるのか​​を理解するためのタスクにまだ直面していないという事実のために、後者があなたに見えるかもしれません。 いずれにせよ、チームリーダーが自分の要件として言うものはすべて取り入れてください。本当に良いことではありません。 彼のアドバイスが実践テストに合格した場合-素晴らしいが、そうでない場合は、この種のエラーを人に納得させるのは通常役に立たない。

おわりに

良いデザインのための普遍的なルールはありません。 状況に有益なルールがあります。 そのような状況がたくさんあるとしても、かつて役立ったルールが役に立たなかったときに他の人に出会わないという意味ではありません。 そして、なぜこの問題に対する別のソリューションではなく、この特定のソリューションを選択したのかを自問することを忘れないでください。