ソフトウェア工学

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






7
C#またはJavaのような言語で代数データ型をどのようにエンコードしますか?
代数データ型で簡単に解決できる問題がいくつかあります。たとえば、リスト型は次のように簡潔に表現できます。 data ConsList a = Empty | ConsCell a (ConsList a) consmap f Empty = Empty consmap f (ConsCell a b) = ConsCell (f a) (consmap f b) l = ConsCell 1 (ConsCell 2 (ConsCell 3 Empty)) consmap (+1) l この特定の例はHaskellにありますが、代数データ型をネイティブにサポートする他の言語でも同様です。 OOスタイルのサブタイプへの明らかなマッピングがあることがわかります。データ型は抽象基本クラスになり、すべてのデータコンストラクターは具体的なサブクラスになります。Scalaの例を次に示します。 sealed abstract class ConsList[+T] { def map[U](f: T …

3
DRY、KISS、SOLIDなどは何に分類されますか?
DRYのようなものは、デザインパターン、方法論、またはそれらの間にあるものですか?それらには、必要に応じて実証できる特定の実装はありません(KISSのようなものを使用しないケースを簡単に実証できる場合でも... 多数の例については、The Daily WTFを参照してください)。一般的には。これらのタイプの「経験則」はどこにあるのでしょうか?

3
「ストリング」の語源
したがって、一連のことは一連のことであり、文字/バイトなどの連続であることは明らかです。文字列と呼ばれることもあります。しかし、誰が最初に文字列と呼んだのでしょうか?そしていつ?そして、どのような文脈でそれが立ち往生しましたか?私はいつもこれについて疑問に思っていました。

4
重複コードを受け入れることができる例外的なケースはありますか?
私は、3つのAPIを構築する必要があるソフトウェアプロジェクトに取り組んでいます。1つはホームバンキングチャネル用、もう1つは代理店チャネル用、3つ目はモバイルチャネル用です。 エージェンシーAPIは、すべての機能を備えているため、最も完成度の高いAPIです。 ここでのアーキテクトは、共通層(すべてのAPIで共有されるクロスチャネルEJBサービス)を作成しました。ただし、APIは異なります。 現在のところ、API間に大きな違いはありません。大きなチームはエージェンシーチャンネルから始まり、現在はホームチャンネルに適応しています。私たちは、単にホームアプリ専用のオブジェクトを強化しています。それ以外の場合、コードはAPI間で95%類似しています。APIはSpring MVCの上に構築されており、(コントローラー、モデル、およびいくつかのユーティリティ)があります。 基本的に、コントローラーはBOをChannelObject(これを行うのに適切な場所ではないようです)、およびいくつかの追加のユーティリティとシリアライザーへのマッピングBOを実行しています。今のところすべてが重複しています。重複の理由は、APIを独立させたいからだと言っています。「明日、私たちが代理店や携帯電話とは異なる行動を家庭で望むなら、私たちは苦労しません!」 重複コードを受け入れる必要がある場合はありますか?
57 java  api  spring 


8
プロジェクトにデザイナーがいない場合、開発者はUIモックアップを行う必要がありますか?
私はプロプライエタリなWebアプリケーションを作成する小さなチームと協力しており、UXは私たち自身が操作するので優先順位は高くありませんが、仕事を楽にするよう努めています。 開発者として、新しい画面の作成を開始する前にUIモックアップを作成する必要がありますか?派手なことは何もありません。ほとんどの場合、同僚と話し合って参照モデルを作成するための一般的なレイアウトです。盲目的にコードを記述する前に、いくつかのUMLダイアグラムの作成と比較していました。 私の同僚の一人は、これは馬鹿げていると言い、それをするのは私の仕事ではありません。

9
可読性と保守性、ネストされた関数呼び出しを記述する特別な場合
ネストされた関数呼び出しのコーディングスタイルは次のとおりです。 var result_h1 = H1(b1); var result_h2 = H2(b2); var result_g1 = G1(result_h1, result_h2); var result_g2 = G2(c1); var a = F(result_g1, result_g2); 私は最近、次のコーディングスタイルが非常に使用されている部門に変更しました。 var a = F(G1(H1(b1), H2(b2)), G2(c1)); コーディングの私の方法の結果、クラッシュする機能の場合、Visual Studioは対応するダンプを開き、問題が発生した行を示すことができます(特にアクセス違反が心配です)。 最初の方法でプログラムされた同じ問題によるクラッシュの場合、どの関数がクラッシュを引き起こしたかを知ることができないのではないかと心配しています。 一方、1行に追加する処理が多いほど、1ページに表示されるロジックが多くなり、読みやすくなります。 私の恐怖は正しいのですか、それとも一般的には商業環境で好まれる何かが欠けていますか?可読性または保守性? 関連するかどうかはわかりませんが、C ++(STL)/ C#で作業しています。

4
なぜ最近のプログラミング言語で変数名の後に型が続くのですか?
ほぼすべての最新のプログラミング言語(Go、Rust、Kotlin、Swift、Scala、Nim、Pythonの最終バージョンでも)で、型が常に変数宣言の変数名の後に来るのはなぜですか? なぜx: int = 42ありませんかint x = 42? 後者は前者よりも読みにくいですか? それは単なるトレンドですか、このソリューションの背後には本当に意味のある理由がありますか?

16
「不明」と「欠損」の違いを保持したまま、変数に「不明」と「欠損」の値を保存する方法を教えてください。
これを「アカデミック」な質問と考えてください。私は時々NULLを避けることについて疑問に思っていましたが、これは満足のいく解決策を思い付かない例です。 測定が不可能(または欠落)であることがわかっている場合に測定値を保存するとします。NULLを避けながら、変数にその「空の」値を格納したいと思います。また、値が不明な場合もあります。そのため、特定の時間枠の測定値がある場合、その期間内の測定値に関するクエリは3種類の応答を返す可能性があります。 その時点での実際の測定値(たとえば、を含む数値0) 「欠落」/「空」の値(つまり、測定が行われ、その時点で値が空であることがわかっている)。 不明な値(つまり、その時点で測定は行われていません。空になることもありますが、他の値になることもあります)。 重要な説明: get_measurement()「空」、「不明」、および「整数」型の値のいずれかを返す関数があると仮定します。数値があるということは、戻り値(乗算、除算など)で特定の操作を実行できることを意味しますが、そのような操作をNULLで使用すると、キャッチされないとアプリケーションがクラッシュします。 NULLチェックを回避して、コードを記述できるようにしたいと思います。たとえば(擬似コード): >>> value = get_measurement() # returns `2` >>> print(value * 2) 4 >>> value = get_measurement() # returns `Empty()` >>> print(value * 2) Empty() >>> value = get_measurement() # returns `Unknown()` >>> print(value * 2) Unknown() printNULLが使用されていないため、どのステートメントも例外を引き起こしていません。したがって、空の値と不明な値は必要に応じて伝播し、値が実際に「不明」または「空」であるかどうかのチェックは、本当に必要になるまで遅らせることができます(値の保存/シリアル化など)。 サイドノート:NULLを避けたい理由は、主に頭の体操です。何かをやりたい場合、NULLを使用することに反対しませんが、それらを回避することでコードがより堅牢になる場合があることがわかりました。

8
コンパイラ、アセンブラ、マシン命令などのようなコンピュータプログラミングの下位コンポーネントに問題がないことをどのように確認できますか?
私たちは日々の生活の非常に重要なタスクを含め、コンピューティングにますます頼るようになっているので、私はそれらの重要なコンポーネントがどのようにテストされるのかと思っていました。 より技術的には、コンパイラとアセンブラはどのようにテストされますか?(これは停止の問題に関連すると思います!!)

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