ソフトウェア工学

システム開発ライフサイクル内で働く専門家、学者、学生向けのQ&A

2
安らかなサービスで順序付きリストリソースを設計するにはどうすればよいですか?
私はこの同じ問題に何度も遭遇しましたが、私が本当に最適だと感じた解決策は見つかりませんでした。 アプリで言うと、順序付けられたリストがあり、ユーザーがドラッグアンドドロップなどでその順序を変更できるようにします。順序の変更を保持したい場合。どのようにモデル化しますか? 順序付きリストリソースの安らかなサービスを設計するにはどうすればよいですか? 具体的には、どのように私が設計する必要がありますlistし、item安らかなリソースのモデルを?私が見た最も一般的なデザインは、またはプロパティitemを持つエンティティです。私が聞いた別のアプローチは、アイテムの二重リンクリストです。orderposition データベースへの書き込みが多すぎず、クライアントの更新と読み取りが一般に高速なアプローチとは何ですか?エンドポイントはどのように公開されるべきですか?

1
シーケンス図:アクターはオブジェクトですか?
最も可能性の高い答えはノーですが、私はこの疑念を抱いています。俳優はクラスとして行動できますか? アクターはイベントをトリガーし、プロンプトを表示できることを知っていますが、アクター(ユーザークラスなど)をモデル化するクラスがある場合、それらのメソッドを呼び出すことができますか?それとも、これは、代表クラスと混同されている俳優の役割の完全な誤解ですか? 正しいと仮定: 正しい場合は疑う:

3
%演算子を使用せずに、よく分散されたハッシュテーブルを実装することは可能ですか?
私は、C#で高速で十分に分散されたハッシュテーブルを実装したいと考えています。任意のハッシュコードを受け取り、それを「制約」して、バケットのインデックス作成に使用できるハッシュ制約関数の選択に問題があります。私がこれまでに見た2つのオプションがあります: 一方では、バケットに常に素数の要素があることを確認し、ハッシュを制約するには、単にバケットの数でモジュロします。実際、これは.NETの辞書が行うことです。このアプローチの問題は、%の使用が他の操作と比較して非常に遅いことです。あなたが見ればAgner霧命令テーブル、idiv(%のために生成されますアセンブリコードで)新しいIntelプロセッサのための〜25サイクルの命令のレイテンシを持っています。3の周りにこれを比較しmul、等をビット単位のオペレーションのための1 and、orまたはxor。 一方、バケットの数は常に2の累乗にすることができます。配列の外部でインデックスを作成しないようにハッシュのモジュラスを計算する必要がありますが、今回はより安価になります。2のべき乗のためのため% Nだけされ& (N - 1)、拘束のみ1~2サイクルかかるマスキング演算に低減されます。これはGoogleのsparsehashによって行われます。この欠点は、ユーザーに適切なハッシュを提供することを期待していることです。ハッシュをマスクすると、基本的にハッシュの一部が切り捨てられるため、ハッシュのすべてのビットを考慮しなくなります。ユーザーのハッシュが不均等に分散している場合、たとえば上位ビットのみが埋められるか、下位ビットが常に同じである場合、このアプローチの衝突率ははるかに高くなります。 私は、両方の長所を備えた使用可能なアルゴリズムを探しています。ハッシュのすべてのビットを考慮し、%を使用するよりも高速です。必ずしもモジュラスである必要はなく、範囲内0..N-1(Nはバケットの長さ)にあることが保証されているだけで、すべてのスロットに均等に分布しています。そのようなアルゴリズムは存在しますか? 助けてくれてありがとう。

3
ファイルの1つのバージョンをプライベートに保つためのgithub戦略
私は学生のためにコーディングの問題を書く講師です。私がやりたいのは、生徒が完了すべき機能のプレースホルダーを含む定型コードを生徒に与えることです。これを複製するために、学生にプライベートgithubリポジトリへのアクセスを許可します。 ただし、サンプルソリューションを備えたバージョンのコードベースも必要です。明らかに、生徒にソリューションへのアクセス権を与えたくありません(課題が終了するまで)。 私はブランチについて考えましたが、私の知る限り、1つのブランチをプライベートに保つことはできません。 プロジェクトを別のプライベートリポジトリにフォークすることもできますが、プロジェクトをsnycに(ソリューションを含むファイルは別として)保持する方法はわかりません。 この状況のワークフローはありますか?
11 git  github 

