私には問題があります-私は完璧主義者です。 私は完璧なコードが大好きです。 結局のところ、これはプログラムを書くための正しいアプローチであるだけでなく、本物の芸術でもあります。 良いリストを読むことで、良い本を読むのと同じくらいの喜びが得られます。 大規模なプロジェクトのアーキテクチャを設計することは、大規模な建物のアーキテクチャを設計することほど簡単ではありません。それがうまく機能すれば、その結果も同様に美しくなります。 時には、完璧なソフトウェアシステムを作成する際に、デザインパターンが優雅に織り交ぜられていることに魅了されます。 絶対にすべてのメソッドが非常にシンプルでわかりやすいので、完璧なコードの古典的な例であると主張するとき、細部への注意を賞賛します。

しかし、残念ながら、この素晴らしさはすべて、厳しい現実と実際のプロジェクトに分かれています。 本番プロジェクトについて話している場合、ユーザーはコードがどれだけ美しいか、そしてアーキテクチャがどれほど優れているかを気にせず、プロジェクトがうまく機能するように気にします。 しかし、いずれにしても、あなたは正しく書くよう努力するべきだと思います。ただこれは狂信的であってはならないということです。 コードを書くための正しいアプローチでさまざまなホリバーを読んだ後、1​​つの傾向が私の目を引きました：誰もがプログラミングに一般的にではなく、開発経験にのみ、前述のアプローチをプロジェクトに適用しようとしています。 多くの人は、グッドプラクティスが100％のシナリオで厳密に従う必要のある絶対的なルールではないことを理解していません。これらは、ほとんどの状況で行動するための単なるヒントです。 すべての優れた実践について、それが機能しない数十の例をいつでも思いつくことができます。 しかし、これはグッドプラクティスがそれほど良くないという意味ではなく、単に場違いに適用されただけです。

別の問題があります-一部のプログラマーは見た目ほど良くありません。 多くの場合、この状況を確認する必要があります：同様の開発者は、完璧なコードに関する大規模な記事で（コンテキストを詳しく調べることなく）単一の考慮事項を見つけ、それをあらゆる場所に適用し始めました。 そして、あなたはこう聞きます： 「ここにそのようなアプローチとそのようなアプローチに関する記事があり、そして彼らはそのような方法で書き始めます 。 」 それとも非難する記事ではないのでしょうか？ 一部のプログラマーがひねくれて、どこかで聞いたグッドプラクティスを適用している場合、これは正しいプログラミング手法を議論する必要がないという意味ではありません。 うまく書きたいという欲求は称賛に値しますが、あなたは自分の能力を落ち着いて評価する必要があります。 航空機のパイロットについては、「曲技飛行」のカテゴリからの多くの操作が説明されていますが、これはすべての初心者パイロットが彼の最初の飛行でそれらのすべてを試す必要があるという意味ではありません。 したがって、ジュニアプログラマーは、4人のギャングの本を読んだ後、彼が現在「知っている」次のプロジェクトで数十のパターンすべてを彫刻するべきではありません。

しかし、完全なコードの説明に戻ります。 適切な開発へのアプローチは、目標、期限、チームなど、非常に多くの要因に依存します。 私はあなたと一緒に、タスクが互いに大きく異なるいくつかのタイプのプロジェクトを検討したいと思います。 コードをどれだけきれいにし、それぞれのケースでどの程度のアーキテクチャを使用する必要があるかを一緒に考えましょう。 一部のプロジェクトでは、他のプロジェクトには明らかに不適切な慣行があります。 次回プログラミングに関する次の記事のアドバイスに怒りを覚えたら、holivarに参加する前に考えてみてください。著者はどのような仕事をしましたか。 これらは悪いヒントではないかもしれませんが、著者のプロジェクトは単にあなたのプロジェクトとは異なります。 それでは始めましょう。

プロジェクト規模

小規模プロジェクト

