8つのプログラミングの落とし穴

この記事には、私が自分自身に陥り、陥り続け、おそらく決して止まらないプログラミングトラップと、仲間を見つけたプログラミングトラップが含まれています。

ただし、どのトラップに陥る可能性があり、それらから抜け出す方法を知っていれば、それらを回避できると考えています。 おそらく、この信念は別のtrapです。

簡単な紹介

あなたが穴に落ちたと想像してください。 深さ3メートルにします。 あなたはそれから抜け出し始めます、スクランブル、しがみつきます、私はあなたが思い付く他のものを知りません、しかし、あなたはおそらく出るでしょう。

プログラミングでは、trapに陥ることもあります。 しかし、穴を例えると、深さ50メートルで、上から重い鉄板で覆われています。

あなたはどう思いますか、そのような穴にどれくらい滞在しますか？

おそらく誰かがあなたを見つけるまで！

しかし、これはそれほど大きな問題ではありません。すべてのプログラミングトラップから、余計な労力をかけずに抜け出すことができます。3つのことを知っておく必要があります。

トラップのプログラミングには驚くべきことが1つあります。ほぼすべてのトラップは、正反対の2つの極端のいずれかに対するコミットメントです。

わなを避けることは狭い道を歩んでいると言えます。左側は問題であり、右側はそれを解決する方法であり、不条理に至ります。

さて、とにかく誰も紹介を読んでいないので、行きましょう！

---

トラップ＃1：最適化

Knutが書いたように、時期尚早の最適化はすべての悪の根源です。 多くの人がこのルールを知っており、従わない人もいれば、絶対に引き上げる人もいますが、遅れた最適化がさらに悪いことを知っている人はほとんどいません！

最適化に集中しすぎる

多くの場合、オリンピックのようにこのタイプのプログラマーは罪を犯します。 効果的なアルゴリズムまたはプロセッサの内部構造の知識は、コードが可能な限り効率的であるべきだと考えさせます。

実際には、最適化には時間がかかりすぎ、コードは完全にサポートされず、拡張性がなく、エラー耐性があります。

閉じ込められている兆候

•迅速でリソースのないコードをすぐに書き込もうとする試み
•他の指標を損なうために、コードからすべてを絞り出したいという欲求
•O（n ^ {2}）の代わりにO（n）を使用するか、2を乗算するすべての演算をビット単位のシフトに置き換えると、プログラムがキャンディーになる

最適化フォーカスが低すぎます

まだ未完成のプロジェクトの1つが終わりに近づいています。 時期尚早な最適化のエラーを回避しようとして、最適化は最後まで忘れられました-最後の（完全に正直な場合、最後から2番目の）ステージに移されました。

今、半分以上が準備ができたとき、私は気づいた-1つのtrapを避けようとすると、私は反対に陥った！

パフォーマンスを許容レベルまで向上させるには、プロファイラーを数回実行し、関数で分離されたいくつかのアルゴリズムを修正するだけでなく、すでに作成されたコードの少なくとも3分の1を書き換える必要があります！

このトラップと呼ばれます-遅延最適化、事前に最適化の可能性を提供しない場合、美しく理解しやすいコードの大部分を捨てなければならないという事実に備えてください！

閉じ込められている兆候

•最適化は時期尚早であるという誠実な信念
•プロジェクトの最終部分まで最適化を遅らせる
•将来の最適化のための小規模なアーキテクチャソリューションの提供の失敗

出口

•コードをすぐに最適化しようとしないでください-将来の最適化の機会を作成してください
•理由もなく最適化を遅らせない
•ルール20/80：結果の80％を与えるコードの20％に時間を費やす（はい、プロファイラーを使用します）

---

トラップ＃2：抽象化

プログラミングの抽象化はおそらく最高のものです。 まず、バイナリコードがあり、次にプロセッサ命令のニーモニック、命令型プログラミング-状態と操作（ステートメント）、構造、手続き型、モジュラー、オブジェクト指向、関数型プログラミングがありました。

gotoを使用してループを整理する必要があることを想像してください。

（動的型付けとテンプレート/ジェネリックを利用する代わりに）データのタイプのみが異なる同じ関数を作成する必要があることを想像してください。

コレクションを取得してサイズ変更することはできないことを想像してください。新しいメモリを割り当て、そこに古いコレクションをコピーし、新しい要素を追加して、未使用のメモリを解放する必要があります。

過度の複雑さ

繰り返しますが、私たちは世界のすべてを抽象化する試みが不条理のポイントにもたらされるtrapから始めます。

