ソフトウェア工学

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

4
メソッド名での接続詞の使用が悪い命名規則なのはなぜですか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 私のチームでは、数人のソフトウェアアーキテクトと緊密に連携しています。彼らは私たちのプロジェクトのすべての設計決定を承認し、コードレビューなどを行います。 私たちのプロジェクトは、主にSymfony 2フレームワークを使用してPHPで実装されたバックエンド機能で構成されています。そのため、構文的には、コード、命名規則、およびプロジェクト構造は、Javaがどのように見えるかとほぼ同じに見えます(Symfony 2はそのような構造を推奨しています)。Java固有の規則もこのケースに適用されるため(可能であれば)、これについて言及しています。 最近、彼らは私が非常に奇妙だと思うことを提案しました:すべてのメソッドはgetEntityOrNull、例えば、setValueOrExceptionなどの名前に接続詞を持つべきです このような命名規則は私にとって非常に間違っているように感じますが、具体的な議論や、これに特に挑戦するオンラインの記事/ページを思い付くことができません。 私が思いついた唯一のものは: そのような情報は次のように、メソッドの注釈中に存在すべきです@returnか@throws メソッド名に接続詞(「and」、「or」など)を使用すると、通常、単一責任原則が適切に尊重されないことが示唆されます。 この命名規則に対する他の具体的な議論は何ですか?

3
依存関係反転の原理と「実装ではなく、インターフェイスへのプログラム」
Dependency Inversion Principleが「実装ではなくインターフェイスへのプログラム」原則とどのように異なるかを理解しようとしています。 「実装ではなく、インターフェイスへのプログラム」の意味を理解しています。また、より柔軟で保守可能な設計を可能にする方法も理解しています。 しかし、依存関係反転の原則が「実装ではなくインターフェイスへのプログラム」の原則とどのように異なるかはわかりません。 Web上のいくつかの場所でDIPについて読みましたが、混乱は解消されませんでした。2つの原則がどのように異なるかはまだわかりません。ご協力いただきありがとうございます。

3
グローバルリクエストコンテキスト-アンチパターン?
今日、私の同僚とPython Webフレームワークとそれらについての印象について話していました。私は、Flaskがグローバルなリクエストを持っているのはひどく臭いで、アンチパターンだと彼に言った。 ドキュメントは、要求コンテキストについて言います: 対照的に、リクエストの処理中には、他にもいくつかのルールがあります。 要求がアクティブな間、コンテキストローカルオブジェクト(flask.requestなど)は現在の要求を指します。 コードはいつでもこれらのオブジェクトを保持できます。 アプリケーションをよりシンプルにするという、この設計決定の背後にある考え方を理解していると思います。Thread Localsの場合のように、これは単なる妥協です。 はい、通常、スレッドローカルを使用することはそれほど賢明な考えではありません。これらは、スレッドの概念に基づいていないサーバーに問題を引き起こし、大規模なアプリケーションの保守を困難にします。ただし、Flaskは大規模なアプリケーションや非同期サーバー向けに設計されたものではありません。Flaskは、従来のWebアプリケーションをすばやく簡単に記述できるようにしたいと考えています。 グローバルオブジェクトに現在の要求情報をパッチすることはアンチパターンですか? 静的コードアナライザーの観点ではグローバルステートであるため、そうではないと考えています。そして、プログラマーとしての私は、ドキュメントを注意深く読むことなく、それがどのように機能するかを理解しません。そして、これはテストに結果をもたらします。 ビューへの引数としてリクエストを渡すことは良い習慣ではありませんか?読みやすく、明示的で、デバッグが簡単だと思います。そして、グローバルな状態を回避します。


