タグ付けされた質問 「design」

非常に頻繁に、最良の設計決定を選択するときに立ち往生しています。関数定義、制御フロー、変数名などの小さな詳細であっても、選択の利点とトレードオフを熟考するのに異常に長い時間を費やします。 これらの重要でない詳細に時間を費やすことで、多くの効率を失っているように感じます。私の現在のデザインがうまくいかない場合、これらのことを変更できることを心の奥で知っていますが、1つの選択肢をしっかりと決定するのに苦労しています。 この問題に対処するにはどうすればよいですか？

61 design  productivity  systems-analysis 

私のプログラム設計では、オブジェクトインスタンスをいくつかのクラスに渡さなければならないことがよくあります。たとえば、オーディオファイルを読み込んでプレーヤーに渡すコントローラーがあり、プレーヤーがそれをplayerRunnableに渡し、playerRunnableが別の場所などに再び渡す場合、見た目は悪くなりますが、それを避ける方法を知ってください。それともこれをしても大丈夫ですか？ 編集：後でファイルを読み込むことができるため、プレーヤーの例が最適ではないかもしれませんが、それ以外の場合は動作しません。

60 class-design  design 

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

57 design  modeling  user-experience  front-end 

私は通常、ほとんどのコード分析の警告に同意し、それらを順守しようとします。しかし、私はこれで苦労しています： CA1031：一般的な例外タイプをキャッチしない このルールの根拠を理解しています。しかし、実際には、スローされた例外に関係なく同じアクションを実行したい場合、それぞれを具体的に処理するのはなぜですか？さらに、特定の例外を処理する場合、呼び出しているコードが変更されて将来新しい例外がスローされるとどうなりますか？次に、その新しい例外を処理するためにコードを変更する必要があります。一方、単にExceptionコードをキャッチしただけなら、変更する必要はありません。 たとえば、FooがBarを呼び出し、FooがBarによってスローされた例外のタイプに関係なく処理を停止する必要がある場合、キャッチしている例外のタイプを特定することに利点はありますか？ たぶんより良い例： public void Foo() { // Some logic here. LogUtility.Log("some message"); } public static void Log() { try { // Actual logging here. } catch (Exception ex) { // Eat it. Logging failures shouldn't stop us from processing. } } ここで一般的な例外をキャッチしない場合は、可能なあらゆる種類の例外をキャッチする必要があります。パトリックには、OutOfMemoryExceptionこの方法で対処すべきでない良い点があります。では、例外をすべて無視したい場合はどうしOutOfMemoryExceptionますか？

57 c#  design  exceptions 

私は最近仕事でいくつかのコードをリファクタリングしました、そして私は良い仕事をしたと思いました。980行のコードを450行に落とし、クラスの数を半分にしました。 これを同僚に見せたとき、これが改善であることに同意しなかった人もいました。 彼らは言った-「より少ないコード行が必ずしも良いとは限らない」 人々が本当に長い行を書いたり、いくつかの行を保存するためにすべてを単一のメソッドに入れたりする極端なケースがあるかもしれませんが、それは私がやったことではありません。私の意見では、コードは適切に構造化されており、サイズが半分であるため、理解/保守が簡単です。 仕事を遂行するために必要なコードを2倍にしたい人がいる理由を理解するのに苦労しています。 ？

55 design  coding-style  code-quality 

イベントループとは何かを理解しようとしています。多くの場合、イベントループでは、イベントが発生したことが通知されるまで何かをするという説明があります。その後、イベントを処理し、以前の操作を続行します。 上記の定義を例にマッピングします。イベントループで「リッスン」するサーバーがあり、ソケット接続が検出されると、そこからのデータが読み取られて表示され、その後サーバーは以前と同じようにリッスンを再開/開始します。 ただし、このイベントが発生し、「そのような」通知を受け取ることは、私にとって非常に重要です。あなたは言うことができる：「それはあなたがイベントリスナーを登録しなければならない「ちょうどそのような」ではない」しかし、イベントリスナーとは何か、何らかの理由で返されない関数です。イベントが発生したときに通知されるのを待っている独自のループですか？イベントリスナーもイベントリスナーを登録する必要がありますか？どこで終わりますか？ イベントは作業するのに最適な抽象概念ですが、単なる抽象概念です。結局、ポーリングは避けられないと思います。おそらく私たちはコードでそれをしていませんが、下位レベル（プログラミング言語の実装またはOS）が私たちのためにそれをしています。 基本的には、次の擬似コードになります。このコードは、十分に低い場所で実行されているため、ビジー待機を発生させません。 while(True): do stuff check if event has happened (poll) do other stuff これはアイデア全体に対する私の理解であり、これが正しいかどうか聞きたいと思います。私は全体の考えが根本的に間違っていることを受け入れることに心を開いています。その場合、正しい説明が欲しいです。

55 design  programming-languages  design-patterns  event-programming 

質問で使用されている例では、最小限のデータを関数に渡し、ユーザーが管理者であるかどうかを判断するための最良の方法に触れています。一般的な答えは次のとおりです。 user.isAdmin() これにより、コメントが何度か繰り返され、何度も投票されました。 ユーザーは、管理者であるかどうかを決定するべきではありません。特権またはセキュリティシステムが必要です。クラスに密接に結合されているからといって、それをそのクラスの一部にすることは良い考えではありません。 私は答えた、 ユーザーは何も決定していません。ユーザーオブジェクト/テーブルには、各ユーザーに関するデータが格納されます。実際のユーザーは、自分に関するすべてを変更することはできません。 しかし、これは生産的ではありませんでした。明らかに、遠近法には根本的な違いがあり、それがコミュニケーションを難しくしています。誰かがuser.isAdmin（）が悪い理由を説明し、それが「正しく」行われたように見えるものの簡単なスケッチを描くことができますか？ 本当に、私はそれが保護するシステムからセキュリティを分離することの利点を見ることはできません。セキュリティに関するテキストには、セキュリティを最初からシステムに組み込む必要があり、開発、展開、保守、さらには寿命のあらゆる段階で考慮する必要があると書かれています。側面にボルトで固定できるものではありません。しかし、このコメントに対するこれまでの17の賛成票は、私が重要な何かを見逃していると言っています。

55 design  object-oriented-design  separation-of-concerns  permissions 

私は最近大学を卒業し、プログラマーとして仕事を始めました。「技術的な」問題を解決したり、1つの解決策があると言うことでデバッグしたりすることはそれほど難しいとは思いません。 しかし、明らかな解決策が1つもない問題のクラスがあるようです-ソフトウェアアーキテクチャのようなもの。これらのことは私を混乱させ、大きな苦痛を引き起こします。 私は自分のプログラムとシステムをどのように「アーキテクト化」するかを決めるのに何時間も費やしています。たとえば、このロジックを1つまたは2つのクラスに分割したり、クラスにどのように名前を付けたり、プライベートまたはパブリックにしたりする必要があるかなどです。プログラムを作成したいだけです。 アーキテクチャフェーズをより迅速に達成し、楽しんでいるコーディングおよびデバッグフェーズに到達するにはどうすればよいですか？

53 design  architecture 

私の教育では、実際のプライマリキー（DBキーだけでなく、すべてのプライマリアクセサー）をユーザーに公開することは欠陥のあるアイデアであると言われました。 私はいつもそれをセキュリティの問題だと思っていました（攻撃者が自分のものではないものを読もうとする可能性があるため）。 ユーザーがとにかくアクセスを許可されているかどうかを確認する必要があるので、その背後に別の理由がありますか？ また、とにかくユーザーがデータにアクセスする必要があるため、その間のどこかに外部の公開キーが必要になります。公開キーには主キーと同じ問題がありますよね？ とにかくそれを行う理由についての例の要求があったので、ここに1つがあります。質問は、この例に当てはまる場合だけでなく、原則自体に関するものであることを忘れないでください。他の状況に対処する回答は明示的に歓迎されます。 アクティビティを処理し、複数のUIとシステム間通信用の少なくとも1つの自動APIを備えたアプリケーション（Web、モバイル）アプリケーションには複数の顧客がいるため、データの分離（論理的には、データは同じDBに格納されます）はシステムに必要です。各リクエストは、どのような場合でも有効性がチェックされます。 アクティビティは非常に細かいので、いくつかのコンテナオブジェクトにまとめられ、「タスク」と呼びます。 3つのユースケース： ユーザーAは、ユーザーBを何らかのタスクに送りたいので、ユーザーBにリンク（HTTP）を送信して、そこでアクティビティを実行させます。 ユーザーBは建物の外に出て、モバイルデバイスでタスクを開く必要があります。 アカウンティングは顧客にタスクの料金を請求したいが、REST-アプリケーションのAPIを参照するコードによってタスク/アクティビティを自動的にロードするサードパーティの会計システムを使用する 各ユースケースでは、エージェントがタスクとアクティビティのアドレス可能な識別子を持っていることが必要です（または、より簡単になります）。

53 design  security  theory 

アプリケーションをOutside Inで構築することとTDDを使用してInside Outで構築することの違いは何ですか？ これらはTDDとユニットテストについて読んだ本です： テスト駆動開発：例による テスト駆動開発：実用ガイド：実用ガイドMicrosoftでの 高品質PHPフレームワークとアプリケーションの開発のための実世界ソリューション NET xUnitテストパターン：テストコード のリファクタリングユニットテストの技術：.Net Growing Object-Oriented Softwareでの例、テストによるガイド ---> JAVAは私の主要言語ではないため、これを理解するのは非常に困難でした:) それらのほぼすべてがTDDの基本と単体テストを一般的に説明しましたが、アプリケーションを構築するさまざまな方法についてはほとんど言及しませんでした。 もう1つ気づいたのは、これらの書籍のほとんど（すべてではないにしても）が、アプリケーションの作成時に設計段階を無視していることです。彼らは、テストケースを迅速に記述し、設計を単独で出現させることに重点を置いています。 しかし、私は人々がTDDにアプローチする方法を議論したxUnitテストパターンのパラグラフに出会いました。Outside InとInside Outの 2つの学校があります。 悲しいことに、この本はこの点について詳しく説明していません。これら2つのケースの主な違いは何かを知りたいです。 それらのそれぞれをいつ使用する必要がありますか？ 握りやすいTDD初心者には？ 各方法の欠点は何ですか？ このトピックを具体的に説明している資料はありますか？

