ソフトウェア工学

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

3
関連する一連のプロパティを独自の構造体/クラスにラップすることは良い習慣ですか?
私の質問は強く型付けされた言語に関係しますが、SwiftでUserオブジェクトを作成します。ユーザーは多数のリンク(FacebookProfile、InstagramProfileなど)を持つことができます。これに関するいくつかの質問。 リンクを独自のオブジェクトでラップすることは良い習慣ですか? struct User { var firstName:文字列 var lastName:文字列 var email:string varリンク:リンク } 構造体リンク{ var facebook:string var instagram:文字列 var twitter:文字列 } それともルーズにすべきですか?技術的にはどちらの方法でも問題ないことはわかっていますが、一般的に、特に読みやすさのために、推奨されるアプローチがあるかどうか疑問に思います。 struct User { var firstName: string var lastName: string var email: string var facebookLink: string var twitterLink: string var instagramLink: string } このようなシナリオでは、リンクはコレクション/リストにする必要がありますか?利用可能なリンクオプションの数は決まっているため、リストの数にしないでください。数は増えていません。私の考えは正しいですか? getUsers、getUser、updateUserなどのユーザーオブジェクト内にネットワークメソッドを配置することは良い習慣ですか? これらは主観的である可能性があることは知っていますが、同様の状況でのベストプラクティスを理解しようとしています。任意のポインタをいただければ幸いです。

4
一意のインデックスを追加できない場合に重複を回避するために可能な方法は何ですか
同時実行の問題で立ち往生しています。 ユーザーが2から3のトランザクションを送信して、DBで重複してはならないデータを永続化するという典型的な問題です。重複するレコードがある場合、エラーを返す必要があります。 この問題は、ハッシュを格納する列にインデックス(一意)を追加できる場合は簡単です。 しかし、この場合、巨大なテーブル(おそらく数百万のレコード)があり、テーブルを変更することはできません。 実際、重複してはならないデータのハッシュを格納する列がありますが、一意のインデックスは設定されていません。 フラッシュの直前にJavaコードが存在するかどうかを確認しようとしていますが、それでも重複が発生します。 これに対する私の可能な解決策は次のとおりです。 挿入しようとしているハッシュがテーブルに既に存在するかどうかをチェックするトリガーを作成します。 このテーブルの一意のインデックスを格納する別のテーブルを作成し、メインテーブルに外部キーを追加します。 胎児の位置に座り泣く

1
Null-Safe演算子(「Elvis演算子」など)がJava 7の「プロジェクトコイン」の一部として拒否されたのはなぜですか?
Java 7の「Project Coin」に提案された機能の1つは「Elvisオペレーター」でした。2009年のJavaOneプレゼンテーションのレポートプロジェクトコインには、そのように説明しました。 このプレゼンテーションで取り上げられている「小さな機能」の1つは、いわゆる「エルビス演算子」です。これは、3項演算子のより簡潔なバージョンです。伝統的なJavaを使用すると、Groovyの一部の機能が欠けていることに気づきました。これは、追加された場合、両方の言語で使用できる1つの演算子になります。「Elvis」演算子は、評価された式がnullのときに使用できるデフォルト値を指定するのに便利です。Groovyの安全なナビゲーション演算子と同様に、これは不要なnullを回避する方法を指定する簡潔な方法です。NullPointerExceptionを回避する方法については、以前ブログで説明しました。 プロジェクトコインの他の側面は最終的に実装されましたが、これは実装されませんでした。含まれる可能性のある候補としてJavaOneで提示されたにもかかわらず、Elvisオペレーターが最終的に拒否されたのはなぜですか? 明確にするために、私はこのオペレーターについて具体的に尋ねています。このオペレーターが当時真剣に検討されていたため、Java 7の「プロジェクトコイン」の一部として拒否された理由についてです。メーリングリストなどで拒否の理由が議論されているのではないかと思いますが、何も見つかりませんでした。Javaのどのバージョンにも含まれていない理由に関するより一般的な情報がある場合、それは許容されますが、好ましくありません。
10 java  api-design 