7
オブジェクト指向のオブジェクト指向言語での実装?
カーレースをシミュレートするJavaコードをいくつか見てきました。これには基本的なステートマシンの実装が含まれています。これは、古典的なコンピューターサイエンスステートマシンではなく、複数の状態を持つことができ、一連の計算に基づいて状態を切り替えることができるオブジェクトにすぎません。 問題だけを説明するために、Carの状態の定数(OFF、IDLE、DRIVE、REVERSEなど)を定義するネストされたenumクラスを持つCarクラスを取得しました。この同じCarクラス内には、更新機能があります。これは基本的に、現在の車の状態を切り替え、計算を行い、車の状態を変更する大きなswitchステートメントで構成されています。 私が見る限り、Cars状態は独自のクラス内でのみ使用されます。 私の質問は、これが上記の性質のステートマシンの実装を処理する最良の方法ですか?それは最も明白な解決策のように聞こえますが、過去には「switchステートメントが悪い」といつも聞いていました。 ここで見られる主な問題は、状態を追加すると(必要に応じて)switchステートメントが非常に大きくなり、コードが扱いにくくなり、保守が難しくなる可能性があることです。 この問題のより良い解決策は何ですか?

5
2人のユーザーが同じユーザー名で同じ瞬間に登録するのを防ぐ方法は?
何百万人ものユーザーが同時に登録しているため、登録をシリアル化できません。並行して登録する必要があります。 データベースにユーザー名「user1」が含まれていないとしましょう。2人のユーザーが「user1」に同時に登録しようとすると、それが受け入れられます。ただし、後で問題が発生します。これは起こらないはずです。 論理的な解決策を探しています。特定のものではありません。これを解決するためのアイデア。

2
ソフトウェア開発における日常作業の量とその推定への影響
私は、ソフトウェア開発における日常的な作業の量は、無視できないとはいえ、比較的小さく、そしてそうあるべきであり、これがソフトウェア推定の基本的な問題であると確信しています。 この結論に至った経緯を説明し、議論に重大な欠陥があるかどうかを教えてください。 高精度で推定できるのは、以前に行われたことを意味する日常業務です。研究と創造性を含む他のすべての種類の作業は、少なくとも+/- 20%の精度では、実際には推定できません。 ソフトウェア開発とは、繰り返し作業を避けることです。その基本原則の1つはDRYです(繰り返さないでください)。プログラマーが繰り返し作業をしていることに気づいたときはいつでも、この繰り返しを回避する抽象化を見つける時が来ました。これらの抽象化は、繰り返しコードを関数に抽出したり、ループに入れたりするような単純なものにすることができます。また、ドメイン固有の言語を作成するなど、より複雑にすることもできます。いずれにせよ、それらの実装には、研究(これを以前に行ったことはありますか)または創造性が伴います。 これらの2つのポイントから、上記の結論を導き出します。 実際、私はこの関係が他のすべての議論、ブログ投稿、またはソフトウェア推定に関する記事で言及されていない理由をかなり長い間疑問に思っていました。理論的すぎますか?私の仮定は間違っていますか?それとも、ささいなことですが、なぜ私が知っているほとんどの開発者は、+ /-20パーセント以上の精度で見積もることができると信じているのですか?

7
Cからは、より高いレベルの言語では学べない原則は何ですか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 3年前に閉店しました。 Cはプログラミングの背後にある原則を学ぶのに適した言語だと思います。Rubyのような高レベルな言語から「魔法のように」なっている低レベルの言語で何を学べると思いますか?
11 c  low-level 

