ほとんど機能しないシステムアイデア
(hardcoresoftware.learningbyshipping.com)ほとんど機能しないシステムアイデア
-
「プラグイン可能にしよう」
- 1つの実装が動作しない場合、開発者が新しい実装を簡単に追加できるようにしようというアイデアです。ただし、ほとんどの場合、APIが提供する機能は期待したほど簡単には動作しません。真にプラグイン可能にするには、2番目の実装を最初から一緒に設計しておく必要があります。
-
「APIを追加しよう」
- プラットフォームを構築して開発者を呼び込むためにAPIを追加することがよくあります。しかし、APIの提供には互換性と相互運用性のための継続的な取り組みが必要で、APIを提供したからといってユーザーが必ず増えるわけではありません。プラットフォーム構築は本気の事業であり、APIを提供するだけでは経済基盤を築くのは難しいです。
-
「さらに抽象化しよう」
- コンピュータサイエンスでは、別のレベルの間接参照で問題を解決できる、という言葉があります。しかし、早すぎる抽象化は保守性、セキュリティ、性能最適化の観点で困難を招くことがあります。計画なしに追加された抽象化は、コードの保守を難しくします。
-
「非同期化しよう」
- 非同期化はコンピュータサイエンスで長く研究されてきたテーマです。ウェブフレームワークはこれをうまく抽象化していますが、フレームワークの外側で非同期化を直接管理しようとすると、予測不可能なバグが発生する可能性が高くなります。
-
「アクセス制御は後で追加しよう」
- システムセキュリティは最初から考慮されるべきですが、リリース速度を優先するためにしばしば後回しにされます。顧客と敵対者の視点の両方で、アクセス制御を最初から考慮していないと、後で製品を再設計しなければならない可能性が高まります。
-
「データを同期しよう」
- データ同期は非常に難しい問題で、経験を通じてのみ解決できる課題が多くあります。データ同期を前提にしたソリューションの構築は、ほぼ望ましくないものです。
-
「クロスプラットフォームにしよう」
- クロスプラットフォーム開発は、OSやクラウドプロバイダ、ブラウザを構築することに似ています。プラットフォームが新しかったり、アプリケーションが単純な場合は機能することがありますが、時間が経つにつれてますます難しくなります。
-
「ネイティブへフォールバックできるようにしよう」
- クロスプラットフォームが制約を受ける場合、ネイティブ機能へ脱出できるようにすることは一般的です。しかし、この方法はフレームワークが維持する状態と衝突する可能性があり、10回中9回は失敗します。
-
結論
- これらのアプローチが常に失敗するわけではないものの、ほとんどの場合、より良い方法があります。基本原則に沿って問題を解決し、失敗しやすいソフトウェアパターンを避けることが重要です。
2件のコメント
プラグのような場合、必須の動作だけをできるだけ絞り込んでインターフェースを設計するのが最も重要です。
インターフェースをただ現在のコードから大まかに構造を拾って作ってしまうと、当然その実装に縛られる不要なインターフェースになってしまいますが、そういうケースは本当に多いです...
Hacker Newsコメント
DSLとAPIはしばしばうまく機能する。TensorFlowのような推論エンジンも、DSL、またはDSLをラップするAPIと見なせる。
DSLは時に非常にうまく機能する。jOOQ.orgを参照できる。
Elastic Load Balancerは、ワークロードに応じて応答する制御ループであり、これは一種のプロダクトだ。
ほとんどの業界でリソース不足が蔓延している。参考として、erikbern.comと「Goal: Process of Ongoing Improvement」を参照できる。
異常検知は分散システム特有の問題ではないが、問題に直面した人には必要に思えるかもしれない。
「ほぼ」という表現はここではうまくいかない。これは単なる悲観主義と皮肉に過ぎない。
多くの人は例外のための微妙な判定関数を探そうとするが、実際はシンプルだ。私が行えばうまくいき、前の人が行うとうまくいかない。
「Domain Driven Design」は、事業構造に合わせてアプリケーションを設計することが、破滅へのレシピだ。
負荷応答制御ループは基本的で必須の構成要素である。多くのシステムで使われている。
複数のDSL、P2Pキャッシュ、ハイブリッド並列性を使うプロジェクトを扱ったが、ほとんどが成功した。
「ただデータを同期しよう」というアプローチは問題を引き起こす可能性がある。
いくつかのアイデアを成功裏に実行した。だから、少し奇妙に聞こえる