たとえば、プロジェクトを数日間書く人が1人います。 これは、小さな個々のタスクを解決するための小さなユーティリティです。 ほとんどの場合、特に開発されず、大きなものにはなりません。 そのようなプロジェクトでは、システムのすべての要素（またはすべての変数）を念頭に置くことができます。 このようなプロジェクトでは、クールなアーキテクチャは必要ありません。2行の松葉杖で解決できるサブタスクがある場合は、そうすることをお勧めします。 もちろん、新しい複雑なサブタスクが表示される場合に使用するのに非常に便利な複雑なアーキテクチャを開発するのに数日費やすことができます。 ただし、微妙な違いがあります。これらのサブタスクは小さなプロジェクトに登場する可能性は低く、すでに時間がかかります。 この状況では、超純粋なコードを書くことに煩わされるべきではありません。 クイックコードもそうではなく、普通に書いてみてください。

中規模プロジェクト

数ヶ月間、すでに5〜6人の人とプロジェクトがあるとします。 ここではあまり話すことはできません。多かれ少なかれシステムについて考え、コード全体を構成する必要があります。 松葉杖が特に蓄積しないことを確認する方が良いでしょう。 予備的な分析と設計にある程度の時間を費やすことはできますが、それほど時間はかかりません。 締め切り前に理想的なシステムを構築するための理想的な計画を立てることができれば称賛に値しますが、理想的ではないが機能するシステムを作成できた方が良いでしょう。 最悪の場合、すべてがうまくいかなかった場合、共同の努力によって数日間、アーキテクチャ全体を作り直すことはそれほど難しくありません。 （ 私はこれを何回かしなければなりませんでしたが、それほど怖くはありません。 ）これがたとえばカスタムプロジェクトである場合、顧客は素晴らしいコードではなく、時間通りに実装された機能を実行するためにあなたに支払います。 それを忘れないでください。

大きなプロジェクト

そして今、私たちは数十人の人々を抱えており、プロジェクトは数年間書かれます。 ここでは、最初からアーキテクチャを非常によく考えておくとよいでしょう。 松葉杖を挿入する必要がある場合は、新しい機能がうまく適合するように、初期段階でアーキテクチャを改造する価値があります。 現在行われているすべてのハックは、1〜2年でひどい苦しみに変わります。 きれいなコードと適切なアーキテクチャに関する本を読んでください-役に立つヒントがたくさんあります。 それらはローカルに適用する必要があり、行のどこにも適用する必要はありません。
私はマーティン・ファウラーの本の自転車が本当に好きです。ファウラーは、かなり大きなプロジェクトの開発についてある会社にアドバイスしました。 このプロジェクトは不適切に書かれており、Martinは少しのリファクタリングを主張しました。 数日間の作業の後、システムの機能を損なうことなくコードの半分を削除することができました。 プログラマーは非常に満足していましたが、ボスだけでは十分ではありませんでした-結局、この仕事は新しい機能の登場には至りませんでした。 古いコードは完全に機能し、その「クリーニング」の活動は経済的に実行可能ではないようでした。 そのため、管理者はそれ以上のアドバイスに耳を傾けず、コードに追加の作業を加えることなく、新しい機能の早期登場を主張しました。 6か月後、プロジェクトは閉鎖されました。 コードは複雑すぎてサポートできません。

プロジェクト支援

サポートなしのプロジェクト

さまざまなフリーランサーやアウトソーシング業者によく知られている活動。 プロジェクトの提供後、内部に潜むすべてのこの恐怖について思い出す必要はありません。 あなたは、プロジェクトが単に使用され、誰もソースコードを開かないことを心から望んでいます。 そして、これは有効なアプローチです。素晴らしいコードではなく、実用的なアプリケーションが必要だからです。 プロジェクトの開始時には、まだアーキテクチャを設計し、クリーンなコードを書く余裕がありますが、締め切りまでに2日間が残り、機能が半分しか実装されていない場合、重要なことはできません。 松葉杖を運転し、良いコードに対する考えられる、考えられないアプローチに違反することは許されています。 この場合、これは正常です。 私はそれが良いと言っているのではなく、いつもそうするようにみんなを動揺させているのではありません。 しかし、これは正常です。 ここでは、芸術としてのプログラミングについて話しているのではなく、時間通りに配信する必要があり、サポートする必要がないプロジェクトについて話している。 理想的な方法ですべてを書き始めると、締め切りに間に合わないリスクを負うことになります。顧客を失望させ、お金を受け取らず、時間を費やし、コードは誰にとっても役に立たないでしょう。 常に当面の目標を思い出してください。

