ソフトウェア工学

Javaでは、変数（フィールド/ローカル/パラメーター）をとしてマークしてfinal、それらへの再割り当てを防ぐことができます。一部の属性（またはクラス全体）が不変であるべきかどうかをすばやく確認できるので、フィールドで非常に便利です。 一方、ローカルおよびパラメーターではあまり役に立たないことがわかり、通常final、それらが再割り当てされないようにマークすることは避けます（内部クラスで使用する必要がある場合は明らかな例外があります） 。しかし、最近では、できる限りfinalを使用するコードに出会いました。これは技術的に詳細な情報を提供していると思います。 プログラミングスタイルに自信がなくなったので、finalどこにでも適用することのその他の長所と短所は何か、最も一般的な業界スタイルは何か、そしてその理由は何だろう。

105 java  coding-style  final 

SquareがRectangleのタイプである場合、なぜSquareはRectangleを継承できないのですか？それとも、なぜそれが悪いデザインですか？ 私は人々が言うのを聞いたことがあります： SquareをRectangleから派生させた場合、Squareは予想される任意の場所で使用できるはずです。 ここで問題は何ですか？そして、なぜSquareはあなたが長方形を期待するどこでも使えるのでしょうか？Squareオブジェクトを作成し、SquareのSetWidthメソッドとSetHeightメソッドをオーバーライドする場合にのみ使用できるのは、なぜ問題があるのでしょうか？ Rectangle基本クラスにSetWidthメソッドとSetHeightメソッドがあり、Rectangle参照がSquareを指している場合、SetWidthとSetHeightは、一方を設定するともう一方がそれに合わせて変更されるため、意味がありません。この場合、SquareはRectangleによるLiskov Substitution Testに失敗し、RectangleからSquareを継承させるという抽象化は悪いものです。 誰かが上記の議論を説明できますか？繰り返しますが、SquareでSetWidthおよびSetHeightメソッドをオーバーライドすると、この問題は解決しませんか？ 私も聞いた/読んだ： 実際の問題は、長方形をモデリングするのではなく、「再整形可能な長方形」、つまり作成後に幅または高さを変更できる長方形をモデリングすることです（それでも同じオブジェクトと見なします）。このように長方形クラスを見ると、正方形は「再成形可能な長方形」ではないことが明らかです。なぜなら、正方形は形を変えられず、依然として正方形であるためです（一般的に）。数学的には、数学的文脈では可変性は意味をなさないため、問題は見られません。 ここでは、「サイズ変更可能」が正しい用語だと思います。長方形は「サイズ変更可能」であり、正方形も同様です。上記の議論に何か欠けていますか？正方形は、任意の長方形と同様にサイズ変更できます。

105 object-oriented-design  inheritance  abstraction  solid 

The Pragmatic Programmerの本を読んだ後、私が最もおもしろいと思った議論の1つは、「コードを書くコードを書く」ことでした。 ネット上でそれ以上の説明や記事を探してみましたが、このテーマに関するいくつかの良い記事を見つけましたが、特定のコード実装や良い例はまだ見つかりませんでした。 それはまだあまり一般的な議論ではなく、ドキュメントが欠けているか、多くの人々に受け入れられていないように感じます。それについてもっと知りたいです。 このテーマについてどう思いますか？生産性を本当に向上させるものですか？本、ブログ、スライドショーなどのテーマに関する良いリソースは何ですか？ いくつかのコード例は、その実装をよりよく理解できるようにするために大いに評価されるでしょう。 メタプログラミング、生成的プログラミング、コード生成など、関連するさまざまなプログラミングテクニックに関するwikiページを次に示します。

105 programming-practices  code-generation  meta-programming  automatic-programming  domain-specific-languages 

私の同僚が絶えず書いています： if (someBool == true) それは私を壁に押し上げます！私はそれを大事にするか、単に落とすべきですか？

105 programming-practices  coding-standards 

この用語は、ソフトウェアアーキテクチャ（「ドメインモデル」、「ドメインドリブンデザイン」など）のコンテキストでよく見られます。私はそれをグーグルで調べましたが、さまざまな定義がたくさんあります。それで、それは本当に何ですか？

