ソフトウェア工学

たとえばMember、lastChangePasswordTimeを持つクラスがあるとします。 class Member{ . . . constructor(){ this.lastChangePasswordTime=null, } } 一部のメンバーはパスワードを変更できないため、lastChangePasswordTimeには意味がない場合があります。 しかし、nullが悪である場合、値が有意に欠落する可能性がある場合は何を使用する必要がありますか？およびhttps://softwareengineering.stackexchange.com/a/12836/248528の場合、nullを使用して意味のない値を表すべきではありません。だから私はブールフラグを追加しようとします： class Member{ . . . constructor(){ this.isPasswordChanged=false, this.lastChangePasswordTime=null, } } しかし、私はそれがかなり時代遅れだと思います： isPasswordChangedがfalseの場合、lastChangePasswordTimeはnullでなければならず、lastChangePasswordTime == nullのチェックはisPasswordChangedのチェックとfalseがほぼ同じなので、lastChangePasswordTime == nullを直接チェックすることをお勧めします。 ここでロジックを変更すると、両方のフィールドの更新を忘れることがあります。 注：ユーザーがパスワードを変更すると、次のように時間を記録します。 this.lastChangePasswordTime=Date.now(); 追加のブールフィールドは、ここでnull参照よりも優れていますか？

39 null  boolean 

私たちの（かなり大きな）コードベースで、次のような継承ツリーを見つけました。 public class NamedEntity { public int Id { get; set; } public string Name { get; set; } } public class OrderDateInfo : NamedEntity { } 私が集めることができるものから、これは主にフロントエンドでのものをバインドするために使用されます。 私にとっては、genericに依存するのではなく、クラスに具体的な名前を付けるため、これは理にかなっていますNamedEntity。一方、追加のプロパティを持たないクラスは数多くあります。 このアプローチには欠点がありますか？

39 object-oriented-design  inheritance 

私は、多数のIoTデバイスのデータを処理するサーバーに常駐するREST APIを使用しています。 私のタスクは、APIを使用してサーバーにクエリを実行し、デバイスに関する特定のパフォーマンス情報を収集することです。 ある例では、利用可能なデバイスとそれに対応する識別子のリストを取得し、その後、それらの識別子（GUID）を使用してサーバーに詳細を照会します。 サーバーは500 Internal Server Error、これらのIDのいずれかでクエリを返しています。私のアプリケーションでは、例外がスローされ、エラーの詳細が表示されません。Postmanで応答をより詳しく調べると、サーバーが以下を含む本文でJSONを返していることがわかります。 errorMessage: "This ID does not exist"。 サーバーが最初にIDを提供したという事実は無視してください。これは開発者にとっては別の問題です。 REST API 500 Internal Server Errorは、クエリが存在しないオブジェクトを参照していることを報告するためにを返す必要がありますか？私の考えでは、HTTP応答コードは、APIの内部メカニズムではなく、REST呼び出しのステータスを厳密に参照する必要があります。私が期待する200 OK問題のAPIに独自のだろうエラーと説明を含む応答、と。 REST呼び出しがどのように構成されているかによって、期待に潜在的な違いがあることがわかりました。 これらの例を考慮してください： http://example.com/restapi/deviceinfo?id=123 http://example.com/restapi/device/123/info 前者の場合、デバイスIDはGET変数として渡されます。404または500は、パス（/restapi/deviceinfo）が見つからないか、サーバーエラーになったことを示します。 2番目の場合、デバイスIDはURLの一部です。私はをよりよく理解しますが、404 Not Foundそれでもパスのどの部分が変数とエンドポイントとして解釈されるかに基づいて議論することができます。

39 api-design  error-handling  http-response 

バグを見つけるための一般的なパターンは、このスクリプトに従います。 たとえば、出力がない、プログラムがハングしているなど、奇妙な点を観察してください。 ログまたはプログラム出力で関連するメッセージを見つけます。たとえば、「Fooが見つかりませんでした」。（以下は、これがバグを見つけるためのパスである場合にのみ関連します。スタックトレースまたは他のデバッグ情報がすぐに利用できる場合は、別の話です。） メッセージが印刷されるコードを見つけます。 Fooが画像を最初に入力する（または入力する必要のある）場所と、メッセージが印刷される場所の間でコードをデバッグします。 この3番目のステップでは、コード内に「Coo not find Foo」（またはテンプレート化された文字列Could not find {name}）が印刷される場所が多くあるため、デバッグプロセスが停止することがよくあります。実際、スペルミスが何度かあったとすると、実際の場所を見つけるのに非常に速くなりました。システム全体で、そして多くの場合世界中でメッセージが一意になり、関連する検索エンジンがすぐにヒットしました。 これから明らかな結論は、コード内でグローバルに一意のメッセージIDを使用し、メッセージ文字列の一部としてハードコーディングし、コードベース内に各IDが1つしか存在しないことを検証する必要があるということです。保守性の観点から、このコミュニティはこのアプローチの最も重要な長所と短所をどのように考えていますか？これをどのように実装するか、そうでなければ実装が必要にならないことを保証しますか？（ソフトウェアには常にバグがあると仮定して）