53 design  web-development  unit-testing  tdd 

私は昨年、1人のチームとしてリッチクライアントアプリケーション（35,000以上のLoC、価値あるもの）を開発しました。現在は安定しており、運用中です。しかし、プロジェクトの最初の段階では私のスキルが錆びていたことを知っているので、間違いなくコードに大きな問題があります。この時点で、ほとんどの問題はアーキテクチャ、構造、および相互作用にあります。簡単な問題は、アーキテクチャ/設計の問題でさえ、すでに取り除かれています。 残念ながら、私はこのプロジェクトに多くの時間を費やしているため、その外側を考えるのに苦労しています。新しい視点からアプローチして、設計に深く埋め込まれている、または固有の欠陥を確認します。 どうすれば頭の外やコードの外に出て、見た目を新しくしてより良くすることができますか？

53 design  architecture  code-quality  productivity 

プロジェクトがあります。このプロジェクトでは、機能を追加するためにリファクタリングしたいと考え、機能を追加するためにプロジェクトをリファクタリングしました。 問題は、作業を終えたときに、それに対応するためにインターフェイスを少し変更する必要があることが判明したことです。だから私は変更を加えました。そして、新しいクラスの観点から、現在のインターフェイスでは消費クラスを実装できないため、新しいインターフェイスも必要です。今では3か月後に、無数の事実上無関係な問題を修正する必要があり、1年前にロードマップされた問題、または問題がコンパイルされる前に修正できないと単純にリストされている問題の解決を検討しています再び。 この種のカスケードリファクタリングを今後回避するにはどうすればよいですか？これは、以前のクラスが互いに緊密に依存しすぎているという単なる症状ですか？ 簡単な編集：この場合、リファクタリングは機能でした。これは、リファクタリングにより特定のコードの拡張性が向上し、一部の結合が減少したためです。これは、外部の開発者がより多くのことができることを意味し、それが私が提供したかった機能でした。したがって、元のリファクタリング自体は機能的な変更ではないはずです。 5日前に約束したより大きな編集： このリファクタリングを開始する前に、インターフェイスのあるシステムがありましたが、実装では、dynamic_cast出荷したすべての可能な実装を単純に確認しました。これは明らかに、インターフェイスから継承することはできなかったことを意味し、第2に、このインターフェイスを実装するための実装アクセス権を持たない人は不可能であることを意味しました。だから私はこの問題を修正し、誰でもそれを実装できるようにインターフェースを公開し、誰でもそれを実装できるようにし、インターフェースの実装が必要な契約全体であると判断しました。 私がこれをしたすべての場所を見つけて火で殺そうとしていたとき、特定の問題であることが判明した場所を1つ見つけました。それは、さまざまな派生クラスのすべての実装の詳細と、すでに実装されているが他のどこかより優れた複製機能に依存していました。代わりにパブリックインターフェイスの観点から実装し、その機能の既存の実装を再利用することもできます。正しく機能するには特定のコンテキストが必要であることを発見しました。おおまかに言って、呼び出し元の以前の実装はちょっと似ていました for(auto&& a : as) { f(a); } ただし、このコンテキストを取得するには、次のようなものに変更する必要がありました std::vector<Context> contexts; for(auto&& a : as) contexts.push_back(g(a)); do_thing_now_we_have_contexts(); for(auto&& con : contexts) f(con); これは、以前はの一部であったすべての操作についてf、一部はgコンテキストなしで動作する新しい関数の一部にする必要があり、一部は現在の遅延の一部で行う必要があることを意味しますf。しかし、すべてのメソッドf呼び出しがこのコンテキストを必要とするわけでも、必要とするわけでもありません。一部のメソッドは、別個の手段で取得する別個のコンテキストを必要とします。そのため、最終的にf呼び出しを行うすべて（大まかに言えば、ほぼすべて）について、必要なコンテキスト（ある場合）、取得元、および古いものからf新しいものへの分割方法を決定する必要がfありましたg。 そして、それが私が今いるところに行き着いた方法です。とにかく他の理由でこのリファクタリングが必要だったからです。

