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

プロジェクトを構築する必要が生じたときはいつでも、事前に計画や設計を考案するのではなく、いつでもそれを構築することができましたが、最初に必要なクラスを書いた後、プロジェクト全体を具体化し、ボトムアップで構築しました。これはソフトウェアを作成する適切な方法ではないことはわかっていますが、オブジェクト指向分析とデザインと呼ばれるものに頭を悩ますことは簡単ではありません。トップダウンの手順設計をより簡単に理解できます。それは、タスクをサブタスクに分解することで構成されているためです。しかし、オブジェクト指向の分析と設計は簡単に理解できません。どのようにコード化するかを知らない限り、必要なクラスとそれらがどのように相互作用するかを知る方法がわかりません。 クラスとオブジェクトの概念を設計プロセスに導入すると、問題をプロシージャとして実装できるものに分解することがなくなるため、トップダウンで設計することができなくなります。代わりに、私が主題について読んだ内容に従って、必要なクラスを決定し、ソフトウェアを実装するときに使用できる統一モデリング言語でさまざまなアーティファクトを作成する必要があります。しかし、私はこの種の設計プロセスを理解していません。すでにシステム全体を考えていなければ、どのクラスが必要になるのか、そしてどのように相互作用するのかをどうやって知るのですか？ これが私の問題です。私はオブジェクト指向プログラミングの概念を理解していますが、オブジェクト指向システムの設計方法を理解していません。それらの概念は、私が知っている任意のオブジェクト指向プログラミング言語で使用できます。したがって、私には、私にとって意味のある方法でオブジェクト指向システムを設計するために使用できる単純なプロセスを説明してくれる人が必要です。

10 design  object-oriented 

最近気付いたのは、次のタイプのプロジェクトを実行しているときです。 プロジェクトを始めるとき MVP /プロトタイプの作業 完全に定義されていない機能を追加する 小規模プロジェクトでの作業 参考までに、私は現在、いくつかのコメントとすべての空白を含む、現在〜1k行のコードがあるPythonプロジェクトに取り組んでいます。 私は、コードの最初の書き込みの統合テスト、仕事にそれが非常に簡単に見つけて、その後、それ一度APIは、多少のユニットテストを追加することで、実際に作業を硬化させます。私のmain関数で実行できるテストの種類、いわば、何よりも「エンドツーエンド」です。 これは、APIがかなり急速に変化しているときにユニットテストが本当に煩わしいためです。これは、上記の条件のいずれかまたはほとんどに一致するプロジェクトで作業している場合によくあります。 このアプローチは良いアプローチですか？これらのタイプのプロジェクトの最初に単体テストと統合テストのどちらを開始するかを決定するとき、どの基準を考慮する必要がありますか？APIがより強固になる前に、この種のプロジェクトを単体テストすることの価値を見逃していますか？

10 design  unit-testing  integration-tests 

