ソフトウェア工学

過去1年で、Dependency InjectionとIOCコンテナを使用して新しいシステムを作成しました。これは私にDIについて多くを教えてくれました！ ただし、概念と適切なパターンを学んだ後でも、コードを分離し、IOCコンテナーをレガシーアプリケーションに導入することは難しいと考えています。アプリケーションは、真の実装が圧倒されるほどの大きさです。値が理解され、時間が与えられたとしても。こんなことをする時間を与えられたのは誰ですか?? もちろん、単体テストをビジネスロジックに組み込むことが目標です！ テスト防止のデータベース呼び出しと絡み合っているビジネスロジック。 この記事を読みましたが、このLos Techiesの記事で説明されているように、Poor Man's Dependency Injectionの危険性を理解しています。私はそれが本当に何も切り離さないことを理解しています。 実装には新しい依存関係が必要になるため、システム全体で多くのリファクタリングが必要になることを理解しています。どんなサイズの新しいプロジェクトでも使用することは考えません。 質問： Poor ManのDIを使用して、レガシーアプリケーションにテスト容易性を導入し、ボールローリングを開始しても大丈夫ですか？ さらに、Poor ManのDIを真のDependency Injectionへの草の根アプローチとして使用することは、原則の必要性と利点を教育する価値のある方法ですか？ インターフェイスの背後でデータベース呼び出しの依存関係と抽象化を呼び出すメソッドをリファクタリングできますか？単純に抽象化することで、そのメソッドをテスト可能にします。これは、コンストラクターのオーバーロードを介してモック実装を渡すことができるためです。 今後、支援が得られると、プロジェクトを更新してIOCコンテナを実装し、抽象化を取り入れるコンストラクタを公開することができます。

14 architecture  dependency-injection  legacy  inversion-of-control 

