ソフトウェア工学

ウィキペディアの記事「ルールオブスリー」に出会いました 3つのルールは、コードの複製された部分を新しいプロシージャに置き換える必要があるかどうかを判断するための、コードリファクタリングの経験則です。コードは1回コピーできますが、同じコードを3回使用すると、新しいプロシージャに抽出する必要があると記載されています。ルールは、リファクタリングでマーティン・ファウラーによって導入され、ドン・ロバーツに起因します。 これは単なる経験則であることは知っていますが、2回目の複製後にのみリファクタリングすることが推奨されるのはなぜですか？最初の複製を作成するときに、リファクタリングにマイナス面はありますか？

16 refactoring  dry  rule-of-three 

私はGRASPを学ぼうとしていますが、これは低結合について説明されています（ここ3ページにあります）。 クラスのメソッドaddTrackについて考えてみましょうAlbum。2つの可能なメソッドは次のとおりです。 addTrack( Track t ) そして addTrack( int no, String title, double duration ) どの方法で結合が減少しますか？Albumクラスを使用するクラスはTrackクラスを知る必要がないので、2番目のものはそうします。一般に、メソッドへのパラメーターは、java。*パッケージの基本型（int、char ...）およびクラスを使用する必要があります。 私はこれに反対する傾向があります。私はさまざまな理由addTrack(Track t)よりも優れていると信じていますaddTrack(int no, String title, double duration)： メソッドのパラメーターはできるだけ少ないほうが常に良いです（Uncle BobのClean Codeによれば、なしまたは1つ、できれば2、場合によっては3、特別な場合は3、3つ以上はリファクタリングが必要です-これらはもちろん推奨ルールではありません） 。 場合addTrackのインタフェースの方法であり、要件がいることを必要とするTrackより多くの情報（たとえば年またはジャンル）を持っている必要があり、インターフェイスを変更する必要があるので、この方法は、別のパラメータがサポートする必要があること。 カプセル化が壊れています。addTrackがインターフェイス内にある場合、の内部を知らないはずTrackです。 実際には、多くのパラメーターを使用して、2番目の方法でより結合されています。仮定noから変更するパラメータニーズをintへlong以上があるのでMAX_INT、トラック（または何らかの理由で）。Trackメソッドとメソッドの両方を変更する必要がありますが、メソッドaddTrack(Track track)のみTrackが変更される場合は変更します。 4つの引数はすべて実際には相互に関連しており、それらの一部は他からの結果です。 どのアプローチが良いですか？

16 design  object-oriented-design  coupling  design-principles 

