汚れた、きれいな、意欲的な

汚い

一緒に考えてみましょう-きれいなコードとは何ですか、そして汚いコードとは何ですか？ または、アメリカ人が言うように、「毛深いコード」、すなわち 毛深い？



クリーンなコードは、ダーティなコードとどのように違いますか？または、彼らが私たちのインターネットで言うように、「govnokod」とはどう違いますか？ それは本当に必要なのですか、このきれいなコードですか？





最初に定義を取得しましょう。



「きれいな」コードに明確な定義を与えることは単に不可能であるように思えます。 これは部分的に美しさのようなものです。写真を見るか、彫刻があります-そして、あなたが見る：はい、それは美しいです。 または、逆に、い。



はい、たとえば美しいと思われる顔の一般的なパターンを定義することを学びました。 しかし、美の明確な定義を与える準備はできていますか？ 私はそうは思いません。



このアナロジーは完全に正しいわけではありませんが（ほとんどのアナロジーと同様）、コードを操作するときに生じる感覚をほぼ伝えます。 数ヶ月前に書かれて、すでに忘れられている見知らぬ人、友人であるかどうかは関係ありません。 コードはそれに似ているかどうかのどちらかです。 それは美しく、清潔で快適です-または毛むくじゃらで、くて臭いです。



そしてもちろん、誰もが「コードの美しさ」について独自の基準を持っています。 彼自身の、いわば、味。



しかし、それにもかかわらず、いくつかの共通点があり、それらが反論すれば、動きが遅く妥協的です。 本質についてではなく、フレームについて。

それらをリストしてみましょう。

読みやすく理解しやすい	混乱し、自明ではなく、理解しにくい。
変更が簡単	彼の内部接続の麻痺。 何かを変えることは信じられないほどの努力と犠牲です
別のモジュールの形でどこかに展開または埋め込むことができます	拡張の場合、埋め込みの場合は書き換えが必要-ラッパー
自動テスト可能	「ブラックボックス」としてのみテストできます。

もちろん、コードの「読みやすさ」または「わかりやすさ」について議論を始めることができます。 これらは正式な用語ではありません。



しかし、彼らは直感的でもあります。たとえば、誰かが他の人に、「すべてを行う」1つまたは2つの巨大な関数の形でプログラム全体を書くことに慣れていることを証明し始め、少なくとも多数の分割を使用して同じ問題を解決する場合彼のための小さな手順と機能は明確ではありません-彼は基本を厳しくする必要があると示唆されています。



そして、OOPを徹底的に掘り下げ、ロジックを別々のクラスにカプセル化することをお勧めします。これにより、コードの巨大な「フットラップ」を数十の画面に解析したり、多数のグローバル変数で動作する（omg）プロシージャと関数の接続を混同したりすることで、脳に負担をかける必要がなくなります。



残りの状況はほぼ同じです：もちろん、リストされている4つのポイントの中にも、相互に排他的な段落があります（読みやすいコードは常に簡単に変更できるとは限らず、拡張性の容易さはテスト自動化などと競合する可能性があります）-しかし、一般的には状況は明らかです。



原則として、これらのポイント（特定のタスクの要件に応じて各ポイントを強化または弱体化する）に基づいて、ダーティコードとクリーンコードを簡単に区別できます。



あまり詳細な分析をせずに、これが単独で行われるのが最善です。 コードが汚れていて臭いことをすぐに理解できる「香り」がある場合。

きれいに

それでは、それを理解してみましょう-なぜそれが必要なのですか、このきれいなコードですか？ そして、コードは本当に汚くて毛深いですか？



まあ、最初に言う必要があります：それは依存します。

「長くてきれい」よりも「早くて汚い」を書くことがはるかに重要な場合があります。 「ダーティ」は常に「速い」という意味ではないことに注意してください。 まったく逆のことが起こります。





一般に、多かれ少なかれ重要な例を検討し、それぞれの場合-ダーティコーディングが正当化される場合と、絶対に受け入れられない場合-を理解しようとします。

例えば

サーバー上で何かが起こっており、ログが書き込まれています-しかし、それらは巨大であり、誰も読むことができません。 ログを読み取り、そこから数値データを引き出してテーブルに表示する小さなユーティリティを作成する必要があります。 入力はログファイル、出力は数字のテキストです。



そのようなタスクは、好きなだけ汚いように書くことができます-スクラップのみが機能し、書き込みに多くの時間がかからなかった場合。 結局、ここで1つの短期タスクを解決しています。

長期的な問題の解決は、エラー登録システムを変更すること（データベースに同じ数値データを書き込むなど）により、はるかに改善されます。



つまり、このユーティリティは理想的には1回または2回使用され、その後破棄されます。 コードのクリーンさはここでは完全に無関係です。

別の例

