ソフトウェア工学

アプリケーションのバックアップ状況を改善しようとしています。DjangoアプリケーションとMySQLデータベースがあります。Gitでデータベースをバックアップすることを提案する記事を読みました。 一方で、データとコードのコピーを同期させておくので気に入っています。 しかし、Gitはデータ用ではなくコード用に設計されています。そのため、コミットごとにMySQLダンプを比較する多くの余分な作業を行うことになります。保存する前にファイルを圧縮しても、gitはファイルを差分しますか？ （現在、ダンプファイルは100MB非圧縮、bzip圧縮時は5.7MBです。） 編集：コードとデータベーススキーマの定義は既にGitにあります。これは実際にバックアップすることを心配しているデータです。

57 database  git  mysql  django 

私は通常、ほとんどのコード分析の警告に同意し、それらを順守しようとします。しかし、私はこれで苦労しています： 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 

私は、チームリーダーがSOLID開発原則の熱心な支持者であるチームに取り組んでいます。しかし、彼は複雑なソフトウェアをドアから取り出すのに多くの経験を欠いています。 すでに非常に複雑なコードベースであったものにSRPを適用した状況があり、現在では非常に断片化されており、理解とデバッグが困難になっています。 現在、コードの断片化だけでなく、プライベートまたは保護されている可能性のあるクラス内のメソッドが「変更の理由」を表すと判断され、パブリックまたは内部クラスおよびインターフェースに抽出されているため、カプセル化にも問題がありますアプリケーションのカプセル化の目標に沿っていない。 20を超えるインターフェイスパラメーターを受け取るクラスコンストラクターがいくつかあるため、IoCの登録と解決はそれ自体が怪物になりつつあります。 これらの問題のいくつかを修正するために使用できる「SRPからのリファクタリング」アプローチがあるかどうかを知りたいです。私は、いくつかの密接に関連するクラスを「ラップ」してそれらの機能の合計への単一のアクセスポイントを提供する多数の空の粗いクラスを作成する場合、SOLIDに違反しないことを読んだ過度にSRPされたクラスの実装）。 それとは別に、誰もが幸せなまま、開発努力を実践的に続けることを可能にする解決策は考えられません。 助言がありますか ？

57 c#  wpf  inversion-of-control  single-responsibility 

辞書は、成果物を次のように定義します。 アーティファクト、アーティファクト[ˈɑːtɪˌfækt] n 道具や芸術作品など、人が作った、または形を与えたもの、特に考古学的に興味のある物体 疑似実験結果などの人工物 （ライフサイエンスおよび関連アプリケーション/生物学）細胞学死、固定、染色などの後に組織に見られる構造で、通常は生体組織には存在しません この言葉artifactは、ソフトウェア開発、ソフトウェア開発サイクル、労力見積もりなどによく登場します。しかし、上記の定義はその文脈では意味がありません。 誰かがソフトウェア業界からいくつかの具体的な例を挙げてこの言葉を説明してもらえますか？

57 terminology 

2008年7月に最新リリースがあり、MITライセンスでライセンスされているChiliプラグインのコードを変更して、GPLでライセンスすることは可能ですか？ 私が見る限り、同じライセンスの下でライセンスされる新しいコードに制限はありません。本当にそうですか、それとも最小限の変更がありますか？ 私の場合、CMSで実行される通常のJavaScriptコードでjQueryプラグインを変更します。これは本質的に、とりわけ： コードは「ChiliBook」名前空間を使用しません。 関数はasとして呼び出されませんが$($element).chili()、asとして呼び出されますGlobalObject.ChiliHighlighter.process($jquery_element)。「GlobalObject」はCMSから使用されるJavaScriptオブジェクトです。 このコードにより、他のモジュールがGlobalObject.ChiliHighlighterオブジェクトを変更して、GlobalObject.ChiliHighlighter.process()定義時にオプションで呼び出される関数を追加できます。 代わりに、私が使用しているリポジトリは、コードがもはや維持されていないときにGPL 2以上のライセンスの下でライセンスされていないコードを含めることができるので、最後のバージョンが3年前にリリースされたため、プラグインはもはや維持されていないと見なされますか？