20のクラスを積み上げ、12の異なるパターンを使用し、DSLを実装して別のDSLを解析し、循環グラフを視覚化して別のテトリスを作成するクロスプラットフォームフレームワークを作成します。これは「抽象化のチャンピオン」です。

閉じ込められている兆候

•基本機能を実装する前にユニバーサルフレームワークを作成します。さらに、作成したコードの30％の強度で使用されます。
•問題を解決する最善の方法は、何らかのパターンを使用することであるという信念
•最も一般化されたものを書き、世界のすべてを受け入れ、機能が使用されない場合でも、特殊な値ではなく、関数の入力値に対して正しい結果を与える

無限への単純化

「抽象化のチャンピオン」の兆候は、経験豊富なプログラマーの間でより一般的です。 抽象化を無視するのは初心者向けです。 最高のものは、これらの両極端のどこかで再びバランスを取っています。

初心者は多くの場合、プログラミング全般および特に使用する言語の抽象化がまだわからないことがよくあります。 このため、彼らは多くの場合、表現力に欠けるコードを作成します。組み込みの言語ツールまたはサードパーティのライブラリ/フレームワークを使用して書き換えることができ、より短く、より理解しやすく、ほとんどの場合、より効率的です。

閉じ込められている兆候

このアイテムの場合、共通の機能を選択するのはかなり困難です。すべての機能は、言語、タスク、およびその他の多くの要因に依存しますが、それでもなお：

•コードを客観的に改善できる抽象化を無視します（たとえば、C ++のイテレータ、Haskellのモナド（意味のあるモナドの記述を拒否することを意味します）、Pythonのジェネレータ、Javaのインターフェイスなど）
•新しいプログラミング言語への切り替え時-抽象概念を学ぶことを拒否します。それがなければ良い生活だったので（例、CからC ++に切り替える場合-イテレータを学ぶことを拒否する、命令型言語からHaskellに切り替える場合-拒否する）モナドの学習から）
•実際に使用していない言語の機能は不要であるという信念（C ++プログラマには適用されません。もちろん、ジョークはありますが、あらゆるジョークで知られているように...）

出口

•抽象化に抽象化を使用しないでください。
•よく知られたアクセス可能な抽象概念が属する場所では使用し、場所がない場所では使用しない
•プログラミング言語が提供する抽象化を学ぶ
•機能を実装する前に、本当に必要かどうかを考えます（YAGNI原則）
•多くの損失なしに抽象化なしで実行できる場合-それらなしで実行する（KISS原則）

---

トラップ3：完璧主義

おそらく、コードを受け取って書くだけのことをあまりにもよく知っている開発者の間で最も人気のあるトラップでしょう。 ハブに関するすばらしい小さな記事がこのトピックに関して最近公開されました。記事へのリンクは記事の最後にあります。

卓越性を目指して

私の前にこのトピックに関するすべてが噛まれましたが、一貫性を保ちたいので、骨によってこのトラップも分析します。

閉じ込められている兆候

•コードの主なものは美しさ、読みやすさ、保守性であるという信念
•許容可能なコードの継続的なリファクタリングと書き換え
•コード内の欠陥を検索する
•合理的な時間内に完璧なコードを書くことができるという信念
•細部への注意の向上
•可能な限り最高の結果を達成しようとします。
•プロジェクトの最も単純な部分でさえ、アーキテクチャを熟考する

カオスの道

前のリストから、完全主義が危険なtrapであることは明らかです。完全に放棄することはできますか？

おそらく、コードの純度を完全に無視して、リファクタリングを拒否し、批判的思考を無効にする方が絶対完全主義よりも優れているでしょう（結局のところ、悪い結果は結果であり、絶対完全主義者は書かれたコードを捨てるだけです）、ここではバランスが重要です。

したがって、卓越性の追求を完全に拒否すると、まったく反対のtrapに陥ります。

閉じ込められている兆候

•コードの読みやすさと拡張性は重要ではないという考え
•特にコードに関連する批判的思考の欠如
•最低限の受け入れ可能な結果でさえ満足できる、またはまったく受け入れられない
•リファクタリングの完全な拒否
•アーキテクチャの複雑な部分について考えることを拒否
•プロジェクトまたはプロジェクトの一部を最初から書き換える機能を受け入れられない

出口

いつものように途中で：

