テスト中
プログラムにバグを1つまたは2つ残しておけば、あなたの後に来る人が楽しみを持つことができます。
1.エラーハンドラをテストしない
ハードウェアまたはオペレーティングシステムの障害を処理するコードをテストしないでください。 とにかく、このコードは決して実行されず、開発プロセスを遅らせるだけです。 また、コードがディスククラッシュ、ファイル読み取りエラー、オペレーティングシステムクラッシュ、およびその他の特別な状況をどのように処理するかをどのように確認できますか？ 結局のところ、このためには、非常に信頼性の低いコンピューターか、それをシミュレートするサンドボックスが必要になります。 最新のハードウェアが失敗することはありません。テストのためだけにコードを書くのはどんな馬鹿でしょうか？ いいえ、これは面白くないです。 ユーザーが苦情を言った場合、OSまたはハードウェアに責任を負わせます-なぜそうなのかを知る必要がありますか？
2.ストレステストを行わない
何かが十分に速く動作しない場合は、より強力なコンピューターを購入するようクライアントにアドバイスします。 ストレステストを行うと、ボトルネックを見つけたり、アルゴリズムを変更したり、プロジェクトを完全にやり直したりする必要があります。 誰がそれを必要としますか？ さらに、顧客で発生するパフォーマンスの問題は、エキゾチックなエリアへの無料旅行を提供します-最も重要なことは、パスポートを準備しておいてください。
（いいえ、主なことは、問題はコートダジュールまたはバリで発生するべきであり、極北や別のトゥムタラカンでは発生しないことです-約
3.テストケースを作成しない
コードカバレッジまたはパスカバレッジをテストしないでください。 自動テストは弱虫用です。 コードの呼び出しの90％を担当する関数を見つけ、それらのテストを記述します。 ほとんどの場合、この方法でコードの約60％をテストし、残りの40％の労力を節約できます。 これにより、プロジェクトの終了時に期限を守ることができます。 誰かがいくつかの追加機能が機能していないことに気付く頃には、すでにその痕跡があります。
4.テスト-co病者向け！
あまりにも多くのプログラマーが恐れている-彼らは上司、クライアント、郵便を恐れ、仕事を失うか、法廷に行く。 この恐怖は生産性を麻痺させ、低下させます。 調査では、テスト段階を除外することで、スケジュールよりも早く作業を行うことができ、これらの不安のほとんどが解消されることが示されています。 したがって、勇敢なプログラマーはテストしません。彼らの目標はコードを書くことであり、ヘルプシステムとテクニカルサポート部門はエラーの修正に対処します。
人がプログラマとしての能力に完全に自信がある場合、テストは必要ありません。 考えてみてください。テストは技術的な問題を解決しないことは明らかです。いや、それは感情的な自信の問題です。 テストを除外し、プログラマーを自尊心を高めるコースに送る方がはるかに効率的です。結局のところ、コードのすべての変更は何年もテストする必要があり、コースを1回だけ完了するだけで十分です。 その利点は明白で驚くべきものです。
5.デバッグモードのみが機能することを確認する
デバッグモードでは、メインモードの一部ではないコマンドを実行できます。 必要なロジックの一部をデバッグモードに転送し、メインロジックから削除します。 適切な工夫をすれば、コードのメインバージョンはコンパイルされません。
（ちなみに、これは関連性があります-偶然ではありますが、最近このレーキを踏んだ-約）
言語選択
（このエッセイは1996年に書かれ始めたので、正確なアドバイスは明らかに無関係であり、それに続くことはほとんどありません;主なアイデアのみが与えられています-およそ。）
プログラミング言語の開発における一般的な傾向は、愚か者に対する保護の信頼性と品質を高めることです。 したがって、最新の言語を使用しないでください。最古の言語を使用してください。これは、あなただけが許可します（ただし、まだプログラミングできる言語です）。
チームワーク
地獄は他の人です
このエッセイでは、仲間を激怒させる方法、上司が付随するコードを取得しようとするのを止める方法、リポジトリ内のコードをフォーマットするトピックでユニバーサルホリバーを開始する方法についてのヒントが常にあります。 その他のヒントを次に示します。
1.キリンは大きいです、彼はよく知っています
上司がFORTRANでの20年の経験が現代のプログラミングに最適であると信じている場合は、厳密に彼の推奨事項に従ってください。 その結果、上司はあなたを信頼し、あなたのキャリアはこれから利益を得ます。そして、あなた自身がコードを難読化する多くの新しく興味深い方法を学びます。
2.技術サポートなし
電話に出ないでください。 メールに追跡番号を割り当てたら忘れてください。
3.口を閉じて
Y2Kのような問題には注意しないでください。 特定の瞬間に忍び寄って西半球の生命を破壊する何かに気付いた場合は、時間H（イベントの瞬間から4年を引いた時間）までパニックを起こさないでください。
（災害映画の台本のように聞こえますか？-約あたり）
友人、知人、または他の有能な人に言わないでください。アイデアにつながる可能性のあるものを公開しないでください。 上司に（通常の優先度の）メモを1通送って、お尻をカバーします。 この手紙を別の重要かつ緊急の添付ファイルとして追加できます。 その後、あなたは静かにやめることができます。Hの時間に彼らはあなたに給料の天文学的な増加で戻ってくるようあなたに懇願するでしょう。
4.クラブ「今月の本」
本を書くのに忙しすぎて自分でプログラミングできない著者を選択してください。 地元の書店を検索して、コード例のない大量の図を含む本を探します。 受け取った本を閲覧し、数百のあいまいで美しい言葉を学びましょう。この言葉を使って、あなたに続く取るに足らない人を威inすることができます。 あなたのコードは印象的です。 広大で理解できない語彙により、人々はあなたが非常に賢く、アルゴリズムが非常に複雑であると考えるようになります。 完全を期すために、説明では平凡な類推を避けてください。
5.天才のふりをする
天才は、彼らの平均的な同僚が彼らに遅れずについていくかどうかについてあまり心配していません（そして、彼らの苦しみからサディスティックな喜びも経験します）。 あなたが天才でなくても振る舞います。 少なくともみんなに、彼らが十分に賢いなら、彼らはあなたの独創的なコードを理解するのに問題はないだろうと言ってください。
6.ばかのふりをする
（前の段落と矛盾しますが、はるかに単純です-約Per。）
あるCプログラマーは、組み込みの数値定数の代わりに名前付き定数の使用を要求する企業ポリシーに悩まされていました。 彼は手紙に従いましたが、法の精神ではなく、100の定数を定義しました。
#define ONE 1
#define TWO 2
#define THREE 3
:
（すべてが相対的です。TopCoderのコンポーネントにも同様のルールがあり、その文字は精神よりも重要です-はい、彼らはこのプログラマーを喜んで手に入れるでしょう-およそPer。）
ところで、定数の簡単な再定義
#define THOUSAND 999
長い間あなたのコードに同行しようとしている人々を楽しませる。
7.セルフロール
あなたはいつもシステムレベルのコードを書きたいと思っていましたか？ これはあなたのチャンスです！ 標準ライブラリを無視し、独自の同等のライブラリを作成します。 あなたの履歴書では、それは驚くほどに見えるでしょう！
たとえば、ヒープ上のメモリを単に割り当てる独自のメモリアロケータを作成します。 複雑な手順を記述して占有メモリを解放する代わりに、ユーザーが定期的に再起動して動的メモリをクリアする必要があります。 そのような戦略に同意すると、彼らはそれを決して取り除くことはありません。
異常な言語のレセプション
（再び、1996年に、珍しい言語は今のようにはまったくなかったので、この章はいくつかの例を使ってメインアイデアに縮小されました-およそPer。）
メンテナーにとって珍しい言語を選択し、その構文の機能を最大限に活用してください。 SQLでは、テーブルまたは他の無関係なテーブルの名前に1文字と2文字の同義語を使用します。 可能な場合は常に異なる構文オプションを使用します-他の
トーン。 Visual Basicでは、シンボルで変数の型を宣言します：代わりに
dim Color_var as string
dim counter as integer
書きます
Dim Color_var$, counter%
雑多
1.コンパイルしない
コードを実行可能ファイルにコンパイルします。 動作することを確認してください。 ソースコードにいくつかの小さな任意の変更を加えますが、再コンパイルはしません。 変更したコードをリポジトリに残します。 次の変更後にプログラムが動作を停止すると、エラーが発生しているように見えます。
2.デバッグを妨げる
従業員が行ごとのデバッガを使用する場合、1行に複数のステートメントを配置します。たとえば、if-then-elseコンストラクトは行全体に収まります。
3.自分自身を改善する
多くの場合、コードを変更し、ユーザーによる定期的な更新が必要です-無関係なバージョンを使用したくないですか？ バージョン間の違いは誰にも教えないでください-自分が気付かなかったエラーについて知る必要はありません。
（ファイルを比較できるリポジトリの奇妙なヒントは約です。）
エラーのみを修正するプログラムのバージョンをリリースしないでください-インターフェース、データベース構造、またはファイル形式にいくつかの重要な変更を追加してください。 このエラーに本当に悩んでいる人は、更新に対処し、残りはそれに慣れて、バグではなく機能を呼び出すようになります。 ほとんどの場合、互換性が必要です。ただし、一方向にのみ確認してください。 理想的には、プログラムの古いバージョンは、新しいバージョンで作成されたファイルをまったく認識しないはずです（はい、いくつかのワードプロセッサが優れた例を提供します）。
4.「プログラムについて」
「プログラムについて」ウィンドウには、プログラムの名前、作成者のリスト、著作権、動画を生成する数メガバイトのコードが含まれますが、プログラムのバージョン、最終更新日、またはダウンロード元のサイトは含まれません。 その後、誰もが異なるバージョンを使用したり、長い間修正されたエラーを報告したりできるようになります。
5. TRUEとFALSEをオーバーライドする
#define TRUE 0
#define FALSE 1
その後、あなたは書くことができます
if ( var == TRUE )
if ( var != FALSE )
誰かがそれを修正します
if ( var )
if ( !var )
変更の場合、TRUEとFALSEを同じ値に設定できます。
（はい、＃define TRUEを覚えています（ランダム（）> 0.5）-約）
6.ライブラリを避ける
C ++で書く場合、STLについて知らないふりをして、すべての操作を配列と文字列で手動で記述してください-これにより、ポインターを処理するスキルを維持し、同時に部外者によるコードを変更しようとする試みを停止できます 一方、サードパーティのライブラリをプロジェクトに含める-これにより、履歴書に気付かずに履歴書に含めることができます。
7.コンパイラ依存コード
コンパイラにバグがある場合は、コードがそれに基づいていることを確認してください。 このツールを使用したら、他の人が代替手段を探すべきではありません。
8.未使用の変数
コンパイラが未使用の変数の存在について警告する場合、それらを削除せずに、それらの使用方法を見つけてください。 私のお気に入りの方法はi = iです。
翻訳者のエピローグ
現在のプログラムでこれらの例を試す最良の機会は、あなたが辞め、永住のために別の国に移動する1週間前です。 他の場合では、これらのヒントに従うことはあなたの健康にとって危険です。 著者および翻訳者は、この記事のアドバイスを使用した結果として国民経済および個人に生じた損害について責任を負いません。