ソフトウェア工学

私は.NET開発者で、今週末にRuby on Railsで遊ぶ機会がありました。 .NETでは、個別のクラスライブラリプロジェクトを作成することにより、アプリケーションのレイヤーを分離します。設計パターンの観点から、Railsでもそれを行う必要がありますか、それともすべてが含まれる1つのプロジェクトだけですか？

11 design-patterns  .net  ruby-on-rails 

C＃、JavaScript、および（できれば）Java 8などの現代言語で一般的に見られるような反復メソッドは、コードの理解可能性およびサポート可能性に対する循環的複雑さの影響を軽減しますか？ たとえば、C＃では次のコードを使用できます。 List<String> filteredList = new List<String>(); foreach (String s in originalList){ if (matches(s)){ filteredList.add(s); } } これには、単純な循環的複雑度2があります。 これを次のように簡単に書き換えることができます。 List<String> filteredList = originalList.where(s => matches(s)); 単純な循環的複雑度は0です。 これにより、実際にサポート可能なコードが増えますか？このトピックに関する実際の研究はありますか？

11 cyclomatic-complexity 

コマンドパターンのこの古い実装があります。これは、すべてのDIOperation実装を通じてContextを渡すようなものですが、後で学習と学習のプロセス（決して停止しない）で最適ではないことに気付きました。また、ここでの「訪問」は実際には合わず、混乱するだけだと思います。 また、コマンドは他のことについて何も知らず、現時点ではすべてが同じキーと値のペアを共有するため、コードのリファクタリングを考えています。どのクラスがどのKey-Valueを所有しているかを維持するのは非常に難しく、変数の重複につながる場合があります。 ユースケースの例：CommandBがCommandAによって設定されるUserNameを必要とするとしましょう。CommandAはキーUserNameForCommandB = Johnを設定する必要がありますか？または、共通のUserName = John Key-Value を共有する必要がありますか？UserNameが3番目のコマンドで使用されるとどうなりますか？ この設計を改善するにはどうすればよいですか？ありがとう！ class DIParameters { public: /** * Parameter setter. */ virtual void setParameter(std::string key, std::string value) = 0; /** * Parameter getter. */ virtual std::string getParameter(std::string key) const = 0; virtual ~DIParameters() = 0; }; class DIOperation { public: /** * …

11 c++  design-patterns  design 

基本クラスが純粋なインターフェイスクラスであることが望ましくないと仮定し、以下の2つの例を使用すると、抽象メソッドまたは仮想メソッドクラス定義を使用する方が適切なアプローチですか？ 「抽象」バージョンの利点は、見た目がきれいで、派生クラスに意味のある実装を強制的に提供させることです。 「仮想」バージョンの利点は、他のモジュールによって簡単に引き込められ、抽象バージョンが必要とするような基本的なフレームワークを追加することなくテストに使用できることです。 要約版： public abstract class AbstractVersion { public abstract ReturnType Method1(); public abstract ReturnType Method2(); . . public abstract ReturnType MethodN(); ////////////////////////////////////////////// // Other class implementation stuff is here ////////////////////////////////////////////// } 仮想バージョン： public class VirtualVersion { public virtual ReturnType Method1() { return ReturnType.NotImplemented; } public virtual ReturnType Method2() …

11 c#  design 

任意のタイプのファイルの解析を担当するモジュールを検討してください。ここですでに説明したように、この問題に取り組むために戦略パターンを使用することを考えています。この質問に進む前に、リンクされた投稿を参照してください。 product.xmlファイルのコンテンツを必要とするクラスBを検討してください。このクラスは、XMLファイルを解析するために、Parserインターフェースの適切な具象実装者をインスタンス化する必要があります。適切な具象実装者のインスタンス化をファクトリに委任して、クラスBが「has-a」ファクトリになるようにすることができます。ただし、クラスBは、具体的な実装者をインスタンス化するためにファクトリに「依存」します。これは、クラスBのコンストラクターまたはセッターメソッドをFactoryに渡す必要があることを意味します。 したがって、ファイルを解析する必要があるファクトリとクラスBは、互いに密接に結合されます。私はこれまで説明してきたことについて完全に間違っている可能性があることを理解しています。私は、注入される依存関係がファクトリであるシナリオで依存関係の注入を使用できるかどうか、そしてこれを実装する正しい方法は何であるかを知りたいので、ユニットテストでファクトリをモックするなどの領域を活用できます。

11 java  design-patterns  dependency-injection 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 6年前に閉鎖されました。 私はソースコードにコメントし、ソフトウェア製品を文書化することを提唱しています。私の個人的な経験と観察から、厳密にコメントされているソースコードに取り組んでいると、ソフトウェアの成長や保守が必要になったときにさまざまな方法で役立ったことがわかります。 しかし、コメントすることは最終的に価値がない、またはその価値には疑問があると言う別のキャンプがあります。コメントなしのコーディングの支持者は次のように主張しています。 コードの一部が適切に記述されている場合、それは自明であり、したがってコメントする必要はありません コードが自明でない場合は、コメントを必要としないように、リファクタリングして自明にする テストスイートはライブドキュメントです 時間が経つにつれて、コードとコメントが同期しなくなり、別の頭痛の種になります アジャイルは、ドキュメントの山よりも作業コードの方が重要だと言っているので、コメントを書くことは安全に無視できます。 私にとってこれは単なる教義です。繰り返しになりますが、私の個人的な観察では、賢明で経験豊富な開発者のチームによって作成されたソフトウェアは、最終的に自明ではないかなりの量のコードになります。 繰り返しますが、Java API、Cocoa API、Android APIなどは、高品質のドキュメントを作成して維持したい場合にそれが可能であることを示しています。 これらすべてを言ったが、個人的な信念に基づいたドキュメントの長所と短所およびソースコードへのコメントについての会話は、通常うまく終了せず、満足のいく結論につながらない。 そのため、ソフトウェアドキュメントの影響、特にソースコードのコメント、品質と保守性、およびチームの生産性への影響に関する学術論文と実証研究を探しています。 そのような記事につまずいたことがありますか、もしあればその結果はどうでしたか？

11 productivity  documentation  code-quality  maintainability  engineering 

ScalaのO'Reillyの本で、コードのコピーアンドペーストが作成することを読みました。 ...コードの肥大化、保守性、スキューの問題が発生し、 文脈の中で歪曲という言葉の明確な定義を見ることができません。コピーペーストの問題は認識していますが、「スキュー」という言葉に当てはめることはできません。これはO'Reillyの本で使用されているため、実際のプログラミング用語が流通していると推測しています。 ポインタはありますか？

11 terminology  code-reuse 

私が読んだ画像認識用のニューラルネットワークの例はすべて、単純な「はい」または「いいえ」の答えを生成します。1つの出口ノードは「はい、これは人間の顔です」に対応し、もう1つの出口ノードは「いいえ、これは人間の顔ではありません」に対応します。 これは説明を簡単にするための可能性が高いことを理解していますが、より具体的な出力を提供するために、このようなニューラルネットワークをどのようにプログラムできるか疑問に思っています。たとえば、動物を分類していたとしましょう。「動物」または「動物ではない」と言う代わりに、「犬」、「魚」、「鳥」、「蛇」などの応答が必要です。これを認識しないでください」。 これは可能であるに違いないと思いますが、その方法を理解するのに苦労しています。エラーの逆伝播のトレーニングアルゴリズムが原因であるように思われます。1つの出口ノード（つまり、「これは犬です」）をトレーニングし、ニューロンの重みが変更されると、以前に別の出口ノードの理想的な状態訓練された（つまり、「これは鳥です」）が逸脱し始め、逆もまた同様です。したがって、あるカテゴリを認識するようにネットワークをトレーニングすると、別のカテゴリに対して行われたトレーニングが妨害され、単純な「はい」または「いいえ」の設計に制限されます。 これにより、そのようなレコグナイザーは不可能になりますか？または、アルゴリズムを誤解していますか？私が考えることができるのは、次の2つだけです。 分類したいものごとに1つのニューラルネットワークをトレーニングし、それらを使用して、より大きなスーパーネットワーク（たとえば、「犬」のネットワーク、「鳥」のネットワークなど）を構築します。 「動物」のスーパーネットワークを作成するために一緒に追加）。または、 信じられないほど高度な数学を必要とし、すべての可能な出力（つまりinsert math magic here）に対して理想的なニューロン重量状態を何らかの形で生成する、ある種の途方もなく複雑なトレーニング方法論を作成します。 （サイドノート1：多層パーセプトロンを一種のニューラルネットワークとして具体的に見ています。） （サイドノート2：最初の箇条書きの「可能性のある解決策」では、特定の各ニューラルネットワークを持ち、「はい」の応答を受け取るまでそれらを繰り返し処理するだけでは十分ではありません。機械学習ではなくプログラミング。情報を供給して適切な応答を受け取るために1つのニューラルネットワークを使用できるかどうかを知りたい）。

11 machine-learning  artificial-intelligence 

データベース接続が共通メソッドを使用して一度取得され、使用される関連クラス全体に渡されるシステムがあります。データベース接続をパラメーターとして別のクラスに渡すと問題が発生するのではないかという疑念があるので、ここで実際に実行可能かどうかを確認していますが、それを行うためのより良いパターンはありますか？ 永続化を行うためのORMツールがいくつかあることは知っていますが、それについてはまだ説明できません。 フィードバックを歓迎します、ありがとう。

11 java  database  patterns-and-practices 

ほとんどのクラスが1つのパッケージに配置されている大規模なコードベースをリファクタリングしています。モジュール性を高めるために、各機能のサブパッケージを作成しています。 パッケージ依存関係グラフにはループがあってはならないことをどこかで覚えていましたが、次の問題を解決する方法がわかりません：FigureパッケージfigureにLayoutあり、パッケージlayoutにLayoutあり、レイアウトを実行するために図が必要なので、パッケージlayoutはパッケージに依存しますfigure。しかし、一方で、a FigureはFigure、その中に他のを含むことができ、独自のを持ちLayout、packageをpackageにfigure依存させますlayout。 実装するContainerインターフェイスを作成FigureしてLayoutパッケージに入れるなど、いくつかのソリューションがあります。これは良い解決策ですか？他の可能性はありますか？ ありがとう

11 java  architecture  packages 

私は最近、一握りのプログラマーと一緒に新しい会社で働き始めました。約70人の従業員を抱える中規模の会社ですが、IT部門の従業員数は9〜10人で、私の横には3人の「プログラマー」がいます。しかし、これらの人たちの経験は非常に限られており、非常に多くのことをやっています。たとえば、プロジェクトの1つはPHP Webサイトです。コードの大部分は20,000行のPHPコントローラーに保存され、PHPには〜6000行のJavaScriptが埋め込まれています。 私はあちこちで小さな提案をし続けていますが、誰も聞いていません。みんなが忙しすぎて私の提案を実行できないと言っています。事は、彼らはそんなに忙しくてはいけないし、物事が正しく行われていなければいけません。彼らはほとんどの時間を、壊れ続けるものの修理に費やしています。各プロジェクトが正しくビルドされていれば、自分ですべてを行うことができました。 これらの人やマネージャーに、物事を変える必要があること、そして物事を変えることで時間を節約できることを納得させるには、どのようなアプローチを取るべきでしょうか？同僚が説得しようとするのをスキップして、会社が正しいことを始めた場合に会社がたくさんのお金を節約する方法についてのビジネス上の提案で、マネージャーに直行しますか？

11 programming-practices  maintenance 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 4年前に閉鎖されました。 ロックされています。この質問とその回答はロックされています。なぜなら、質問はトピックから外れていますが、歴史的に重要だからです。現在、新しい回答やインタラクションを受け入れていません。 ビジネスインテリジェンス開発者の役割は、従来のWeb開発者の役割よりもどのような特性/スキルを期待していますか？

11 terminology 

私は、QA組織としてのテスト効率の測定に関する経営陣との議論に参加しようとしています。この背後にある主な理由は、私たちのチームの半分が外注されており、私たちのビジネスは私たちがどれほど効果的/効率的であるかのいくつかのメトリックを提供したいので、私たちは請負業者のサービス契約と契約パラメータを交渉するための基礎データを持っている。 このテーマについて私が見つけた意見のほとんどは、開発者の効率性に関するものです。コードの行、配信されたストーリーポイント、導入された欠陥などです。 しかし、テスターはどうですか？テストは主に要件ベースで、手動、半自動、自動のテストが混在しています（すべてを自動化していないためではなく、テストシステムで自動化できないものがあるためです）。

11 testing  efficiency  qa  metrics 

UpperCaseは長い複雑な名前の最初の文字の単語の区切りで実際に読みやすいことがわかったので、UpperCaseでLinuxファイル名の一部を指定する傾向があります。ほとんどが実行可能ファイル、いくつかのディレクトリも。 しかし、Linux distribのすべてのファイル名の大部分は小文字であることに気付きました。 だから私は少し前にグーグルを作りました、そして私はこの記事を見つけました：Linux File Names、Unixの世界では常に小文字を使うべきだと述べています、 ... 大文字または大/小文字混合を使用する正当な理由が考えられない限り、Linuxでは常に小文字を使用するのが最善です。ほとんどのUnixの人々はほとんど排他的に小文字を使用しますが、この「文化的な」点は別として、小文字を使用するもう1つの正当な理由があります。LinuxでDOSファイルシステムを共有またはアクセスしている場合、DOSは大文字または大文字と小文字が混在したファイル名のファイルを表示できません... それは本当ですか？

11 linux  unix  file-systems 

私は電気のエンジニアであり、デジタルの世界に突入し、私が学んでいる間に学びました。次の図に示すように、PID（比例-積分-微分）ループを実行するTIプロセッサをプログラミングしています。 それについても説明します。 非反転端子が接地された負帰還オペアンプ。マイナス端子から入力します。フィードバックループは、抵抗器と並列のRE直列回路と、コンデンサと並列のRE直列回路です。 この回路をCコードに変換する方法はありますか？私はこれに関する私の要素から少し外れているので、ヘルプを使用できます。

11 c