前書き メインラインのベクターグラフィックスレンダリングエンジンの多くには、アルゴリズム上の欠陥があります。これらは、各シェイプを個別にレンダリングし、ピクセルカバレッジを計算してアンチエイリアスを作成してから、それらを重ね合わせます。はい、それは簡単ですが、正しい解決策はさらに簡単です。 これは、透明度によってカバレッジを膨らませるので、融合の問題につながります。アルファブレンディングは、状況を正確に表さないルールに従います。たとえば、50％カバーされているピクセルが、50％補完カバーされているピクセルに隣接している場合、100％のカバレッジではなく、75％のカバレッジになります。 。これがどのように見えるかは、アルゴリズムの調整方法やその他の詳細によって異なりますが、本質的にはこれは既知のエラーです。誰かが、さまざまなエンジンエラーを文書化し、それをどのように改善できるかを示す論文を書くという困難を乗り越えました。 画像1：完全に代表的ではないサンプル。上の行に拡大されたエラーを示す三角形でできた形状をレンダリングしたサンプル。SVGソース この問題には、単純な単純な解*があり、カバレッジ計算を行わずにスーパーサンプルを使用して、画像をフィルターで絞り込みます。おまけとして、ボックスフィルタリングよりも優れた画像再構成アルゴリズムを使用できます（「ピクセルは正方形ではありません3」を参照）。現在のソリューションと同等の速度を持つソリューションもあり、これらのソリューションはハードウェアラスタライゼーションパイプラインで実行する方がはるかに簡単です（この問題を回避するために構築されているため、GPUでこのエラーが表示されることはほとんどありません）。 これもコストがかからない問題ではありません。グラフィックデザインに携わっている多くの人が、この問題を手動で回避するために重要な時間を費やして、ここでオーバーラップがあり、オーバーラップがないことを確認して、コンピューターがそれらの問題を修正するようにします。そして多くの場合見事に失敗します。しかし、クライアントはなぜエラーがそこにあるのか気にせず、修正する必要があります。 質問 エラーはどのように伝播しますか？それらはすべて同じエラーを実行しているため、アルゴリズムに同じソースを使用していると結論付けることができます。デザイナーがこのアルゴリズムを選択した原因は何でしょうか？3Dプログラマーだけがこのエラーを認識し、2Dプログラマーが認識しなかったのに、APIと教育でその部分を成文化したのはなぜですか？ このエラーがそれ以上伝播しないようにする方法を教えてください。 補遺（これについては質問していません） *どうやら、スーパーサンプリングは問題なく機能するという私の主張は並外れており、並外れた証明が必要です。スーパーサンプリングが機能するための鍵は、スーパーサンプリングがカバレッジ処理を行わないことです。本質的に、スーパーサンプラーは各サンプルをポイントサンプルとして扱います。ポイントサンプルは、基になる領域を想定していないため、アルファ比較が発生しない場所では発生しません。 答えの1つで説明されているように、それが一貫して機能するために。一貫性を保つために、サンプルを整数サンプリングで処理する必要があります。これにより、一度スクリーンスペースに変換された各ポイントが、等しい座標に対してまったく同じソリューションを取得し、サンプルがピクセル境界によって2回シェーディングされないことが保証されます。これを行うには、サンプルが左下のサンプルである場合、サンプルがピクセルをトリガーしない可能性があります（したがって、正確なエッジは> vs <=で処理されるというルールを作成します）。1つを除くすべてのコンソールグラフィックカードは、このように機能します。これにより、余分なデータをキャッシュしたり、近くで追加のテストを行ったりする必要がなくなります。このソリューションは、カバレッジベースのソリューションよりも安定しており、より一般的で一貫しています。 アルゴリズムは元のコードとまったく同じで、コードが少し少なく、サンプルが少し多くなっています。したがって、カバレッジベースのアルゴリズムと同じかそれ以上ではありません。これは、グラフィックスカードだけでなく、他のほぼすべての信号処理分野で古くからこのような方法を使用してきたためです。 この方法には欠点がありますか？まあ、単純な仮定をすると、少し遅くなります。理論的には、カバレッジラスタライザよりも速い漸近的な振る舞いをします。レイトレーサーのように、典型的なシーンではまだ同等です。また、畳み込みベースのエフェクトの使用を実装するのがより困難になる可能性があります。

10 design  algorithms 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 3年前休業。 Web開発のコンテキストで、誰がデータベースを設計しますか？バックエンドのWeb開発者をサーバー側の処理、データモデリングなどに関連付ける情報のホスト全体にもかかわらず、方程式のデータベース設計の側面は神秘的に存在しないようです。 誰が物理データベースをセットアップするかについては言及していません。データベースの論理モデルを設計し、ユーザーストーリーのインタビューを実施して、必要なフィールド、フィールド仕様などについての情報を入手する人について言及しています。 。 データベースの（PROPER）設計は簡単な作業ではなく（私はこの 672ページャーを読んでいます）、簡単に職業全体になる可能性があることに気付きました。ただし、インターネットを上下に検索しても、Web開発のコンテキストで誰がこのタスクを処理することが予想されるかについては、驚くほど少ない結果しか得られていません。

