ここまで、知っておくべき最も基本的なプログラミングの原則を紹介してきましたが、これらよりも役に立つかもしれない、別のカテゴリーのプログラミングの原則があります。

上記の原則は、コードを賢く使う方法を教えてくれますが、次の原則は、コードを賢く使う方法を教えてくれます。中には奇妙なものもあり、ユーモラスなものも多くありますが、どれも等しく実用的で重要なものばかりです。気をつけよう!

1 拡大の原理

こちらはバリエーションが豊富で、どれをメインにするか迷うほどです。おそらく最も「公式」なものは、ソフトウェア封筒の法則で、より一般的には、Art of UNIX Programmingで言及されているJamie ZawinskiにちなんでZawinskiの法則として知られているものでしょう。

"どのプログラムも、メールを読めるようになるまで拡張しようとする。そのように拡張できないプログラムは、拡張できるプログラムに置き換えます。

つまり、時間が経つにつれて、プログラムはどんどん機能を集め、必然的に複雑化する方向に進化していくということです。これは、プログラムの主目的とは無関係な新機能を次々と追加していく「フィーチャークリープ」と呼ばれるもので、ご存知の方も多いでしょう。フィーチャークリープは肥大化を招き、肥大化は通常、好ましくない。

これは、ソフトウェアの性能にも言えることです。

"ソフトウェアは、利用可能なすべてのリソースを○○するために拡張する。"

90年代は、ハードディスク、CPU、RAMの制限が今よりずっと厳しく、プログラマーはできるだけ制限内に収まるように努力していました。しかし、より大きなドライブ、より高速なCPU、より多くのRAMを手に入れた今、制限を守ることはまだ難しい。すべてのものは時間とともに膨張する。それをコントロールするのがあなたの仕事です。

2 「悪いことは良いことだ」という考え方

まるで、インフレの原理と呼応するかのように、「悪いことは良いことだ」という考え方があります。これは、リチャード・P・ガブリエルがソフトウェア品質に関する論文で紹介したのが最初です。

"制限があっても使い方が簡単なソフトは、逆にユーザーや市場にアピールできるかもしれない"

つまり、ソフトウェアが解決しようとする問題を1つだけ特定し、その問題に対して素晴らしい仕事をすることが賢明なのです。シンプルであること注意力が散漫になればなるほど、プロジェクトの管理は難しくなり、ユーザーからも嫌われることになります。

これを無視するとどうなるかというと、結局はソフトウェアの原理である

"複雑すぎるプロジェクトは、やがて自分の開発者ですら理解できないほど複雑になってしまう。"

これは、より広い意味でのピーター原理から派生したもので、次の役職に期待される能力ではなく、現在の能力に基づいて昇進した場合、すべての社員は無能の状態に陥るというものである。この原理をソフトウェアに当てはめると、なぜ悪いソフトウェアほど良いソフトウェアになる傾向があるのかがわかるでしょう。

III.イーグルソンの法則

「6ヶ月以上見ていない自分のコードは、他の人が書いたものである可能性があります。

この一見がっかりするような言葉も、実は受け入れてみる価値があるのです。実は、完璧な人間なんていないんです。今、自分は優秀なプログラマーだと思うかもしれませんが、学ぶべきことは常にあり、発展の余地は常にあるのです。もし、昔のコードを振り返ってギョッとしたら、それはおそらく、その後に何か新しいことを学んだということです。

つまり、昔のプロジェクトを振り返ってみて、改善点や次回はこうしようということが見当たらない場合は、プログラマーとして停滞している可能性があるのです。

4 ミニマムサプライズの原則

"必要な機能が高い驚愕度を持っている場合、機能の再設計が必要な場合がある"

この原則は、1984年にIBM Systems Journalに初めて掲載されましたが、今日でも驚くほど適切な内容になっています。

これは本質的に、革新性と親しみやすさの微妙なバランスに触れている。もしあるソフトウェアが他のソフトウェアとあまりにも違っていて、ユーザーの期待に応えられなければ、ユーザーはそのソフトウェアを採用しない可能性が高い。それよりも、印象的なほど大きく、かつ身近に感じられるほど小さな改善を、少しずつ進めていくことが大切です。

5 サイバネティック・エントモロジーの法則

"もう1つバグがある"

サイバネティック昆虫学のルバルスキーの法則と呼ばれることが多いが、このルバルスキーが実際に誰なのかは不明である。しかし、彼の原理はすべてのプログラマーに当てはまる。どんなにきれいにコードを書いても、どんなに堅牢にモジュールをテストしても、どんなに頻繁にクラスをリファクタリングしても、常に別のバグが存在する。