39 design-patterns  logging  error-messages 

私が仕事で取り組んでいる大規模なプロジェクトのライブラリを作成しているときに、トークンを電子メールアドレスに送信する必要があるという問題が発生し、その後コードに戻されてさらに使用できるようになりました。 私の同僚は（Pythonを使用してcode = input("Enter code: ")）STDINから読み、それをユーザーに渡すように言っていますが、私にはライブラリがサーバー上のバックグラウンドタスクで使用される可能性があるため（この場合は間違いなく）、これは悪い習慣のようです。 これがアンチパターンと見なされるかどうか疑問に思っていました。

39 programming-practices  libraries  anti-patterns 

それで、私は数年前からプログラミングをしていて、最近ReSharperをもっと使い始めました。ReSharperが私に常に示唆していることの1つは、「 'if'ステートメントを逆にして入れ子を減らす」ことです。 このコードがあるとしましょう： foreach (someObject in someObjectList) { if(someObject != null) { someOtherObject = someObject.SomeProperty; } } そして、ReSharperは私がこれを行うことを提案します： foreach (someObject in someObjectList) { if(someObject == null) continue; someOtherObject = someObject.SomeProperty; } ReSharperは、ネストがどれだけ進んでいるかに関係なく、IFを反転させることを常に提案するようです。この問題は、少なくともいくつかの状況でネストするのが好きだということです。私にとっては、特定の場所で何が起こっているのかを読み、理解するのが簡単に思えます。これは常にそうではありませんが、私は時々より快適なネストを感じます。 私の質問は、個人的な好みや読みやすさ以外に、ネストを減らす理由はありますか？パフォーマンスの違いや、私が気付いていない他の何かがありますか？

39 .net  coding-style  code-quality  clean-code  resharper 

for (Canvas canvas : list) { } NetBeansは、「機能的操作」を使用することを提案しています。 list.stream().forEach((canvas) -> { }); しかし、なぜこれが好ましいのでしょうか？どちらかといえば、読みやすく、理解しにくいです。を呼び出してからstream()、forEach()パラメーター付きのラムダ式を使用していますcanvas。for最初のスニペットのループよりも優れていることはわかりません。 明らかに、私は美学だけについて話している。おそらく、ここには技術的な利点がありますが、私には欠けています。それは何ですか？代わりに2番目の方法を使用する必要があるのはなぜですか？

39 java  lambda  java8  stream-processing 

私は次のことをどうしたらいいかわかりません： 独自のツール内の外部ツールからデータを取得します。このデータはオランダ語で書かれています。Javaコードを英語で書いています。次に、このオランダ語を英語に翻訳するか、オランダ語のままにする必要がありますか？たとえば、2つの部門があります：Bouw（英語の建設）とOnderhoud（英語の保守）。 作成するのは論理的ですか？ public enum Department { BOUW, ONDERHOUD } または： public enum Department { CONSTRUCTION, MAINTENANCE } あるいは： public enum Afdeling { BOUW, ONDERHOUD } （アフェデリングはオランダ語の学科です）

39 naming  translate 

動作を決定するためにブール値パラメーターを使用するのは間違っていますか？、ブールパラメータを使用して動作を決定することを避けることの重要性を知っています。たとえば： 元のバージョン public void setState(boolean flag){ if(flag){ a(); }else{ b(); } c(); } 新しいバージョン： public void setStateTrue(){ a(); c(); } public void setStateFalse(){ b(); c(); } しかし、動作の代わりにブール値パラメーターを使用して値を決定する場合はどうでしょうか？例えば： public void setHint(boolean isHintOn){ this.layer1.visible=isHintOn; this.layer2.visible=!isHintOn; this.layer3.visible=isHintOn; } 私はisHintOnフラグを削除し、2つの別個の関数を作成しようとしています。 public void setHintOn(){ this.layer1.visible=true; this.layer2.visible=false; this.layer3.visible=true; } public void setHintOff(){ this.layer1.visible=false; this.layer2.visible=true; this.layer3.visible=false; } …