1
Java正規表現パターン-時定数またはインスタンスメンバーをコンパイルしますか?
現在、正規表現でマッチングを行っているシングルトンオブジェクトがいくつかあり、私Patternのsは次のように定義されています。 class Foobar { private final Pattern firstPattern = Pattern.compile("some regex"); private final Pattern secondPattern = Pattern.compile("some other regex"); // more Patterns, etc. private Foobar() {} public static Foobar create() { /* singleton stuff */ } } しかし、先日、これは悪いスタイルであり、Patternsは常にクラスレベルで定義されるべきであり、代わりにこのように見えると誰かに言われました: class Foobar { private static final Pattern FIRST_PATTERN = Pattern.compile("some regex"); private …

3
シニア開発者として採用されたばかりで、ジュニア開発者であったことはありません。[閉まっている]
閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか? 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 6年前に閉鎖されました。 私はしばらくの間フリーランサーとコーダーでしたが、最近、特定の分野が不足しているにもかかわらず、素敵なNYの会社でいくつかのレベルのインタビューを受けて採用されました。これは、企業が経験の少ない高齢者を採用するのに一般的ですか?特定の学習曲線を尊重するために数週間待つでしょうか? 会社で働くことについて何も知らないので、心配です。1週間後、私はまだソースの確認と調査を行っていますが、1週間の仕事の後、一部の同僚は私が遅いと考えているようです。私は数学、物理学、アルゴリズムが得意ですが、それでもこの会社で使用されているすべてのテンプレートについて学ぶ必要があります。 ここの誰もが彼のチームで経験の少ない上級メンバーをすでに受け取っていますか?これは受け入れられますか? それを心配するのをやめるために、上司とのミーティングを計画しています。良いアイデアのように聞こえますか? [編集] これらの答えをありがとう。私は間違いなく-新規-シニア開発者です。月曜日に自信を持ってオフィスに戻りました。良い給料を受け取った最初の数週間は、未知のテンプレート/ソースの前で少し無能だと感じるのが普通だと思います。

4
MVCでサービスレイヤーを使用する
コントローラーが太りすぎて、モデルのインスタンス化が増え始めると、サービスレイヤーを使用できます。 サービスクラス内にロジックをラップするだけの場合、1つまたは2つのメソッドで多数のサービスを取得します。これはコード臭のように感じます。これに関するベストプラクティスはありますか? サービスはモデルをインスタンス化できますか? サービスがモデルをインスタンス化する場合、サービスを単体テストすることはできません。それらは統合テストでのみカバーできますか?
12 mvc  services 

3
シングルアサートユニットテストはDRYの原則に違反しませんか?
ユニットテストを書くときはいつでも、テストが失敗したときにデバッグを容易にするために、テストごとに1つのアサートをしようと常に試みてきました。しかし、この規則に従うと、各テストで同じコードを常にコピーしているように感じます。テストを増やすことで、読み取りと保守に戻るのが難しくなります。 シングルアサーションテストはDRYに違反していますか? そして、メソッドごとに1つのテストを行うなど、良いバランスを見つけるために従うべき良いルールはありますか?* *私はおそらく、これに対するすべてのソリューションに適した1サイズではないことを認識していますが、これにアプローチする推奨方法はありますか?

2
機能的なコンピューターを構築できますか?
FPがやったように、結局、すべてのプログラムは構造化されています。つまり、どれだけ純粋に機能するかは問題ではありません。常にアセンブリに変換されるため、実際に実行されるのは命令、状態、ループです。FPをエミュレートしています。 ハードウェア初心者として、私の質問は次のとおりです。機能スタイルで実際に計算するコンピューターアーキテクチャを使用しないのはなぜですか。たとえば、コンピューターは「concat」、「map」、「reduce」などのプリミティブな「機能チップ」で構成できます。プログラムは、目的の結果を計算するために、これらのチップ間でデータを流す方法をコンピューターに伝えるだけです、連結言語など。 これは本当に意味をなさないが、私が考えていることを説明するかもしれない。

2
構造体にtypedefを使用する理由
C(ANSI、C99など)では、構造体は独自の名前空間に存在します。リンクリストの構造体は、次のようになります。 struct my_buffer_type { struct my_buffer_type * next; struct my_buffer_type * prev; void * data; }; しかし、ほとんどのCプログラマーが次のような構造体を自動的にtypdefすることは非常に自然に思えます typedef struct tag_buffer_type { struct tag_buffer_type * next; struct tag_buffer_type * prev; void * data; } my_buffer_type; そして、通常の型のように構造体を参照しget_next_element(my_buffer_type * ptr)ます。 今、私の質問は次のとおりです。これには特定の理由がありますか? ウィキペディアによると、http://en.wikipedia.org/wiki/Typedef#Usage_concerns 一部の人々は、typedefの広範な使用に反対しています。ほとんどの引数は、typedefが変数の実際のデータ型を単純に隠すという考えに基づいています。たとえば、LinuxカーネルハッカーでありドキュメンタリーであるGreg Kroah-Hartmanは、関数プロトタイプ宣言以外の目的での使用を推奨していません。彼は、この慣行はコードを不必要に難読化するだけでなく、プログラマーが単純に大きなタイプの構造であると誤って誤用する可能性もあると主張します。[4] typedefを使用すると、コードの保守が簡単になると主張する人もいます。K&Rは、typedefを使用する2つの理由があると述べています。まず、プログラムの移植性を高める手段を提供します。プログラムのソースファイル全体に現れるすべてのタイプを変更する代わりに、変更する必要があるtypedefステートメントは1つだけです。第二に、typedefは複雑な宣言を理解しやすくします。 場合によってはstructtypedefされた構造体を使用しない別の名前空間を使用することで十分なメリットがないのか、他にもCプログラミング文化がいくつかあるので(Windows CプログラミングにはLinux Cプログラミングとは異なる伝統があります)私が知らない伝統。 それから私は歴史的な考察に興味があります(前任者、Cの最初のバージョン)。

6
不変型の欠点は何ですか?
クラスのインスタンスが変更されることを期待されていないとき、私はますます不変の型を使用しているようです。より多くの作業が必要になります(以下の例を参照)が、マルチスレッド環境での型の使用が簡単になります。 同時に、可変性がだれにも利益をもたらさない場合であっても、他のアプリケーションで不変型が表示されることはほとんどありません。 質問:不変の型が他のアプリケーションで使用されることがほとんどないのはなぜですか? これは、不変型のコードを書くのが長いためです。 または、私は何かを見逃していて、不変の型を使用するときにいくつかの重要な欠点がありますか? 実生活からの例 WeatherそのようなRESTful APIから取得するとしましょう。 public Weather FindWeather(string city) { // TODO: Load the JSON response from the RESTful API and translate it into an instance // of the Weather class. } 一般的に表示されるのは次のとおりです(コードを短縮するために新しい行とコメントが削除されています)。 public sealed class Weather { public City CorrespondingCity { get; set; } public SkyState …
12 c#  immutability 

2
アンダースコアで変数/メンバーを開始すると、コンパイラが困惑することがありますか?
私は高校以来、このような変数を定義することを教えられてきました。 int _a; または int __a; アンダースコアで始まる変数を使用して一時変数に名前を付けるコンパイラーを最終的に困惑させるので、悪い慣習を検討する必要があります。 私の知る限り、これが名前の最後にアンダースコアを移動することを好む理由です: int a_; ただし、アンダースコア開始変数を使用するコードがたくさん見られます。そして、そのコードはVisual Studio 2010とg ++ 4.xの両方でかなりうまくビルドされます。 だから私は疑問に思う:これは最近の問題ではないのですか?最新のコンパイラは命名規則について賢いですか?

2
PHPでクラスのフィールドを宣言することは実際に有害ですか?
次のコードを考えてみましょう。セッターは、過去に何度か実際に行ったプログラミングエラーのために意図的に壊れています。 <?php class TestClass { private $testField; function setField($newVal) { $testField = $newVal; // deliberately broken; should be `$this->testField = $newVal` } function getField() { return $this->testField; } } $testInstance = new TestClass(); $testInstance->setField("Hello world!"); // Actually prints nothing; getField() returns null echo $testInstance->getField(); ?> $testFieldクラスのトップで宣言したという事実は、そのプログラミングエラーを隠すのに役立ちます。フィールドを宣言していなかった場合、このスクリプトを呼び出すとエラーログに次の警告に似たものが出力されます。これは、デバッグを支援するのに役立つ可能性があります。大規模で複雑な実世界のアプリケーション: PHP Notice:未定義のプロパティ:13行目の/var/www/test.phpのTestClass :: $ …
12 php 


5
自分のコンピューターがハーバードアーキテクチャかフォンノイマンアーキテクチャかをどのように確認できますか?
2つのアーキテクチャの違いは、ハーバードアーキテクチャの命令とデータの分離であることを理解しています。しかし、どのタイプのシステムを使用しているかをどのようにして知ることができますか?システムがフォン・ノイマンかハーバードかを決定するようなプログラムを書くことは可能ですか?別のアーキテクチャがありますか、またはこれらのアーキテクチャのみが知られていますか?

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