3
S式(-ish)表記法に対するXMLの利点は何ですか?
XMLおよびS-expressions(-ish)表記法について質問したいと思います。S式はかなり古いです。また、それらは本当にシンプルです。意味が等しく、構文が異なる2つの形式を検討できます。 (ポーランド語のウィキペディアから取られたxmlコード) <?xml version="1.0" encoding="UTF-8"?> <ksiazka-telefoniczna kategoria="bohaterowie książek"> <!-- komentarz --> <osoba charakter="dobry"> <imie>Ambroży</imie> <nazwisko>Kleks</nazwisko> <telefon>123-456-789</telefon> </osoba> <osoba charakter="zły"> <imie>Alojzy</imie> <nazwisko>Bąbel</nazwisko> <telefon/> </osoba> </ksiazka-telefoniczna> S-Expression(-ish)バージョン: (:version "1.0" :encoding "utf-8") (ksiazka-telefoniczna :category "bohaterowie książek" ; komentarz(a comment) (osoba :charakter "dobry" (imie Ambroży) (nazwisko Kleks) (telefon 123-456-789)) (osoba :charakter "zły" (imie Alojzy) …
11 xml 

6
ワードあたり2のべき乗のビットは「便利」ですか?もしそうなら、なぜですか?
バイナリワードの2のべき乗のビット(バイトあたり8ビットなど)が「良いこと」または「便利だ」と主張するソースがいくつかあります。理由を指摘する情報源は見つかりません。 からバイトが8ビットである理由の歴史は何ですか?承認済みの回答を読みます。 バイナリコンピューターは、設計者が2の累乗のサイズを作成するように動機付けます。 いいけどなんで?同じ質問ですが、私が見つけた質問のコメントフィールドに: 最後の文は冗談ですか?12ビットのバイトは2のべき乗ではないため不便です。-robjb 繰り返しますが、理論的根拠はありません... アドレスの計算は2のべき乗で非常に単純であり、小さな缶で生のトランジスタからロジックを作成する場合に重要です-マイク バイトは最小のアドレス可能な単位なので、これはあまり意味がありません。しかし、コメントに対する賛成がたくさんあります。たぶん私は何かを見逃した。 ウィキペディアから: 8ビットの事実上の標準は、1バイトに値0〜255を許可する便利な2の累乗です。 そして、これは便利だろう...? 明確にするために、これはバイトあたりのビット数(例:8または6など)であり、バイトあたりの値数(例:2 8または2 6など)ではありません。混乱のため、これはWordのサイズに関するものではないことも指摘します。 私は歴史的な理由に過度に興味はありません。それらは他の場所でよく説明されています(リンクを参照)。 SOに関する関連質問:https : //stackoverflow.com/questions/1606827/why-is-number-of-bits-always-a-power-of-two
11 hardware  byte  bit 

3
非CRUD操作を処理するREST APIを設計する方法は?
SOAPベースのサービスのセットをRESTful APIに変換しようとしています。 オペレーション名を分析してリソースを識別することから始め、リソースを取得しましたSubscription。 サブスクリプションの状態を更新する必要がある場合POST、リソースに直接アクセスできないため、サーバーに単純に要求を送信することはできませんが、RPCスタイルの操作を呼び出してプロパティを更新する必要があります。さらに、サブスクリプションの状態を「アクティブ」に変更する場合にのみ、外部サービスへの追加の呼び出しが必要です。 これらの場合、基礎となる操作を処理するためのベストプラクティスは何ですか? 私が思いついた解決策は、クエリパラメータを使用することです。そのため、アクティベーションサービスを呼び出す必要がある場合は、次のようなものを使用できます。 POST /subscriptions/{subscriptionid}/?activate=true Subscriptionオブジェクトのフィールドを直接更新できないことを考えると、この種の変換を処理するベストプラクティスはありますか? 更新1: POSTリクエストの本文にいくつかの値、たとえば「state」:「active」を入れることができます サービス内でトリガーされる適切な操作を確認します。

3
`Employee`クラスはどのように設計されるべきですか?
私は従業員を管理するためのプログラムを作成しようとしています。ただし、Employeeクラスの設計方法を理解することはできません。私の目標は、Employeeオブジェクトを使用してデータベース上の従業員データを作成および操作できるようにすることです。 私が考えた基本的な実装は、この単純な実装でした: class Employee { // Employee data (let's say, dozens of properties). Employee() {} Create() {} Update() {} Delete() {} } この実装を使用すると、いくつかの問題が発生しました。 ID従業員のは、私は、新しい従業員を記述するためのオブジェクトを使用するのであれば、何があるだろう、データベースによって与えられていないID既存の従業員を表すオブジェクトはながら、まだ格納するだろう持っていますID。そのため、オブジェクトを説明するプロパティと、オブジェクトを説明しないプロパティがあります(SRPに違反していることを示すことができますか?新しいクラスと既存の従業員を表すのに同じクラスを使用しているため...)。 Create一方、この方法は、データベース上の従業員を作成することになっているUpdateとは、Delete既存の従業員(ここでも、上で動作するようになっているSRP ...)。 「作成」メソッドにはどのようなパラメーターが必要ですか?すべての従業員データまたはEmployeeオブジェクトのための数十のパラメーター? クラスは不変であるべきですか? どのようにUpdate動作しますか?プロパティを取得してデータベースを更新しますか?または、「古い」オブジェクトと「新しい」オブジェクトの2つのオブジェクトを取り、それらの違いでデータベースを更新しますか?(答えは、クラスの可変性に関する答えと関係があると思います)。 コンストラクターの責任は何ですか?必要なパラメーターは何ですか?idパラメーターを使用してデータベースから従業員データを取得し、プロパティを設定しますか? それで、あなたが見ることができるように、私は私の頭の中に少し混乱を持っています、そして、私は非常に混乱しています。そのようなクラスがどのように見えるべきかを理解してください。 このような頻繁に使用されるクラスが一般的にどのように設計されているかを理解するためだけに、意見を望まないことに注意してください。

1
オニオンアーキテクチャと3層アーキテクチャ
BLがCRUDを実行するためにDAL(またはDALのインターフェース)のメソッドを呼び出す責任を負った3層アーキテクチャーよりも、オニオンアーキテクチャーにのみ利点があると思います。タマネギは、関心事、テスト容易性、保守容易性のより良い分離があり、よりきれいです。 だから、オニオンアーキテクチャはすべての面で本当に優れており、3層アーキテクチャは物事を行うための古い方法にすぎません。または、3層アーキテクチャを使用したい場合、いくつかのシナリオがあります。

2
推移的な依存関係に依存するか、明示的に宣言する方が良いでしょうか?
私はこのようなプロジェクト構造を持っています: My Project - Other Team's Project -Third Party Dependency My ProjectOther Team's Project機能する必要があり、両方My Projectと機能Other Team's Projectする必要Third Party Dependencyがあります。これらを管理するために、依存関係管理システムを使用しています。 設計の観点から、My Project推移的に依存する方が良いThird Party Dependencyでしょうか?それとも、両方のために優れているMy ProjectとOther Team's Projectの両方に明示的に彼らが使用することを宣言しますかThird Party Dependency? 他のいくつかのこと: 両方のプロジェクトに同じバージョンのが必要ですThird Party Dependency。 それらが異なるチームによって管理されているため、何も壊れないことを保証するためにテストされるOther Team's Project更新された場合は保証されませんMy Project。

4
機能ブランチの作業中にコード品質を改善する必要があります
あなたが見つけたよりも良い状態にコード/キャンプサイトを残すことについてのこの記事が本当に好きです -コードの清潔さを維持するための現実の現実的なアプローチのようです。 また、機能を単独で開発する方法として機能ブランチが本当に好きなので、気に入らない場合は簡単にマージできないなどです。 ただし、機能ブランチで作業しているときにifいコードを見つけた場合、修正する必要がありますか? それを修正するには多くの欠点があるように感じます: ブランチをマージして戻すと、diffが乱雑になり、変数名の変更や関数の抽出が乱雑になります 機能が放棄された場合、クリーンアップコミットをチェリーピック(近くのコードが変更されて乱雑なマージが行われた方法に応じて機能する場合と機能しない場合があります)、再実行、または単に放棄する必要があります。 反対に、ファイルにいるときに実行しないと、ブランチをマージする数日後に実行するのを忘れることになります。 私はこれが意見に基づいていると警告されました(タイトルに含まれている事実から外れていると思いますshould)が、答えがあると感じています(確かに人々は両方のアプローチを使用しているので答えが必要です)。また、についての質問development methodologiesは話題になっており、ある程度の意見が必要だと思います。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.