10 design  web-development  database  database-design 

誰かが私に連絡して、依存性注入を概念的な方法で定義し、ソフトウェア設計でDIを使用することの実際の長所と短所を説明するように求められるたびに。DIの概念を説明するのが難しいと告白します。単一の責任の原則、継承に関する構成などに関する歴史を伝える必要があるたびに。 開発者のためにDIを説明する最良の方法を説明してくれる人はいますか？

10 design  design-patterns  software 

おそらく多くの人と同じように、設計の問題が頭痛の種になっていることがよくあります。たとえば、問題に直感的に適合し、望ましい利点があるデザインパターン/アプローチがあります。多くの場合、何らかの回避策がないとパターン/アプローチを実装するのが困難になる警告があり、パターン/アプローチの利点が無効になります。多くのパターン/アプローチを繰り返し処理してしまう可能性があります。実際には、簡単な解決策がない実際の状況では、ほぼすべてのパターンに非常に大きな注意事項があるためです。 例： 最近遭遇した実際のものに大まかに基づいた架空の例を紹介します。継承階層が過去のコードのスケーラビリティを妨げていたため、継承ではなくコンポジションを使用したいとしましょう。私はコードをリファクタリングするかもしれませんが、スーパークラス/ベースクラスがサブクラスの機能を単に呼び出す必要があるにもかかわらず、それを回避しようとするいくつかのコンテキストがあることがわかりました。 次善のアプローチは、半分のデリゲート/オブザーバーパターンと半分の構成パターンを実装して、スーパークラスが動作を委任できるようにするか、サブクラスがスーパークラスのイベントを監視できるようにすることです。その場合、クラスを拡張する方法が不明確であるため、クラスの拡張性と保守性が低下します。また、既存のリスナー/デリゲートを拡張するのも難しいです。また、スーパークラスを拡張する方法を確認するために実装を知る必要があるため、情報は十分に隠されていません（コメントを非常に広範囲に使用しない限り）。 したがって、この後は、オブザーバーまたはデリゲートを完全に使用して、アプローチを過度に混同することに伴う欠点を回避することを選択する場合があります。ただし、これには独自の問題があります。たとえば、事実上すべての行動にオブザーバー/デリゲートが必要になるまで、行動の量を増やすためにオブザーバーまたはデリゲートが必要になることに気づく場合があります。1つのオプションは、すべての動作に対して1つの大きなリスナー/デリゲートを持つことですが、実装するクラスは多くの空のメソッドなどで終了します。 それから私は別のアプローチを試すかもしれませんが、それと同じくらい多くの問題があります。それから次のもの、そして次のものなど。 この反復プロセスは、各アプローチが他のアプローチと同じくらい多くの問題を抱えているように見え、一種の設計決定麻痺につながる場合、非常に難しくなります。また、使用する設計パターンやアプローチに関係なく、コードが同じように問題を抱えてしまうことを受け入れるのも困難です。このような状況になった場合、問題自体を再検討する必要があるということですか。この状況に遭遇したとき、他の人は何をしますか？ 編集： 私が明確にしたい質問のいくつかの解釈があるようです： OOPは実際にはOOPに固有のものではないことが判明したため、OOPについて質問から完全に除外しました。さらに、OOPについて渡した私のコメントの一部を誤解するのは簡単です。 反復的なアプローチでさまざまなパターンを試す必要があると主張したり、パターンが機能しなくなった場合は破棄したりする必要があると主張する人もいます。これは私が最初に参照するつもりだったプロセスです。これは例からは明らかだと思いましたが、もっと明確にすることができたので、そのために質問を編集しました。

10 design  design-patterns  object-oriented  refactoring  clean-code 

