ソフトウェア工学

システム開発ライフサイクル内で働く専門家、学者、学生向けのQ&A

1
ポンプのプライミングとは何ですか?プライミング読み取りとも呼ばれます
私はこの表現とパターンを昔に教えられました。確かに、その名前は、水を汲み出す前に水で満たす必要があった古いポンプに由来しますが、誰が気にしますか?ここでコードについて話しています。 いくつかの本当に良い例と、パターンが達成することの説明は歓迎されます。このパターンは今日どのように考えられていますか? プライミングは時々、欠陥のあるループを動作させることができますが、DRYを犠牲にします。したがって、より良い設計への道の途中で一時停止することがあります。これはアンチパターンと見なされますか?代替手段はありますか?

2
最小驚きの原理(POLA)とインターフェース
四半世紀前に私がC ++を学んでいたとき、インターフェースは寛容であるべきだと教えられました。消費者は代わりにソースやドキュメントにアクセスできないかもしれないので、メソッドが呼び出される順番を気にしないでくださいこの。 しかし、私がジュニアプログラマーや上級開発者を指導したときはいつでも、彼らは驚いたことに反応し、これは本当にこれが本当のことなのか、それとも流行から外れたのかと疑問に思いました。 泥のように明確ですか? これらのメソッド(データファイルを作成するための)とのインターフェイスを検討してください。 OpenFile SetHeaderString WriteDataLine SetTrailerString CloseFile もちろん、これらを順番に実行することもできますが、ファイル名(考えてみてくださいa.out)や、含まれているヘッダーとトレーラーの文字列については気にしないと言って、単に呼び出すことができますAddDataLine。 それほど極端ではない例として、ヘッダーとトレーラーを省略する場合があります。 さらに、ファイルを開く前にヘッダーとトレーラーの文字列を設定することもできます。 これは認識されているインターフェイス設計の原則ですか、それとも名前が与えられる前のPOLAの方法ですか? NBは、このインターフェイスの詳細に動揺することはありません。これは、この質問のための単なる例です。

1
Math.minが1つの要素配列で機能する理由
MDNによると、Math.minは数字のみを受け入れ、引数の1つが数字でない場合、を返しNaNます。それは我々が複数の番号を持つ配列を渡す場合は、私たちが得ることは事実だNaN。このように、: Math.min([1,2])、私たちはただ1番号を持つ配列を使用する場合、Math.minこの例のように、アレイ内の番号を返しますMath.min([5])。この文書化されていない動作を見る理由は誰にもわかりますか?
17 javascript  math 

7
PerlのDBIx :: Classはいつ使用する必要がありますか?
DBIx :: Classは、DBIを介して接続できるデータベースへの人気のあるPerlインターフェースです。技術的な詳細については適切なドキュメントがありますが、その適切な使用に関する情報はほとんどありません(おそらくそれを望まない状況を含む)。 多くの場合、人々はデータベースに関係するすべてのものに使用すべきだと考えているため、再帰的にそれを利用します。しかし、私はそれが苦痛のポイントになるほど誤用されるのをよく見ました。コードとアーキテクチャのレビュー中の私の質問は、常に「Fooがあなたに与える利益は何ですか?」です。ほとんどの場合、これらの状況で私が見る開発者は、それに対する一貫した答えを形成できません。しかし、その後、彼らはしばしば単純なSQLを理解しません。 過去2か月間、「なぜDBIx :: Classを使用するのですか?」と人々に尋ねてきました。良い回答を1つだけ受け取りました(そして、その人はフォローアップの「いつそれを使わないのか」にも答えることができました)。リード開発者のPeter Rabbitsonは、FLOSS Weeklyのインタビューで答えに近づきましたが、インタビューの途中で少し埋もれてしまいました。 それでは、DBIx :: Classを使用することがプロジェクトに適しているかどうかをどのように判断できますか?
17 perl 

