ソフトウェア工学

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

4
エラーメッセージに関連ドキュメントへのリンクを含めますか?
外部の開発者が使用している商用ライブラリとコード例を作成します。ライブラリの使用方法を広範囲に説明する(登録済みユーザーは利用できますが、閉鎖された)ドキュメントがあります。 開発者の多くは初めてのユーザーなので、多くの初歩的なエラーが発生します。 エラーログにドキュメントへのリンクを含めることは適切ですか?考えられる欠点は何ですか?いくつかは予想できますが、以下を克服することは可能と思われます ドキュメントのURLが古い 最新のドキュメントに反映されていないバージョン固有のエラー 他に何か問題があり、無関係なドキュメントに送信することで開発者の時間を無駄にしています 意味の例の下に、太字のテキストを追加するのは良い考えですか? [エラー]プロジェクトstandalone-pomで目標org.apache.maven.plugins:maven-archetype-plugin:1.2.3:generate(default-cli)を実行できませんでした:目的のアーキタイプが存在しません(com.example.library。 archetypes:library-archetype-blank:1.2.3.0)->詳細および考えられるトラブルシューティングについては、http://example.com/docs/setting-up-an-archetypeを参照してください

4
多くの異なるステータスを表す整数コードを返す関数を作り直す
私は、以下の短いサンプルを含めたいくつかのひどいコードを継承しました。 この特定のアンチパターンに名前はありますか? これをリファクタリングするための推奨事項は何ですか? // 0=Need to log in / present username and password // 2=Already logged in // 3=Inactive User found // 4=Valid User found-establish their session // 5=Valid User found with password change needed-establish their session // 6=Invalid User based on app login // 7=Invalid User based on network …

3
その会社のために特別に設計された学習プログラミング言語[終了]
休業。この質問には詳細または明確さが必要です。現在、回答を受け付けていません。 この質問を改善してみませんか?詳細を追加し、この投稿を編集して問題を明確にしてください。 2年前休業。 ライブラリ、ロジックなどで役立つ他のXY言語がある場合、なぜ誰かが自社内でのみ使用する独自の言語を開発するのでしょうか。自分の言語を開発するよりも、他のものを使ってフローを進める方がずっと簡単ではないでしょうか?

4
プログラムの高レベルのアーキテクチャを文書化するための標準はありますか?
私はアマチュア開発者であり、これまでのすべてのプログラムは、コード内に文書化できるほど単純でした。コードを読んでいる間、私が何をしているのか、そのようなアクションは明らかでした(私の標準的なテストは、6か月後にコードを見て、最初に読んだときにすべてを理解することでした-私は短いメモリスパンを持っています)。 私は今、プログラム間のさまざまな相互作用を覚える能力を超えてプログラムに直面しています。 コード自体 データベース内のインデックス さまざまなモジュール間の相互作用(「ワーカー」コアコードと「ライブラリ」モジュール) 私の現在のドキュメントはホワイトボードで、コード、データベースインデックス、実行中のアクション、状態変化などを指すあらゆる種類のボックスと矢印があります。参考までに、混乱の断片: 私の質問は、より複雑な製品のドキュメント化のための標準または名前付きのベストプラクティスのセット(これは特定の名前でグループ化された一連のプラクティスであるという意味で名前が付けられている)があるかどうかです。 私が探す必要があるキーワードは何ですか(「ドキュメントソフトウェアアーキテクチャ標準」での一般的な試みと同様のバリエーションは、通常、ワークフローまたはビルディングアーキテクチャCADシステム用のソフトウェアにつながりました)。 また、高レベルの説明には一般的なベストプラクティスがなく、誰もが独自の哲学を構築することも期待しています。

6
飢えている開発チームで何をすべきか?[閉まっている]
休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか?この投稿を編集して、事実と引用で回答できるように質問を更新してください。 3年前休業。 それは、特にあなたが遅れている場合、通常の開発者としてのクリティカルパスにいるのはうんざりです。あなたが上級開発者であるとき、チームがリーダーシップを求めているとき、それはさらに悪いことです。 ほとんどのチームの仕事が重要な部分を待って停止している場合、チームの他のメンバーは何をすべきですか?私たちは重要な部分へのアクセスを制限しているので、他の人は私たちが何をしても関係なく待つだけです。他の人が何をすべきかについてのアドバイスを探しているとき、良い答えは何ですか?