57 licensing  gpl  mit-license 

パラメーターとして整数を使用するRESTエンドポイントがあるとします。 /makeWaffles?numberOfWaffles=3 この場合、負の数のワッフルを作ることができないため、この数を正にしたいです（そして、0のワッフルを要求するのは時間の無駄です）。したがって、正の整数を含まない要求を拒否したいと思います。また、最大の整数を超えるリクエストを拒否したい（今はMAX_INTEGERであるとしましょう）。 誰かが非正数のワッフルをリクエストした場合、HTTP 400（Bad Request）ステータスを返すべきですか？私の最初の考えはイエスです：それは私がリクエストを完了するための有効な数字ではありません。ただし、RFCでは、ビジネスルールをスローする理由として言及していません。 400（Bad Request）ステータスコードは、クライアントエラー（たとえば、不正な要求構文、無効な要求メッセージのフレーミング、または不正な要求ルーティング）が原因でサーバーが要求を処理できないか、処理しないことを示します。 ビジネスルールは、これら3つの例のいずれにも該当しません。これは構文的に正しく、適切にフレーム化されており、不正なリクエストルーティングではありません。 パラメータが構文的に正しいが、ビジネスルールに違反している場合、HTTP 400（Bad Request）ステータスを返す必要がありますか？または、返すのに適切なステータスがありますか？

56 api-design  http 

norに相当する演算子はありますか？たとえば、私の好きな色は緑でも青でもありません。 そして、コードは次と同等になります。 // example one if (color!="green" && color!="blue") { } // example two if (x nor y) { // x is false and y is false }

56 operators 

64ビットハードウェア上で最新の64ビットオペレーティングシステムを実行する、最新のデスクトップマシンを対象としたソフトウェアの64ビットバージョンと共に32ビットバージョンを提供する正当な理由はありますか？ 64ビットソフトウェアの方が効率的で、必要に応じてメモリ使用量を増やすことができるようです。Appleは、4 GBをはるかに下回るRAMが1〜2 GBしかなくても、電話に64ビットプロセッサを使用します。 32ビットCPUの制限。

56 hardware  64-bit  32-bit 

通常の本能は、コードに表示されるコードの重複を削除することです。しかし、複製が幻想的である状況にいることに気づきました。 より詳細に状況を説明するために：私はWebアプリケーションを開発していますが、ほとんどのビューは基本的に同じです-ユーザーがスクロールして選択できるアイテムのリスト、選択したアイテムを含む2番目のリスト、および「保存ボタンをクリックして、新しいリストを保存します。 問題は簡単なように思えました。ただし、それぞれのビューには独自の癖があります-場合によっては何かを再計算する必要があり、時には追加のデータなどを保存する必要があります。これらは、メインロジックコードにコールバックフックを挿入することで解決しました。 基本的にすべての機能にコールバックを提供する必要があり、メインロジックはコールバック呼び出しの巨大なシーケンスのように見えるため、ビューには非常に多くの微細な違いがあります。すべてのビューには実行される独自のコードがあり、すべてコールバックで実行されるため、最終的には時間やコードを節約しません。 問題は次のとおりです。 違いは非常に小さいため、コードはすべてのビューでほぼ同じように見えますが、 非常に多くの違いがあるので、詳細を見るとき、コードを書くことは少し似ていません この状況にどのように対処すればよいですか？ コールバックコールのみで構成されたコアロジックを持つことは良い解決策ですか？ または、コードを複製して、コールバックベースのコードの複雑さをなくすべきですか？

56 coding-style 