私はC＃で作業しており、作成中の2つのアプリ間で通信を行っています。Web APIとJSONが好きになりました。現在、2つのサーバー間でテキストデータとファイルを含むレコードを送信するルーチンを作成しています。 インターネットによると、ここに示すようにmultipart / form-dataリクエストを使用することになっています。 SO質問「C＃クライアントからのマルチパートフォーム」 基本的に、次のような形式に従ってリクエストを手動で記述します。 Content-type: multipart/form-data, boundary=AaB03x --AaB03x content-disposition: form-data; name="field1" Joe Blow --AaB03x content-disposition: form-data; name="pics"; filename="file1.txt" Content-Type: text/plain ... contents of file1.txt ... --AaB03x-- RFC 1867-HTMLでのフォームベースのファイルアップロードからコピー この形式は、優れたJSONデータに慣れている人にとって非常に苦痛です。したがって、明らかに解決策は、JSONリクエストを作成し、Base64でファイルをエンコードして、次のようなリクエストで終わることです。 { "field1":"Joe Blow", "fileImage":"JVBERi0xLjUKJe..." } そして、好きな場所でJSONのシリアル化と逆シリアル化を利用できます。さらに、このデータを送信するコードは非常に簡単です。JSONシリアル化用のクラスを作成し、プロパティを設定するだけです。ファイル文字列プロパティは、いくつかの簡単な行で設定されます。 using (FileStream fs = File.Open(file_path, FileMode.Open, FileAccess.Read, FileShare.Read)) { byte[] file_bytes = …

14 c#  asp.net  json  file-handling  webforms 

Robert C. Martin's Clean Code：A Handbook of Agile Software Craftsmanshipの45ページで、Martinは出力引数を避けるべきであると書いています。「出力引数」の意味と、それらを避けるべき理由を理解するのに苦労しています。 出力引数のMartinの例appendFooter(s);は、関数を呼び出しますpublic void appendFooter(StringBuffer report)。彼のコードの改善はreport.appendFooter(); コードコンテキストが不足していることが原因の可能性がありますが、出力引数の使用がコーディングの悪さと見なされる方法はわかりません。誰かが概念を説明したり、これを理解するためのコードの追加例を与えることができますか？ 上記の原則により、次の関数も汚れたコードの例と見なされますか？ int[] numberArray = {3, 5, 7, 1}; sortArray(numberArray); 上記が出力引数を使用しないというマーティンの原則に違反する場合、フィールドとして配列を持つオブジェクトと、配列をソートするために呼び出すことができる関数を持つ方が良いでしょうか？ ObjectWithArrayField numberArray = new ObjectWithArrayField(3, 5, 7, 1); numberArray.sort();

14 java  clean-code 

「Webコンポーネント」と「カスタム要素」はしばしば混同され、この質問のタイトルのWeb検索では、まだあまり明確になりません。それを修正しましょう。

14 javascript  web-development  dom  component 

異なるバージョンのソフトウェア間でファイルタイプの後方互換性を許可するための優れた設計とは何ですか？ たとえば、Microsoftはどのようにして2007、2010、2013などの単語をすべての開いているdocxファイルに取得しますが、異なるエディションではより多くの/少ないデータを保存し、わずかに異なる方法でデータをすべて同じファイルタイプに保存できますあるバージョンで保存されたファイルは別のバージョンで開くことができますが、ファイルの特定の要素は古いバージョンでは使用できない可能性がありますか？ つまり、それを行うための本当に明白な方法は、 private string openfile(string filename) { File.Open(filename) ... some logic that gets a header from the file that will never change switch (fileversion) case 2007: ..... case 2010 ..... case 2013 ..... } しかし、それは信じられないほどモノリシックで、あまり拡張性がなく、多くのコピー/貼り付けコードにつながる可能性があります。 だから私は、ファイルに存在する必要があるヘッダーなどの不変の構造、およびシリアル化/逆シリアル化に必要なメソッドを定義するすべてのバージョンのベースインターフェイスを使用することを考えていましたインターフェースを実装する新しいバージョンのクラスは古いバージョンを継承し、ファイルがほとんど同じであるため、変更されたもののみをオーバーライドします。 ファイルの構造についてはあまり気にしません。XMLを使用することは既に決まっているので、最初のスキーマは概して決定済みです。ただし、将来的には間違いなく変更されることになるので、これらの変更に容易に対応できるようにコードを設計できるようにしたいだけです。

14 design  file-handling  backward-compatibility 

これは主にFPに関する理論的な質問ですが、私のポイントを説明するためにテキストアドベンチャー（古い学校のZorkなど）を取り上げます。FPを使用してステートフルシミュレーションをどのようにモデル化するかについて、ご意見をお聞かせください。 テキストアドベンチャーには、本当にOOPが必要です。たとえば、すべての「部屋」はRoomクラスのインスタンスであり、基本的なItemクラスとItem<Pickable>持ち運びできるものなどのインターフェイスを持つことができます。 FPでのワールドモデリングの動作は異なります。特に、ゲームの進行（オブジェクトの移動、敵の敗北、スコアリングの増加、プレイヤーの位置の変更）に応じて変化する必要があるワールドに不変性を適用する場合。私Worldはそれをすべて備えた単一の大きなオブジェクトを想像します。探索できる部屋は何か、それらはどのようにリンクされているか、プレイヤーは何を運んでいるか、どのレバーがトリガーされたか。 純粋なアプローチは、基本的にこの大きなオブジェクトを任意の関数に渡し、それらによって返される（おそらく変更される）ことだと思います。例えば、私は新しい部屋に変更されてそれをmoveToRoom取得Worldして返す関数を持っています。World.player.locationWorld.rooms[new_room].visited = True これがより「正しい」方法であっても、そのために純粋さを強制しているようです。プログラミング言語によっては、この潜在的に非常に大きなWorldオブジェクトをやり取りするのに費用がかかる場合があります。また、すべての関数がWorldオブジェクトにアクセスする必要がある場合があります。たとえば、部屋は浸水する可能性があるため、他の部屋でトリガーされたレバーに応じてアクセス可能またはそうでない場合がありますが、プレイヤーがライフジャケットを持っていれば、とにかく入ることができます。モンスターはプレイヤーが別の部屋でいとこを殺害したかどうかによって攻撃的であるかもしれません。この手段roomCanBeEnteredの機能は、アクセスする必要があるWorld.player.invetoryとWorld.rooms、describeMonsterアクセスする必要があるWorld.monstersので、（基本的に、あなたがしなければなりません負荷全体を渡します）。これは、特にFPのプログラミングスタイルが優れている場合でも、グローバル変数を呼び出すように思えます。 この問題をどのように解決しますか？

14 functional-programming 

私が理解しているように、暗黙的な変換はエラーを引き起こす可能性があります。 しかし、それは理にかなっていない-通常の変換もエラーを引き起こすべきではありませんか？ なぜ持っていない len(100) 次のように解釈する（またはコンパイルする）言語で動作する len(str(100)) 特に、それが機能する唯一の方法（知っている）だからです。言語はエラーが何であるかを知っています、なぜそれを修正しませんか？ この例ではPythonを使用しましたが、これほど小さいものは基本的に普遍的だと感じています。

14 programming-languages  type-conversion 

私の現在のプロジェクトでは、同じ名前で汎用パラメーターの数が異なる汎用クラスを作成するという要件に直面しています。例えば： MyClass<T1> MyClass<T1, T2> MyClass<T1, T2, T3> これらすべてを同じ名前空間に入れたいので、クラスとファイルの構造と名前の付け方について混乱していますか？ クラスをファイルごとに1つに制限し、ファイルが名前空間階層を表すフォルダー構造にあり、ファイルの名前がクラスの名前と一致する必要があるという考えに従う場合、この状況にどのように対処しますか？ 私は本当にここに求めています、私は名前を付けるべきであるファイルが含まれMyClass<T1>、そしてどのような私は名前を付ける必要があるファイルが含まれMyClass<T1, T2>？型パラメータの名前はどうあるべきかを尋ねているのではありません。

14 c#  .net 

サーバーコンポーネント、Webアプリコンポーネント、iOSコンポーネント、Androidコンポーネントなど、複数のコンポーネントを持つプロジェクトがあるとします。これらのコンポーネントはすべて個別のコードベースですが、疎結合（たとえば、サーバーの変更）コードでは、他のすべてのコンポーネントの変更も必要になる場合があります） Gitでこのプロジェクトを整理する最も効率的な方法は何ですか？すべてを1つのリポジトリに配置すると、常に最新バージョンを使用できますが、1つのコンポーネントを変更し、他のコンポーネントを変更し始めると事態は非常に面倒になります。 一方、各コンポーネントを個別のリポジトリとして作成する場合、これらのリポジトリを「リンク」して、アプリのバージョン2.0にサーバーコンポーネントのバージョン1.5などが必要であることを知るにはどうすればよいでしょうか？ 複数の関連するレポをより効果的に管理するために、最新のreadme（または表示されないより良いソリューション）を維持する以外に、gitに機能はありますか？

14 git 

前の質問への回答では、特定の構成体の正しい用語について小さな議論が始まりました。私は（以外の質問見つからなかったので、このまたはその明確にこの問題に対処するため、非常に正しいことではない、）、私はこの新しいものを作っています。 疑わしい用語とその関係は、type、type constructor、type parameter、kinds or sorts、およびvaluesです。 また、ウィキペディアで型理論を確認しましたが、それでもそれほど明確にはなりませんでした。 したがって、適切な参照回答を得るために、自分の理解を確認するために： これらのことはどのように適切に定義されていますか？ これらのそれぞれの違いは何ですか？ それらは互いにどのように関連していますか？

14 type-systems  data-types  type-theory 

処理できる例外のみをキャッチする必要があることを読みました。これにより、ベース例外クラス（この場合はC＃）をキャッチするのは悪い考えです（他の理由に加えて）。現在、私はプロジェクトの一部であり、これまでのところ、キャッチされている基本例外以外は何も見ていません。そうするのは悪い習慣と見なされると述べましたが、応答は「このサービスは24時間365日実行する必要があるため、そうです」でした。 24時間年中無休で実行する必要のあるプログラムで例外を適切に処理する方法についての良い応答がなかったため、ここにいます。24時間実行する必要のある「重要な」プログラム/サービスの例外処理に対処する方法に関する情報/提案を見つけることができませんでした（この場合、サービスが1分間停止しても大丈夫かもしれません）または2つなので、重要ではありません）。私はそれがプログラムの正確な性質に依存することを理解しています。命にかかわる問題を引き起こす可能性のあるプログラムの要件は、オンラインゲームのログスキャナーとはまったく異なります。 2つの例： 1：イギリス鉄道の顧客向けの先行入力サービス。鉄道駅をオンラインで検索するときに使用されます。 2：線路、列車などのさまざまなセンサーから提供されるリアルタイム情報に基づいて、上記の鉄道の鉄道スイッチを自動的に制御するプログラム。 最初のプログラムが1、2分間停止しても、おそらく大きな問題は発生しませんが、後者は人的被害を引き起こす可能性があります。それぞれに対処する方法の提案？この問題に関する詳細情報と考えを見つけることができる場所へのポインター？

14 exception-handling 

私は最近、会社に入社して、Webアプリを構築するアジャイル開発プロジェクトのスクラムマスターとして働いています。 このチームは、アジャイルチームの最大規模になりそうです（来週は9を予定）。チームを2つのチームに分割する可能性について話しましたが、スタンドアップを短くすること（現時点では過度ではありません）ではなく、スプリントプランニングセッションで人々が完全に退屈しないようにすること（これもあまり長くありません）。 このプロジェクトには、高度に技術的なバックエンド開発者（非常に複雑なものなど）とUIの設計/構築/統合という2つの非常に明確な層があります。バックエンドの人たちが技術的なことを話しているとき、UIの人たちはゾーンアウトしているようです。時間を効率化するためだけにチームを分割する論理的な方法のように思えますが、コラボレーションと知識の共有を減らすことしかできないという点で、私は1つの大きな予約を持っています。2つのチームは、チームの他のメンバーが何を構築しているのかについて本当に良い考えを持っていません。 誰かがこのようなものに対処した経験がありますか？

14 web-development  project-management  agile  web-applications  user-experience 

C、C ++、C＃、Java、および他の多くで使用されている「短絡」という用語を聞いたことがあります。これは何を意味し、どのシナリオで使用されますか？

14 concepts  conditions  if-statement 

私は自分の心に疑問を抱いていました。次のサブルーチン（リスト内の要素を検索するなど）の最後にはreturnステートメントがあります。 list *search_list(list *l, item_type x) { if (l == NULL) return(NULL); if (l->item == x) return(l); else return( search_list(l->next, x) ); } 最後にreturnステートメントの意味がわかりません（つまり、research search_list（l-> next、x））。誰もがスタックモデルを使用してこの概念を説明できれば、本当に役立ちます。

14 functions  recursion 

ボブおじさんのきれいなコードを読んでいます。私は英語を母国語としないため、次の声明を理解できませんでした。 クラスとオブジェクトのような名詞や名詞句の名前を持つ必要があり Customer、WikiPage、Account、とAddressParser。避け言葉が好き Manager、Processor、Data、またはInfoクラスの名前インチ クラス名は動詞であってはなりません。 私が知っているように、のいずれもManager、Processor、Data、およびInfo動詞である、そうではありませんか？彼が強調したい実際のポイントは何ですか？

14 coding-style  terminology  code-quality  naming