あなたは元気で、機敏で、速く、風のようにコードを書きます。 しかし、将来、他の人が簡単に修正できる可変コードを作成します。
はい、あなたは言いますか？ なんで？
コードが1年で期限切れになると思ったことはありますか？ 将来の開発者が慎重に作成されたソリューションの原始的な美しさを台無しにすることを気にしませんか？ ランダムに出会え、かけがえのない、完全に時代遅れの汚れの塊に感心しませんでしたか？ 誰も理解できないゾンビコード、恐れと恐怖でみなされるコード、誰もそれを変更する勇気がないので、会社に永遠に住むコードを書いてみませんか？
それは簡単ではありませんが、あなたはそれを行うことができます。 少し努力するだけで、すぐにコードを書くだけでなく、「まあまあ」のレベルを超えて、生き残った最終的なゾンビコードを書く機会を与えるスキルと規律を身に付けることができます。そしてあなたが去った後。
そして今、それを行う方法：
何もチェックしない
テストは時間の無駄です。 信頼性の錯覚を与え、コードが他の人にどのように機能するかを示すことができます。 テストを実施する必要がある場合は、最後に実行し、テストが正しいことを述べてください。 もちろん、最初はテストせず、誰かをテストするためにテストを使用しないでください。そのような開発は、理解して変更する簡単な方法です。
リファクタリングなし
まず、コードが機能する場合、修正しないでください。 第二に、誰も優雅さとシンプルさを開発する時間がありません。 必要に応じて、テストによる開発（TDD）が許可されますが、これがなければ開発できません。 最後に、「技術的義務」とは、ソフトウェア機能を測定するためのツールの販売です。
理解できないコードを書く
コードの可能性を隠すことは非常に可能です。 まず、クラスとメソッドに、責任ではなく、自分がしていることを宣言するような名前を付けます。 「以前に製品を購入した」などの名前は長すぎて参考になりません。 「情報の表示」の方がはるかに優れています。 さらに良いのは、「プレビュー」だけです。 一般名を長く生きてください！
-できるだけ頻繁に「Buffer」、「Temp」、「X」などの一般的な名前を使用します。
-インターフェイスの名前には略語と略語を使用します。
-時間と労力を節約するだけでなく、データ型に関する情報を混乱させるために、一般的な構造を使用します。
-型なしコレクションで型付き構造を使用します。
-すべてを配列に書き込みます。
-コード全体で半連結構造をコピーして貼り付け、異なるデータや状況に合わせて変更しますが、値の名前を変更したり、コメントを変更したりしないでください。
-時々（ただし、あまり頻繁ではないが）、不正な型を示す変数名を指定します。たとえば、浮動小数点数「MessageText」を指定します。
-タイプObjectまたはStringのパラメーターを値で渡し、意味のあるタイプをカプセル化しません。
「定数を入力する必要がある場合は、値と同じ名前を付けてください。」 または、ギリシャ文字を使用します。
-コメント-ノイズと間違った方向を追加する機能。 最良のコメントは、コードが何を行うかを宣言し、コードの変更後も同じままです。
-コードを読んでいる人は、コードが何をするかだけを見るべきであり、どのようにそれを行うべきかを見るべきではないことを覚えておいてください。 そして、いかなる場合でも、ケースの基本的な用語を使用しません。
読めないコードを書く
他の人のコードを読むことは時間の無駄であり、創造的なスタイルを台無しにする可能性があります。 独自の基準を守って、決してコメントしないでください。
集計は無駄です。 これらすべての余分なパディングなしでコードのコンパイルが速くなり、分割によりコードが読みやすくなります。 可能な限りすべてを1行で記述してください。
モジュール性は制限です。 ソリューション全体を頭の中に保持できるのに、なぜそれらを多数のクラスとメソッドで配布するのですか？
複雑さは大きく、過度の複雑さはさらに優れています。 最新の言語機能を使用すると、5行の明白な行ではなく、2行の不明瞭なコードを記述できます。 誰かが尋ねたら、それが効率を改善し、そして/またはあなたが使用した言語の秘密の特徴の彼らの無知を笑うことを述べなさい。
ハードコードを書く
可能な限り多くのアーキテクチャソリューションを適用し、何があろうとそれらに固執します。
情報を共有しない
ゾンビコードが何かをしている理由を説明しないでください。 チームメイトや作業中のプロジェクトについて話すことは避けてください。 あなたのチームメイトがあなたにアドバイスし、あなたに迷惑をかけたり、あなたのチームメイトが理解していることを誤って見せたりするかもしれません。 そして、これは望ましくありません。
ペアプログラミングは控えてください。 これにより、コードで既に回答されている質問に時間を浪費します。 本当に追い詰められている場合は、コードが何をしているのかを説明してください。
メールで誰かと仕事をしなければならない場合。 返信の間に少なくとも2日間待機し、受信トレイを頻繁に変更します。
悪党の計画に干渉する可能性のある、いわゆる「政治」、「基準」、または「プロセス」を回避または破ります。 彼らはあなたに「品質改善」と「時間の節約」を約束しますが、嘘です。
一方、他の開発者を率いる必要がある場合は、ポリシー、ディレクティブを発行し、必要に応じて何度でもプロセスを変更できます。 しかし、なぜこれらすべてを説明することはありません。
チームの新しい開発者、特に初心者は、オリエンテーション、教育、サポートなしで急いで火の中に飛び出さなければなりません。 彼らの質問が無視されるか、彼らがそれらを取り除くことを試みるために押されていることをrid笑されていることを確認してください。 本当に彼らに請求書の支払いを強制したい場合は、GoogleとStack Overflowへのアクセスをブロックします。
DevOpsはありません。 決して
DevOpsの方法と専門家は避けるべきです。 必要に応じてすべてを手動で調整し、必要に応じてすべてを変更します。 制御システムに疑念を抱く-すべての準備が整ったときにのみコードを公開します。 必ずニックネームを使用し、メッセージには何も表示しないでください。
もちろん、チームとの継続的なコミュニケーションや情報交換に参加しないようにすることはできますが、あまり頻繁に行うべきではありません。
文書化する必要がある場合は、恐ろしく行います。
外部のドキュメントを書く必要がある場合は、何が書かれているのかを理解できるようにそれを書いてください。 略語を決して解読せず、いくつかの重要な手順をスキップしてください。コードを理解しようとする必要があるため、残りも汗をかく必要があります。 ドキュメントを誤って保存し、無効な検索タグを設定します。
既製のソリューションを探しないでください
これは弱さの兆候です。 最初のソースからすべてを自分で見つけてください。 他の人の図書館は疑わしいです。 独自のフレームワークを作成します。
ゾンビの黙示録のコードを書く
これらのすべてのヒントを一貫して適用すると、プログラムはウォーキングデッドになります。ゾンビは絶えず分解しますが、完全に死ぬことはありません。 これらの努力はすべて、あなたが去った後でもあなたのコードを保存します。
次の人があなたの住んでいる場所を知っている猛烈なサイコパスであるかのようにコードを書く必要があることを忘れないでください。 しかし、ゾンビの群衆と戦うのに忙しすぎるので、これは起こりそうにありません。
名前に署名しないでください。