1
単純な構成の代わりに弱参照を使用した方がよい状況はありますか?
が、Javaのドキュメントを指定し、その弱参照は、主にマッピングをcanonicalizingために、あなたが見つけるされている多くの、多くの、多くのWeakHashMapは、その存続期間中にオブジェクト・メタデータを格納するための完璧であることを、述べてインターネット上の人々を。ただし、誰もがわかりやすく適切な例を作成することに煩わされることはありません。 WeakHashMapを使用してオブジェクトにいくつかのプロパティを追加するか、メタデータサウンドを格納します。言い換えれば、悪いデザインです。継承が利用できない場合があることを理解しています(最終的なクラス、インターフェース)が、構成についてはどうですか?合成が選択肢にならない一例は考えられません。「言語の癖」ではなく、確立された原則に依存しているので、確かにより良いものです。 それでは、単純な構成の代わりに弱参照を使用した方がよい状況はありますか?そうでない場合、なぜインターネット上の誰もがそれを誤解しているように見えるのですか?


2
スタックの制限
最近、OSが異なる3つのデバイスでスタックの制限をテストしました(制限とは、スタックが持つことができるレベルの最大数を意味します)。2^ 16レベルに達するたびに、オーバーフローエラー、および2 ^ 16-1を配置すると、正しく動作します。 だから私の質問は-それは本当ですか?スタックには、定義により最大値2 ^ 16-1がありますか、それともOSに依存しますか?
10 stack 

2
非同期プロセスにスタック構造が使用されていますか?
この質問には、スタックの使用目的を説明するEric Lippertによる優れた回答があります。何年もの間、一般的に言えば、スタックとは何か、どのように使用されるかを知っていましたが、彼の回答の一部は、非同期プログラミングが標準となっている今日、このスタック構造があまり使用されていないのか疑問に思います。 彼の答えから: スタックは、コルーチンのない言語での継続の具体化の一部です。 具体的には、これのコルーチンなし部分は私に不思議に思っています。 彼はここでもう少し説明します: コルーチンは、それらがどこにあったかを記憶し、しばらくの間別のコルーチンに制御を委譲し、後で中断したところから再開することができますが、必ずしも呼び出されたコルーチンの直後ではありません。C#での "yield return"または "await"を考えてください。C#では、次のアイテムが要求されたとき、または非同期操作が完了したときの場所を覚えておく必要があります。コルーチンまたは同様の言語機能を持つ言語では、継続を実装するために、スタックよりも高度なデータ構造が必要です。 これはスタックに関しては優れていますが、スタックが単純すぎてより高度なデータ構造を必要とするこれらの言語機能を処理できない場合、どの構造を使用するかについて未回答の質問が残りますか? 技術が進歩するにつれてスタックはなくなりますか?それを置き換えるものは何ですか?ハイブリッドタイプのものですか?(たとえば、私の.NETプログラムは、非同期呼び出しにヒットするまでスタックを使用し、完了するまで他の構造に切り替えます。その時点で、スタックは、次の項目を確認できる状態に戻されますか? ) これらのシナリオはスタックに対して高度すぎると言うことは完全に理にかなっていますが、スタックを置き換えるものは何ですか?私がこの数年前に知ったとき、スタックは非常に高速で軽量であり、アプリケーションからヒープから離れて割り当てられたメモリの一部であり、手元のタスクの効率的な管理をサポートしていたので(スタックは意図されていましたか?)。何が変わったの?
10 stack 

7
マイクロサービスアーキテクチャでは、サービスは互いに直接対話する必要がありますか?
Webアプリケーションを形成するWebサービスがいくつかあります。クライアントはREST API呼び出しを通じてこれらのサービスにアクセスできます。 これらのサービスは互いに直接通信できる必要がありますか?もしそうなら、それらはマイクロサービスの概念に反するカップルになるでしょうか? クライアントは、クライアントにWebページをロードするために必要なデータを取得するために、次々にそれらを直接呼び出す必要がありますか? または、クライアントからの要求を処理し、その要求のデータをフェッチしてからクライアントに送り返す、サービスの上に別のレイヤーを配置する必要がありますか?

3
ストレステストの合否基準がないのは妥当ですか
わかりやすくするために、私が作成したストレステストは、システムが限界点に達するまで、システムの負荷を徐々に増やしていきます。理論的には無期限に実行されますが、システムリソースは有限であるため、しばらくすると障害が発生することが予想されます。システムに予想される負荷がありますが、これは負荷テストで個別にテストされます。このストレステストの目的は、スケーリングを実装する必要がある前に、システムにどれだけの負荷をかけることができるかを調べることです。 私はシステムのストレステストを作成している最中です。合格/不合格の基準があるのが理にかなっているのではないかと思っています。テストの性質上、負荷は、ブレークポイントに到達する(つまり、失敗する)まで着実に増加します。私は明らかに、この限界点が事前に何であるかを知らないので、システムが処理できる負荷は(とにかく)期待できません。 現在、予想される負荷などでシステムをテストする他のパフォーマンステストがあります。これは、合格/不合格の基準を簡単に設定でき、これらの基準をストレステストの基礎として使用できます。言い換えれば、ストレステストに到達するための最小ベースラインを設定することはできますが、これが正しいことかどうかはわかりません(これが他のテストを「複製」していますか?)。 パフォーマンステストの経験が豊富な方に協力していただければ幸いです。ストレステスト(ある場合)の際に、他のどの合格/不合格基準を使用しましたか?