経験豊富な開発者は、コードが解決しているパターンと問題が十分に理解されている場合にコードの実装にかかる時間を推定することは比較的可能ですが、最終目標が十分に理解されているときに、どのように適切な推定を行うことができますか？実装は95％の理論的/問題解決であり、実装の量は非常に少ないですか？ 私の仕事は、明確に定義された目標を達成するためのタスクで構成されることがよくありますが、その目標を達成する方法を見つける必要があり、ソリューションを理解するまで、どのような障壁が存在するかは明確ではありません。具体的には、コード生成ツールまたは自動化されたコード操作ツールに頻繁に取り組んでいます。ソリューションが完全に解決され、ツールが完成すると、実際の変更の95％がすぐに直接実行されます。ただし、生成ツールまたは分析ツールで予期しないエッジケースを処理するために、さらにいくつの問題を解決する必要があるかを見積もる方法はありません。 計画の目的のために、私の会社はそれがどれくらいの時間がかかるかについてのより良いアイデアを望んでいますが、ソリューションの各ステップを解決することを通して作業中にいくつの追加の問題が出てくるかわかりません。どのようにすればより良い見積もりを出すことができるのか分かりません。

56 estimation  automation 

gdb は2009年にリバースデバッグのサポートを実装しました（gdb 7.0を使用）。2012年まで聞いたことはありません。特定の種類のデバッグの問題に非常に役立つことがわかりました。前に聞いたことを望みました。 私が間違っている場合、私を修正しますが、私の印象は、テクニックがまだほとんど使用されておらず、ほとんどの人がそれが存在することを知らないということです。どうして？ 逆デバッグの使用が一般的なプログラミングコミュニティを知っていますか？ 背景情報： Stackoverflow：リバースデバッグはどのように機能しますか？ gdbは「リバースデバッグ」という用語を使用しますが、他のベンダーは同一または類似の手法に対して他の用語を使用します。 MicrosoftはそれをIntelliTraceまたは「履歴デバッグ」と呼びます Omniscient Debuggerと呼ばれるJavaリバースデバッガーがありますが、おそらくJava 6では動作しません 他のJavaリバースデバッガーがあります OCamlのデバッガー（ocamldebug）はタイムトラベルと呼びます

56 debugging 

個人的に、.NetでWeakReference型を使用する必要がある状況に遭遇したことはありませんが、一般的な信念は、キャッシュで使用する必要があるということです。博士ジョン・ハロップは、彼の中にキャッシュ内WeakReferencesの使用に対して非常に良いケース与えた答えにこの質問を。 また、AS3開発者がメモリフットプリントを節約するために弱い参照を使用することについて話すことをよく耳にしましたが、私が持っていた会話に基づいて、意図した目標を必ずしも達成することなく複雑さを追加するようであり、ランタイムの動作はかなり予測不可能です。そのため、多くの人は単純にそれをあきらめ、代わりにメモリ使用量をより慎重に管理する/コードを最適化してメモリ集約度を下げます（またはCPUサイクルを増やしてメモリフットプリントを小さくします）。 Jon Harrop博士はまた、.Net弱参照はソフトではなく、gen0には弱参照の積極的なコレクションがあると彼の答えで指摘しました。MSDNによると、長い弱参照はオブジェクトを再作成する可能性を与えてくれますbut the state of the object remains unpredictable.！ これらの特性を考えると、弱い参照が役立つ状況を考えることはできません。おそらく誰かが私を啓発できるでしょうか？

56 c#  .net  garbage-collection  weak-references 

