ソフトウェア工学

Webでいくつかの記事を読んで、アジャイル、XP、スクラム、ペアプログラミングが互いにどのように異なり、互いに関連しているかを調べ、次の行を導き出しました。 スクラムとXPはほぼ同じです。XPのリリース期間はスクラムよりも短い ペアプログラミングは、アジャイルとXPの両方の方法論で採用されています しかし、アジャイルがXPとどのように異なるかを特定できませんでした。 URLを提供するだけでなく、これに関するあなたの経験と考えを読んで喜んでいるでしょう。

32 project-management  agile  scrum  pair-programming  extreme-programming 

好奇心から、小、中、大のプロジェクトの違いは何ですか？コードの行数または複雑さで測定されますか？ 物々交換システムを構築しており、これまでのところ、ログイン/登録用のコードは約1000行あります。たくさんのLOCがありますが、これは大きなプロジェクトだとは思いません。これはそれほど複雑ではないからです。どのように測定されますか？

32 project 

ソフトウェア/ライブラリがWindowsプラットフォームをサポートしている場合、ほとんどの場合、ディレクトリと変数の名前はwin32。これは、C / C ++プロジェクトで最も一般的です。MinGWプロジェクトのターゲットトリプルでさえ使用しwin32ます。これには理由がありますか？WindowsやMicrosoft Windowsのような適切な名前を使用しないのはなぜですか？命名の選択に法的な障害がありますか？ この質問はAPIに関するものではなく、使用中の命名規則に関するものです。ライブラリが他のオペレーティングシステムをサポートする場合、多くの場合、のような固有の名前linux、freebsdまたは必要な特別なサポートを使用します。しかし、Windowsの場合、それは多くの場合省略されてwin32います。

31 coding-standards  naming-standards 

クラスimplementsがインターフェイスの場合、継承をフォローしていると言えますか？クラスがextends別のクラスの場合、それは継承であることを知っています。

31 java  terminology  interfaces  inheritance  definition 

「ビルダー」パターンは「テレスコープコンストラクター」アンチパターンに対処することに制限されていますか、それとも不変オブジェクトの複雑な作成のより一般的な問題に対処すると言うことができますか？ StringBuilderクラスは、その名の単語「ビルダー」を持っているが、それは伸縮コンストラクタとは何の関係もありません、それは単に私たちは不変オブジェクトのコンストラクタに渡す必要があることを、すべてのデータを収集するのに役立ちます。 私には、答えは非常に明確な「はい」のように見えますが、このトピックについては意見の相違があるようです。 私はこの質問に答えていました：プログラマーSE：コンストラクターでの正当な「本物の仕事」？OPが複雑なツリーを含む（おそらく不変の）オブジェクトを作成したい場合、「ビルダー」パターンのアイデアがポップアップし、それを調査中に「StringBuilder」スタイルのオブジェクト作成と言われるこのQ＆Aを見つけましたではない私には明確ではない理由のために、「ビルダー」パターンの適用、：stackoverflowの-のStringBuilderとビルダパターン。（その質問に答えた人は、私が知る限り説得力のあるポイントを作ることができませんでした。）

31 design  design-patterns  builder-pattern 

たとえば、0、0.5、... 5のボタンのリストを表示し、0.5ごとにジャンプします。私はforループを使用してそれを行い、ボタンSTANDARD_LINEで異なる色を使用しています： var MAX=5.0; var DIFF=0.5 var STANDARD_LINE=1.5; for(var i=0;i<=MAX;i=i+DIFF){ button.text=i+''; if(i==STANDARD_LINE){ button.color='red'; } } この場合、IEEE 754では各値が正確であるため、丸めエラーはありませんが、浮動小数点の等価比較を避けるために変更する必要がある場合は苦労しています： var MAX=10; var STANDARD_LINE=3; for(var i=0;i<=MAX;i++){ button.text=i/2.0+''; if(i==STANDARD_LINE/2.0){ button.color='red'; } } 一方で、元のコードはよりシンプルで、私にとっては楽しみです。しかし、私が検討していることが1つあります。i== STANDARD_LINEはジュニアチームメイトを誤解させますか？浮動小数点数に丸め誤差がある可能性があるという事実を隠していますか？この投稿のコメントを読んだ後： https://stackoverflow.com/questions/33646148/is-hardcode-float-precise-if-it-can-be-represented-by-binary-format-in-ieee-754 一部の浮動小数点数が正確であることを知らない開発者が多いようです。私の場合、浮動小数点数の等価比較が有効であっても、避けるべきですか？または、私はこれについて考えすぎていますか？

31 javascript  coding-style  floating-point 