5
関数をパラメーターとして使用する場合、関数はすぐに不純ですか?
入力パラメーターの純度は実行時まで不明であるため、関数を入力パラメーターとして使用する場合、関数はすぐに不純であると見なされますか? 関連:関数が関数の外部で定義されているが、パラメーターとして渡されない純粋な関数を適用する場合、副作用がなく、出力のみが入力のみに依存するという基準を満たしている場合でも純粋ですか? コンテキストについては、JavaScriptで機能コードを作成しています。

8
最終的に一貫したサービスに対するテストを作成するにはどうすればよいですか?
Google App Engine Datastoreの上にサービスを構築しています。これは最終的に一貫したデータストアです。私のアプリケーションでは、これで問題ありません。 ただし、PUTオブジェクトのようなことをしてからオブジェクトを取得し、返されたオブジェクトのプロパティをチェックするテストを開発しています。残念ながら、データストアは最終的に一貫しているため、これらの簡単なテストは再現できません。 最終的に一貫したサービスをどのようにテストしますか?

3
小さなチームにバージョン管理分岐ポリシーを導入する
私は最近会社で始めた請負業者です。 チームは3人の開発者であり、2人の下級から中級レベルの開発者で構成されており、同じレベルの別の開発者が間もなく開始され、私(6年xp)です。両方の既存の開発者にとって、それは大学/大学からの最初の仕事であり、彼らは以前に自分の仕事を監督する上級開発者を持ったことがありません。 明示的なバージョン管理ポリシーはありません。開発者はすべての開発をトランクで行い、開発マシンから直接本番環境に展開します。既存のチームは分岐に精通していません。 これをすべて変更し、CI、TDDテスト/ステージング/プロダクションサーバーなどを導入し、これを補完するバージョン管理ポリシーを導入します。 ソース管理システムはTFSであり、これまで使用したことはありません。1つの巨大なリポジトリとして構成されています。 私はそれらのいくつかの指針を書き留めましたが、チームの経験を念頭に置いて、追加/修正する必要がある他のものはありますか? バージョン管理ポリシー 開発はトランクで行われます 変更に1週間以上かかると推定される場合は、ブランチで行う必要があります。トランクからブランチへの定期的なマージを行い、2つの同期がとれないようにします。 本番コード用に作成されたリリースブランチ。そのブランチには、安定したコードのみが含まれている必要があります。スプリントごとに1回、トランクから更新される1つのリリースブランチを作成するか、週ごとに個別のリリースブランチを作成することができます。 本番コードに影響する緊急のバグ修正を行う必要がある場合は、リリースブランチで行われ、トランクにマージされます。 1つのリリースブランチ戦略を採用する場合、トランクはスプリントの終わりに向かってスプリントごとに1回リリースブランチにマージされます。 リリース戦略ごとに個別のブランチを採用する場合、トランクはリリースブランチにマージされません。 一部のシナリオでは、分岐が多すぎる場合、異なる分岐でバグを2回修正する必要があります。短いスプリントをしている場合、これはあまり頻繁に起こるべきではありません。 3台のサーバーを使用する予定です。リポジトリ内の最新のコードを常に実行しているテスト環境。リリース候補コードおよびUATをステージング/テストするための最新のリリース候補を実行しているステージング環境、および運用環境。 私がこれを行うことを計画している理由は、これまでクライアントは内部ソフトウェアのみを実行していたためです。最新のプロジェクトは注目度の高いメディアクライアント向けであり、私は、チームが現在行っているものよりも専門的な開発モデルを採用する必要があると感じています。 たとえば、現時点では、ユーザーはバグレポートを使用してチームに電話をかけることができます。開発者はバグを見つけて修正し、自分のマシンで簡単な目玉テストを実行してから、実稼働環境に直接展開します。自動テストなどはありません。 後知恵では、機能ブランチはあまりにも遠いステップだと思うので、削除します。 したがって、本質的には、a)まったく分岐しない)b)リリースブランチとトランク、およびc)リリースとトランクごとのリリースブランチになります。 私は後者に傾いていました。私の最初の考えは、リリース候補と別々のサーバー(UAT / Production)で同時に稼働するリリースの両方を同時に持つことですが、事実上、トランクはいつでもリリース候補であるため、リリースは非常識に傾いています。私が考えたのは、利害関係者に開発コードを見せたくない場合は、別のリリース候補ブランチが必要になるかもしれないが、YAGNIとその他すべて.....