104 domain-driven-design  terminology  domain-model  domain-objects 

次のコメンテーターは書いています： マイクロサービスは、組織の機能障害をコンパイル時の問題から実行時の問題に移行します。 このコメンテーターは、問題について次のように説明しています。 機能はバグではありません。実行時の問題=>製品の問題=>責任者への機能障害に関するより強力で迅速なフィードバック 今、私はそれを取得しmicroservicesあなたは： スループットのレイテンシーを潜在的に増加させます-これは生産および実行時の懸念です。 解析の実行時エラーが発生する可能性があるコード内の「ネットワークインターフェイス」の数を増やします。 潜在的に青緑の展開を行うことができます。これらは、インターフェイスの不一致によって保持される可能性があります（ネットワークインターフェイスを参照）。ただし、青緑の展開が機能する場合は、実行時の懸念が大きくなります。 私の質問は、マイクロサービスに移行すると実行時の問題が発生するということです。

104 microservices  runtime  compile-time 

私はいくつかの機能的なJavaScriptを実行しています。Tail-Call Optimizationが実装されたと思っていましたが、結局は間違っていました。したがって、私は自分でトランポリンを学ぶ必要がありました。ここや他の場所を少し読んだ後、基本を理解し、最初のトランポリンを作成することができました。 /*not the fanciest, it's just meant to reenforce that I know what I'm doing.*/ function loopy(x){ if (x<10000000){ return function(){ return loopy(x+1) } }else{ return x; } }; function trampoline(foo){ while(foo && typeof foo === 'function'){ foo = foo(); } return foo; /*I've seen trampolines without this, mine …

104 javascript  functional-programming 

モバイルアプリケーションとAPIの量は日々増加しているため、REST APIを保護するための最適なセキュリティソリューションを探しています。 私はさまざまな認証方法を試しましたが、まだいくつかの誤解があるため、より経験豊富な誰かのアドバイスが必要です。 このすべてを理解する方法を教えてください。何か間違って理解した場合は、お知らせください。 REST APIが一般にWEBと同様にステートレスである限り、各リクエスト（cookies、token ....）で認証データを送信する必要があります。ユーザーを認証するために広く使用されている3つのメカニズムを知っています HTTPSを使用したトークン。私はこのアプローチを何度も使用しましたが、HTTPSで十分です。ユーザーが正しいパスワードとログインを提供すると、応答としてトークンを受け取り、それを以降のリクエストに使用します。トークンはサーバーによって生成され、保存されます。たとえば、ユーザー情報が保存される別のテーブルまたは同じテーブルに保存されます。そのため、各リクエストサーバーで、ユーザーがトークンを持っているかどうかを確認します。トークンがデータベース内と同じである場合。すべてが非常に簡単です。 JWTトークン。このトークンは自己記述的であり、トークン自体に関するすべての必要な情報が含まれています。このトークンは秘密キーワードを使用してサーバーによって生成（署名）されるため、ユーザーは有効期限やその他の要求などを変更できません。これも明らかです。しかし、個人的には、トークンを無効にする方法の1つの大きな問題です。 OAuth 2.サーバーとクライアント間で直接通信が確立される場合、このアプローチを使用する必要がある理由がわかりません。私の知る限り、OAuthサーバーは、他のアプリケーションがパスワードとログインを保存せずにユーザー情報にアクセスできるように、制限されたスコープでトークンを発行するために使用されます。これは、ユーザーが何らかのページでサインアップしたい場合、ソーシャルネットワークにとって優れたソリューションです。サーバーは、たとえばtwitterやfacebookからユーザー情報を取得する許可を要求し、登録フィールドにユーザーデータなどを入力できます。 オンラインストアのモバイルクライアントを検討してください。 最初の質問は、最初のタイプのトークンよりもJWTを好むべきですか？モバイルクライアントでログイン/ログアウトユーザーが必要な場合、トークンをどこかに格納する必要があります。JWTの場合、ログアウト時にトークンを無効にする必要があります。トークンを無効化するには、無効なトークンリスト（ブラックリスト）を作成する方法があります。うーん。テーブル/ファイルのサイズは、トークンがテーブルに保存されてユーザーに関連付けられ、ログアウト時に削除された場合よりもはるかに大きくなります。 それでは、JWTトークンの利点は何ですか？ OAuthに関する2番目の質問は、サーバーと直接通信する場合に使用する必要がありますか？クライアントとサーバー間のもう1つのレイヤーの目的はトークンの発行のみですが、通信はoauthサーバーではなくメインサーバーと行われます。私が理解しているように、OAuthサーバーは、ユーザーの個人情報にアクセスするためのサードパーティアプリのアクセス許可（トークン）を付与する責任があります。しかし、私のモバイルクライアントアプリケーションはサードパーティではありません。

104 security  rest  api  oauth  https 

私が比較的大規模なプロジェクトを開発しているとします。すでにすべてのクラスと関数をDoxygenで文書化しましたが、各ソースコードファイルに「プログラマーのメモ」を置くことを考えていました。 これの背後にある考え方は、特定のクラスがどのように機能するかを素人の用語で説明することです（ほとんどのコメントがそうする理由だけでなく）。言い換えれば、仲間のプログラマーにクラスがどのように機能するかについての別の見方を提供することです。 例えば： /* * PROGRAMMER'S NOTES: * * As stated in the documentation, the GamepadManager class * reads joystick joystick input using SDL and 'parses' SDL events to * Qt signals. * * Most of the code here is about goofing around the joystick mappings. * We want to …

104 documentation  large-scale-project 

この基本的な知識に欠ける質問（主にStack Overflowについて）を見てきました。この質問のポイントは、それを求めている人々とそれを参照している人々に良い情報を提供することです。 Webプログラミングのコンテキストでは、サーバー側プログラミングとクライアント側プログラミングの違いは何ですか？どの言語がどの言語に属し、どの言語をいつ使用しますか？

104 web-development  server-side  client-side 

今日、同僚と興味深い議論をしました。 私は防御的なプログラマーです。「クラスは、クラスの外部から対話するときにオブジェクトが有効な状態になることを保証する必要がある」というルールを常に順守する必要があると思います。このルールの理由は、クラスがそのユーザーが誰であるかを知らず、違法な方法で対話された場合に予想通り失敗する必要があるためです。私の意見では、この規則はすべてのクラスに適用されます。 今日議論した特定の状況では、コンストラクターへの引数が正しいことを検証するコードを作成しました（たとえば、整数パラメーターは> 0でなければなりません）。前提条件が満たされない場合、例外がスローされます。一方、私の同僚は、ユニットテストがクラスの不正な使用を検出する必要があるため、このようなチェックは冗長であると考えています。さらに、彼は防御的なプログラミングの検証もユニットテストする必要があると考えているため、防御的なプログラミングは多くの作業を追加するため、TDDには最適ではありません。 TDDが防御的なプログラミングを置き換えることができるというのは本当ですか？結果としてパラメーターの検証（およびユーザー入力を意味するものではありません）は不要ですか？それとも、2つの手法は互いに補完するのでしょうか？

104 tdd  defensive-programming 

この質問はC＃言語に関するものですが、JavaやTypeScriptなどの他の言語をカバーするものと期待しています。 Microsoft は、.NETで非同期呼び出しを使用する場合のベストプラクティスを推奨しています。これらの推奨事項のうち、2つを選択しましょう。 TaskまたはTask <>を返すように非同期メソッドのシグネチャを変更します（TypeScriptでは、Promise <>になります） 非同期メソッドの名前をxxxAsync（）で終わるように変更します 現在、低レベルの同期コンポーネントを非同期コンポーネントに置き換えると、これはアプリケーションのフルスタックに影響します。async / awaitは「最後まで」使用した場合にのみプラスの影響を与えるため、アプリケーション内のすべてのレイヤーのシグネチャとメソッド名を変更する必要があることを意味します。 優れたアーキテクチャでは、各レイヤーの間に抽象化を配置することが多く、低レベルのコンポーネントを他のコンポーネントに置き換えることは、上位レベルのコンポーネントには見えません。C＃では、抽象化はインターフェイスの形式を取ります。新しい低レベルの非同期コンポーネントを導入する場合、コールスタック内の各インターフェイスを変更するか、新しいインターフェイスに置き換える必要があります。実装クラスで問題が解決される方法（非同期または同期）は、呼び出し元には隠されません（抽象化されません）。呼び出し元は、同期か非同期かを知る必要があります。 「良いアーキテクチャ」の原則と矛盾するベストプラクティスを非同期/待機しませんか？ 非同期依存関係に切り替えるときにスタック内で置き換えることができるように、各インターフェイス（IEnumerable、IDataAccessLayerなど）が非同期の対応物（IAsyncEnumerable、IAsyncDataAccessLayer）を必要とするということですか？ 問題をもう少し進めると、すべてのメソッドが非同期（Task <>またはPromise <>を返す）であると仮定し、メソッドが実際に非同期呼び出しを同期しないようにする方が簡単ではないでしょうか非同期？これは将来のプログラミング言語から期待されるものですか？

103 c#  architecture  async 

私は自分のコードで定期的にユニットテストを書く習慣を身につけようとしていますが、最初に読んだのはテスト可能なコードを書くことです。 この質問は、テスト可能なコードを作成するという固い原則に触れていますが、テストの作成をまったく計画せずに、それらの設計原則が有益である（少なくとも害がない）かどうかを知りたいです。明確にするために-テストを書くことの重要性を理解しています。これは、それらの有用性に関する質問ではありません。 私の混乱を説明するために、この質問に影響を与えた作品で、ライターは現在の時刻をチェックし、時刻に応じて値を返す関数の例を示します。作成者は、内部で使用するデータ（時間）を生成するため、テストが困難になるため、これを不良コードと指摘します。私にとっては、しかし、引数として時間を渡すことはやり過ぎのようです。ある時点で、値を初期化する必要がありますが、なぜ消費に最も近いのではありませんか？さらに、私の考えでは、このメソッドの目的は、現在の時刻に基づいて何らかの値を返すことであり、この目的を変更できるかどうかを示すパラメータにすることです。これと他の質問は、テスト可能なコードが「より良い」コードと同義語かどうか疑問に思います。 テストがない場合でも、テスト可能なコードを書くことはまだ良い習慣ですか？ テスト可能なコードは実際にはより安定していますか？重複として提案されています。ただし、その質問はコードの「安定性」に関するものですが、読みやすさ、パフォーマンス、結合など、他の理由でもコードが優れているかどうかについてより広くお尋ねしています。

103 design  unit-testing  testing  tdd 

言語を学ぶには、本を購入し、例に従ってください。可能な場合はいつでも練習を試すことができます。しかし、私が本当に探しているのは、一度学んだ言語を習得する方法です。 今、私は経験が1つの主要な要因であることを知っていますが、言語の内部を学ぶこと、基礎となる構造などはどうでしょうか。 この本を読んで、その本を読んで、このゲームとそのゲームを作るという記事があります。しかし、私にとってこれは言語をマスターすることを意味するものではありません。どんなに難しくても、他の人のコードを読んで理解できるようにしたい。関数をいつ使用するか、いつ使用するかなどを理解する リストは延々と続く可能性がありますが、私はポイントを作ったと信じています。:) 最後に、必要に応じて、例としてCを使用しますが、Cを例として使用した場合に最適です。

103 programming-languages 

ループに入れ子になったループから抜け出すために保存することを理解しています。このgotoステートメントは回避され、バグが発生しやすいプログラミングスタイルとして悪用され、決して使用されることはありません。 代替テキスト： 「ニール・スティーブンソンは自分のラベルに「dengo」という名前を付けるのはかわいいと思っている」 オリジナルのコミックを参照：http : //xkcd.com/292/ 私はこれを早く学んだからです。どんな種類のバグがgoto実際につながるのかについての洞察や経験は本当にありません。ここで何を話しているのか： 不安定？ 維持不能または読み取り不能なコード？ セキュリティの脆弱性？ 完全に何か他のもの？ 「goto」ステートメントは実際にどのようなバグにつながりますか？歴史的に重要な例はありますか？

103 coding-style  history  bug  bad-code  goto