私はいくつかの論文、記事、およびコンパイラー：原則、手法、およびツール（第2版）（別名「ドラゴン・ブック」）のセクション4.1.4、第4章を読み、すべて構文コンパイラーのエラー回復のトピックについて説明しています。ただし、いくつかの最新のコンパイラーで実験した後、構文エラーだけでなく、セマンティックエラーからも回復することがわかりました。 構文的に関連するエラーから回復するコンパイラーの背後にあるアルゴリズムと手法はかなりよく理解していますが、コンパイラーがセマンティックエラーから回復する方法を正確には理解していません。 現在、ビジターパターンのわずかなバリエーションを使用して、抽象構文ツリーからコードを生成しています。コンパイラが次の式をコンパイルすることを検討してください。 1 / (2 * (3 + "4")) コンパイラーは、次の抽象構文ツリーを生成します。 op(/) | ------- / \ int(1) op(*) | ------- / \ int(2) op(+) | ------- / \ int(3) str(4) コード生成フェーズでは、ビジターパターンを使用して、抽象構文ツリーを再帰的に走査し、型チェックを実行します。コンパイラが式の最も内側の部分に到達するまで、抽象構文ツリーをたどります。(3 + "4")。次に、コンパイラーは式の両側をチェックし、それらが意味的に同等ではないことを確認します。コンパイラは型エラーを発生させます。ここに問題があります。今コンパイラは何をすべきですか？ コンパイラは、このエラーから回復し、式の外側の部分を型チェックを継続するためには、返却しなければならないいくつかのタイプ（intまたはstrに、表現の最も内側の部分を評価するから）を、次式の最も内側の部分。ただし、単に返すタイプがありません。型エラーが発生したため、型は推定されませんでした。 私が仮定した1つの可能な解決策は、型エラーが発生した場合、エラーが発生し、型エラーが発生したことを示す特別な値が以前の抽象構文ツリートラバーサル呼び出しに返されることです。以前のトラバーサル呼び出しでこの値が検出された場合、抽象構文ツリーのより深いところで型エラーが発生したことがわかっているため、型を推測することは避けてください。この方法は機能するように見えますが、非常に非効率的です。式の最も内側の部分が抽象構文ツリーの奥にある場合、コンパイラーは多くの再帰呼び出しを行って、実際の作業が実行できないことを認識し、それぞれから単に戻る必要があります。 上記の方法を使用していますか（疑わしい）。もしそうなら、それは効率的ではありませんか？そうでない場合、コンパイラがセマンティックエラーから回復するときに使用される方法は正確には何ですか？

10 design  design-patterns  language-agnostic  type-systems 