4
副作用を処理するためのIOモナドパターンの利点は純粋にアカデミックですか?
さらに別のFP +副作用の質問で申し訳ありませんが、私にこれに完全に答える既存の質問を見つけることができませんでした。 関数型プログラミングの私の(限られた)理解は、状態/副作用を最小限に抑え、ステートレスロジックから分離する必要があるということです。 また、これに対するHaskellのアプローチであるIOモナドを収集します。IOモナドは、プログラム自体のスコープ外であると見なされる、後で実行するために、ステートフルアクションをコンテナにラップすることによってこれを実現します。 私はこのパターンを理解しようとしていますが、実際にはPythonプロジェクトで使用するかどうかを決定するため、Haskell固有の仕様を避ける必要があります。 原油の着信。 私のプログラムがXMLファイルをJSONファイルに変換する場合: def main(): xml_data = read_file('input.xml') # impure json_data = convert(xml_data) # pure write_file('output.json', json_data) # impure これを行うためのIOモナドのアプローチは効果的ではありません: steps = list( read_file, convert, write_file, ) その後、実際にそれらのステップを呼び出すのではなく、インタープリターにそれを行わせることで、責任を放棄しますか? または別の言い方をすれば、それは次のように書くことです: def main(): # pure def inner(): # impure xml_data = read_file('input.xml') json_data = convert(xml_data) write_file('output.json', json_data) return …

2
フリーソフトウェアを別の言語に移植する場合のライセンス条項
既存のソフトウェアパッケージを別の言語に移植するというアイデアを模索しています。Apache License 2.0の下でリリースされており、無料で配布されています。ただし、ライブラリの使用とそのコピーの作成には大きな違いがあります。もちろん、私は完全な信用を与えて、それがどこから来たのかについて正直に言うでしょう。そして、私は確かにポートからお金を稼ぐつもりはなく、他のプロジェクトでそれを使うだけです。 もちろん、私はライセンスを読みました。 著作権ライセンスの付与。このライセンスの条件に従い、各コントリビューターは、派生的作品の複製、準備、公開、公演、サブライセンス、および著作物およびそのような派生著作物をソースまたはオブジェクト形式で配布します。 [...] 再配布。次の条件を満たす場合は、改変の有無にかかわらず、ソースまたはオブジェクトの形式で、作品またはその派生作品のコピーを複製および配布できます。 a。作品または派生作品のその他の受領者には、このライセンスのコピーを提供する必要があります。そして b。あなたは、変更されたファイルに、あなたがファイルを変更したことを示す顕著な通知を表示させる必要があります。そして c。配布する派生著作物のソース形式で、派生著作物のいかなる部分にも関係しない通知を除く、著作物のソース形式からのすべての著作権、特許、商標、および帰属通知を保持する必要があります。そして d。作品に配布の一部として「NOTICE」テキストファイルが含まれている場合、配布する派生作品には、そのようなNOTICEファイルに含まれる帰属通知の読み取り可能なコピーを含める必要があります[...] 修正に独自の著作権表示を追加することができ、修正の使用、複製、または配布のための追加または異なるライセンス条項を提供することができます。それ以外の場合、作品は本ライセンスに記載されている条件に準拠します。 私は、ライセンス、既存の著作権表示、帰属などのコピーを熱心に保持している限り、ポート(「派生著作物」として)は著者の許可の有無にかかわらず完全に許可されます。 しかし、だからといって、その意味をすべて理解しているわけではありません。たとえば、ポートは必ず元のライセンスと同じライセンスを共有する必要がありますか? 私はまだ作業を開始していませんし、パッケージの作者とはまだ連絡していません(ただしそうします)。多くの作業が無駄になるリスクがあるかどうかを確認したいと思います。また、APIのみに基づいてクリーンルーム実装を作成する必要があるかどうか、または既存のソースコード(まだ見ていない)に基づいて作業を行うことができるかどうかを知る必要もあります。