3
別の品質保証(QA)の完全に重複したシステムを作成することは悪い習慣ですか?
職場では、かなり複雑なシステムがあります。このシステムをSystem_Aと呼びます。QAチームは別のシステムを作成しました。このシステムをSystem_Bと呼び、System_Aをテストします。 System_Bの使用方法は次のとおりです。入力(System_B自体を使用)INを生成し、そのような入力をSystem_Bを介して処理し、出力O_Bを生成します。したがって、プロセスは次のとおりです。 System_B(IN) -> O_B。 次に、System_Aにも同じことを行い、独自の出力O_Aを生成します。 System_A(IN) -> O_A。 いつでも、O_Bは期待される出力であり、O_Aは観測された/実際の出力であると想定されます。暗黙のうちに、O_Bは「ゴールド」ソース(真実)です。しかし、問題の組み合わせに遭遇しました。 O_Aは間違っている、O_Bは正しい O_Aは正しい、O_Bは正しい O_Aが間違っている、O_Bが間違っている O_Aは正しい、O_Bは間違っている O_Bが常に正しいと想定されている場合(または何が期待されている場合)、何が正しいかをだれが決定しますか まあ、それはO_Bが人間の検査と分析で時々(またはしばしば)間違っていることがわかりました。物事はこのプロセスを使用してQAに合格し、実際のユーザーは不満を抱きます。結局、O_Bが間違っていたことが判明するまで戻ります。 問題はこれです。実際のシステムをテストするための「テストシステム」を作成することは悪い習慣ですか? 滑りやすい斜面はどうですか?それでは、「テストシステム」をテストするためにさらに別のシステムが必要だと主張できないでしょうか。 開発者は少なくとも2つのコードベースを学習する必要があり、おそらくSystem_BはSystem_Aよりも複雑であるため、コストは明らかに法外です。System_Bが組織にとってどれほど良いか悪いかをどのように定量化しますか? System_Bを作成する本来の「説得力のある」理由の1つは、テストを「自動化」することでした。現在、完全に自動化されていることを非常に誇りに思っています(System_Bが入力を生成して、それ自体を使用して出力も生成するプロセスをブートストラップするため)。しかし、定量化できない方法で、より多くの危害を加え、より複雑さを導入したと思います。QAの仕事は完全に自動化されていますか?その理由は、並列システムを作成することを正当化するのに十分ですか? 私の本当の懸念はこれです。System_Bが間違っていることは誰もが知っています(かなり頻繁に)。System_Bが入力の処理に非常に優れていて、その出力がゴールドソースである場合は、System_AをSystem_Bに置き換えてみませんか?それに対して、職場の誰も満足のいく対応をすることができません。 この問題に関するガイダンスは大歓迎です。

2
スクラムスタンドアップでは、昨日行われたことの議論は、ボード上のタスクまたは実行されたすべての作業に限定されるべきですか?
私は、毎日のスタンドアップでのスクラムルールは、チームは昨日何をしたか、今日何をしているか、そしてそれらを妨げるものについてのみ話すべきだと言っていることを知っています。他には何もありません。しかし問題は、開発者が1日を自分のタスクに関係のない作業に費やし、それについてスタンドアップで話し合うことです。彼らが昨日やったことです! 私の経験では、ボード上のタスクについて話し、スタンドアップに焦点を合わせ、全員のタスクに焦点を合わせ続け、見積もりを確認してレコードを毎日追跡する方がより効果的であることがわかりました。 ディスカッションをボード上のタスクに限定することは有効ですか?
10 agile  scrum  meetings 


2
縮小したCSSをGitに保存する必要がありますか?
私はGulpを使用して、取り組んでいるプロジェクトのSASSコードから縮小されたCSSを生成します。 Gitからライブ配信するときに、この縮小されたCSSを再生成するのがベストプラクティスと考えられるかどうか疑問に思いました... または 縮小されたCSSファイルをGitに保存して、サーバー側で追加の作業をせずに、自動的に本番環境にプッシュする方法は? これについての人々の考えに感謝します。ありがとう!

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