バックグラウンド 私はいくつかのソーシャルネットワーキング機能を含むクライアント向けのアプリに取り組んでいます。私はもともとモバイルフロントエンドを開発していましたが、バックエンドの開発も担当する状況でした。 一般的な背景として、私たちのシステムでは、ソーシャルネットワークから期待されるように、ユーザーが他のユーザーをフォローし、フォローしているユーザーに関する通知を受け取ることができます。注意すべき点は、ほんの数サブセット（せいぜい数百人）のユーザーのみがフォローできることであり、ほとんどのユーザーベースはこれらの個人の少なくとも1人をフォローしていると予想されます。 UI側には、番号が付いた通知ボタンがあり、ボタンをクリックすると通知画面に移動します。 問題 私は、通知を実装するための戦略と、データベースに1つ以上の通知テーブルを作成するために見つけたほとんどのリソースを調査してきました。（私が好む例はここで受け入れられた答えです：https : //stackoverflow.com/questions/9735578/building-a-notification-system）。 私を後押ししているのは、通知に関するほとんどのデータベース駆動型の戦略では、各フォロワーの通知ごとに行を挿入する必要があるということです。したがって、1,000人がSallyをフォローしている場合、対応するテーブルに1,000行を挿入します。それはスケーラブルですか？数万人または数十万人のユーザーがサリーをフォローしていて、彼女が1日に数十の投稿を作成している場合はどうなりますか？ 私の元のアイデアはクエリですべてを処理することでした：通知ボタンの数は、最後に通知画面にアクセスしたときより最近投稿されたコンテンツの行数を要求することによって取得され、個々の通知はより詳細なクエリから生成されます通知画面にアクセスしたとき。このアプローチでは、書き込みや追加のストレージは必要ありませんが、柔軟性がなく、サーバーをかなり難しくします。 セットアップ （前の開発者によって確立された）バックエンドは、CodeIgniterとMySQLデータベースを使用します。現在、くだらないGoDaddy共有ホスティングアカウントで実行されていますが、本稼働に入る前にアップグレードされると思います（希望ですか？）。ホスティングパッケージは、ユーザーの増加に合わせてスケーリングされます。 現在、私たちのフロントエンドはモバイルアプリのみですが、後でウェブサイトも構築する予定です。現時点では、サーバーから通知に関するリアルタイムのプッシュ更新を取得することに関心はありません。 補遺 私はバックエンドに特化しておらず、私はその部門の頭の中にいます。クライアントはそれを知っており、私はこの種のプロジェクトの範囲を説明するために最善を尽くしましたが、現時点では他の誰もプロジェクトに取り組むことを信頼しないことを明確にしています。テスターの追加を開始する前に、あと1か月の作業が必要であり、あらゆる種類のパフォーマンスメトリックを取得できます。ユーザー数や今後5年間に使用するハードウェアを実際に見積もることはできませんが、クライアントは数十万人以上のユーザーを望んでいると思います。 これがここに投稿される問題の具体的な内容であることを願っています。必要に応じて調整できます。ご不明な点がある場合や、重要な詳細を省略している場合は、お問い合わせください。 tl; dr すべてのユーザーが同じ数百人の何人かしかフォローしていない場合、データベース主導の通知システムは長期的なスケーラビリティにマイナスの影響を及ぼしますか？ フォロワーごとに通知ごとに個別の通知行を必要とせずに、通知をデータベース主導にする方法はありますか？ 完全にクエリ駆動型の通知システムはスケーラブルですか、それともDBにデータを書き込まない以外に利点がありますか？ 私はこれを早すぎると思いすぎていますか？クライアントが限られた予算であり、最終製品が人気があるかどうかまだわからないので、今のところ機能するものを構築するだけで問題が発生した場合に最適化を検討できますか？

10 design  php  mysql  social-networks 

ほとんどのWebアプリケーションは要求/応答パラダイムに基づいていると言っても安全だと思います。PHPは、これらのオブジェクトを正式に抽象化したことがありません。1つのグループがこれを変更しようとしています：https : //github.com/php-fig/fig-standards/blob/master/proposed/http-message.md しかし、彼らは不変性の問題についてはある程度傍受された。一方では、要求/応答オブジェクトは通常、ライフサイクル中にほとんど変更を必要としません。一方、特に応答オブジェクトでは、多くの場合、HTTPヘッダーを追加する必要があります。 さらに、不変性がPHPの世界で実際に使用されたことはありません。 不変の要求/応答オブジェクトを使用すると、どのような利点がありますか jsonオブジェクトを返すとします。 $response = new JsonResponse($item); 素敵でシンプル。しかし、要求はクロスオリジンリソースシェアリング（CORS）要求であることがわかりました。応答を生成するコードは気にする必要はありませんが、下流のどこかに、必要なAccess-Controlヘッダーを追加するプロセスがあります。元の応答を維持し、追加のヘッダーを使用して新しい応答を作成する利点はありますか？それとも厳密にはプログラミングスタイルの問題です。 リクエストオブジェクトはもう少し興味深いです。同じように始まります： $request = new Request('incoming request information including uri and headers'); 初期情報を変更する必要はありません。ただし、リクエストが渡されると、処理情報を追加する必要が生じることがよくあります。たとえば、特定のリクエストに対して実行するアクションを決定するURLマッチャーがあるとします。 $request->setAttribute('action',function() {}); 実際にアクションを実行するのは、下流プロセスの責任です。不変の要求をラップする変更可能なRequestAttributesCollectionを使用することもできますが、実際には少し扱いに​​くい傾向があります。また、属性コレクションを除いて、不変のリクエストを持つこともできます。例外も扱いにくい傾向があります。この種の要件に対処した経験はありますか？

