ソフトウェア工学

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

1
オープンソースライセンス互換性チェッカー
オープンソースライセンスのさまざまな組み合わせが相互に互換性があるかどうかを確認するためのツールはありますか？ Apacheのライセンスは、許可と法律の強制力のバランスが取れていると思われるため、Apacheライセンスを配布に使用するさまざまなツールの構築を計画しています。ただし、他のオープンソースプロジェクトのコンポーネントをコードベースに含めるか、アダプターを使用可能にして、エンドユーザーがそのようなコンポーネントをコードベースに統合できるようにします。 たとえば、CKEditorやTinyMCEなどのリッチHTMLエディターをパッケージに含めたいのですが、そうすると、どちらのプロジェクトのライセンスにも違反しますか？GPLコードを使用した場合、プロジェクトをGPLにすることを余儀なくされることは間違いありません。しかし、MPL、LGPLなどはどうでしょうか？ 純粋に技術的な理由でそのような決定をしたいのですが、もしあなたがオープンソースをしているなら、他のオープンソースプロジェクトの希望を無視するのは愚かなことでしょう。 ライセンスXがライセンスYと互換性があるかどうかを判断するのに役立つツールを探しました。その場合、どの方向で互換性がありますか（Xは問題なくYを含めることができますが、YにXが含まれる場合は問題があるなど）。代替ライセンス条項にコードを含めると、ライセンス条項にどのような影響がありますか。ただし、これまでに見つけたのは、他のライセンスとGPLを比較するのに適したリストとチャートだけです。ライセンスの問題を解決するツールがあれば、正しい方向に向けていただければ幸いです。
1
Brendan Eichが引用したPeter Norvigの論文
私はCoders at Workを読んでいますが、Brendan EichはNorvigがHarlequinにいたときの「デザインパターンが実際にプログラミング言語の単なる欠陥である方法について」という論文を引用しています。 誰でもこのペーパーへのリンクを提供できますか？
2
Agile / SCRUMで使用するポイントスケールの選択に関する優れたガイドですか？
プロジェクトにはPivotal Trackerを使用しており、次の3つのポイントスケールから選択できます。 0,1,2,3 0,2,4,8 0,1,3,5,8 そして、私たちの決定を導くのに役立つリソースを探しています。（2回の反復で0,1,2,3を使用した後、他の1つがはるかに有用または意味のある場所を確認できます。）
10 agile  scrum 
5
継続的インテグレーションパイプラインで信頼できる十分な自動テストがあるのはいつですか？
テストとの継続的な統合は、常に「出荷可能な」コードがチェックインされていることを確認するのに役立ちます。 ただし、包括的なテストスイートを維持することは非常に難しく、多くの場合、ビルドにバグがあるように感じます。 CIパイプラインテストに自信を持たせるには、どのくらいのテストが必要ですか。十分なテストがあるかどうかを判断するために、ある種のメトリックを使用していますか？
4
関数を呼び出すこの方法は悪い習慣ですか？
私は次のコードを持っています： public void moveCameraTo(Location location){ moveCameraTo(location.getLatitude(), location.getLongitude()); } public void moveCameraTo(double latitude, double longitude){ LatLng latLng = new LatLng(latitude, longitude); moveCameraTo(latLng); } public void moveCameraTo(LatLng latLng){ GoogleMap googleMap = getGoogleMap(); cameraUpdate = CameraUpdateFactory.newLatLngZoom(latLng, INITIAL_MAP_ZOOM_LEVEL); googleMap.moveCamera(cameraUpdate); } このようにすると、LatLngたとえば、別のクラスの内容を知る責任がなくなると思います。 また、関数を呼び出す前にデータを準備する必要はありません。 どう思いますか？ このアプローチには名前がありますか？それは本当に悪い習慣ですか？
4
すべての要件を収集する前にリリース日を決定することは機敏ではありませんか？
私はCraig Larman著の 『Applying UML and Patterns』を読み始めたところです。それは私が仕事で言われたことの多くに挑戦するのでそれは非常に興味深いと思います。要件はアジャイルで一度に完全に収集されるわけではなく、要件の収集を完了するには多くの反復が必要であると私は読んだ。その場合、明日、新しい画期的な要件（または要件としてマスカレードする変更要求）が存在する可能性があることを考えると、ハードセットの締め切りを設定することになります。
5
PostgreSQLなどのリレーショナルデータベースのトリガーは本当に必要ですか？
保存されたデータを検証してデータベースの整合性を保つためにトリガーを使用できることを知っています。ただし、データをデータベースに格納する前に、アプリケーション側でデータの検証を実行してはどうでしょうか。 たとえば、クライアントを保存し、DDLレベルでは簡単に実行できない検証を実行したいとします。 https://severalnines.com/blog/postgresql-triggers-and-stored-function-basics 別の例は監査です。 更新 トリガーとデータベーストランザクションがどのように連携するか。たとえば、挿入されているデータの検証を実行したい場合などです。トランザクション内で行われます。以前に何が起こるか：トランザクションがコミットされるか、トリガーが実行されますか？
4
「時期尚早の抽象化」とは何ですか？
私はフレーズが乱れているのを聞いたし、私には議論が完全に正気ではないように聞こえます（ここでわざわざ言っているとすみません、それは私の意図ではありません）。 一般的なケースがわかる前に抽象化を作成したくない場合は、（1）属していないものを抽象化に入れるか、（2）重要なものを省略します。 （1）私にはこれはプログラマーが十分に実用的ではないように聞こえます、彼らは最終的なプログラムには存在しないものがあると仮定しているので、抽象化のレベルが低い状態で作業していますが、問題はありません時期尚早な抽象化、それは時期尚早な結着です。 （2）重要なことの省略は1つです。後で重要になることが仕様から省略されている可能性があります。これに対する解決策は、独自の結論を導き出してリソースを無駄にすることではありません。間違っていると思います、それはクライアントからより多くの情報を取得することです。 これは、抽象化から具体化に至るまで常に作業する必要があります。これは、最も実用的な方法であり、その逆ではないためです。 そうしないと、クライアントを誤解し、変更が必要なものを作成するリスクがありますが、クライアントが独自の言語で定義した抽象化のみを構築する場合は、このリスクにぶつかることはありません（少なくとも、いくつかの具体的な暗闇の中でのショット）、はい、クライアントは詳細について考えを変える可能性がありますが、本来彼らが望むものを伝えるために使用していた抽象化は依然として有効である傾向があります。 以下に例を示します。クライアントがアイテムバギングロボットの作成を希望しているとします。 public abstract class BaggingRobot() { private Collection<Item> items; public abstract void bag(Item item); } 私たちは、クライアントが使用した抽象化から何かを構築していますが、わからないことについては詳しく説明していません。これは非常に柔軟性があり、「時期尚早な抽象化」と呼ばれるのを見てきましたが、実際にはバギングがどのように実装されたかを想定するのは時期尚早です。複数のアイテムを一度にバギングすることをクライアントと話し合った後、 。クラスを更新するために必要なのはシグネチャを変更することだけですが、ボトムアップを始めた人にとっては、大規模なシステムのオーバーホールが必要になる可能性があります。 時期尚早な抽象化などはなく、時期尚早な結集だけです。このステートメントの何が問題になっていますか？私の推論のどこに欠陥がありますか？ありがとう。
1
API Gatewayの背後にあるマイクロサービスはアクセストークンを検証する必要がありますか？
APIゲートウェイ経由でのみ外部からアクセスできるマイクロサービスがたくさんあります。 API GatewayはOAuthリソースとして設定され、1つ以上のマイクロサービスにダウンストリームのリクエストを渡す前にトークンを検証します（署名の確認など）。 私のマイクロサービスはスコープとクレームを検証するためにトークンを必要としますが、このサービスがトークンを検証する必要もあるでしょうか？ 少しやりすぎのようですが、このシナリオについてオンラインでアドバイスを見つけることはできません。 APIゲートウェイでのトークンの検証は十分ですか？または、後でもう一度検証するのがベストプラクティスですか？
4
マイクロサービスアーキテクチャがマイクロサービスごとに個別のデータベースを必要とする場合、コストがかかりすぎて管理できません。なぜそれが必要なのですか？
私はマイクロサービスについて読みましたが、分離を実現するためだけにサービスごとに個別のDBを作成するのは私には非論理的です。Webサービスと単一のデータベースのみを使用して同じことを実現できます。なぜそれが必要なのですか？データベースを分離することは議論の余地があります。または私は明らかに間違っていますか？これについて教えてくれませんか？
4
適切な方法で条件付きを多態性に置き換えますか？
2つのクラスDogと、Cat両方がAnimalプロトコルに準拠している（Swiftプログラミング言語に関しては、Java / C＃のインターフェースになる）と考えてください。 犬と猫の混合リストを表示する画面があります。Interactor舞台裏のロジックを処理するクラスがあります。 ここで、ユーザーが猫を削除するときに確認アラートを表示します。ただし、犬はアラートなしですぐに削除する必要があります。条件付きのメソッドは次のようになります。 func tryToDeleteModel(model: Animal) { if let model = model as? Cat { tellSceneToShowConfirmationAlert() } else if let model = model as? Dog { deleteModel(model: model) } } このコードはどのようにリファクタリングできますか？それは明らかににおいがする
2
Forthの柔軟性が文法を不適切にするのはなぜですか？
私は最近、スタックベースのプログラミング言語を書く仕事を引き受けました。しかし、自分の言語の設計を始める前に、既存のスタックベースの言語を読んで実験するのは良い考えだと思いました。 これにより、この投稿のトピックに移動します。私は、Postfixスタイルの式を使用するスタックベースの言語であるForthに関するWikipediaの記事を読んでいました。記事では、私は次の声明を見ました： Forthの柔軟性により、静的なBNF文法が不適切になり、モノリシックコンパイラーがありません。コンパイラを拡張するには、文法を変更して基礎となる実装を変更するのではなく、新しい単語を書くだけで済みます。 私の理解では、フォースの専門用語では、「単語」という用語は基本的に「サブルーチン」と同義のようです。これを考えると、上記のステートメントは奇妙に思えます。Forthで新しい関数を作成する機能がForthの正式な文法を不適切にするのはなぜですか？定義する新しいサブルーチンごとに文法を書き直す必要があるのはなぜですか？環境で新しい単語を書くことは、コンパイラの拡張をどのように構成しますか？上記のステートメントは、新しい関数を定義できるため、正式な文法はPythonには不適切であると言っているように見えます。 実際、私は以下のForthの単純なサブセットに対してBNFスタイルの文法を書くことを試みることにしました。 program ::= stmt+ stmt ::= func | expr func ::= ':' expr+ ';' expr ::= INTEGER | word word ::= ('+' | '-' | '*' | '/' ) 上記の文法は、Forthステートメントの有効なサブセットをカバーしているように思われ、Forth言語のすべての有効なステートメントをカバーするように拡張することはそれほど難しくないと思われます。さらに、コンパイラーのパーサーが上記の文法を実装している場合、コンパイラーがどのように拡張されるかはわかりません。コンパイラは、環境に新しい単語を追加するだけです。環境のみが変更されます。まるで、上記のWikipediaからの抜粋は、コンパイラー（変更されない）を構成する下線コードとコンパイラーの環境（変更される）を融合しているようです。 要約すると、なぜ新しい単語（サブルーチン）を定義するForthの能力が、書かれた文法には不適切なのでしょうか。
2
警告システムのアーキテクチャ
さまざまなプログラムからのアラートメッセージを処理し、それらのアラートを処理して電子メールを介してダウンコンシューマーに送信できるシステムを作成したいと考えています。これはすべて1つの内部ネットワークに含まれます。 基本的なアーキテクチャを次のようにしたいと思います。 私の現在の主な関心事は「メッセージハンドラー」ビットです。これが私の「ソートAPI」になります。このシステムのすべてのコンポーネントが、データベースへのすべての書き込みを処理するAPIにデータを送信するようにします。このアプローチは、セキュリティを簡素化し、より複雑なDBクエリの多くを1つのプログラムに含めることができるため、より簡単だと思います。 懸念事項は、これを言語にとらわれないようにしたいことです。つまり、どのコードでもメッセージをハンドラに送信して、メッセージを解釈できるようにする必要があります。これは、JSONフラットファイルを介して、またはプログラムへのREST呼び出しを介して（下流のアプリケーションに柔軟性を与える）希望します。 私の質問は メッセージハンドラーを気にする必要がありますか？それとも、下流のアプリケーションと他の2つのコンポーネント（管理コンソールとアラートマネージャー）への直接データベースアクセスを許可するだけで簡単になりますか？ このようにして、DBテーブルへのINSERTが有効である限り、任意のアラートを挿入できます。 私は貿易でソフトウェアデザイナーではないので、失礼します。ただ、自由な時間にプロジェクトをやってもらいたいのです。
6
ほとんどのクラスをデータフィールドのみのクラスとメソッドのみのクラス（可能な場合）に分離することは、良いパターンですか、それともアンチパターンですか？
たとえば、クラスには通常、クラスのメンバーとメソッドがあります。例： public class Cat{ private String name; private int weight; private Image image; public void printInfo(){ System.out.println("Name:"+this.name+",weight:"+this.weight); } public void draw(){ //some draw code which uses this.image } } しかし、単一責任の原則とオープンクローズの原則について読んだ後、クラスをDTOと静的メソッドのみのヘルパークラスに分離することを好みます。例： public class CatData{ public String name; public int weight; public Image image; } public class CatMethods{ public static void printInfo(Cat …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.