これはある意味、自由の原則と言えるでしょう。完璧なコードを目指すのは当然ですが、完璧主義が良いものの敵であることも忘れてはいけません。間違いを探し、現れたら修正し、次に進む。

6 カーニガンの法則

"デバッグ "は、そもそもコードを書くことの2倍大変です。したがって、コードをできるだけ巧妙に書けば、定義上、デバッグするのに十分な **art ではありません。"

ブライアン・カーニガン（briankernighan）は、この洞察に満ちた法則で有名なC言語のバイブルを共著した人物そのものです。重要なのは、良いコードを書く、読みやすいコードを書く、シンプルなコードを書く、賢いコードでない限りは、ということです。

象牙の塔のような複雑さでプログラミングスキルを磨こうとするのは、クリーンでより良いコードを書くという意味とは正反対のことです。コードが理解しにくいほど、どうしても壊れてしまったときのデバッグが難しくなります。

ロバート・C・マーティンが説明するように、デバッグだけではありません。

"確かに、読む時間と書く時間の比率は10対1を優に超えています。私たちは、新しいコードを書く努力の一環として、古いコードをひたすら読み込んでいます。. .[だから、読みやすくすれば書きやすくなる"。

7ラバーダック試運転

これは原理というよりテクニックなのだが、あまりに便利で不思議なので見過ごしてしまう。

まず、「Practical Programmer」で取り上げられているように、ラバーダックデバッグとは、壊れたソフトウェアを、コードを一行ずつ無生物（ラバーダックなど）に解釈してデバッグする行為である。説明するという行為が、脳のさまざまな部分を刺激し、矛盾を見つけ、何が悪かったのかを把握しやすくなるからです。

だから、自分用に買うにしても、プログラミングのパートナーに買うにしても、ラバーダックはプログラマーにとってとても嬉しいプレゼントなのです。

8 「九十九の法則

"コードの最初の90パーセントが、開発時間の90パーセントを占めている。残りの1割のコードが、残りの9割の開発時間を占めているのです。"

このtomcargill**による生意気な格言は、プログラミングが苛立たしい理由の核心に触れるものです。終わったと思ったら、まだ半分しか終わっていない。

ホフスタッターの法則と密接な関係がある。

"ホフスタッターの法則 "を考慮しても、いつも予想以上に時間がかかるものなのです。

9 パーキンソンの法則

"仕事は完成に使える時間を埋めるように拡大する"

この原則は、シリル・ノースコート・パーキンソンによって開拓されたもので、プログラミングに絶対的に適用される広範な原則であり、上記の90のルールと密接に関係している：プロジェクトを完了するのに必要な時間と正確に同じだけかかる。ソフトウェア開発において、「予定より早く仕上げる」というのは、ほとんど神話に近い。

パーキンソンの法則は、ソフトウェアを完成させて出荷したいのであれば、適切な納期が重要である理由です。そのため、現代のプロのプログラマーは、アジャイルプロジェクトマネジメントの原則やAsanaのようなプロジェクト管理ツールを推奨することが多いのです。

10 ブルックの法則

"遅れたソフトウェアプロジェクトにマンパワーを加えると遅くなる"

次にプロジェクトが遅れるのは、ほとんどのプログラミングプロジェクトが割り当てられた時間よりも長くかかるからでしょう。エンコーダーを追加しても、問題を早く解決することはできないことを覚えておいてください。

むしろ、完成までに時間がかかるかもしれません。新しいエンコーダを使いこなす必要があるだけでなく、既存のエンコーダと競合する可能性があります。より多くのことを文書化する必要があり、より多くの****が皆と同じ見解を持つ必要があり、危機の期間を通しての経験からより多くの摩擦が生じるでしょう。

プログラマーとしての転身

これらの原則を理解したあなたは、学校やオンラインコース、ブートキャンプで出会うものよりも、実はプログラミングの実世界に適しているのです。これらの原則は、長年の経験と失敗から生まれたものです。

この新しい知恵で、需要の高いプログラミングのキャリアをより現実的に期待し、船出することができます。そのために、プログラミングのキャリアチャンスを最大限に生かす方法を学びましょう。プログラミングが自分に向いていないと思う人は、心配しないでください。コーディング以外の技術的な仕事も検討してみてください。

また、私たちが見逃している奇妙なプログラミングの原則があれば、以下のコメント欄で教えてください。