ソフトウェアの世界の不条理な法則

ソフトウェア開発者のような賢い人々がなぜそんなに頻繁にそれを台無しにするのか疑問に思ったことはありますか？ やった人もいます。 この投稿ではレビューします 専門家の行動を説明する書かれていない法律のいくつか コンピューティングの。

私の最初のコンピューターはコモドール64でした。ほぼ30kbのRAMがシステム用で、残りの32 kbはワープロ、ゲーム、家業会計、そして私が所有する6GBのコンピューターで行うほぼすべてのものです。 それは質問を開いたままにします 今日の機器はソフトウェアのニーズに対応していますか、それともソフトウェアは利用可能であるため、より多くのハードウェアリソースを使用していますか？

公平に言えば、ゲームは同じではなく、グラフィックも同じ品質ではなく、映画を見たり音楽を聴いたりすることは不可能だったでしょう。 しかし、それを考えざるを得ない バージョンをリリースし、実際に新しいものを提供することなく、ますます多くのリソースを消費するプログラムがあります。

原因は次のとおりです。

Zawinskyの法則

Netscapeの開発者であるJamieZawinskyは、次のように主張しました。 すべてのプログラムには、電子メールを読むことができるようになるまで機能が組み込まれています。 彼が成功しない場合、彼はそうすることができる別の人に置き換えられます。

彼がそれを言ったとき、冗談は彼がもともと電子メールクライアントとして意図されていなかったプログラムに言及していたということでした。 Google Playの多くのアプリが、仕事をする必要のない電話コンポーネントやユーザーデータにアクセスする許可を求めていることがわかったとき、面白くなくなりました。

これをユーザーをスパイする試みの一部と解釈する人もいます。 しかし、それができるという理由だけで何かをするのはおそらく人間の本性です。

ソフトウェアに適用されるピーターの法則

ローレンス・ピーターは、ヒエラルキーの中で、人がひどく無能な立場に上がると述べたことで有名になりました。 しかし、彼は複雑なプロジェクトについて何かを言う時間もありました。

「複雑なプロジェクトは、それ自体の開発者でも理解できないほど複雑になります。」

驚き最小の原則

1984年にIBMSystems Journalに掲載されたこの原則は、次のように述べています。

「必要な機能が大きな驚きを引き起こす場合、その機能を再設計する必要があるかもしれません。」

言い換えれば、 ソフトウェアの一部または全部がユーザーが慣れていたものと大きく異なる場合は、再設計するのが最善です。。 理想的には、達成に努める 印象的であるのに十分な大きさであるが、慣れ親しむのに十分小さい段階的な改善 ユーザーのために。

残念なことに、ShuttleworthはUnityを立ち上げたときにそれを考慮していませんでした。

サイバネティック昆虫学法

コンピュータの歴史における最初のバグは本物でした。 MARK IIコンピュータのリレーのXNUMXつに蛾が飛来し、誤動作を引き起こしました。

比喩を続けると、サイバネティック昆虫学の法則はそれを保持します 常にもうXNUMXつのバグがあります。

これは、すべてのコンピューターユーザーが知っていることです。 オペレーティングシステムをいくらテストしても、手遅れになると常に障害が発見されます。

カーニハンの法則

Linux Adictos には、作成者が検索エンジンに優しい方法で記事を作成できるようにするためのプラグインがインストールされています。初日から大嫌いでした。少し文学的な逃避をして書こうとする試みは、即座に赤丸で非難されます。時間が経つと慣れてきて、タッチアップをする必要がほとんどなくなりました。

同じことがプログラマーにも起こります。多くの場合、プログラマーは、理解と保守が容易な単純なコードを作成するよりも、コーディング能力を実証することに関心があります。

したがって、カーニハンの法則は次のように成り立っています。

デバッグは、そもそもコードを書くよりもXNUMX倍難しいです。 したがって、コードを可能な限り賢く書くと、定義上、それをデバッグするほど賢くはありません。

90/90の法則

実生活で営利プロジェクトを開始した人なら誰でも、期待される利益の半分を稼ぐために、すべてのプロジェクトにXNUMX倍の時間がかかり、予算のXNUMX倍の費用がかかることを知っています。

コンピュータの世界には、この法則の変形があります。 たとえば、あるトム・カーギルは次のように述べています。

「コードの最初の90％は、開発時間の最初の90％を表しています。 コードの残りの10％は、開発時間の残りの90％を表しています。」

はっきりしませんでしたか？ おそらくホフスタッターの法則が役立つでしょう：

「ホフスタッターの法則を念頭に置いても、常に予想よりも時間がかかります。」

UbuntuとFedoraの開発者は知っておく必要があると思います。 または、少なくとも6か月ごとに覚えておいてください。

ブルックスの法則

オープンソースソフトウェアプロジェクトには、多くの場合XNUMXつの問題があります。 資金調達と協力者の不足。 XNUMX番目が問題でない限り。 ブルックによると：

「予定より遅れているソフトウェアプロジェクトに労力を加えると、それはさらに遅れるでしょう。」

当然のことながら、新しいエンコーダーを更新する必要はありません。 より多くの文書化が必要になり、全員の同期を維持するためにより多くの官僚主義が必要になり、おそらく争いが発生するでしょう。

そしてもちろん、私たちは友人のパーキンソン病と彼の主張を忘れることはできません どれだけの空きスペースから始めても構いません。 あなたは常にもっと必要になります。 彼はオフィススペースについて言及していましたが、RAMとディスクスペースについても同じことが言えます。