サポートされているプロジェクト

そして、ここで私は普通に書きます。 そのため、アーキテクチャは正常であり、コードはクリーンになります。 顧客が重要な機能を追加するように求め、1時間でタスクを完了すると、これは非常にいい感じです。既存のアーキテクチャに完全に適合するため、新しいコードを簡単に追加できます。 既製のコードベースで作業するのは非常に簡単です。コードは非常に明確で、その中でナビゲートするのは簡単です。 そして、顧客が些細なことをするように要求するときに別の感覚があります（そして、これが本当に些細なことであることが非常に簡単であることが顧客に非常に明白です）、そしてあなたはクラスの現在の不協和音を見て、あなたは何日過ごす必要があるのか​​疑問に思いますこのささいなことですが、何らかの理由でキーボードに触れたくありません。 そして、このコードを見るのは嫌です。

プロジェクト規模

内部プロジェクト

あなたは自分自身またはあなたのチームのためにプロジェクトを書きますが、誰にも見せません。 この場合、多くの自由が許可されます。 もちろん、理想からソフトウェア開発へのアプローチへの逸脱を強制する人はいませんが、本当にしたいのであれば、できることです-これには非難できることは何もありません。 有能なドキュメントを開発する必要はありません、コメントは母国語で書くことができます（開発に関わるすべての人が理解すれば）、そしていくつかの非自明なアーキテクチャソリューション（コードからはまったく明らかではない）はチームメイトに言葉で説明できます。 私はあなたがこれをしなければならないと言っているのではありません。 しかし、たとえば、あなたがどこかで急いでいる場合、いくつかの良い習慣は無視されます。

公共プロジェクト

ここにはまったく異なる状況があります。 お気に入りのユーザーからの100の質問で毎日発生しないように、プロジェクトを適切に文書化することをお勧めします。 そして、ドキュメントを英語で書くことをお勧めします（ただし、コメントとして）。 また、コードクリーナーを記述して、外部の人が簡単に理解できるようにすることをお勧めします。 APIをお持ちの場合は、考え直してみてください。本当に必要な場合は、必要なすべてのデータを何らかの方法で引き出すことができるインターフェイスを貼り付けるだけではありません。 プロジェクトはあなただけでなく、サードパーティのプログラマーにも属していることを忘れないでください-あなたのコードを扱う人を尊重してください。 暗いゲートウェイに巻き込まれたくないようにプログラムを作成し、悪いことをしてください。

具体的なプロジェクト

高負荷プロジェクト

Highloadは独立した会話です。 実際には、優れたアーキテクチャや読み取り可能なコードなど、高性能を実現するには多くの犠牲を払わなければなりません。 最適化後に居心地の良いプロジェクトがどのように変わったかを見て、血の涙を流したい場合があります。 しかし、何をすべきか？ しかし、プログラムの時間は半分になりました。 場合によっては特に選択する必要はありません。

サードパーティライブラリを使用するプロジェクト

サードパーティのライブラリについて話し始めると、同僚の何人かが理解して見てくれます。 そして私は彼らの顔を見ます-彼らは私と同じ苦しみを経験しました。 大規模プロジェクトの実際の状況では、完全にすべての機能を自分で記述することはほとんどありません。 通常、誰かがすでに解決した非常に一般的なタスクに遭遇します。 この状況では、自分で車輪を再発明するよりも、既成のソリューションを採用する方が賢明です。 それは事実ですが、この既製のソリューションの作成者はあまり良いプログラマーではないことが判明する場合があります。 彼らのプロジェクトはその主なタスクに対処していますが、それは書かれていました...まあ、専門的ではありません。 そして、それをあなたのプロジェクトに統合します...まあ、少し複雑です。 この状況は、あなたのきれいな建築を台無しにするひどい松葉杖を再び書くことを強制します。 しかし、この機能を自分で実装することは多くの場合不採算であるため、これは別の生産ニーズです。 （ 秘密をお話しします。何度も我慢できず、サードパーティのライブラリの代わりにライブラリを作成しました。しかし、これはルールというよりは例外です。 ）