5
関数型プログラミング言語を命令型ではなく宣言型にするのはなぜですか?
関数型プログラミングの利点を説明する多くの記事で、C / C ++ / C#/ Javaなどの命令型言語とは異なる「宣言型言語」と呼ばれるHaskell、ML、Scala、Clojureなどの関数型プログラミング言語を見てきました。私の質問は、関数型プログラミング言語を命令型ではなく宣言型にするものです。 宣言型プログラミングと命令型プログラミングの違いを説明するよくある説明は、命令型プログラミングでは、宣言型言語の「何をすべきか」ではなく「何をするか」をコンピューターに伝えるというものです。この説明に関して私が抱えている問題は、すべてのプログラミング言語で常に両方を実行しているということです。最下位レベルのアセンブリに移動しても、コンピューターに「何をすべきか」と伝え、CPUに2つの数字を追加するように指示します。追加の実行方法については指示しません。Haskellのような高レベルの純粋な関数型言語であるスペクトルのもう一方の端に行くと、実際には特定のタスクを達成する方法をコンピューターに伝えていることになります。それはあなたのプログラムがコンピューターが単独で達成する方法を知らない特定のタスクを達成するための一連の命令です。Haskell、Clojureなどの言語はC / C ++ / C#/ Javaより明らかに高いレベルであり、遅延評価、不変データ構造、匿名関数、カリー化、永続データ構造などの機能を提供することを理解しています関数型プログラミングは可能かつ効率的ですが、宣言型言語として分類しません。 私にとって純粋な宣言型言語は、宣言のみで構成される言語であり、そのような言語の例はCSSです(はい、CSSは技術的にはプログラミング言語ではないことを知っています)。CSSには、ページのHTMLおよびJavascriptで使用されるスタイル宣言が含まれています。CSSは宣言以外に何もできません。クラス関数、つまり、パラメーターに基づいて表示するスタイルを決定する関数、CSSスクリプトを実行できない関数などは作成できません。プログラミング言語)。 更新: 私は最近Prologをいじくり回してきましたが、完全に宣言的なプログラミング言語だけではない場合、Prologは完全に宣言的な言語(少なくとも私の意見では)に最も近いプログラミング言語です。Prologでプログラミングを精緻化するには、ファクト(特定の入力に対してtrueを返す述語関数)またはルール(入力に基づいて特定の条件/パターンに対してtrueを返す述語関数)のいずれかを宣言することによって行われます。パターンマッチング手法を使用して定義されます。プロローグで何かを行うには、述語の1つ以上の入力を変数に置き換えてナレッジベースを照会し、プロローグが述語が成功する変数の値を見つけようとします。 私のポイントは、プロローグには命令的な指示はなく、基本的にはコンピューターに知っていることを伝え(宣言)、知識について尋ねる(問い合わせる)ことです。関数型プログラミング言語では、メモリの場所を直接操作したり、段階的に計算を書き込んだりしていなくても、値の取得、関数Xの呼び出し、それに1の追加などの指示を与えています。私は間違っているかもしれませんが、Haskell、ML、Scala、Clojureでのプログラミングがこの意味で宣言的であるとは言いません。上で説明した意味で、適切で、真で、純粋な関数型プログラミング宣言です。

4
単一責任原則は機能に適用できますか?
ロバートC.マーティンによると、SRPは次のよ​​うに述べています。 クラスが変更される理由は1つだけです。 ただし、彼の本Clean Code、第3章:関数では、次のコードブロックを示しています。 public Money calculatePay(Employee e) throws InvalidEmployeeType { switch (e.type) { case COMMISSIONED: return calculateCommissionedPay(e); case HOURLY: return calculateHourlyPay(e); case SALARIED: return calculateSalariedPay(e); default: throw new InvalidEmployeeType(e.type); } } そして次のように述べます: この機能にはいくつかの問題があります。まず、それは大きく、新しい従業員タイプが追加されると成長します。第二に、非常に明確に複数のことを行います。第三に、変更する理由は複数あるため、単一責任原則(SRP)に違反しています。[強調鉱山] まず、SRPはクラスに対して定義されていると思いましたが、関数にも適用できることがわかりました。第二に、この関数には複数の変更理由がありますか?従業員の変更が原因で変更が確認できます。