サーバーが時々クラッシュするのはなぜですか-誰も知りません。 ログアナライザーを使用すると、同じタイプの多数のリクエストが原因でドロップが発生し、適切に定義されたパラメーター値で到着することを理解でき、この状況を早急に再現する必要があります。

この動作を正確に再現する小さなユーティリティを作成する必要があります。



一見、最初の例を繰り返します。 ただし、ここで疑問が生じます。テストプロセスではそのような状況を再現できないため、このユーティリティをテストツールとしてさらに開発する必要がありますか？ 定期的に使用される独立したアプリケーションになりますか？



答えが「はい」または少なくとも「可能」である場合、コードが開発者自身にとっても1か月または2か月で理解可能であると同時に、何らかの形で自分自身を拡大できるようにすることに少し注意を払う必要があります。

たとえば、他のリクエストシーケンスを追加し、サーバーアドレスとリクエスト数、キーパラメータの値などを設定します。



これにより、「here and now」ユーティリティの開発が若干遅くなりますが、サーバーへのリクエストのシーケンスを再生するという質問が再び発生する場合、ユーティリティはすぐそこにあり、最小限のdopilivanieが必要になります。 そして最も重要なこと-何が起こっていたかを思い出すための最小時間。

3番目の例

数年にわたって市場で成功裏に開発されてきた会社の主要なソフトウェア製品のためのソフトウェアモジュールの開発。



モジュールが分離され、他のモジュールとの相互作用インターフェースが定義されているように見えます。 「ひねり、ひねり、govnokodを書きたい。」 しかし、その後、深刻な「しかし」が発生します。



6か月後にこのモジュールはどうなりますか？ 年？ 彼はサポートが必要ですか？ 変更？ 機能拡張？ おそらく最終的には別の製品に発展するのでしょうか？

少なくとも1つの質問で少なくとも「おそらく」答えが得られる場合、たわごと、悲しいかな、そしてああ、厳密にはお勧めできません。



しかし、これは質問の全リストではありません。 そして、2〜3年後に誰がこのモジュールを使用しますか？ それを書いた人、または他の誰か？



他の誰か-もし彼はこのコードを理解する必要があります。

そしてこれが悪い、役に立たないコードである場合、サボテンを泣いて噛んで、作成者を呪うか、すべてをゴミ箱に入れて書き直しますが、当局からpodzhopniksを期限を破って受け取ってください。



開発者自身がこのコードを使用する場合-さらにそうです。 はい、6か月後には、何、どこで、どのように機能するかを思い出せなくなります。 彼は、コードが完全に異質であるかのように、このコードを理解する必要があります。 彼は自分の敵ではないのですか？

4番目の例

少しのお金で短時間で注文するアプリケーション（ウェブサイト、最もシンプルなインターフェースを備えたデータベース-何でも）の開発。



一方で-コーディングして忘れても、それが機能するのであれば、何でも何でも書くことができます。



一方、この顧客が1か月後に戻ってきて、追加するものや追加のお金をやり直すものを要求した場合はどうなりますか？ 泣き、刺すが、サボテンを噛む？ 注文を拒否しますか？



しかし、彼が別の開発者（会社）に目を向け、プロジェクトの品質に関する否定的なフィードバックを受け取り、「邪悪なgovnokodery」に戻らず、友人に助言すればどうなるでしょうか。



私はカルマの質や後世の記憶などについて語っていません。

5番目の例

チーム開発。



govnokodirovaniyaの絶対予防の最も深刻なケース。

チーム開発の場合、意識的に悪いコードを選択することを支持する議論を想像することすら困難です。



私が言えること-1人のgovnokoderは敵の背後にいる敵のエージェントよりも多くの害を及ぼすことができます！

チームがそれを分離せず、完全に残されたユーティリティとミニアプリケーションを残して、何にも関係なく、誰にも危害を加えない場合、チームの生産性はゼロではありません。マイナスになります。



読み、掘り下げ、修正し、宣誓する必要があります-そして最終的に投げて書き直します-独立して良いコードを開発するよりも時間がかかるだけでなく、チーム内の一般的な雰囲気を台無しにし、くだらないコードに対処することを余儀なくされるすべての開発者のモラルをマイナスします私のせいで。



テストはどうですか？ 護衛？ 機能拡張??



さらに冒とく的な段落を2つ書くことができますが、できません。 できません。

キーボードは、govnokodがチームにどれほどの害を及ぼす可能性があるかを考えて、弱った指から外れます...

これはひどい...ひどい...

志望

したがって、ダーティコードとは何か、なぜ悪いのかは大まかに理解できます。 純粋なコードが何であるかはまだよくわかりませんが、その必要性を感じています。

なぜ常にそこにあるのか、この汚いコード、なぜそれが常に存在し、その作者を含むすべての人の人生を台無しにするのか？



