ソフトウェア工学

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

4
パラメータ化されていないクエリにエラーを返させないのはなぜですか？
SQLインジェクションは非常に深刻なセキュリティの問題です。その大部分は間違いを犯しやすいためです。ユーザー入力を組み込んだクエリを作成するための明確で直感的な方法では脆弱性が残り、それを緩和する正しい方法ではパラメーター化について知る必要があります最初にクエリとSQLインジェクション。 これを修正する明白な方法は、明白な（しかし間違った）オプションをシャットダウンすることだと思われます：パラメータの代わりにハードコードされた値をWHERE句で使用する受信したクエリが素敵で説明的なものを返すようにデータベースエンジンを修正します代わりにパラメータを使用するよう指示するエラーメッセージ。これには、管理ツールからのアドホッククエリなどを簡単に実行できるように、オプトアウトオプションが必要になることは明らかですが、デフォルトで有効にする必要があります。 これを行うと、SQLインジェクションがほぼ一晩中停止しますが、私が知る限り、実際にこれを行うRDBMSはありません。そうでない理由はありますか？
22 security  sql  rdbms 
5
ごみ箱のユーザーを管理するにはどうすればよいですか？
できれば多くのユーザーがいるシステムを作成しました。私たちのデータベースは、需要の高いユーザー名を使用するゴミのユーザーでいっぱいになるのではないか、あるいは単に登録して二度と戻ってこないのではないかと心配しています。 私はこれが一般的であることを知っています、3つのGoogleアカウントを持っているので自分でこれを行いますが、1つだけを使用します。
8
チームでBuilderパターンの使用を促進するにはどうすればよいですか？
私たちのコードベースは、私のような古いプログラマーと新しいプログラマーであり、均一性のために行われた方法ですぐにそれを行うことを学びます。私たちはどこかから始めなければならないと考えて、私は自分自身にそれとしてデータホルダークラスをリファクタリングしました： セッターメソッドを削除し、すべてのフィールドを作成しましたfinal（final公理的には "良い"です）。結局のところ、セッターはコンストラクターでのみ使用されていたため、副作用はありませんでした。 Builderクラスを導入しました コンストラクター（そもそもリファクタリングを促したもの）が約3行のコードにわたるため、Builderクラスが必要でした。それは持っている多くのパラメータを。 運が良ければ、チームメイトが別のモジュールで作業していて、たまたまセッターが必要でした。なぜなら、必要な値がフローのさまざまなポイントで利用可能になったからです。したがって、コードは次のようになりました。 public void foo(Bar bar){ //do stuff bar.setA(stuff); //do more stuff bar.setB(moreStuff); } セッターを取り除くことでフィールドが不変のままになることを可能にするため（以前に不変性についての不満を聞いたことがあります）、またビルダーはオブジェクトの作成をトランザクション可能にするため、代わりにビルダーを使用する必要があると主張しました。次の擬似コードをスケッチしました。 public void foo(Bar bar){ try{ bar.setA(a); //enter exception-throwing stuff bar.setB(b); }catch(){} } その例外が発生すると、barデータが破損しますが、ビルダーでは回避できます。 public Bar foo(){ Builder builder=new Builder(); try{ builder.setA(a); //dangerous stuff; builder.setB(b); //more dangerous stuff builder.setC(c); return builder.build(); }catch(){} …
3
作成中は変更可能で、その後は変更できないメンバーを持つクラス
オブジェクトのコレクションを作成するアルゴリズムがあります。これらのオブジェクトは非常にわずかなものから開始されるため、作成中は変更可能ですが、アルゴリズム内のさまざまな場所にデータが入力されます。 アルゴリズムが完了した後、オブジェクトは決して変更されるべきではありませんが、ソフトウェアの他の部分によって消費されます。 これらのシナリオでは、以下に説明するように、クラスの2つのバージョンを使用することをお勧めしますか？ 可変のものはアルゴリズムによって作成され、その後 アルゴリズムが完了すると、データは不変オブジェクトにコピーされ、返されます。
22 c# 
8
膨大な数の失敗したテストに対処する方法は？[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 私はJavaで書かれた古いプロジェクトの開発に取り組んでいます。LOCは1,000万を超え、さらに悪いことに、4000を超える機能テストがあります。 Hudsonによってスケジュールされたテストは、大きなコード変更のたびに狂ったように失敗しています。テストの失敗の検証-製品またはテストに問題がある場合、数か月かかります。何をテストしているかわからないため、古いテストを削除することはできません！ 私たちにできることは？そのような量のレガシーテストをどのように進めるのですか？
2
機能の所有権は良い習慣ですか？
最近、私の会社では、1人の開発者が1つの機能に集中する（そして1人だけ）ことが推奨されています。それは、開発者を通常のチームルーチンとは別に設定し、他の責任（会議など）から解放するようなものを意味します。この人は、テクノロジに関して「唯一の」責任を負います。 記録のために、SAFe内でSCRUMを使用し、チームごとにフルタイムの開発者がいて、2つのチーム（AndroidとiOS）の間でQAと製品所有者を共有しています。 これは短期的に生産性を高めることに同意しますが、多くの理由でこれは悪い習慣であると感じています（そして大学で学んだと思います）。 コードレビューは価値を失います。 最小限の知識共有。 リスクの増加。 チームの柔軟性の喪失。 私は正しいですか、それとも悪い習慣ではありませんか？
4
gitの「リベースのゴールデンルール」はそれほど重要ですか？
最近、GITの機能ブランチのリベース戦略に絶対に反対する人々と議論しました。ローカルのプライベートブランチにのみリベースを使用することは受け入れられているパターンのようですが、この「リベースのゴールデンルール」と呼ばれるように、同じ機能とブランチで作業する複数の人がいる場合はリベースを使用しないでください：//www.atlassian.com/git/tutorials/merging-vs-rebasing/conceptual-overview） これにはコンセンサスがあることに驚いています。私は完全なリベース戦略で3年間働いたが、約20人の開発者が一緒に働いて、それがうまくいったことを推測した。 プロセスは基本的に次のとおりです。 機能ブランチを作成し、「myfeature」と呼び、origin / myfeatureにプッシュします。 他の人がそれをチェックアウトして作業するかもしれません マスターからリベースすることがあります： "myfeature"から、git rebase origin / master ; そして、はい、あなたはそれをプッシュする必要があります。 他の人がコミットをプッシュしたい場合はどうなりますか？彼らはそれをリベースするだけです：git rebase origin / myfeature。そのため、彼らは現在、早送りしており、無理なくプッシュすることができます。 尊重する唯一の原則は、機能ブランチが誰かによって所有されているということです。プッシュフォースできるのは所有者だけです。 だから、私は認める：プッシュ力があるとすぐに、エラーを起こすリスクがある。それは本当だ。しかし、エラーから回復する方法もたくさんあります。実際、3年間の開発では、強制的なミスはあまり見られませんでした。それが起こったとき、常に適切に回復する方法を見つけました。 それでは、なぜこの「リベースの黄金のルール」が広く受け入れられているのでしょうか？私がそれで逃した何か他のものがありますか？私はそれが最小限の組織を必要とすることを理解しています（すべての戦略は何らかの組織を必要とします）が、それは機能します。
22 git 
4
MVCが「懸念の分離」である場合、なぜRazor Syntaxが導入されたのですか？
私の質問は、Microsoftによって導入されたMVCデザインパターンとRazor Syntaxに関連しています。 MVCの設計パターンを学習している間、私はこの考えは「懸念の分離」として知られる原則に基づいていると言われました。 ただし、Razor構文を使用すると、ビューで C＃を直接使用できます。 これは懸念事項の交差点ではありませんか？
2
なぜScalaには戻りがあるが、壊れて継続しないのか
Scalaにはbreakor はありませんcontinue。そのため、ループの動作にはもう少し考えが必要です。 ループを早期に終了するには、末尾再帰、例外、またはscala.util.control.Breaks（例外を使用する）が必要です。 この理由は、のようにgoto、それらが流れを不明瞭にする流れの構造であり、より良く、驚くほどではない方法で達成できるということです。 しかし、それらと同じ引数を使用できるようですreturn。 なぜScalaはを意図的に省略breakしましたcontinueが、そうではなかったのreturnですか？
2
ASP.NET MVCアプリケーションは、Entity Frameworkをモデルとして直接使用する必要がありますか？
私はVisual Studio 2013（MVC 5）で最初のMVCアプリケーションを構築していますが、モデルをセットアップする最適な方法については少しわかりません。 既存のデータベースからコードファーストを使用して、エンティティフレームワークモデルを生成しました。私の最初の本能は、ビューで使用されるモデルとなるいくつかの中間クラスを作成し、それらのクラスをエンティティフレームワーククラスと連携させることでした。 中間クラスを書いているとき、EFクラスがたまにプライベートセッターで行ったり、あるデータ型から別のデータ型にキャストしたりすることの多くを再実装していることに気付きました。それは無駄のように思えた。 エンティティフレームワーククラスをMVCアプリケーションのモデルとして直接使用するという一般的な規則はありますか？または、これらの中間クラスを構築するのに欠けている利点がありますか？
5
実装に依存しないことは本当に価値がありますか？
現在、Tomcat、Spring 4、Spring Security、MySQL、およびJPA w / Hibernateを使用して取り組んでいるプロジェクトがあります。 私は、ORMプロバイダーの基盤となる実装をシームレスに、または少なくとも痛みを軽減するために、JPAを選択しました。これは、実装（JAX-RS）よりも仕様を精神的に使用しているということは、Java開発コミュニティのデフォルトの観点であると言えます。 これが本当にやりがいのある仕事であるかどうか興味があります。Hibernateを直接使用した場合、メインのJPA仕様の一部ではない機能を使用できるため、ある程度のパワーが得られると確信しています。 私の懸念の一部は、YAGNIのアイデアから来ています。私は本質的に特定のスタイルと方法でプログラミングしているため（Hibernateの代わりにJPAを使用）、将来のある時点でORM実装を交換できます。私は製品の寿命にわたってこれが起こることをひどく疑っているので、私は本質的に私はおそらく恩恵を決して享受しないものに努力しています。 あなたの考えは何ですか？JPAのようなものになると、「インターフェースへのプログラミング」は価値がありますか？実際に製品のORM実装全体を交換したことはありますか？とにかくJPAリークのようなものからの抽象化を完全に回避できたことがありますか？個人的には既にデータベーステーブルをクリーンアップするために単一のネイティブSQL呼び出しがあり、JPA仕様に組み込まれているもの（メソッドのプレフィックスの取得/設定、およびMEMBER OFの違い） / IN。これは、基礎となる実装に自分自身をバインドするだけで、回避する機会を与えてくれます。
3
継承のないオブジェクト指向言語はありますか？
今日のコードレビューの間に、私の同僚は何か面白いことを言った。 prototypeは、継承が必要な場合にのみ役立ちます- いつ継承が良いアイデアですか？ 私はこれについて考え、私は通常、継承を使用して、最初はひどく設計されたコードを回避することに気付きました。現代のオブジェクト指向スタイルは継承よりも合成を好みますが、これを心に留めて実際に強制した言語は知りません。 クラス、オブジェクト、メソッド、インターフェースなどを備えた汎用プログラミング言語はありますか？クラスベースの継承を禁止しますか？（このような考えが意味をなさない場合、なぜですか？）
2
Haskellでエラーを報告する最もクリーンな方法
私はHaskellの学習に取り組んでおり、私が書いた関数のエラーに対処する3つの異なる方法に出くわしました。 単にerror "Some error message."例外をスローするように書くことができます。 私は自分の関数を返すMaybe SomeTypeことができます。私は返すものを返すことができる場合とできない場合があります。 関数を返すEither String SomeTypeことができます。エラーメッセージまたは最初に返されるように求められたものを返すことができます。 私の質問は、どのエラー処理方法を使用すればよいのか、そしてその理由は何ですか？コンテキストに応じて異なる方法を使用する必要がありますか？ 私の現在の理解は： 純粋に機能的なコードの例外に対処するのは「困難」であり、Haskellでは、できる限り純粋に機能的なものに保ちたいと考えています。 Maybe SomeType関数が失敗または成功する場合（つまり、失敗する可能性のあるさまざまな方法がない場合）は、返すことが適切です。 Either String SomeType関数がさまざまな方法のいずれかで失敗する可能性がある場合、返すことは適切なことです。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.