小さなシステムのために開発する方法。便宜とは何ですか？
私は内部自動化のための小さなシステムを開発しています。私はasp.netWebフォームを使用しており、次の選択肢に直面しています。
オブジェクト指向スタイルでシステムアーキテクチャを開発する（開発はより困難で時間がかかるようになる）
または
フォームにコントロールを配置し、コントロールハンドラーにSQLクエリを書き込むだけです（高速開発、テストの複雑さ）
現在、私は最初の方法を使用していますが、私の選択が正しいかどうか疑問に思い始めています。どのように便利ですか？
柔軟性と形式主義
品質を必要としないプロジェクト（プロトタイプなど）と可能な限り最高の品質を必要とするプロジェクト（ライフクリティカルシステムなど）の間には連続性があります。
左側では、プロトタイプには1つだけの目標があります。それは、何かを示すために迅速に開発され、その後破棄されることです。ここでは、高品質のコードを記述したり、標準に従うことは重要ではありません。コードは一度書き込まれ、決して読み取られません。高い比率のバグは許容されます。
右側では、ライフクリティカルシステムは信頼性に関して細心の注意を払う必要があります。つまり、形式的な証明など、特に高価な手法を使用する必要があります。ここでは、バグが飛行機の墜落事故や原子力発電所のメルトダウンを引き起こす可能性があります。そのため、可能な限り完璧に近づけることが非常に重要です。
プロトタイプからライフクリティカルシステムに移行する場合、中長期的な費用を削減するため、または当局が要求するある種のコンプライアンスを確保するために、ますます多くの技術が必要になります。これらの手法にはコストがかかります。製品の短期的なコストが増加します。これらの手法には、次のものが含まれますが、これらに限定されません。
- ソフトウェアテスト、
- 非公式および公式のコードレビュー、
- コーディング規約、
- 規格への準拠、
- 正式な文書、
- 静的コード分析、
- 等.
プロジェクトの検索
この連続体のどこにあなたのプロジェクトがありますか？短期間の使い捨てプロジェクトの場合は、フォームにコントロールを設定し、早めに発送して、忘れてください。それが何年にもわたって複数の開発者によって維持される可能性のあるプロジェクトである場合は、それをクリーンにしてください。後継者（または数か月後の自分）があなたに感謝します。
プロジェクトの位置を決定するのに役立つ可能性のある多くの要因があります。
- プロジェクトに取り組んでいる開発者はたくさんいますか、それとも1人だけですか？
- 正確な基準への準拠が必要ですか（たとえば、会計に関連するソフトウェアを考えてください）？
- プロジェクトは何年も維持されるように作られていますか、それともすぐに別のシステムに置き換えられますか？期間が短いというバイアスがあることに注意してください。一部のプロジェクトは、最長で2〜3年存続すると考えられていましたが、20〜30年経っても、まだアクティブです。
- 信頼性は必要ですか？個人的に使用するWebアプリは頻繁にクラッシュする可能性があります。誰も気にしません。すべての顧客のすべてのトランザクションを処理するビジネスシステムは、時々クラッシュすると、さらに多くの問題を引き起こします。
- 何人使用しますか？
- 等.
製品を連続体のどこに配置するかわからない場合は、顧客に尋ねてください。契約書に書かれていることを確認してください（プロトタイプをできるだけ早く提供するように依頼した顧客がいて、最初から電子メールで通知されていたにもかかわらず、書き直さないと維持されないことに本当に驚いていました）。誰も知らない場合は、YAGNIを適用します。プロトタイプのように実行しますが、プロジェクトが何年にもわたって維持されるのに適していると思われる場合は、最初からやり直す準備をしてください。
パラダイムとプロセス
製品の早期出荷に常に失敗する場合は、次の変更を検討することをお勧めします。
使用するパラダイムのいずれか。たとえば、静的プログラミング言語から動的プログラミング言語に移行します。動的プログラミング言語は、コードの品質を損なうことなく、Webアプリの柔軟性と開発速度を向上させることがよくあります。
またはプロセス。たとえば、アジャイルを使用すると、実用的な製品を早期に出荷し、継続的に改善することができます。つまり、高速開発と高品質のコードの両方を一緒に使用できます。
質問に答えるには…
最終的に質問に答えるには：
あなたは「内部自動化のための小さなシステム」について話します。極端な品質は必要ないようです。しかし、それでも注意してください。何か悪いものを出荷したくないのなら、それを何年も維持してください。本当に小さい場合は、プロトタイプの作成に数日を費やし、それが成功した場合は、実際のアプリを作成しますか？
ASP.NET？ Pythonのような動的言語を使ってみませんか？ Djangoを使用すると、迅速に実行する必要があるWebアプリケーションの優れた候補であり、フォームにSQLクエリを使用するASP.NETと比較しておそらくはるかにクリーンになります。
コーディングを始めたら、あちこちに物を置いて、プロジェクトが混乱します。あなたが今しているように、方法番号1に従ってください、それは後で支払います。
自動化システムは、それがどれほど小さくても、中長期にわたって信頼性が高く手頃なサービスを保証する必要があることを考慮してください。
適切な構造を使用せず、2〜3年でメンテナンスを行う必要がある場合は、設計/実装をより適切に、整理された、一貫した方法で構造化すると、自分自身に感謝するでしょう。
アプローチ1を続行すると、システムの更新も簡単になります。また、コンポーネントが適切に設計されていれば、他のプロジェクトのコードをリサイクルできるという大きな利点もあります。
この質問は、私たちがあなたの組織について事実上すべてを知っていなければ真に答えることはできませんが、とにかくここにいくつかの指針があります。
特に新しいシステムの場合、作成するコードのすべての行を完全に抽象化して階層化する必要があるというアドバイスに盲目的に耳を傾けないでください。最初の要件を満たして、完全に階層化された抽象化されたアプリを作成する場合、デプロイから6週間後にユーザーが戻ってきて、「ああ、実際に必要なのは「x」ではなく、「 y '。」あなたは不平を言ってうめき声を上げます、そして何人かのプログラマーは実際に彼らが新しい要件について間違っていることをユーザーに納得させようとします。すべては、投資している優れたアーキテクチャを持っていて、それをすべて取り除いたくないからです。
展開後に戻ってくる変更が軽微な場合や、設計段階でドメインを十分に理解して設計段階でそれを予測できる場合がありますが、常に発生するとは限りません。この変更は、経験のない新しいドメインに影響を与える可能性があります。その場合、既存のモデルを追加することは事実上不可能であり、大量のコードをリッピング、変更、および変換する必要があります。
私のアドバイスは常に、新しいソフトウェアの場合（「営業担当者に連絡先のデータベースを提供できますか？」）、常に可能な限り迅速かつ簡単に実用的なプロトタイプを作成する必要があるということです。マークアップにSQLデータソースが含まれているWebフォームは、このプロトタイプフェーズに最適です。地獄、あなたも本当のデータベースが必要ですか？現在、NoSQLまたはディスク上の単純なシリアル化されたオブジェクトを使用して多くのことを実行でき、SQLテーブルを埋めるためにコーディングするよりも開発がはるかに高速です。 Twitter BootstrapのようなUIフレームワークを使用して、UI時間を短縮します。1日目からリレーショナルデータベースに書き込む必要がある場合は、EntityFrameworkを調べてデータアクセスを高速化します。
「完了して展開した」とは、「2か月後に戻って最適化する必要がある」という意味であることを、必ず伝えてください。これらの数値を見積もりに組み込み、展開後の変更が戻ってきたら、必要な時間を追加するだけです。
最初の展開後に戻ってくる変更のレベルに応じて、システムが安定していることを「本当に」確信できるようになった時点を決定し、時間をかけて適切な状態に分解する必要があります。レイヤー。私の意見では、時期尚早の最適化は多くの問題の根源であり、時期尚早の抽象化と階層化は「最適化」に分類されます。それで頑張ってください！