52 design  programming-practices  refactoring  coupling 

ときどき空を見つめたり、アイデアをスケッチしたり、紙の上に擬似コードを書いたりします。それから私はそれをスクラッチしてやり直し、問題の正しい解決策があると思うとコードを書き始めます。 何日もコードを書かずに考えるのは普通ですか？これは、私が問題に近づいているという兆候ですか？IDEで具体的なコードを作成しないことに不安を感じます。

52 design 

私はc＃やrubyなどのオブジェクト指向プログラミング言語の経験があります。オブジェクト指向スタイルでプログラムを設計する方法、クラスとオブジェクトを作成する方法、およびそれらの間の関係を定義する方法を知っています。いくつかのデザインパターンも知っています。 人々はどのように機能的なプログラムを書くのですか？どうやって始めますか？関数型言語の設計パターンはありますか？極端なプログラミングやアジャイル開発などの方法論は関数型言語に適用できますか？

52 design  haskell  functional-programming 

外部APIから入力を受け取る関数をコーディングしているとしましょうMyAPI。 その外部APIにMyAPIは、a stringまたはa を返すことを示す契約がありnumberます。 それはのようなものから保護することをお勧めしますnull、undefined、booleanそれはのAPIの一部ではないにもかかわらずなど、MyAPI？特に、そのAPIを制御することはできないため、静的型分析などの方法で保証することはできません。 私はロバストネスの原則に関連して考えています。

51 design  api  api-design  web-services  functions