10 design  php  web-development  architecture 

以下を検討してください。 def some_function(): return 1 def some_generator(): yield 1 上記のコードでsome_functionは、は関数some_generatorですが、はジェネレーターです。それらは非常に似ています。 コードを読み取るときに発生する問題は、「関数」のすべての行をスキャンして、yield実際に関数なのかジェネレータなのかを判断する前に、キーワードを探す必要があることです。 ジェネレーターに別のキーワードを使用する方が理にかなっているように思えます、例えば： gen some_generator(): yield 1 defジェネレータと関数の両方にキーワードを使用するメリットは何ですか？関数とジェネレータを分離するために新しいキーワードが導入されていないのはなぜですか？

10 design  programming-languages  python 

背景： サーバーアプリケーションを設計し、さまざまなサブシステム用に個別のDLLを作成しています。話を簡単にするために、2つのサブシステムがあるとします。1）Users2）Projects ユーザーのパブリックインターフェイスには、次のようなメソッドがあります。 IEnumerable<User> GetUser(int id); また、Projectsの公開インターフェースには次のようなメソッドがあります。 IEnumerable<User> GetProjectUsers(int projectId); したがって、たとえば、特定のプロジェクトのユーザーを表示する必要がある場合は、呼び出すことができます。これによりGetProjectUsers、オブジェクトがデータグリッドなどに表示するのに十分な情報を返します。 問題： 理想的には、Projectsサブシステムはユーザー情報も保存せず、プロジェクトに参加しているユーザーのIDのみを保存する必要があります。提供するためにGetProjectUsers、それが呼び出す必要GetUserのUsers自身のデータベースに格納された各ユーザーIDのシステム。ただし、これには多数の個別のGetUser呼び出しが必要であり、Userサブシステム内に多数の個別のSQLクエリが発生します。私は実際にこれをテストしていませんが、このおしゃべりなデザインを使用するとシステムのスケーラビリティに影響します。 私はさておき、サブシステムの分離を置けば、私は可能性があり、両方のシステムにより、単一のスキーマアクセス可能で、すべての情報を保存し、Projects簡単に行うことができJOIN、単一のクエリですべてのプロジェクトのユーザーを取得します。クエリ結果からオブジェクトProjectsを生成Userする方法も知っている必要があります。しかし、これは多くの利点を持つ分​​離を壊します。 質問： 誰もがこれらの個別のGetUser呼び出しをすべて回避しながら、分離を維持する方法を提案できますGetProjectUsersか？ たとえば、私が考えていたのは、ユーザーが外部システムにラベルと値のペアでユーザーに「タグを付ける」機能を与え、特定の値を持つユーザーに要求することでした。たとえば、 void AddUserTag(int userId, string tag, string value); IEnumerable<User> GetUsersByTag(string tag, string value); 次に、プロジェクトシステムは、プロジェクトに追加された各ユーザーにタグを付けることができます。 AddUserTag(userId,"project id", myProjectId.ToString()); GetProjectUsersの実行中、1回の呼び出しですべてのプロジェクトユーザーをリクエストできます。 var projectUsers = usersService.GetUsersByTag("project id", myProjectId.ToString()); 私がこれについて確信が持てない部分は、はい、ユーザーはプロジェクトにとらわれませんが、実際にはプロジェクトメンバーシップに関する情報はプロジェクトではなくユーザーシステムに保存されます。私は自然に感じないので、ここで私が見逃している大きな欠点があるかどうかを判断しようとしています。