•コードの美しさと結果の達成が重要であり、2番目のコードがさらに重要であることを受け入れる
•最後の手段としてゼロから書き直すことを検討しますが、必要な場合があることを受け入れます。
•リファクタリングに費やすことができる最大時間を許可します。 作業時間全体の20、50、さらには80％である可能性があります。主なことは、それを超えないことです。
•欠陥を発見したら、それを修正するのに時間を費やすのに十分強いかどうかを検討します。
•20/80ルールを使用する-最初に、結果の80％をもたらす作業の20％を実行してみてください。

これらのヒントが、ハブロフスクの人々の完璧主義のtrapから抜け出すのに役立つことを願っています。 それらのすべては、この病気に対処する苦い経験を​​通して理解され、私がプログラミングをしてきたすべての時間の間文字通り苦しみました。

---

トラップ＃4：テクノロジーとツール

プログラミングは止まりません。今では、あなたが自由に使えるツールとライブラリがあり、それらがあなたのためにすべての仕事をしなければ、間違いなく簡単になります。

ただし、頻繁に使用されることもまれにしか使用されないこともあります。 最初のケースから始めましょう。

怠azine

もちろん、すでに作成されたライブラリ、フレームワーク、およびツールの使用は、怠の合理的な現れにすぎませんが、時には善意でさえも行き過ぎです。

Hello Worldを作成する際に、ブースト、Qtを同時に接続し、STLを積極的に使用することは良い考えではありませんが、時々同様のことが起こり、これは別のtrapです。

閉じ込められている兆候

•Mersen Whirlwindのために、30 MB以上のライブラリを接続する
•必要なものはすべてすでに書かれているという信念
•自転車の方が良いかもしれないことを受け入れない
•IDEで自動補完なしにコードの行と行を書くことができない
•作業の原則を理解することなく、ツールを積極的に使用する。 たとえば、GUIビジュアル編集ツール（Qt Creator、CodeGear Rad Studio、MS Visual Studioなど）を頻繁に使用し、同時にデバイスの把握を拒否する

仕事中毒

これは、すべてのツールとライブラリの使用を放棄し、nano（またはさらに悪いことに-パピルスで）のバイクで裸のコードを書くことを促すことを皆に促すことを意味しますか？

まったくありません。 それどころか、あなたが見るように、プログラムによる継承を完全に無視することはさらに悪い悪です。 そして、おそらくプログラマにとって最も危険なtrapです。

閉じ込められている兆候

•正当な理由なしに、ますます多くの自転車を定期的に書く。
•言語と標準ライブラリの機能がすべてに十分であるべきだという信念
•オートコンプリート（Sublime Textではなく、IDEでのように）が硬化薬であるという信念
•巨大ではありますが、既存の類似物に機能的にも近い独自のライブラリを作成する
•自分のコードがどのように機能するかを理解していない人には、デバッガーとプロファイラーが必要であるというステートメント

出口

•使用可能なツールを知ってください。ただし、どこでも使用しないでください。
•サードパーティのライブラリを使用するか、自転車を書くかを選択する前に、長所と短所を慎重に検討してください。
•最新のツールを使用して生産性を向上させ、同時にそれらに依存しないでください
•トレーニング/テストプロジェクトでこれらのルールに例外を設けることができることを受け入れます。

---

トラップ5：ゴールデンハンマー

トラップチャートのもう1つのポイントは、金色のハンマーです。

ゴールデンハンマーは悪い習慣です。 いくつかの問題を解決するときにメソッドが機能した後、閉じ込められた人は可能な限りこのメソッドを使用し始めます！

同様の用語がいくつかあります-万能薬、魔法の薬、銀の弾丸、つまり 常に、100％の場合、任意のタスクを実行するメソッド。 このトピックの別のことわざは、顕微鏡で釘を打つことです。

ゴールデンハンマーはかなり一般的ですが、他のトラップとはまったく異なります。 どんなものでも黄金のハンマーになることができ、誰かがOOPに夢中になり、すべての人、デザインパターンの誰かのためにクラスを書き、工場とシングルトーンのみからプログラムを構築できます。

ある人にとっては、黄金のハンマーはお気に入りのプログラミング言語であり、ある人にとってはお気に入りのパラダイムであり、ある人にとっては開発方法論です。

金色のハンマーを区別する主なことは、いつでもどこでもそれを使用する試みです。

閉じ込められている兆候

•すべてのタスクに1つのプログラミング言語を使用する
•1つのパラダイムですべてのプログラミングの問題を解決できるという信念（ほとんどの場合、OOPとFPについてのことを言う）
•1つの開発方法論の条件に関係なく、すべてのプロジェクトで使用できます。たとえば、すべてのプロジェクトでTDDを軽率に使用できます
•ほとんどのタスクのために、言語が提供するツールの使用。たとえば：
-すべての引数を定数リンクのみで渡す
-プログラム全体で1種類のコレクションのみを使用する場合、たとえば配列（ベクトル）
-どこでも触知できないオブジェクトの使用
-同様の構文言語（JavaやCなど）で使用する
同じインデントスタイルとエンティティの命名方法