私の意見では、すべてが非常に簡単です。きれいなコードを書くことは芸術であり、実際に誰でも自分で開発できる超大国です。 しかし、誰もがその開発の必要性について考えているわけではありません。



専門大学や専門コースでこの主題のアイデアを得ることは言うまでもありません-彼らは「必要な」技術、プラットフォーム、言語の最上部のみを提供します-一般的に彼ら自身の純粋なコーディングスキルの向上に特別な注意を払いません。



もちろん、時間の経過とともに、開発者が「汚いコードの感覚」を開発した場合、開発者は必然的に、よりクリーンで優れたものを書き始めます。

彼は余暇に興味深い記事を読み、デザインパターンを研究しています。 しかし、彼が興味を持っているのでこれを行うのは偶然です-きれいなコードを書くスキルを開発する必要性を理解しているからではありません。



そして同時に、理想的には、彼は常に自分のコードがまだ十分ではないと感じ、完璧からはほど遠いと感じています。 そして、たとえ彼の現在の「govnokod」が彼が2、3年前に書いた最高のものの上にカットされたとしても-まだ成長する余地があります。



この点で、私のような同僚との興味深い会話を思い出します。同僚は、私のように、開発者の地位の候補者と複数のインタビューを行う機会がありました。



私たちは若いプログラマーについて、そして何がプロフェッショナル開発の可能性を最も証言しているのかについて話しました。

最終的に、重要度の順に、いくつかの簡単なポイントになりました。



1）うまく機能する頭（だから私たちは常に論理パズルを持っています）

2）高レベルの自己批判（したがって、コードを記述してエラーを見つけるタスクが常にあります）

3）プログラミングへの関心（それほど重要ではないが、タスクは原則として決定されない）



つまり、頭がうまく機能しない場合、あなたは意志と勤勉さをすべて備えた開発者にはならないことは明らかです。 しかし、たとえそれが金色で知性に満ちていても-これは保証にはほど遠いです。



若い専門家は、（特に-ほとんどのクラスメート、仲間の学生、仲間だけと比較して）彼にとってそれがいかに簡単であるかを見て、卵だけが涼しいと心から信じるようになります。

そして、おそらくこれにはいくつかの理由がありますが、ChSVは非常に優れており、「私はすでに頭が良く、これに挑戦しようとする人はだれでも」と信じて、ある日最終的に開発を停止します。



そして、彼がまだ彼の作品に活発で熱心な関心を持っているのは良いことです。 彼が「面白いから」記事や本を読み続けると。 それから彼は、凍結することはありませんが、開発を続ける可能性はわずかです。



そして最後に、男（または少女-あまり一般的ではないが、この政治的に間違った現実を許してくれます）と賢く、自己批判的-まれに彼のコードに満足していることはほとんどなく、一般的に彼はまだ成長し、成長しなければならないと信じています-その瞬間、職業に対する興味が（完全ではないにしても）失われ、読みが少なくなり、実験が少なくなります。



彼は「仕様に厳密に従って」タスクを実行することをより頻繁に開始します。できれば、使い慣れた領域から既に慣れているタスクを実行してください。 新しい言語、プラットフォーム、概念にあまり注意を払わない。



そして、それは非常に優れたフィットのスペシャリストになります。 多くの場合、それほど狭くはありませんが、比較的学際的です。 尊敬します。



しかし、それは本来の可能性の頂点には達していません。



そして、非常にまれな場合にのみ、知的で能力があり、非常に自己批判的な、燃えるような目を持つ若者は、毎年、毎時間成長し、最終的にはスターになります。 非常に急速に「ローカルの名人」になりますが、フリーズせず、これに限定されず、成長、開発、改善を続けます。



ああ、この写真の美しさ-存在しない涙を一掃したい！ 彼はなんと美しいのでしょうか。この無限に若い男は、精神的な衝動で、彼のすべての貫通する視線が向けられている天国を持ち上げます！



彼の道の素晴らしさを理解したとき、彼の周りの人々がどれほど幸せであるか、そして彼の隣に少なくとも2つまたは3つのステップを踏みます。 彼が全速力で飛ぶ可能性のその美しい無限大に少なくとも髪に近づきます！



燃えるような目をもっと見たい、明るい心はこの無限に向いた。 少なくとも少しの間、これらのアトランティス人を支援し、少なくとも少しの間、彼らをより高く押し上げ、この達成不可能で素晴らしい目標に近づけたいと思います。



そして、下にとどまり、彼らが追跡の空間と時間をどのように貫通するかを見る喜びを感じながら。



そして、少なくとも少し、少なくとも少し-彼は助け、支持し、傍観しなかった、彼自身の重要性によって携挙で凍りついて、軽的な目を向けなかったことを知るために-「Phe ... youth ..」