Builderパターン（主にJava）の多くの実装を見てきました。それらはすべて、エンティティクラス（クラスとしましょうPerson）とビルダークラスを持っていますPersonBuilder。ビルダーはさまざまなフィールドを「スタック」し、new Person渡された引数とともにを返します。Personクラス自体にすべてのビルダーメソッドを配置するのではなく、明示的にビルダークラスが必要なのはなぜですか？ 例えば： class Person { private String name; private Integer age; public Person() { } Person withName(String name) { this.name = name; return this; } Person withAge(int age) { this.age = age; return this; } } 簡単に言えます Person john = new Person().withName("John"); なぜPersonBuilderクラスが必要なのですか？ 私が見る唯一の利点は、Personフィールドをとして宣言できることfinalです。したがって、不変性が保証されます。

31 java  design-patterns  builder-pattern 

私がフロントエンドを持っていると仮定します。フロントエンドは、ほとんどが角ばった、うなり声、お辞儀を使って書かれた単一ページのアプリケーションです。そして、私がバックエンドを持っていると仮定します。ほとんどの場合、ORMの上に置かれたREST APIであり、データベースからオブジェクトを保存/取得し、うなり声、エクスプレス、シークライズなどを使用します。 角度のあるアプリケーションは、ユーザーに表示されるすべての視覚的な処理を行いますが、バックエンドによって提供されるサービスを介したGUIとして機能します。 これらを2つの異なるコードベースに分離し、独立した開発、バージョン管理、継続的統合、開発へのプッシュなどを可能にすることが望ましいでしょう。 私の質問は、これをきれいに行うための方法は何ですか？フルスタックJavaScriptの推奨ベストプラクティスはありますか？ オプション＃1はモノリス、つまり「それらを分離しない」ようです。利点は、ビルドチェーンがシンプルであり、すべてが1か所にあることですが、多くの欠点があるようです。個別にバージョン管理するのが難しく、前面が壊れていると、展開できない背面を意味します。 オプション＃2は準モノリスのようです。フロントエンドビルドチェーンにより、多数のファイルがバックエンドに書き込まれます。distフロントエンド上のディレクトリをするとき、フロントエンドminifies、uglifiesなどので、基本的に、バックエンドには、いくつかのディレクトリを参照することになり、それがすべてを実行し、バックエンドに公開してしまいます。 オプション＃3は完全に分離されているようです。フロントエンドとバックエンドはそれぞれ異なるポートで独自のサーバーを実行し、完全に独立したプロジェクトです。欠点は、互いのポートについて知るように設定する必要があるようです。バックエンドは、フロントエンドからのCORSを許可する必要があり、フロントエンドは、それらのすべてのエンドポイントが予想される場所を知る必要があります。 オプション＃4は、docker-composeなどを使用して、すべてをまとめてリグすることです。 私は他のオプションがあると確信しています。推奨されるベストプラクティスは何ですか？

31 architecture  javascript  node.js  front-end  backend 

なぜ私たちがコーディングするのか疑問に思っていました virtual void MyFunction() = 0; ではなく pure virtual void MyFunction(); この決定の根拠についての参照はありますか？

31 c++  syntax  keywords  virtual-functions 

プログラミング言語とマークアップでは、コメントは一般にどのように扱われますか？私はいくつかのカスタムマークアップ言語のパーサーを書いており、最も驚きの少ない原則に従うことを望んでいるので、一般的な規則を決定しようとしています。 たとえば、トークン内に埋め込まれたコメントは、トークンと「干渉」する必要がありますか？一般的に、次のようなものです： Sys/* comment */tem.out.println() 有効ですか？ また、言語が改行に敏感であり、コメントが改行にまたがっている場合、改行を考慮するかどうか stuff stuff /* this is comment this is still comment */more stuff として扱われる stuff stuff more stuff または stuff stuff more stuff ？ 私はいくつかの特定の言語が何をするかを知っており、意見を求めていませんが、トークンと新しい行に関してマークアップによって一般的に期待される一般的なコンセンサスはありますか？ 私の特定のコンテキストは、Wikiのようなマークアップです。

31 parsing  comments 

プログラマーチームが80年代から90年代前半にソフトウェア開発をどのように管理していたかを知りたいです。すべてのソースコードは、全員が作業した1台のマシンに単純に保存されていたのか、ソースがフロッピーを介して手動でコピーされ、手動でマージされたのか、またはネットワーク（CVSなど）で実際にリビジョン管理システムを使用したのか今？または、おそらくオフラインCVSのようなものが使用されていましたか？ 今日では誰もがソース管理に依存しています。それは簡単です。しかし、80年代には、コンピューターネットワークのセットアップはそれほど簡単ではなく、ベストプラクティスのようなものがまだ発見されていました... 70年代と60年代のプログラミングはかなり異なっていたので、リビジョン管理は不要でした。しかし、80年代と90年代に人々がコードを書くためにコンピューターを使用し始め、アプリケーションのサイズと範囲が拡大し始めたので、当時は人々がどのように管理していたのでしょうか。 また、これはプラットフォーム間でどのように異なりますか？AppleとCommodore 64とAmigaとMS-DOSとWindowsとAtariの比較 注：私は主に、大きなUNIXマシンではなく、その日のマイクロコンピューターでのプログラミングについて話しています。