特効薬は存在しません

このトラップはルールの例外であり、別のトラップに陥る危険を冒すことなくそれを回避することが可能だと思います。

私が再び気付いたパターンのこの例外は、金色のハンマーが存在しないことを証明しています-トラップを二重実体として誤解したと説明する私の方法ですが、使用を拒否することを恐れていません。

これは、このtrapから自分を解放する正しい方法です。

出口

•プログラミング言語が1つしかわからない場合-もう1つまたは2つ（おそらくそれ以上ですが、合理的な範囲内で）
•いくつかのプログラミング言語を知っているが、明らかなお気に入りがある場合は、他の言語をより頻繁に使用してみてください
•命令型プログラミングまたはオブジェクト指向プログラミングのみに準拠してプログラミングした場合は、機能的な
•常に1つの開発方法論を使用している場合は、何か新しいことを試してください。
•慣性に関する決定を下す前に（そして金hammerを使用する前に）-可能な代替ソリューションを考えてください

---

トラップ＃6：クロスプラットフォーム

クロスプラットフォームアプリケーションとは、複数のオペレーティングシステムや複数のプラットフォームで実行されるアプリケーションです。

そして、ここでも2つの極端があります-一部の開発者は、すべての可能なOSで動作し、PC、タブレット、スマートフォンに等しく適しているようにアプリケーションを作成しようとしています。

みんなとみんなのために

多くの場合、人々は信じられないほどのクロスプラットフォームを達成したいと考えています。

その結果、アプリケーションはどのOSでも完全に正しく動作せず、PCやタブレット、スマートフォンで使用するのも同様に不便です。

それらは、過剰なクロスプラットフォームに閉じ込められています！

閉じ込められている兆候

•変更することなく、すべてのターゲットプラットフォームで許容可能な結果を​​生成するコードを作成できると考える
•移植やコードの少なくとも一部の変更を望まずに、できるだけ多くのオペレーティングシステムとプラットフォームをカバーしようとする
•1つのプラットフォームのみを対象としたコードを嫌う

Win32のみがあります

そしてその逆-一部のプログラマーは、作成者と同じOSでのみ動作するソフトウェアを作成します。さらに、まったく同じマウス、キーボード、仮想現実ヘルメットが必要です。

多くの場合、この理由は、プログラマが使用しているもの以外に他のOSやプラットフォームがあるという事実を考えていないからです。

閉じ込められている兆候

•各ターゲットOS /プラットフォームのすべて（またはほとんど）のアプリケーションコードの書き換え
•これを回避できる、意図的に移植が困難なコードを記述する
•カスタムコンパイラ/インタプリタ拡張機能の使用

出口

•ターゲットOS /プラットフォームを慎重に識別する
•一部のOS /プラットフォームでは、コードの一部を変更するか、ゼロから別のバージョンを作成する必要があるという事実に備えてください
•故意にコードを1つのプラットフォームにバインドしないでください
•これにより開発が困難になる場合は、複数のプラットフォームにまたがるようにしてください

---

トラップ＃7：防衛

（なしで）防御的プログラミングは、あなた自身（現在または過去）を見る可能性のあるもう1つの素晴らしいトラップです。

無防備なプログラミング

無防備なプログラミングは、防御的なプログラミングの実践の反対です。関数には常に正しい引数が渡される、副作用がない、またはコードの操作に影響を与えない、ポインターがnullにならないなどと考えられています。

場合によっては、コードが多くのチェックから解放されることもありますが、そのようなコードのデバッグは大変です。 それがトラップである理由です。

閉じ込められている兆候

•フィアレスネスオーバーフロー、ゼロ除算および丸め誤差
•標準およびライブラリ関数/クラスの絶対的な不確実性に対する信念
•ユーザーが入力するときに間違いを犯さないという信念
•記憶は決して終わらないという信念
•アプリケーションに必要なすべての構成ファイルが存在し、常にそれらにアクセスできるという信念

防衛的プログラミング

アプリケーションの明らかに動作する部分、各関数内の15個のASSERT、独自の例外ライブラリ、ロギング、わずかな逸脱でアプリケーションをドロップしようとする数百万のテスト。

これはコインの裏側です-防御的なプログラミングのtrapです。