10 c#  design  scalability  server-side 

データベースでデータの変更（挿入、更新、削除）を実行するいくつかのメソッドがあります。ORMは、私は方法のこれらのタイプの戻り行の影響を受けたint型の値を使用しています。操作の成功/失敗の状態を示すために、「私のメソッド」に対して何を返す必要がありますか？ を返すコードを考えてみましょうint： A.1 public int myLowerLevelMethod(int id) { ... int affectedRows = myOrm.deleteById(id) ... return affectedRows; } 次に、使用法： A.2 public void myOtherMethod() { ... int affectedRows = myLowerLevelMethod(id) if(affectedRows > 0) { // Success } else { // Fail } } ブール値を使用する場合と比較してください。 B.1 public boolean myLowerLevelMethod(int id) { ... int …

10 design  error-handling  methods 

主な問題 最も近代的なプログラミングプラットフォームはパッケージ管理のために持っている良いサポートを見て（と思うgem、npm、pipなど、）、それが促進し、疎結合アーキテクチャを作成するように、内部で開発されたパッケージで構成されたアプリケーションやシステムを設計する意味がありませんか？ 例 この例としては、データベースアクセス用のパッケージの作成や、システムの認証やその他のコンポーネント用のパッケージの作成があります。もちろん、これらも外部パッケージを使用します。次に、システムはこれらのパッケージをインポートして使用します-独自のコードベースにコードを含める代わりに。 考慮事項 私には、これはコードのデカップリングを促進し、保守性を支援するように思われます。ほとんどWebベースのデスクトップアプリケーションのようなものです（更新はほとんど自動的に適用され、単一のコードベースは単一の機能などに適用されます）。 これは合理的で健全なデザインコンセプトのように見えますか？これは、今日のアプリケーションを構造化する標準的な方法として実際に使用されていますか？

10 design  design-patterns  architecture  packages  coupling 

よるとコマンドクエリ分離原則と同様に、データにおける思考とのClojureとDDD 1は、計算や意思決定から（世界の変更）の副作用を分ける必要があるプレゼンテーションので、両方の部分を理解し、テストするために容易になるという。 これは未回答の質問を残します。境界に対して相対的に、「世界に尋ねる」ことをどこに置くべきでしょうか？一方では、外部システム（データベース、エクステンションサービスのAPIなど）からのデータの要求は参照透過的ではないため、純粋な計算コードや意思決定コードと一緒に置かれるべきではありません。一方で、どのデータを要求する必要があるかが事前にわからない場合があるため、計算部分から切り離して引数として渡すことは問題があるか、おそらく不可能です。

10 functional-programming  domain-driven-design  clojure  design  side-effect 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 4年前休業。 私は過去2週間、小規模で営利目的のマルチプレイヤーアーケードゲームのために、いくつかの基本的な極端なプログラミングコンセプトを扱ってきました。1週間かけてユーザーストーリーを作成し、リリース計画を作成するための要件を決定しました。また、思いついた最初の反復計画のコーディングと適用に1週間費やしました。私は、1人の開発者にとって明らかに便利な概念のいくつかを特定しました。 継続的インテグレーション 早期に機能を追加しない テスト駆動開発 システムのメタファーを選択 単一の統合ポイントを使用する すべてのバグをテストする 常にリファクタリング 持続可能なペースを設定する シンプルさ 頻繁なリリース 特に、単一の開発者プロジェクトでの作業に適したものがないとしたら、私は興味がありますか？ また、シンプルさとテスト駆動開発の考えを踏まえると、この観点から、確立された機能豊富な既製のプラットフォームを使用する方が良いでしょうか？ それとも、可能であれば、絶えずリファクタリングし、機能を早期に追加しないなどのルールで提示される問題に遭遇しないように、ゼロから作業する必要がありますか？

10 design  project-management  extreme-programming  solo-development