まず、いくつかのコンテキスト（ほとんどの人が知っているもの）： すべての一般的なプログラミング言語には明確な進化があり、ほとんどの場合バージョンによってマークされます。Java5、6、7など、PHP 5.1、5.2、5.3などがあります。新しいバージョンをリリースすると、新しいAPIが利用可能になり、バグが修正され、追加されます新しい機能、新しいフレームワークなどです。全体として：それは良いことです。 しかし、言語（またはプラットフォーム）の問題はどうでしょうか？言語に何か問題がある場合、開発者はそれを回避するか（可能であれば）、それと共存することを学びます。 現在、これらの言語の開発者は、それらの言語を使用するプログラマーから多くのフィードバックを得ています。そのため、時間（およびバージョン番号）が経過するにつれて、これらの言語の問題はゆっくりと、しかし確実に消えていくことになります。まあ、そうでもない。どうして？下位互換性、それが理由です。しかし、これはなぜですか？より具体的な状況については、以下をお読みください。 私の質問を説明できる最善の方法は、PHPを例として使用することです。 PHPは何千人もの人々に愛され、嫌われています。すべての言語には欠陥がありますが、明らかにPHPは特別です。このブログ投稿をご覧ください。PHPのいわゆる欠陥の非常に長いリストがあります。今、私はPHP開発者ではありません（まだ）が、すべてを読み通しており、そのリストの大きな部分が実際の問題であると確信しています。（潜在的に主観的であるため、すべてではありません）。 さて、もし私がPHPを積極的に開発している人の1人であれば、これらの問題を1つずつ解決したいと思っています。ただし、それを行うと、言語の特定の動作に依存するコードが新しいバージョンで実行されると壊れます。2語で要約すると、後方互換性です。 私が理解していないのは、なぜPHPの下位互換性を保つ必要があるのか​​ということです。これらの問題をすべて修正したPHPバージョン8をリリースした場合、「このバージョンでは古いコードを実行しないでください！」という大きな警告を出すことはできませんか？ 非推奨と呼ばれるものがあります。私たちは何年もそれを持っていて、それはうまくいきます。PHPのコンテキスト：最近の人々がどのようにmysql_*関数の使用を積極的に推奨していないか（そして代わりにmysqli_*PDO を推奨するか）を見てください。廃止は機能します。使用できます。それを使うべきです。関数で機能する場合、言語全体で機能しないのはなぜですか？ 私（PHPの開発者）がこれを行うとしましょう： これらのすべての欠陥を修正した新しいバージョンのPHP（たとえば8）を起動します 新しいプロジェクトは、そのバージョンの使用を開始します。これは、はるかに優れた、より明確な、より安全なものだからです。 ただし、古いバージョンのPHPを放棄しないように、更新プログラムをリリースし続け、セキュリティの問題、バグなどを修正します。これは、ここにリストしていない理由から理にかなっています。これは一般的な習慣です。たとえば、バージョン5.5.xに主に焦点を合わせていたにもかかわらず、OracleがMySQLのバージョン5.1.xを更新し続けた方法を見てください。 約3〜4年後、古いバージョンのPHPの更新を停止し、それらを消滅させます。この3年か4年で、ほとんどのプロジェクトはとにかくPHP 8に切り替えられるので、これは問題ありません。 私の質問は次のとおりです。これらの手順はすべて理にかなっていますか？それはとても難しいでしょうか？それができれば、どうしてできないのですか？ はい、欠点は後方互換性を破ることです。しかし、それは支払う価値がありませんか？良い点として、3、4年後には、その問題の90％が修正された言語になります。その名前はその人気を保証します。 編集：OK新しい計画。

56 programming-languages  backward-compatibility 

聞きたいのですが、jQueryをゆっくりと学んでいます。 私が見るものは、神オブジェクトのアンチパターンの正確な例です。基本的に、それが何であれ、すべてが関数に送られます。$ 私は正しいですか、jQueryは本当にこのアンチパターンの例ですか？

56 jquery  anti-patterns 