2
集計境界を設計する方法は?
eコマースのようなアプリケーションを書きたいのですが。 また、類似のアプリケーションでは、製品のプロパティと機能が異なる場合があります。このような機会をシミュレートするために、次のドメインモデルエンティティを作成しました。 カテゴリ -これは「エレクトロニクス>コンピューター」のようなもの、つまり製品のタイプです。Сategoriesには、プロパティのリストが含まれています(List <Property>)。 プロパティ -名前、測定単位、データ型を含む独立したエンティティ。たとえば、「名前」、「重量」、「画面サイズ」。同じプロパティに異なる製品を含めることができます。 製品 -プロパティに関連する名前と値のリストのみが含まれます。Valueは、プロパティの値フィールドとフィールドIDのみを含むオブジェクトです。 たとえば、新しい製品を追加するときに、現在のカテゴリに関連するプロパティ(category.AddNewProduct(product))を含む現在のカテゴリに関連するすべてのデータを知る必要があるため、このスキームでカテゴリを単一の集計のようにすることを最初に決定しました。しかし、どのカテゴリにも属さない新しいプロパティを追加する必要がある場合はどうすればよいですか。たとえば、特定のカテゴリにプロパティを追加することを明確に示しているため、このcategory.AddNewProperty(property)は実行できません。 次のステップでは、個別のプロパティを個別の集計に決定しましたが、それは単純なエンティティのリストになります。 もちろん、PropertyAggregateのようなものを作成して、プロパティとビジネスルールの内部リストを保持できますが、製品を追加するときは、不変条件を確認するために、このカテゴリに属する​​プロパティのリスト全体をカテゴリ内に含める必要があります。しかし、アグリゲート内のリンクを他のアグリゲートで維持することは悪い習慣であることも知っています。 このビジネスケースを設計するためのオプションは何ですか?

2
サーバーレスアーキテクチャはどのようにデータベース接続を管理しますか?
サーバーレスアーキテクチャの主な利点は、そのようなプログラムが継続的に実行するために専用サーバーを必要としないことです。次に、要求時に呼び出され、関数の終了時に停止します。 つまり、レスポンシブであるためには、サーバーレスプログラムをすばやく起動する必要があります。次に、データベース接続などの時間のかかるアクションをどのように処理しますか?それは毎回データベースに接続しますか、それともサーバー接続で行われるような関数呼び出しのためにデータベース接続を個別に管理しますか?

1
依存バージョンの競合を回避しますか?
私のjarを使用するすべてのJavaプロジェクトは、ほぼ確実に、私のjarにも依存関係として含まれている別のjarへの追加の依存関係があります。 問題は、他のjarに複数のバージョンがあることです。 プロジェクトの2番目のjarのバージョンが私のjarの2番目のjarのバージョンと異なる可能性が高い場合に、発生する可能性のある問題を回避するにはどうすればよいですか? 私のjarファイルを追加するために、ユーザーが特別なクラスローディングトリックを実行するという面倒なことをしたくありません。 その共通の依存関係のすべての可能なバージョンについて、jarのさまざまなバージョンの束を作成する必要がありますか?そして、あなたはちょうどあなたがたまたま持っている2番目のjarの同じバージョンを使用する私のjarのバージョンを選択するだけですか? これを処理するよりスマートな方法はありますか、そして人々が衝突することなく私のjarをより簡単に使用できるようにしますか?