閉じ込められている兆候

•プロジェクトの各機能は、アサーションのパックまたは例外の発生で始まります
•テストは、サードパーティライブラリを含むすべてのコードを完全にカバーします。
•プロジェクトには、独自のクラスMyProjectExceptionと、少なくとも10の子孫の複雑な階層があり、その意味は、誤った関数引数のレポートに限定されます。
•アプリケーションで発生するほとんどすべてのログ
•わずかな逸脱でも受け入れられないため、エラーメッセージを表示してアプリケーションをドロップし、完全なメモリダンプを含むバグレポートを自動的に送信する必要があります。

出口

•チェックする価値があるものとそうでないものについて慎重に検討します。
•ユーザー入力と外部リソースを確認するときは、特に注意してください。
•可能な限り標準の例外クラスを使用するようにしてください。
•すべてをチェックしようとしないでください
•重大なエラーをマイナーなエラーから分離し、本当に悪いことが起こらなくてもアプリケーションが動作し続けるようにする
•最も重要なデータのみをログに記録し、バグレポートを送信する控えめな機能を実装する

---

トラップ＃8：スヌーズ

この問題のバランスを見つけるのは非常に難しいため、トラップは非常に興味深いものです。

トラップの本質は、ある種の機能を実装することが多いことです。TODO、HACK、その他いくつかのメモを付けます。

これらのタスクの実現は自分で延期され、TODOを覚えている人はめったになく、長い間未完成のままです。

閉じ込められている兆候

•プロジェクト内の多数のTODOおよびHACKマークとその数は減少しません
•コードレビューは、新しいTODOとWTFの配置を除いて、結果をもたらしません。
•タスクに間接的に関連して（TODOを離れる代わりに）実装したり、検出されたエラーを修正する（FIXまたはHACKを離れる代わりに）ためにタスクから少し注意をそらすことができない

マルチタスクプログラマー

プロジェクトの一部の実装中に、直接関連していても（たとえば、「TODO：check argument to null」というマークを残すのではなく、例外クラスを記述して破棄するなど）、実装中に切り替えることができないプログラマがいます。

逆に、これを行うことができるプログラマーもいますが、私はそのようなマルチタスクプログラマーと呼んでいますが、問題は実際のマルチタスク処理がなく、実際、あるタスクから別のタスクにすぐに切り替わることです。

これにはプラスがあります-TODOとHACKはコードに設定されていませんが、すぐに修正され、別のコードで見つかったエラーは排除されます。

そして、いつものように、これは無料で提供されません。その結果、頻繁に切り替えるため、プログラマーは最初のタスクを忘れたり、完了する時間がない場合があり、再び戻ったとき、どの方向に移動していたか覚えていません。

プロジェクトのさまざまな部分をすばやく頻繁に切り替える場合は、悪いニュースがあります。

閉じ込められている兆候

•後でタスクに集中するために単一のTODOを残さない
•頻繁に切り替えるため、1つの機能の実装を開始すると、代わりに2つの完全に無関係な機能を実装する
•ペアでプログラムする場合、パートナーはあなたの考えを追跡できません

出口

•タスクを延期してTODOを設定する前に、タスクを迅速に実装する方法を検討します
•メインタスクから気を散らすことを恐れないでください。しかし、あまりにも頻繁に、そして長時間実行しないでください。
•コードを検査し、すぐに見つかったエラーを修正する
•現在のタスクに関係のない大規模な機能を延期する-TODOを残す
•ペアでプログラミングする場合は、切り替えをまったく行わず、無関係なタスクをすべて先送りする

---

参照資料

• AlenaC ++：時期尚早の最適化に関する見積もりを実際に所有しているのは誰ですか
• Wordpresse：セキュリティプログラミング

• Habrahabr：遅延最適化
• Habrahabr：プログラマーの無能な5つの段階
• Habrahabr：これらの無数のパラダイム、概念、ツール、およびフレームワーク
• Habrahabr：麻痺解析：コードを書くだけでは知識が多すぎる
• Habrahabr：理解しなければならない3つの重要なソフトウェア原則
• Habrahabr：クロスプラットフォームは素晴らしい
• Habrahabr：クロスプラットフォームのハードウェア：解決策はありますか？
• Habrahabr：セキュリティプログラミング

• ウィキペディア：KISS
• ウィキペディア：YAGNY
• ウィキペディア：DRY
• ウィキペディア：完全主義
• ウィキペディア：ゴールデンハンマー
• ウィキペディア：先延ばし

結論の代わりに

ロープを歩いて頑張ってください！