ユニットテストは初めてで、DBを呼び出してDTOを設定するREST Webメソッドが1つあります。擬似コードは public object GetCustomer(int id) { CustomerDTO objCust = //get from DB return objCust; } 私の疑問は、含まれるこれらのメソッドとテストのタイプ（Integration / Unit）のテストの書き方です。単体テストの場合、DBにアクセスする必要がありますか。そうであり、顧客IDを渡してアサーションをほとんど行わない場合、データが最終的に変更されて失敗する可能性があります。 ここでこれらの概念を理解している何かが欠けていると思います。

16 testing  unit-testing  rest  integration-tests 

高度にサイロ化された「一匹狼」の開発部門構造で2年以上働いた後、アジャイルスクラムを採用しています。すごい。私はアジャイルが好きです。開発者として、無数の利害関係者が昨日プロジェクトを終えた後、プロジェクトをスローダウンすることなく、集中して忙しく生産的になります。 しかし、現在の「モデル」と対比してSCRUMに移行する側面が1つあり、開発部門以外の人は少しでも好きになれないと思います。それが、「待機中」に小さな変更を行う現在の能力です。私たちの開発の大部分は、社内での消費のみを目的としており、ほぼ全員が同じ建物内にいます。そのため、他の部門のリーダーまたはマネージャーが特定のアプリケーションの「コードベースの所有者」に来て、小さなものを要求することは長年にわたって一般的な慣習でした（それほど小さくはありませんが、これらの「ドライブバイ」に基づいた週プロジェクト）。私たちの上司でさえ、彼に持ち込まれたものをこのように中継することがあります。非常に頻繁に、その時点で問題のコードベースで作業している場合、ソースファイルをポップアップ表示するだけで、 基本的なアジャイルSCRUM方法論では、これらの調整は、欠陥（以前に消費したストーリーで指定された要件を満たしていない）または新しい小さなストーリー（記載されているすべての要件を満たしましたが、それらの要件は不完全、曖昧、または不正確でした） 、またはユーザーが新機能を見た後に配信後に変更されました）。どちらにしても、大半はないがほとんどゼロで、1-ポインタとなり、比較的低い優先度（システムは、現在の状態で使用可能ですが、それは次のようになりそうならば...ずっとクーラー）であることが、彼らがそうなって、バックログをトップダウンで操作するときにスプリントに持ち込まれます。 この可能性は、他の部門によるアジャイルプロセスへの積極的な反対の源として開発者会議で提起されました。これはIMOにとって有効な懸念事項です。POの背後にある利害関係者は、すべてが同じ視点を持っているわけではないため、最も重要なことについて常に同意するわけではありませんが、最終的な決定を下すのは通常マネージャーだけです。製品バックログに表示されます。 その後、暫定的に「キャンディジャー」と呼ばれる解決策が提案されました（別の用語は「グレービーボート」でした）。さまざまな部門の「リトルガイ」によって要求された小さな調整。既存のストーリーの欠陥ではなく、チーム内のコンセンサスまたは称賛により、開発者の1日の半分以下で済むと推定されます。エンドユーザーの意見では、ユーザーエクスペリエンスに対する即時の重要なプラスの影響が、プライマリバックログと並行してリストに追加されます。それらは「ストーリー」として識別されますが、優先順位付けの対象となる「大きな」ストーリーの主要なバックログとは別に保持されます。スプリントの通常の進行中にいつでも、これらの調整のいずれかを行うことができるシステムの領域で作業している場合、微調整を簡単にすることで、スプリントに微調整を加え、より大きなストーリーと一緒にコーディングできます。これをする大きなストーリーやその他のコミットされた作業の完了を危険にさらしてはなりません。POはこのリストにもアクセスでき、微調整を含む基本機能に触れる今後のユーザーストーリーに取り組んでいる場合、要件としてストーリーに組み込むことができます。その他。これにより、微調整がより早く実行される可能性が高くなると考えられていました。 これにより、スクラムマスターによる「ええと」のトレーニングが行われ、私たちの間に反応が生じました。バックログが1つあります。2つのバックログは、どの＃1アイテムが本当に最も重要であるか、どのリストのアイテムが実際の速度を決定するか、2つのバックログのうちどちらが実際に属するかという問題を紹介しますどちらか一方に勝手に）。「プロセスを機能させる」と私たちは言いました。変更がエンドユーザーにとって本当に重要な場合、彼らは部門長が時間/お金の決定を行うのに十分な騒ぎをし、バックログのトップに対する開発チームの意識にぶつかるでしょう。 私は床に質問を投げかけると思った：あなたの意見では、「一口サイズ」の物語の平行リストは、小さく、有用であるが最終的には優先度の低い変更をより速くすることに価値があるか、それとも全体的に良い決定ですか？それらをメインのバックログに組み込み、スプリントへの組み込みを基本プロセスで管理するにはどうすればよいですか？

16 agile  feature-requests  product-backlog 

ユーザーとリンクの2つのリソースがあります。 ユーザーは複数のリンクを関連付けることができます。次のURIでユーザーに関連付けられたリンクにアクセスできるように、RESTful APIを設計しました。 /users/:id/links ただし、常にリンクだけのURIが必要です。ユーザーに関係なく、すべてのリンクが必要な場合があります。 このために私は： /links これは大丈夫ですか？リンクに2つのURIがありますか？ 代わりに、次のようなURIを使用してユーザーのリンクにアクセスする必要があるかどうか疑問に思います。 /links/user/:id または /links/?user=:id この方法では、リンク用のリソースは1つしかありません。

16 api  rest  api-design 

私はC＃開発の初心者であり、より応答性の高いUIを作成したいと考えています。私の予備調査では、これを達成するための2つの方法を見てきました。 BackgroundWorkerクラスと組み合わせたマルチスレッド。 新しいAsync / Await修飾子。 新しい方が良いという意味ですか？2つの方法の違いは何ですか？新しいプロジェクトを作成したい場合、どの方法を選択するのですか？ 編集：たぶん指定する必要があります。Windows Formsアプリケーションを作成しています。ここでは、必要なすべてのデータがローカルディスクに保存/ロードされます。また、いくつかのUSBデバイスと通信します。

16 c#  .net  multithreading  async 

定型コードの量を大幅に減らす場合は、リフレクションを使用することをお勧めしますか？ 基本的に、一方の側でパフォーマンスとおそらく読みやすさと、他方の側で定型コードの抽象化/自動化/削減との間にトレードオフがあります。 編集：推奨されるリフレクションの使用例を次に示します。 例として、Base10個のフィールドと3個のサブクラスSubclassAをSubclassB持ち、SubclassCそれぞれが10個の異なるフィールドを持つ抽象クラスがあるとします。それらはすべて単純なBeanです。問題は、2つのBase型参照を取得し、対応するオブジェクトが同じ（サブ）型であり、等しいかどうかを確認することです。 ソリューションとしては、最初にタイプが等しいかどうかをチェックしてからすべてのフィールドをチェックするか、リフレクションを使用して同じタイプであるかを動的に確認し、「get」（convention構成上）、両方のオブジェクトでそれらを呼び出し、結果で等しいを呼び出します。 boolean compare(Base base1, Base, base2) { if (base1 instanceof SubclassA && base2 instanceof SubclassA) { SubclassA subclassA1 = (SubclassA) base1; SubclassA subclassA2 = (SubclassA) base2; compare(subclassA1, subclassA2); } else if (base1 instanceof SubclassB && base2 instanceof SubclassB) { //the same } //boilerplate } boolean compare(SubclassA …

16 java  programming-practices  reflection 

ランダムな数式を生成および評価するために、このアイデアを頭の中で実行しています。そこで、私はそれをテストするためにコーディングする前に、それを試してアルゴリズムを作り上げることにしました。 例： ランダムに生成する式の例を次に示します。 4 + 2 [easy] 3 * 6 - 7 + 2 [medium] 6 * 2 + (5 - 3) * 3 - 8 [hard] (3 + 4) + 7 * 2 - 1 - 9 [hard] 5 - 2 + 4 * (8 - (5 + 1)) …

16 algorithms 

ショッピングカートの設計に取り組んでおり、セッションまたはデータベースのいずれかにショッピングカートを保存する必要がありますが、どちらのアプローチが最適かはわかりません。 ユーザーはログインしておらず、カートに商品を追加していません（匿名ユーザー） ユーザーがログインし、カートに製品を追加しています。 ユーザーがログインせずにWebショップにアクセスして製品を追加するだけでなく、チェックアウトプロセスに行かない可能性が高いため、最初のケースは私を混乱させます。 ただし、ショッピングカートを作成して保存するには、このユーザーのショッピングカートを作成する必要があります。2つのオプションがあります。 ユーザーが製品を追加するときに、データベースにカートを作成し、このカートをこのユーザーに関連付けます。ログインした瞬間に、このカートをログインしているユーザーに移動します。 ユーザーがログインしてデータベースにカートを作成し、ログインしたユーザーをこのカートにユーザーと関連付けた場合、カートを作成し、製品を追加してセッションに保存します。 データベースベースのカートシステムとセッションベースの両方に肯定的側面と否定的側面があることを知っていますが、次の点を考慮するためにどちらが最善のアプローチであるかはわかりません 拡張性 柔軟性 拡張性 アプリケーションは速度に注意する必要があります この側面に関する入力を探して、パスを決定します。

16 database  session  design  web-applications 

私はその本を読んでいprogramming in Luaます。と言った クロージャーは、多くの状況で価値のあるツールを提供します。これまで見てきたように、これらはsortなどの高階関数の引数として役立ちます。クロージャーは、newCounterの例のように、他の関数を構築する関数にも役立ちます。このメカニズムにより、Luaプログラムは機能的な世界からの洗練されたプログラミング手法を組み込むことができます。クロージャーはコールバック関数にも役立ちます。ここでの典型的な例は、従来のGUIツールキットでボタンを作成するときに発生します。各ボタンには、ユーザーがボタンを押したときに呼び出されるコールバック関数があります。ボタンを押したときに、ボタンごとにわずかに異なる処理を行う必要があります。たとえば、デジタル計算機には、各桁に1つずつ、10個の同様のボタンが必要です。次のような関数を使用して、それぞれを作成できます。 function digitButton (digit) return Button{label = tostring(digit), action = function () add_to_display(digit) end} end を呼び出すdigitButtonとを返すように見えるのでaction（これによりクロージャが作成されます）、digit渡されたにアクセスできますdigitButton。 私の質問は： Why we need call back functions? what situations can I apply this to? 著者は言った： この例では、Buttonは新しいボタンを作成するツールキット関数であると想定しています。labelはボタンのラベルです。actionは、ボタンが押されたときに呼び出されるコールバッククロージャーです。コールバックは、digitButtonがタスクを実行した後、ローカル変数digitがスコープから出た後、長時間呼び出すことができますが、それでもこの変数にアクセスできます。 著者によると、同様の例は次のようになります。 function Button(t) -- maybe you should set the button here return t.action -- so …

16 programming-languages  programming-practices  lua 

私たちは、さまざまな顧客向けの多数のプロジェクトを持つソフトウェアコンサルタントです。従来はSubversionを使用していましたが、現在Gitへの移行を検討しています。 私たちが作成するドキュメントの大部分はお客様と共有されており（要件、グローバル設計、テスト仕様など）、MS Officeを使用してこれらを作成しています。Subversionでは、「ロック」機能を使用して、同じドキュメントを同時に編集しているユーザーがいないことを確認できます。Gitでは、分散型の性質上、gitにはロックがないため、これを行うことはできません。 ロックは実際には通信メカニズムにすぎませんが、非常に効果的なものです。 現在、私たちのコードと顧客向けのドキュメントは通常、異なるsvnリポジトリの異なるサブフォルダーにあります。gitに移行するときに、私たちが推奨することは何ですか？オプションのセットが表示されます： svnリポジトリをgit 1-on-1に移動します。Officeファイルでロックを使用する代わりに、gitの人々が提案することを行い、何らかの方法でワークフローを変更して修正します。これは、ドキュメント編集のブランチで機能し、オーバーレビューをマージする可能性があります。このアプローチは、プロジェクト管理情報を含むExcelシートなどを分割します。チームメンバーは簡単に編集できますが（これを行うことをお勧めします）、正式なレビュープロセスの対象ではありません コードにはgitを、ドキュメントとプロジェクト管理にはsvnを使用します。これには、よりデザイン性の高い特定のドキュメントが仕様のコードの「近く」にないため、更新を忘れる可能性が高くなるという欠点があります。さらに、誰もが2つのツールセットを使用して理解する必要があります。とはいえ、これはおそらく、顧客と向き合っていない設計ドキュメント用のテキストベースのドキュメントツール（ラテックス、マークダウン、HTMLなど）に移行する絶好の機会です。 1に似git lockていますが、svnロックが行うことを行うコマンドをハックします（読み取り専用フラグを適切に切り替え、何らかの手段でサーバーと同期します）。 DVCSでロックが機能しないという議論は、あなたが完全にオフラインのときでもシステムが機能するはずだからです。SVNロックもオーバーライドできます。それらは通信メカニズムです。なんらかのネットワーク接続がなければ、コンピューターはあまり通信できません。 私svn lockたちのワークフローにどの程度適合しているかに非常に満足しているお店は私たちだけではありませんよね？ アイデアやヒントはありますか？ /programming/119444/locking-binary-files-using-git-version-control-systemが見つかりましたが、議論はかなり技術的なものです。2人のチームメンバーが同じバイナリファイルを同時に編集するという実際的な問題を解決または回避する方法を探しています。

16 git  svn  dvcs  excel  word 

今から何年も実行されるコードを書く プログラミング言語が変わります。ライブラリが変更されます。5年、10年、または20年前のコードも実行され、期待どおりの結果が得られる場合がありますが、2年前のコードは構文エラーで失敗する場合があります。言語は進化しているため（少なくとも、ほとんどは進化しているため）、これは部分的に避けられません。開発者には、コードを維持する責任があります。しかし、生産コードでは安定性が重要な要件である場合があり、コードを毎年変更して言語の変更に適応させる必要なく、コードを10年間実行する必要があります。または、たとえば科学データ分析用の小さなスクリプトがあり、それらを何年も触れなかった後に再訪する必要があるかもしれません。たとえば、気象庁では、速度が重要ではない部分にも多くの操作可能なFortranコードがあり、コードの安定性が理由の1つです。私' 不安定性への恐怖は、Pythonへの移行に対する彼らのオブジェクトの1つです（もちろん、言語のinertia性は別として、古いコードに依存しない新しいコードに対してのみ可能です）。もちろん、安定したコードの1つの戦略は、オペレーティングシステム全体を凍結することです。しかし、それは常に実現可能ではありません。 例としてPythonを使用していますが、問題は特にPythonに限定されません。 Pythonの互換性の問題に関するドキュメント Pythonの場合、後方互換性のない変更に関するポリシーの概要を示すドキュメントがいくつかあります。 PEP-5 PEP 5によると： Pythonの移行バージョンのリリースと後方互換性のないバージョンのリリースとの間には、少なくとも1年間の移行期間が必要です。ユーザーは、少なくとも1年はプログラムをテストし、非推奨の構成の使用から別の構成に移行する必要があります。 個人的には、1年はかなり短いと思います。つまり、コードを書く可能性がありますが、1.5年後にはもう実行されなくなります。 PEP 291 PEP 291には、下位互換性を維持するために避けるべき事項のガイドラインの不完全なリストが含まれています。ただし、Python 2.xのみに関連します。Python 2.7は2.xシリーズの最終リリースであり、Python 2.7はバグ修正のみであるため、このPEPは歴史的な関心のみになりました。 PEP 387 下位互換性のない変更に関するPEP 387もあります。PEP 387はドラフトであり、公式のポリシーではありません。2009年6月、これはPython-ideasメーリングリストで議論されました。ディスカッションの一部では、開発者が言語の変更に対して堅牢なコードを作成する方法に焦点を当てました。ある投稿は、やってはいけないことに関するいくつかのアドバイスをリストしました： これに加えて、おそらくほとんどの場合に当てはまるいくつかのルールがあります：で始まるものを呼び出したり"_"、モンキーパッチを適用したり、自分以外のクラスのオブジェクトで動的クラス置換を使用したりしないでください、継承階層の深さに依存せず（たとえば、no ".__bases__[0].__bases__[0]"）、DeprecationWarningsを生成せずにテストを実行し、他のライブラリから継承するクラスに属性を追加するときに潜在的な名前空間の競合に注意してください。しかし、これらすべてが1か所に書き留められているとは思いません。 さらに、「地雷原」（新機能が変更される可能性が高い）と「凍結領域」（ほとんど販売されていないAPIが変更されないことが実質的に保証されている）についていくつかの点がありました。アントワーヌ・ピトルーの引用： 「凍結領域」は、負の値（明示的な「地雷原」）ではなく、正の値（明示的なパブリックAPIと明示的に保証された動作）で定義する必要があると思います。そうしないと、いくつかの重要なものを地雷原に置くことを忘れ、後から互換性のない方法でそれらのものを変更する必要があるときに噛まれます。 このスレッドから結論は出ていないようですが、探しているものの中核にかなり近づいています。スレッドはほぼ4年前であるため、状況はおそらく変更または改善されています。どのような種類のコードが存続する可能性が高く、どのような種類のコードがより脆弱ですか？ 移植のガイドライン 上記のドキュメントに加えて、各Pythonバージョンには移植ガイドラインが付属しています：Python 3.2への移植、Python 3.3への移植など。 便利な互換性 PEP 3151は、有用な互換性の概念を紹介してくれました。私自身の言葉で言えば、これは、コードが慎重に記述されている場合にのみ、言語開発者が互換性を維持するように注意する必要があるという考えに要約されます。それは実際に有用な互換性を定義するものではありませんが、上記のPEP 387の議論から引用したアイデアに似ていると思います。 プログラマーの観点から プログラマーとして、私はPythonが将来変化し、人々、特に私自身が、おそらく数年後に、1、2、または3つのマイナーバージョンアップのPythonバージョンでコードを実行しようとすることを知っています。すべてが互換性があるわけではありません。実際、失敗するコードを思い付くのは簡単です（かつて私が言ったコードに遭遇しましたif sys.version[:3] != '2.3': print 'Wrong version, exiting'）。私が探しているのガイドラインのセットです何をすべきか、何 ではない 行うには、私のコードはまだ将来的に変更されていない実行される可能性を高めるため。 そのようなガイドラインはありますか？将来も実行されるPythonコードを作成するにはどうすればよいですか？ 私の質問は、Pythonコアとその標準ライブラリだけでなく、一般的に使用されるアドオンライブラリ、特にnumpy、scipyにも関連していmatplotlibます。 編集：これまでのところ、答えの2つはpython2対python3に関連しています。これは私が言っていることではありません。Python2からPython3に移行するツールについて知っています。私の質問はまだ来ない言語変更に関連しています。より安定したコーディングガイドラインを見つけるには、クリスタルボールよりも優れています。例えば： …

16 python 

ウィキペディアによると、アジャイルは「RAD」の一種であり、これは間違っていると思います。私が知っていることから、アジャイルはRAD自体が90年代に成功しなかったために開発されました（変更にはあまりにも厳格です）。それとも私は間違っていますか？ （備考：どうやらアジャイルソフトウェア開発に関するWikipediaの記事は、間に改善されたが、それだけで一覧表示されますRADをないスーパーセットとして、アジャイルの前身として）。 本Radical Project Management（Thomsett）からの参照 「..RAD、アジャイル、オブジェクト指向などの新しい開発の流行...」 CISA認定情報システム監査員： ..2 つの代替ソフトウェア開発を認識しています。メソッド：アジャイルで迅速なアプリケーション開発 ソフトウェアのアジャイル管理： アジャイルメソッドは、主にRADの軽量アプローチから派生しています。 ソフトウェア推定のベストプラクティス： swの主な方法。開発者 次のように要約できます 。1.ウォーターフォール.. 4. RAD 5.アジャイル この質問のポイントは次のとおり です。アジャイル型はRADですか、それともスタンドアロン開発アプローチですか？

16 agile  development-process  rad 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 4年前に閉鎖されました。 私は最近SQLを学び、MySQL / PostgresとすぐにOracle DBで練習しています。また、データベースの「ロードマップ」調査のためにWebを検索しましたが、残念ながらそれを見つけることができませんでした。 特定のデータベースの概念が初心者から中級者から上級者に至るまでの規模と規模を理解する必要があります。私はほとんどの場合、リレーショナルデータベースについて考えています。 初心者->中級->上級者の進行において、以下にリストされているスキルをどのようにレイアウトするかを説明してください。 Where句 構文を更新する 参加する ステートメントの変更と作成 一時テーブル カーソル インデックス 外部キー 制約 取引 サブクエリ ピボット 集計関数 プロファイリング OLAPおよびOLTP トリガー 実行計画 実行のヒント パフォーマンスカウンター 正規化

16 learning  database  skills 

MITライセンスプロジェクトのソースコードを変更し、それに新しいクラスも追加しました。間違っている場合は修正してください。ただし、ライセンスの上に著作権表示を追加し、もう一方を削除することは合法だと思います。しかし、以前の著者の貢献をどのように帰すべきでしょうか？別のファイルを使用する必要がありますか？また、ライセンスや著作権表示のないHTMLファイルもいくつかありますが、これらも変更しました。それらを異なる方法で処理する必要がありますか？ 私の質問は、私が拡張しているプロジェクトのファイルの一部も変更しているという点で、この質問とは異なります。 更新 著作権表示を削除する提案は奇妙に聞こえますが、最初にこれを投稿したときに念頭に置いていたのは、コードに悪意のあるものを追加した場合、著者は責任を負わないということです。MITライセンスには免責事項が含まれているため、これは問題になりません。

16 copyright  mit-license  attribution