2
ダイアディック関数assertEquals(expected、actual)に伴う問題の解決
長年にわたるカウボーイコーディングの後、私は良質のコードを書く方法についての本を手に入れることにしました。私はRobert Cecil MartinのClean Codeを読んでいます。第3章(関数)には、2項関数に関するセクションがあります。これは本からの抜粋です。 のような明白な二項関数でさえassertEquals(expected, actual)問題があります。予想されるはずの場所に実際の回数を何回入れましたか?2つの引数には自然な順序はありません。予想される実際の順序は、慣れるために習得する必要がある規則です。 著者は説得力のあるポイントを作成します。私は機械学習で働いており、これにいつも出会います。たとえば、sklearnライブラリのすべてのメトリック関数(おそらくフィールドで最も使用されているpythonライブラリ)では、入力の順序に注意する必要があります。例として、sklearn.metrics.homogeneity_scoreは入力labels_trueおよびとして使用されlabels_predます。この関数の機能はあまり重要ではありません。重要なのは、入力の順序を切り替えてもエラーがスローされないことです。実際、入力を切り替えることは、ライブラリ内の別の関数を使用することと同じです。 ただし、この本では、のような関数の賢明な修正については触れていませんassertEquals。assertEquals上記のような頻繁に遭遇する機能の修正については考えられません。この問題を解決するための良い方法は何ですか?
10 functions 

3
イベントを再生するときにCRQSの副作用を処理するにはどうすればよいですか?
CQRSではバグを修正するのは簡単で、イベントを再デプロイして再生するだけだと言われています。 ただし、イベントを再生するだけでアイテムが2回出荷される場合、イベントの1つが原因で、制御できない外部システムが顧客に「アイテムを出荷する」原因となる場合はどうでしょうか。 それをどのように解決しますか?

6
コーディングする前にOOPシステムを設計する簡単なプロセスは何ですか?
プロジェクトを構築する必要が生じたときはいつでも、事前に計画や設計を考案するのではなく、いつでもそれを構築することができましたが、最初に必要なクラスを書いた後、プロジェクト全体を具体化し、ボトムアップで構築しました。これはソフトウェアを作成する適切な方法ではないことはわかっていますが、オブジェクト指向分析とデザインと呼ばれるものに頭を悩ますことは簡単ではありません。トップダウンの手順設計をより簡単に理解できます。それは、タスクをサブタスクに分解することで構成されているためです。しかし、オブジェクト指向の分析と設計は簡単に理解できません。どのようにコード化するかを知らない限り、必要なクラスとそれらがどのように相互作用するかを知る方法がわかりません。 クラスとオブジェクトの概念を設計プロセスに導入すると、問題をプロシージャとして実装できるものに分解することがなくなるため、トップダウンで設計することができなくなります。代わりに、私が主題について読んだ内容に従って、必要なクラスを決定し、ソフトウェアを実装するときに使用できる統一モデリング言語でさまざまなアーティファクトを作成する必要があります。しかし、私はこの種の設計プロセスを理解していません。すでにシステム全体を考えていなければ、どのクラスが必要になるのか、そしてどのように相互作用するのかをどうやって知るのですか? これが私の問題です。私はオブジェクト指向プログラミングの概念を理解していますが、オブジェクト指向システムの設計方法を理解していません。それらの概念は、私が知っている任意のオブジェクト指向プログラミング言語で使用できます。したがって、私には、私にとって意味のある方法でオブジェクト指向システムを設計するために使用できる単純なプロセスを説明してくれる人が必要です。

