古い経験豊富な請負業者は、さまざまなキューにSQLite DBを使用していました-私は若い開発者であり、不快に感じることで正当化されますか？
Context：私は2年の確かな経験を持つ組み込みの開発者です。私は4人のスタートアップの唯一の技術者です。製品のMVPがあり、次のイテレーションを開発する準備ができています。元のMVPはパートナーの請負業者チームによって開発され、1人の古い組み込み開発者がすべてのソフトウェアを実行しています。私は入社が遅すぎて、MVPの設計に入力することができませんでした。製品はゲートウェイタイプのデバイスです：組み込みLinux、メッセージは一方向に送られ、限られたインテリジェンスは内部で発生し、反対側に送られます。
「問題」：システム内のすべてのものが単一のSQLiteデータベースに組み込まれているようです。処理されたメッセージと未処理のメッセージは同じテーブルにあり（1つのフィールドがメッセージを示すために使用されます）、関連するもののプロビジョニングは別のテーブルにあります。ロギングとデバッグも、データベースのさらに別のテーブルに書き込むことによって行われます。システムは主にpythonで記述されていますが、その最大の部分は、データ操作の大部分を行うように見える複雑なSQLのラッパーでいっぱいの大規模なクラスです。
これらすべてが私を不快にさせます。特に、「キューとしてのデータベース」設計のアンチパターンの古典的なケースのように見えるメッセージ部分は特に不快です。そうは言っても、保守性の曖昧で曖昧な言及、モジュール化の欠如による変更の導入の難しさ、およびデータ流れ、処理されています。それは請負業者が私の判断に対して「長年の経験の権限」を持っていることを助けません。
このデザインの選択に不快に感じることは正当化されますか？つまり、原則として機能します。リファクタリングへの欲求は非常に強く、非合理的であり、特定のビジネス上の制約に常に対処する必要があるわけではないことを知っています。しかし、それでは...最初から始めて、最初のMVPの有用なビットだけを削除するだけで、これまでに作成されたシステムで作業するよりもクリーンで時間がかからないような気がします。しかし、それはただ私の若い人の熱狂的ですか？
最初の問題は、デザインを「間違っている」と考えることです。それは本当に物事を考える正しい方法ではありません。むしろ、設計が異なれば、設計のトレードオフも異なります。どのデザインにも、お互いに比較検討した長所と短所があります。設計に問題がある場合、それは「間違っている」のではなく、むしろトレードオフの選択が不十分であるということです。それについて考えたり説明したりしないでください。設計が間違っているのではなく、より良いトレードオフがどのように存在するかを考えてください。
SQLiteと組み込みLinuxシステムを使用しているという事実により、データベースをキューとして使用することは、他の状況に比べてはるかに問題が少なくなります。 Database-as-queueには2つの大きな欠点があります。
- データベース操作はかなり高価であり、パフォーマンスが低下します。
- 新しいメッセージは、データベースを繰り返しクエリして確認することによって検出する必要があります。
ただし、SQLiteの操作は一般的なデータベースよりもはるかに安価であるため、パフォーマンスの低下は最小限です。 SQLiteは、データ変更通知もサポートしています。これにより、プログラムはデータベースに繰り返し問い合わせることなく、データベースへの変更を検出できます。
SQLiteは無料で多くの機能を提供します。基本的には、テーブルを定義すると、SQLiteがテーブルをディスクに永続化し、再起動時にそれらをロードしてファイルが破損しないことを保証し、強力なクエリツールを提供して、データに対する複雑な操作を可能にします。さらに、SQLiteは、他のアプリケーションを構成せずに、これらすべてを提供します。これは、コードが使用するライブラリにすぎません。このすべてにSQLiteを使用しない場合は、その機能を自分で実装する必要があります。
私の評価では、この方法でSQLiteを使用することはかなり賢明な選択です。あなたの回答は、自分の力を知るのに十分なデータベースを使用していない誰かとして私に伝わります。もちろん、私がそれを変更することを知らない他の考慮事項があるかもしれません、またはそれはシステムが他の方法で単に不十分に構築されているかもしれません。
しかし、懸念を上司に伝えたい場合：
- 最初にシステムを使用するときは、誠実な努力を払ってください。これにより、キャストを行うときにシステムがより妥当になります。また、何が機能し、何が機能しないかについて、はるかによく理解できます。そして多分あなたはSQLiteを愛することを学ぶでしょう。
- 上司が気にかけている正確な事柄を特定できるようにする：ケースを作成する際のパフォーマンスの向上、機能の増加など。
ここでの判断で、ジュニアレベルの一般的なプログラマエラーを犯していると思います。解決策はあなたがそれをしたであろう方法ではないので、あなたはそれを再設計したいと思います。快適になるために必要な最も重要なことの1つは、デザインが本来あるべきものであるかどうかは問題ではないということです。それは本当に、本当に重要ではありません。重要なのは、それが機能するかどうか、改善できるかどうか、そしてそれらの改善を行うために何がかかるか（時間とお金）だけです。
1つの具体的な問題については言及していません。気に入らないデザインが表示されます。しかし、なぜあなたのマネージャーは気にする必要がありますか？同様の規模と複雑さの実用的な運用ソフトウェアソリューションを作成しましたか？彼らは完全に良い搾乳牛を持っています、そしてあなたは彼らにそれをいくつかの魔法の豆と交換してもらいたいのです。
このソフトウェアが機能するという前提から始めましょう。信頼性が高く、パフォーマンスも良好です。顧客満足度は高いです。さあ、あなたはやって来て、それを書き換えたいとマネージャーに伝えます。基本的に、これを構築するために費やした初期時間と投資は 沈没したコスト であり、未知の能力のために機能する有益なソフトウェアをスクラップしたいと言っています。
コードの記述は、本番環境への移行のほんの始まりにすぎません。おそらくあなたが気付いていない現在のソリューションで解決される多くの技術的な課題があります。再設計を行うことは、すでに解決されたものを再発見する必要があることを意味します。途中で、あなたは新しい問題を紹介する義務があります。新しいプロダクションバグを作成する可能性は十分にあります。そして、あなたは上司にその時間、コスト、リスクにサインアップして、具体的な利益をゼロにしたいと思っていますか？それが彼らにとって良い選択ではない理由を理解していますか？非技術的であることは実際にはそれをもっとマネージャーがこれを行うことを許可するでしょう、少なくはありません。技術者ではないマネージャーに、不必要な書き換えを行う価値があると納得させる方がはるかに簡単です。有能なマネージャーは、ジュニア開発者にベテランのワーキングソリューションを書き直させることには実質的に利点がないことを知っています。
ここで、現在の実装がバグがあり、遅く、不安定であるとしましょう。たぶん、ソリューションは壊れやすく、いくつかの変更を行うと、完全な書き換えよりも時間がかかります。それはまったく別の状況です。しかし、あなたはまだ議論に勝たないかもしれません：時々、改善のコストは利益よりも大きいです。書き換えが実行可能または正当化されなかったため、悪いデザインの範囲内で作業しなければならなかった回数のカウントを失いました。
あなたのキャリアのこの時点で、あなたは自分のやり方でそれを構築することについての心配よりも、他の人が行ったことから学ぶことについてもっと心配すべきです。あなたが物事を行うための良い方法を学ぶのは必ずしもそうなるとは限りません。開発者としての私の最初の数年間は、死にかけているプラットフォームで構築された貧弱なデザインの中で、かなりひどいコードのラングリングに費やされました。当時は嫌いでしたが、期待していた最高の教育の1つでした。どのようにしてできないか、なぜ良いデザインが重要なのかについて多くを学びました。賢い人がかつて私に言った：「賢い人は自分の過ちから学ぶ。本当に賢い人は他の人の過ちから学ぶ。」
私はあなたの靴の中に、そして請負業者の靴にも身を置くことができます。
次の質問を自問してください。
まず、デザインを変えるのにどれくらい時間がかかりますか？それは本当に価値がありますか？
製品に新しい機能を追加するための努力。
そのままのデザインの良い点（彼はあなたよりもはるかに多くの経験を持っているのでこれが鍵です、それは特定のユーザーのためにデザインされるかもしれません...）
製品の引き渡しはありましたか？たぶんそれが必要なのかもしれませんが、製品、モチベーション、そのデザインを理解していません。
それほど悪くないかもしれませんが、もう少し情報が必要です