39 design  object-oriented-design  coding-style  parameters  boolean 

ErlangとRubyの両方には、配列を平坦化するための関数が付属しています。言語に追加するためのこのようなシンプルで便利なツールのようです。これを行うことができます： >>> mess = [[1, [2]], 3, [[[4, 5]], 6]] >>> mess.flatten() [1, 2, 3, 4, 5, 6] あるいは： >>> import itertools >>> mess = [[1, [2]], 3, [[[4, 5]], 6]] >>> list(itertools.flatten(mess)) [1, 2, 3, 4, 5, 6] 代わりに、Pythonでは、配列をゼロから平坦化するための関数を記述するという問題を経験する必要があります。これはばかげているように見えますが、配列の平坦化はよくあることです。これは、2つの配列を連結するためのカスタム関数を作成する必要があるようなものです。 私はこれを無駄にグーグルで検索したので、ここで質問しています。Python 3のような成熟した言語に10万のさまざまなバッテリーが含まれているのに、配列を平坦化する簡単な方法が提供されない特別な理由はありますか？そのような機能を含めるという考え方は、ある時点で議論され、拒否されましたか？

39 python  python-3.x 

そのため、フランス語の動詞（データセットではなく、アルゴリズム）を活用するプログラムを作成しようとすると、ちょっとした問題に遭遇しました。 動詞を活用するアルゴリズムは、実際には動詞の17程度のケースではかなり単純であり、各ケースの特定のパターンで実行されます。したがって、これらの17のクラスの活用接尾辞は静的であり、（ほとんどの場合）すぐに変更されることはありません。例えば： // Verbs #1 : (model: "chanter") terminations = { ind_imp: ["ais", "ais", "ait", "ions", "iez", "aient"], ind_pre: ["e", "es", "e", "ons", "ez", "ent"], ind_fut: ["erai", "eras", "era", "erons", "erez", "eront"], participle: ["é", "ant"] }; これらは、フランス語の最も一般的な動詞クラスの接尾辞です。 他のクラスの動詞（不規則）がありますが、その活用も次の1世紀または2世紀の間は変化しないでしょう。これらは不規則であるため、パターンから確実に共役できないため、完全な共役を静的に含める必要があります（32の不規則もあります）。例えば： // "être": forms = { ind_imp: ["étais", "étais", "était", "étions", "étiez", "étaient"], …

39 design  strings 

ほとんどのプログラミング言語（動的および静的に型付けされた言語の両方）には、関数を宣言するための変数の宣言とは大きく異なる特別なキーワードおよび/または構文があります。関数は別の名前付きエンティティを宣言するのと同じように見えます： たとえば、Pythonの場合： x = 2 y = addOne(x) def addOne(number): return number + 1 何故なの： x = 2 y = addOne(x) addOne = (number) => return number + 1 同様に、Javaのような言語では： int x = 2; int y = addOne(x); int addOne(int x) { return x + 1; } 何故なの： int x …

39 language-design  scala  syntax  functions  grammar 

現在、当社は、ほとんどの場合、Ruby on Rails WebサーバーとJavaのキオスクシステムからC / C ++の組み込みデバイス（標準Webブラウザーのインターフェースを含む）までのさまざまなRESTクライアントで構成されるアプリケーションを開発しています。チームを拡大する必要があり、優秀なシニアプログラマを見つけることができなかったため、会社とともに成長するジュニアプログラマのトレーニングに力を入れることにしました。 すでにRubyとRailsの本をいくつか提供し、いくつかのおもちゃプログラムを作成するように依頼しましたが、現在のWebプログラミングの学習曲線がいかに急勾配であるかを理解しています。 15年前にプログラミングを始めたとき、DelphiとSource Safeのみを使用し、使用可能なソフトウェアを最初から作成することができました。どちらもシンプルなツールであり、環境の内部構造を掘り下げるのは簡単でした。ゆっくりとサードパーティのフレームワークの使用を開始し、CVS、SVN、そして最終的にGitに切り替えて、HTTP、JavaScript、CSS、RESTなどの今日のWebを構成する要素を学びました。今日、長年の経験の後でも、 Delphiについて過去に行ったようにRuby on Railsが内部でどのように機能するかについても重要であり、私にとって重要なことは、基本的な学習ブロックを使用しているツールに接続できることです。 私が雇っているプログラマーは、チームと統合して使用可能なものを作成するのに長い時間がかかるようです。なぜなら、単一のフレームワーク（レール）を使用することを学ぶことはたくさんあるからです：Ruby、HTML、CSS、JavaScript、 REST、テストケース、データベースアクセス（フレームワーク内に魔法のように構築されたSQLを使用！）、MVC、3つの異なるパッケージマネージャー（Ubuntuに最適、Rubyにgemとbundler）、ssh、git、Apache、Phusion Passengerのデプロイなど ジュニアプログラマーと直接やり取りする必要があるのは初めてなので、私は迷っています。非常に多くの選択肢がある場合に、Web開発の今日のベストプラクティスについてジュニアプログラマーを訓練する最良の方法は何ですか？