3
インターフェース分離の原則は具体的な方法に適用されますか?
インターフェース分離の原則は、クライアントが使用しないメソッドに依存することを強制されるべきではないことを示唆しているので、クライアントはそのインターフェースメソッドに空のメソッドを実装すべきではありません。 しかし、具体的な方法はどうですか?すべてのクライアントが使用するわけではない方法を分離する必要がありますか?次のクラスを考えてみましょう: public class Car{ .... public boolean isQualityPass(){ ... } public int getTax(){ ... } public int getCost(){ ... } } public class CarShop{ ... public int getCarPrice(int carId){ Car car=carList[carId]; int price=car.getTax() + car.getCost()... (some formula); return price; } } 上記のコードでは、CarShopはisQualityPass()を新しいクラスに分離する必要がある場合、CarでisQualityPass()メソッドをまったく使用しません。 public class CheckCarQualityPass{ public boolean isQualityPass(Car car){ …

2
メソッドのパラメーター化とグローバル変数
私のコードが成長し始めるとき、私をしばらく悩ませてきた非常に単純な質問があります。 ネストされた関数呼び出しの長いルートを通過するときに、パラメーターをグローバル変数に置き換える必要がありますか? 多くの関数が共有変数を変更できるため、グローバル環境はプログラムの状態を予測不可能にする可能性があることを理解していますが、それでもグローバルスペースは物事をとても簡単にします。 私自身について説明しましょう: functionA(){ x = something functionB(x) } functionB(x){ functionC(x) } functionC(x){ finallyDoSomethingWithX(x) } finallyDoSomethingWithX(x){ x += 1 //Very dummy example ignoring pass by value, not reference. } と取り換える: globalX; functionA(){ globalX = something functionB() } ... ... ... finallyDoSomethingWithX(){ globalX += 1 } 2番目の方法は、パラメーターが簡単に蓄積され、コードを再利用する必要があるときに非常に制限される場合があるため、プログラムに非常に多くの自由を与えると感じますが、同時に、変数に関連する場合、関数がモジュール性を失うように感じますグローバル環境では、たとえば、finallyDoSomethingWithX別の変数thaで操作したい場合にも再利用性が失われglobalXます。 私は実際にデザインパターンを使用していないため、これが起こっていると思います。Javascriptでプログラミングしているためです。私にとっては、中規模プロジェクトでは、1つのスクリプトですべてを扱う言語のように感じます。 何かアドバイスは?パターン?必要に応じて、より具体的にすることができます。

3
依存性注入:すべてのパーツを保持するCarクラスを作成する必要がありますか?
私のC ++アプリケーションには多くの車があり、すべてRaceTrackに含まれています。 各車は何百ものパーツで構成されています。各部分は他の部分に依存しています。 私はDIとMark Seemannの本で多くのSO質問を読みましたが、すべての自動車部品は相互に依存し、この部品のスープは自動車なので、自動車部品を保持するためだけにCarクラスを定義するべきではないようです。私は正しいですか? したがって、すべてのレーシングカーをRaceTrackに配置すると、自動車の実体はなく、トラック上で互いにレーシングし合うことに依存する多くの自動車部品がありますか?私は正しいですか? 編集: 車のロジックをプログラミングしている場合は車のクラスが必要であることは明らかだったので、長い間私は車のクラスをプログラミングしていました。しかし、DIでは、それは私にはそれほど明白ではありません。Carクラスが定義されていない場合にCarクラスを作成しないのは、DIの慣用句ですか? つまり、運転用にSteeringWheelを、ピットクルー用にホイールにBoltsAndNutsを配置し、車全体を表すインスタンスがなくても、他のあらゆる種類の面白いインターフェースを配置しても問題ありませんか?

2
blue-sky / prototypeプロジェクトで最初に単体テストを作成するか統合テストを作成するかを評価する
最近気付いたのは、次のタイプのプロジェクトを実行しているときです。 プロジェクトを始めるとき MVP /プロトタイプの作業 完全に定義されていない機能を追加する 小規模プロジェクトでの作業 参考までに、私は現在、いくつかのコメントとすべての空白を含む、現在〜1k行のコードがあるPythonプロジェクトに取り組んでいます。 私は、コードの最初の書き込みの統合テスト、仕事にそれが非常に簡単に見つけて、その後、それ一度APIは、多少のユニットテストを追加することで、実際に作業を硬化させます。私のmain関数で実行できるテストの種類、いわば、何よりも「エンドツーエンド」です。 これは、APIがかなり急速に変化しているときにユニットテストが本当に煩わしいためです。これは、上記の条件のいずれかまたはほとんどに一致するプロジェクトで作業している場合によくあります。 このアプローチは良いアプローチですか?これらのタイプのプロジェクトの最初に単体テストと統合テストのどちらを開始するかを決定するとき、どの基準を考慮する必要がありますか?APIがより強固になる前に、この種のプロジェクトを単体テストすることの価値を見逃していますか?

2
ラージスケールスクラム(LeSS)およびスケールドアジャイルフレームワーク(SAFe)の意図された、またはターゲットの組織規模はどれくらいですか?
スクラムガイドは 5と11のメンバー間のどこかのために製品の所有者、3-9員の開発チーム、および1スクラムマスターで構成され、単一のユニットを定義します。プロダクトオーナーがサポートスタッフを持っている場合や、チームがその数をわずかに変更するための専用のスクラムマスターを持っていない場合がありますが、約12人で制限されているようです。 ネクサスガイドは、単一の製品に取り組んで3-9スクラムチームを処理するためにスクラムをスケーリングする1つの方法を説明します。専用のメンバーになるか、さまざまなスクラムチームのメンバーで構成される新しいNexus統合チームが追加されます。そのガイドに基づいて、それは約20〜120人にスケーリングされます。 統制のとれたアジャイルは、1チームからNチームにスケールアップできます。標準的な個々のチームのサイズは、スクラムとほぼ同じです。3〜9人のメンバーと、さまざまなスペシャリスト、独立したテストチーム、ドメインエキスパートなどからのサポートの役割です。このフレームワークでの考慮事項は、単純なスケーリングではなく、アジャイルメソッドの適用です。大規模な組織では、コンプライアンス、アウトソーシング、グローバルに分散されたチームを必要とする規制環境。制限は、製品または製品ラインごとにDAのインスタンスを1つ持つことです。 程度の差はありますが、私はスクラム、ネクサス、DADを使用したプロセスの作業または実装に携わってきたので、それらについてしっかりと理解しています。私は、他の人が言っていることを読んでいる以上に、LeSSとSAFeの実用的な知識を持っていません。 LeSSは簡単なようです。これは、Nexusに代わるものであり、はるかに大きな拡張機能を備えています。LeSSのルールでは、LeSSは2〜8チーム向けに設計され、LeSS Hugeは8チーム以上向けに設計されています。開発組織のサイズは、LeSSの場合は15〜80、LeSS Hugeの場合は80以上と推定されます。組織によっては、LeSSの製品組織で20〜110人、LeSS Hugeで100人以上が見られ、管理、独立したQA、運用などがカウントされます。どちらの形式のLeSSも、単一の製品、またはおそらく密接に関連する一連の製品(製品ラインやマイクロサービスのセットなど)を対象としています。すべての製品には、LeSS(またはLeSS Huge)の独自のインスタンスがあります。 SAFeには、組織全体(操作、ユーザーエクスペリエンス、エンタープライズアーキテクトおよびシステムエンジニア、製品マネージャー、QA、開発者など)が含まれているようです。3つのレベルの組織と4つのレベルの組織という2つのモデルがあります。3レベルの組織は、チーム、プログラム、およびポートフォリオを識別します。4レベルの組織は、プログラムとポートフォリオの間にバリューストリームレベルを追加します。識別された役割の数に基づいて、これは複数の製品と並行プログラムを持つ大企業組織をターゲットにしているようです。実装のためのガイダンスを読む、彼らは実装組織が幹部と管理を訓練し、それから少なくとも50人の開発チームのメンバーを訓練することを期待しているようです。最小の組織サイズは、特定されたすべてのグループおよび実装を意味のある複数の製品にわたって数百人と思われます。 LeSSはターゲットオーディエンスに関してNexusの「競争相手」であり、SAFeは他のスケーリングされたアジャイルフレームワークよりもはるかに多くの製品または製品ラインを持つ非常に大規模な組織をターゲットにしているという私の想定では正しいですか?

8
どのようなアルゴリズムにセットが必要ですか?
私の最初のプログラミングコースでは、何かの重複を削除するなどの必要があるときは常にセットを使用するように言われました。例:ベクトルからすべての重複を削除するには、上記のベクトルを反復処理して各要素をセットに追加すると、一意のオカレンスが残ります。ただし、各elementoを別のベクトルに追加し、要素が既に存在するかどうかを確認することで、これを行うこともできます。使用する言語によってパフォーマンスが異なると思います。しかし、それ以外のセットを使用する理由はありますか? 基本的に、どのような種類のアルゴリズムがセットを必要とし、他の種類のコンテナでは実行すべきではないのですか?

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