5
列挙型は脆弱なインターフェースを作成しますか?
以下の例を考えてください。ColorChoice列挙の変更は、すべてのIWindowColorサブクラスに影響します。 列挙型は脆弱なインターフェースを引き起こす傾向がありますか?多態的な柔軟性を可能にする列挙型よりも優れたものはありますか? enum class ColorChoice { Blue = 0, Red = 1 }; class IWindowColor { public: ColorChoice getColor() const=0; void setColor( const ColorChoice value )=0; }; 編集:私の例として色を使用して申し訳ありませんが、それは質問についてのものではありません。これは、ニシンを避け、柔軟性の意味についてより多くの情報を提供する別の例です。 enum class CharacterType { orc = 0, elf = 1 }; class ISomethingThatNeedsToKnowWhatTypeOfCharacter { public: CharacterType getCharacterType() const; void setCharacterType( const CharacterType …

2
イベントソーシングとREST
Event Sourcingの設計に出会い、RESTクライアントが必要なアプリケーションで使用したいと思います(正確にはRESTfulです)。ただし、RESTは非常にCRUDに似ており、イベントソーシングはタスクベースであるため、これらを接続することはできません。RESTサーバーへの要求に基づいてコマンドの作成をどのように設計できるのか疑問に思いました。この例を考えてみましょう: RESTを使用すると、Fileというリソースに新しい状態を設定できます。1つのリクエストで、新しいファイル名を送信したり、親フォルダーを変更したり、ファイルの所有者を変更したりできます。 イベントソーシングを使用できるようにサーバーを構築する方法。私はこれらの可能性について考えていました: フィールドが変更されたサーバ上で決定し、適切なコマンドを作成する(RenameFileCommand、MoveFileCommand、ChangeOwnerCommand、...)と個別にこれらを派遣。ただし、このセットアップでは、各コマンドが失敗し、他のリソースがトランザクションから除外され、リソースへの「アトミックな」変更から除外されます。 発送のみ一つのコマンド(UpdateFileCommand)およびコマンドハンドラでは、より正確に集計では、変更されたフィールドを決定し、代わりに個々のイベントを送信します(FileRenamedEvent、FileMovedEvent、OwnerChangedEvent、...) これはまったく好きではありません:サーバーへのリクエストでは、ヘッダーで使用するコマンドを指定します。UIはまだタスクベースです(ただし、通信はRESTを介して行われます)。ただし、REST通信のその他の使用(外部アプリなど)では失敗します。1つのリクエストで1つのフィールドのみを変更するようにバインドされているためです。また、UI、REST、およびESベースのバックエンドに非常に大きなカップリングをもたらします。 あなたはどちらを好むでしょうか、これを処理するより良い方法はありますか? サイドノート:イベントソースのためにJavaとAxon Frameworkで書かれたアプリ。

4
フロントエンド開発者は、バックエンド開発者向けにJSON形式を指定する必要がありますか?
私はプロジェクトでフロントエンドの役割を担っています。PHPがJavaScriptに返すJSONの正確な形式をバックエンドチームメイトに指定する必要がありますか? たとえば、ここで説明する形式と同様の形式を使用する必要があることを伝えます。 フロントエンドで使用するためのJSONを適切に構成する方法 または、自分の役割を可能な限り無菌状態に保ち、単にバックエンドインターフェイスから必要な入力と出力を言葉で説明する必要がありますか?(もちろん、これが発生した場合、異なるデータ構造形式を処理することは私の側でより困難になる可能性があります)

1
なぜPHPはそんなに嫌われているのですか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 最近、PHPがどれほどひどいものであるかについて、いくつかのジョークや漫画に出くわしました。 言語の完全な無知として、これはなぜですか?それは私自身の認識ですか、それともプログラミングコミュニティの全体的な一般的な感覚ですか?
17 php 

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.