初心者チームプロジェクト

平均的な開発者であれば、これ、これ、そしてそれを知っておくべきだという声明をよく聞くことができます。 開発者は言語に堪能であると想定され（たとえば、OOP言語について話している場合は、少なくともポリモーフィズムと継承とは何かを知る必要があります）、問題なく複雑な構文構造を認識でき、プラットフォームの基本的なメカニズムを理解し、基本的なデザインパターンを理解できます（クラスを参照）訪問者という名前で、彼はシステムの特定の断片をすぐに理解します）、英語で簡単にコメントを読みます、そして、彼はもっと多くのことができます。 しかし、少なくとも平均的な開発者になる前は、誰もがその当時は新しい人でした。 そして今日、プログラミングの世界では、この技術を理解し始めたばかりの人がたくさんいます。 彼らが多くのことをする方法を知らず、知らないことは普通です。 数人の初心者プログラマーが集まって小さなプロジェクトを作成する場合、状況は非常に正常です。 開発プロセスの間に、彼らは多くを学びます。 もちろん、彼らはまったく正しくない多くのことをします。 しかし、あなたは彼らにこれを期待すべきではありません。 上級の同僚が別のポイントを提案してくれたら嬉しいです：コードをより良く書き直す方法、読むべき本。 しかし、領主とともに彼らに要求する必要はありません。 初心者向けのプロジェクトでは、「右」からの多くの逸脱は許容されます。なぜなら、彼らは学習しているだけだからです。 ヒントとコツはよく、最初に完全にきれいなコードで理想的なアーキテクチャを書くための要件は完全に良いというわけではありません。

非実動プロジェクト

実証プロジェクト

時々、同僚にクールなものを見せるためにデモプロジェクトを作成する必要があります。 言語、エンジン、ライブラリ、またはこれらの人々がこれまでに遭遇したことのない他の何かである可能性があります。 原則として、デモプロジェクトを非常に詳細に記述し、コードにコメントを豊富に提供する必要があります。 場合によっては、1行のコードで数十行のコメントが発生することがありますが、これは正常です。 完璧なプロジェクトを書くのではなく、コードを例として使用するだけです。 また、コード自体は非常に曲がって長時間動作する可能性がありますが、これは重要ではありません。他の目標もあります。それは、テクノロジーを公開することです。

学術プロジェクト

このプロジェクトでは、誰にも何も見せませんが、私たちはいくつか興味深いものに取り組んでいます。 あるアルゴリズムを研究するとしましょう。 アルゴリズムの10バージョンと一緒に記述するのは正常です。 おそらく、バージョンは異なる言語になります。 命名規則（実際のプロジェクトを開発するときに観察するのがよいでしょう）について気にし、本に示されているように、同じ名前の同一のものを呼び出すことは完全に正常です。 しかし、どの言語でどのような違いが生じますか？ ここではアルゴリズムを扱っていますが、今ではそのようなことを気にする必要はありません。 結果を誰かに見せようとするなら、あなたはすでにコードに取り組むことができますが、これは全く異なる話になります。 それまでの間、学習段階にある間の主な目標は、完璧なコードを書くことではなく、勉強することです。 もちろん、これらのことは組み合わせることができ、アルゴリズムの最も理想的な実装を記述しようとすることができますが、これは必須ではありません。 主なことは、主要な学術目標を完全なコードの目標に置き換えることではありません。

ローカルプロジェクト