39 web-development  teamwork  ruby-on-rails  training  junior-programmer 

ここからsmurf命名という用語を取りました（21番）。トラブルに慣れていない人を救うために、Smurfの命名は、関連するクラス、変数などの束に共通の接頭辞を付ける行為であるため、「a SmurfAccountViewpass SmurfAccountDTOto to SmurfAccountController」などになります。 私がこれに対して一般的に聞いた解決策は、smurf名前空間を作成し、smurfプレフィックスを削除することです。これは一般的に私に役立ちましたが、私は2つの問題に直面しています。 私はConfigurationクラスを持つライブラリで作業しています。呼び出すこともできましたがWartmongerConfiguration、Wartmonger名前空間にあるため、単に呼び出されConfigurationます。同様Configurationに呼び出すことができるクラスもありますSmurfConfigurationが、それはSmurf名前空間にあるため、冗長になります。私のコードにSmurf.Configurationは横に表示される場所があり、Wartmonger.Configuration完全修飾名を入力するのは面倒で、コードが読みにくくなります。SmurfConfigurationand（ライブラリではなく私のコードである場合）を扱う方が良いでしょうWartmongerConfiguration。 私はServiceSmurf名前空間で呼び出されたクラスを呼び出しましたSmurfService。Smurfジョブを実行する複雑なSmurfライブラリの上にServiceあるファサードです。Smurf接頭辞がなければ非常に一般的なSmurfServiceため、より良い名前のようServiceです。それSmurfServiceはすでに一般的で役に立たない名前であり、スマーフを取り除くことはこれをより明白にしただけだと認めることができます。しかし、、などと命名することもできますがRunner、Launcherそれでも「気分が良くなる」SmurfLauncherのLauncherは、a が何をするのかわからないからですが、a SmurfLauncherが何をするのかは知っているからです。あなたは、a Smurf.Launcherがすることはa と同じように明白であるべきだと主張することができますSmurf.SmurfLauncher、しかし、 `Smurf.Launcherは、smurfsを起動するクラスではなく、セットアップに関連する何らかのクラスであることがわかりました。 これらのいずれかに対処するためのオープンな方法と閉じた方法があれば、それは素晴らしいことです。そうでない場合、彼らの迷惑を軽減するための一般的な慣行は何ですか？

39 naming  coding-standards 

私の学校のCSプログラムでは、オブジェクト指向プログラミングについては一切言及していません。そのため、私はそれを補足するために独力で読んでいます。具体的には、Bertrand MeyerによるObject Oriented Software Constructionです。 Meyerは、クラスが実装に関する可能な限り多くの情報を隠すべきであると繰り返し指摘していますが、これは理にかなっています。特に、彼は、属性（つまり、クラスの静的で計算されていないプロパティ）とルーチン（関数/プロシージャ呼び出しに対応するクラスのプロパティ）を互いに区別できないと繰り返し主張しています。 たとえば、クラスPersonに属性がある場合、定数属性として定義されている場所またはのようなものに内部的に対応するageかどうかを表記法から判断Person.ageすることは不可能であると主張します。これは私にとって理にかなっています。ただし、彼は次のように主張し続けています。return current_year - self.birth_datereturn self.ageself.age クラスの短い形式として知られるクラスの標準クライアントドキュメントは、特定の機能が属性または関数のどちらであるかを明らかにしないように考案されます。 つまり、クラスのドキュメントでさえ、「getter」が計算を実行するかどうかを指定することを避けるべきだと主張しています。 これ、私は従わない。この区別をユーザーに知らせることが重要になるのは、ドキュメントだけではありませんか？Personオブジェクトで満たされたデータベースを設計する場合Person.age、高価な呼び出しかどうかを知ることは重要ではないので、何らかのキャッシュを実装するかどうかを決定できますか？彼が言っていることを誤解していませんか、それとも彼はOOP設計哲学の特に極端な例ですか？

39 design  object-oriented  documentation  performance