問題の概要： 長い話を簡単に言えば、私はコードベースと開発チームを引き継ぎました。私はこれを置き換えることは許されておらず、God Objectsの使用は大きな問題です。今後、リファクタリングをしてもらいたいのですが、「もっと簡単だから」、God Objectsを使ってすべてをやりたいチームから押し戻されています。これは、リファクタリングが許可されないことを意味します。私は長年の開発経験、これらのことを知るために雇われた新しいボスなどを押し返しました。また、サードパーティのオフショア会社が営業担当者を説明しました。これは現在、役員レベルと会議です明日であり、長期的にはより安くなると思うので、多くの技術的な弾薬を使ってベストプラクティスを提唱したいと思います（そして、個人的にはサードパーティが心配していることだと感じています）。 私の問題は技術レベルからのものであり、長期的にはよく知っていますが、超短期間と6か月の期間には問題があります。 1人（ロバートC.マーティン、別名ボブおじさん）の、1人のデータ（1人のみ）（ロバートCマーティン）が十分な議論をしていないと言われているように。 質問： 「神」オブジェクト/クラス/システムのこの使用は明らかに悪いと言っている分野の有名な専門家が直接引用できるリソース（タイトル、発行年、ページ番号、引用）は何ですか？最も技術的に有効なソリューションの場合）？ 私がすでに行った研究： ここにはたくさんの本があり、「god object」と「god class」という言葉の使用についてインデックスを検索しました。奇妙なことに、ほとんど使用されておらず、たとえば、私が持っているGoF本のコピーは使用されません（少なくとも私の目の前のインデックスによると）が、下の2冊の本で見つけましたが、もっと欲しい私は使えます。 ウィキペディアのページで「God Object」と現在の参照リンクの少ないスタブを確認したので、個人的には有効とは見なされない環境ではあまり使用できないと言うことには個人的に同意します。引用された本はまた、私がこれらの技術的ポイントを議論している人々によって有効であるには古すぎると考えられています。 「オブジェクトは使いやすい」。私は個人的にこの声明が間違っていると信じていますが、それが何であれ真実を証明したいと思います。 ロバートCマーティンの「C＃のアジャイルの原則、パターン、および実践」（ISBN：0-13-185725-8、ハードカバー）では、266ページに「神のクラスが悪い考えであることを誰もが知っています。システムのすべてのインテリジェンスを単一のオブジェクトまたは単一の機能に集中させること。OODの目標の1つは、動作を多数のクラスおよび多数の機能に分割および分散することです。-そして、とにかく時々神のクラスを使用する方が良いことを時々言い続けます（例としてマイクロコントローラーを引用）。 ロバートCマーティンの「クリーンコード：アジャイルソフトウェアクラフツマンシップハンドブック」136ページ（およびこのページのみ）で、「神のクラス」について説明し、「クラスは小さくなければならない」ルールの違反の主な例として呼び出しています彼は138ページから始まる単一責任原則の推進に使用しています。 私が抱えている問題は、すべての参考文献と引用が同じ人（ロバートC.マーティン）から来ており、同じ一人の人/情報源から来ていることです。彼はただ一つの見解であるため、「神クラス」を使用しないという私の願望は無効であり、ソフトウェア業界の標準的なベストプラクティスとして受け入れられないと言われています。これは本当ですか？ボブおじさんの教えを守ろうとすることで、技術的な観点から間違ったことをしているのでしょうか？ 神のオブジェクトとオブジェクト指向プログラミングおよび設計： これについて考えるほど、OOPを勉強するときに学ぶことが多くなり、明示的に呼び出されることはありません。良いデザインへのその暗黙は私の考えです（私が学びたいので、自由に訂正してください）、問題は私がこれを「知っている」ことですが、誰もがそうではありません。統計的にほとんどの人はプログラマーではないため、実際にはほとんどの人が統計的に無知であるにもかかわらず、私は事実上それを普遍的な真実と呼んでいます。 結論： 彼らが技術的な主張をしており、真実を知り、実際のエンジニア/科学者のような引用でそれを証明できるようにしたいので、引用する最良の追加結果を得るために何を検索するのか迷っています私は、神のオブジェクトを使用したコードの個人的な経験のために、神のオブジェクトに偏っています。どんな援助または引用も深く感謝されるでしょう。

56 object-oriented  class  object  single-responsibility