まあ、多くの人はすぐにどこでも正しく書くことに慣れる必要があると言うでしょう。 ただし、ローカルコードには固有の特性があります。誰にも見せられる必要はありません。誰にも報告する必要はありません。開発中の考慮事項のいくつかに従ってください。 ワークフロー中に、多くの中間的な不良コードが発生する場合があります。 プラットフォームで遊んで、いくつかの実験を行うことができます。 あなたは私たちに合った方法で開発を行うことができます。 一般的なアーキテクチャに関係なく、最も不適切な場所からローカルファイルに保存するだけで、ある種のデータダンプを作成できるとします。 その過程で、私たちが仕事をする方が都合が良い場合は、任意の言語で任意の数のコメントを書くことができます。
ただし、クリエイティブプロセスが終了すると状況が完全に変わるため、結果を他のユーザーに表示する必要があります（たとえば、ローカル開発を中央リポジトリに送信する）。 この前に、コードをとかす必要があります。 すべての実験、松葉杖、余分なコメントを削除する必要があります。残りのコードはできるだけ明確で読みやすいものにする必要があります。 あなたの著作を扱う人を尊敬してください。

プロトタイププロジェクト

このようなプロジェクトのタスクは、特定の機能をすばやく展開して、外観をより明確にすることです。 これは非常に合理的なアプローチです。 5つの実装オプションがあるとします。各オプションの一般的な概念を簡単に説明しようとしています。 その後、実際の例を使用してすべてのアプローチを確認し、メインプロジェクトの構築に基づいてアプローチを選択できます。 プロトタイピングタスクを正しく理解することは非常に重要です。 そのようなコードを読む必要はなく、完全に書き込もうとする必要もありません。 「この変数はもう少しわかりやすい」または「インターフェイスのこのボタンを1ピクセル左に移動するといい 」などのステートメントでプロトタイプを誓う人々にいつも悲しくなります 。 そこで変数がどのように命名されるかを気にする人、それはプロトタイプであり、そのままにしておきます。 このような議論は、完成したプロジェクトで既に開催することができますが、プロトタイプレベルでは、これは無意味です。

アミューズメントプロジェクト

友人と私は、一人の良い人に良い誕生日プレゼントを作ることにしたことを一度覚えています。 Javaプロジェクトを作成しました。これは、OOP形式で、彼の人生、友人、および彼が対話するさまざまな興味深いものを表しています。 さらに、プログラムは実際に機能し、コンソールからさまざまな面白いコマンドを実行することができました。 ソースコードに関しては、絶対にすべての命名規則（クラス、メソッド、変数など）がロシア語で書かれています（優れたJavaでこれを行うことができます）。 Javadocもロシア語で書かれており、有用な情報はありませんでした。 ロジックは最も簡単な方法で実装されました。 高速で複雑なアルゴリズムの代わりに、最も単純なアルゴリズムを使用しました。 私たちは考え直そうとさえしなかったので、建築はあまり美しくありませんでした。
ギフトは成功しましたが、完璧なコードを書くために良い方法を使用しませんでした。 そして問題は、プロジェクトの目標が完全に異なっていたことです。

まとめ

いくつかの基本的な考え方に再び注意を向けたいと思います。 優れたプログラマーになりたい場合は、絶えず開発し、より良い書き方を学び、自分よりも成長しなければなりません。 あなたは常に、できるだけきれいに書くようにしてください。 ただし、大規模なプロジェクトではコードが完璧にならないことを理解する必要があります。 たわごとに我慢しないでください、恥ずかしがらないように書いてください。 しかし、現在のプロジェクトの目標を忘れてはなりません。ほとんどの場合、完璧なコードへの欲求は目標ではなく、それを達成するための方法に過ぎないからです。 確かに、強制的にコーディングする必要はなく、常に正しく書き込もうとしますが、特別な狂信も見せるべきではありません。 あなたの目標を思い出し、あなたがいる状況を思い出してください。 完全なコードを書くのはそれほど簡単ではありません。 コードとこれらの改善がもたらす効果を改善するための努力を測定します。 優れたコードに関する記事を読んでいる場合は、考えすぎずにどこへでも急いで行く個々のヒントを取り出す必要はありません。 これらのヒントが提示されているコンテキストに注意してください。 問題の状況を考えてください。 よく知られている善を実際に適用することが適切な場合と、そうでない場合を検討してください。 とにかく、もっと考えてみると、これはプログラミングに役立ちます。 そして、すべてがあなたとうまくいくでしょう。