自明なソフトウェアと自明でないソフトウェアを区別する方法 [閉まっている]

それでは、プログラムを本当に簡単にするものは何でしょうか？

「些細なソフトウェア」がプログラミングの議論で頻繁に使用されていない限り。「何かが重要なソフトウェアであるために重要なのか」または「何かが非常に重要になったために重要なソフトウェアであるのか」を本当に理解できないという意味で、私はそれを非常にあいまいにしています。

たとえば、ユニットテストの問題については、「ユニットテストが必要な場合を除いて」とよく耳にします。

私はここで四肢に出かけ、言うつもりです：

些細なプログラムは、ビジネスに直接影響を与えないものです。

製造会社は会計ソフトウェアを些細なものと見なしますが、沸騰する鋼を動かすロボットアームを制御するソフトウェアは重要です。前者のバグと低いサポートのターンアラウンドに対処できますが、後者には対処できません。問題がある場合は、すぐに修正する必要があります。

私は、その声明の最も一般的な意図は、プログラムが次の特徴を持つことだと考えています。

• それは小さい。
• 短い寿命。
• さらに拡張する必要はありません。
• 開発者は1人だけです。

完全に捨てることで、バイナリとソース。誰かが気づいた場合、それは簡単ではありませんでした。

些細なことは...

• 既に存在するものを、なぜ車輪を再発明するのですか？
• 他のいくつかのプログラムを一緒にスクリプト化するか、実行する必要がある既存のライブラリを多用する小さなコードを記述することで簡単に構築できるもの。
• 普通のCS学部生は、小規模から中規模の宿題をすることができます。
• カクテルナプキンに簡単に収まる詳細な要件が含まれているもの。
• 4分または5分のチャンクの気晴らし/酔っぱらい/暇なときにコーディングできるもの。
• シンプルなコード生成ツールで作成できるもの。

企業環境では、これらを追加します。

• ビジネスユーザーが修正をしばらく待つのを気にしないもの。
• 内部的に使用され、ITからの公式サポートがないもの。
• リソースの計画とスケジューリングを行う際に、ビジネスによって最も低い優先度の中で優先されるもの。

私は、簡単にプログラムを合理的にコーディングできるものとして定義します。

• 一度に。
• 単一のファイル/モジュールとして（Javaまたはモジュールの非常にきめ細かい分割を強制する何らかの言語でプログラミングしていないと仮定）。
• スペシャリストではなく、まともな「すべての取引のジャック」プログラマーによって。

「簡単な」プログラムの例を次に示します。

1. テクノロジーまたはサンプルコードを試すことができるように、セットアップしてコーディングを開始した「ダミー」プロジェクト。展開する意図はなく、誰にも見せることもありません。
2. 技術的なプレゼンテーション用に作成されたデモコード。
3. 「ワンオフ」。私は、一度使用するために構築しなければならないクイックアプリケーションを意味します。これは、特定の方法で移動する必要があるデータの奇妙な状況、またはその後により永続的なものにすぐに置き換えられるものだからです。

トライバルソフトウェアは存在しません。要件を聞いたときに、実際には常に非トライバルである場合にトライバルになるものです。

ここに10年前にUsenetで見た引用がありますが、今ではもっと関連性があります。

ソフトウェアソリューションの複雑さは、それが何をすべきかの説明の複雑さに反比例します。- 不明

単なるゲッター/セッターメソッドの単なる束であるプログラム。プログラミングロジックはありません。たぶん、いくつかのループを持つ何か。

それが私の些細な定義です。

私たちの作業定義は「他に何も依存しないもの」です。

残念なことに、些細な試作製品がいくつかあり、それが非自明な生産製品になりました。

また、プロジェクト全体の計画に対するプログラムの影響の文脈で使用されたと聞いています。特定の仕様が製品の納期を変更しない場合、それは些細なラベルに該当します。

「議論する価値さえない」の同義語として「自明」を使用する傾向があるプログラマーを知っていました。