31 version-control  history 

非常に機密性の高いデータ（銀行/カードの詳細よりも機密性の高いデータ）を扱うWebサイト/モバイルアプリ/デスクトップアプリを構築しようとしているクライアントがいます。データは機密性が高いため、中央のデータベースに保存したくありませんが、アプリの同期が必要です（モバイルアプリにデータを追加して、デスクトップアプリと同じデータを参照してください）。 これを行うための良い、信頼できる方法を考えることはできませんし、1つあるかどうかはわかりません。それが私がここにいる理由です。誰も私がこのデータをどのように扱うことができるか知っていますか？ 私が考えていた解決策の1つは、アプリ間で何らかの形で同期するクライアント側のデータベースを各アプリに持たせることでした。

31 database  web-applications  database-design  synchronization 

Pythonで次のように書けば for i in a: i += 1 a変数iはの元の要素のコピーであることが判明したため、元のリストの要素は実際にはまったく影響しませんa。 元の要素を変更するには、 for index, i in enumerate(a): a[index] += 1 必要になります。 この振る舞いには本当に驚きました。これは非常に直感に反し、他の言語とは一見異なるように思われ、今日は長い間デバッグしなければならなかったコードにエラーが生じました。 以前にPythonチュートリアルを読んだことがあります。念のため、この本をもう一度チェックしましたが、この動作についてはまったく言及していません。 この設計の背後にある理由は何ですか？チュートリアルが読者が自然にそれを手に入れるべきであると信じるように、それは多くの言語の標準的な実践であると予想されますか？繰り返しで同じ動作が存在する他の言語は何ですか？将来的に注意する必要がありますか？

31 python  list  iterator 

パスワードの設定/リセットにも使用されるREST APIがあるとします。また、これがHTTPS接続で機能すると仮定します。そのパスワードを呼び出しパスに入れない正当な理由はありますか、BASE64でエンコードすることもできますか？ 例として、次のようなパスワードをリセットします。 http://www.example.com/user/joe/resetpassword/OLDPASSWD/NEWPASSWD BASE64は暗号化ではないことを理解していますが、この場合はショルダーサーフィンのパスワードを保護したいだけです。

31 rest  passwords 

友人のグループと私は過去少しの間プロジェクトに取り組んでおり、私たちは私たちの製品に固有のシナリオを表現する素晴らしいOOP方法を発明したかったのです。基本的に、私たちは東方スタイルの 弾丸地獄ゲームに取り組んでおり、私たちが思いつく可能性のある弾丸のあらゆる行動を簡単に表現できるシステムを作りたかったのです。 それがまさに私たちがやったことです。Unityのコンポーネントシステムのように、弾丸の動作を自由に弾丸インスタンスにアタッチできるさまざまなコンポーネントに分割できる、非常にエレガントなアーキテクチャを作成しました。うまく機能し、簡単に拡張可能で、柔軟性があり、すべてのベースをカバーしていましたが、わずかな問題がありました。 また、アプリケーションには大量の手続き生成が含まれます。つまり、弾丸の動作を手続き的に生成します。なぜこれが問題なのですか？さて、弾丸の動作を表現するためのOOPソリューションは、エレガントではありますが、人間なしで作業するのは少し複雑です。人間は、論理的で賢い問題の解決策を考えるのに十分賢いです。手続き型生成アルゴリズムはまだそれほどスマートではなく、OOPアーキテクチャを最大限に活用するAIを実装するのは難しいことがわかりました。確かに、それはアーキテクチャの欠陥であり、すべての状況で直感的ではないということです。 したがって、この問題を解決するために、さまざまなコンポーネントによって提供されるすべての動作を基本的にbulletクラスに押し込みました。これにより、想像できるすべてが、他の関連するコンポーネントインスタンスではなく、各bulletインスタンスで直接提供されます。これにより、手続き生成アルゴリズムの操作が少し簡単になりますが、現在の弾丸クラスは巨大な神オブジェクトです。これは、他のコードの5倍以上のコードを持つ、これまでのプログラムで簡単に最大のクラスです。維持するのも少し苦痛です。 別の問題で作業しやすくするために、クラスの1つが神のオブジェクトに変わっても大丈夫ですか？一般に、別の問題に対する簡単な解決策を認めている場合、コードにコードの匂いがすることは問題ありませんか？

31 object-oriented  architecture  code-smell