ソフトウェア工学

C ++ 17には[[nodiscard]]属性が導入されており、プログラマーは、返されたオブジェクトが呼び出し元によって破棄された場合にコンパイラーが警告を生成する方法で関数をマークできます。同じ属性をクラスタイプ全体に追加できます。 私は元の提案でこの機能の動機について読んだことがあり、C ++ 20が属性をのような標準関数に追加することを知っていますstd::vector::empty。その名前は戻り値に関する明確な意味を伝えません。 これはクールで便利な機能です。実際、それはほとんど便利すぎるようです。私が読んだ[[nodiscard]]すべての場所で、人々はあなたがそれを選択したいくつかの関数または型に追加し、残りを忘れるかのように議論しています。しかし、特に新しいコードを書くとき、なぜ破棄不可能な値が特別な場合である必要がありますか？通常、破棄された戻り値はバグではなく、少なくともリソースの無駄ではありませんか？ そして、コンパイラができるだけ多くのエラーをキャッチする必要があるというのは、C ++自体の設計原則の1つではありませんか？ もしそうなら[[nodiscard]]、独自の非レガシーコードをほぼすべての非void関数とほぼすべてのクラスタイプに追加してみませんか？ 私は自分のコードでそれをやろうとしましたが、非常に冗長で、Javaのように感じ始めることを除いて、うまく動作します。意図をマークする他のいくつかの場合を除いて、デフォルトで破棄された戻り値について コンパイラーに警告させるほうがはるかに自然に思えます[*]。 標準提案、ブログエントリ、Stack Overflowの質問、またはインターネット上の他の場所では、この可能性に関する議論がゼロであるため、何かが足りないはずです。 新しいC ++コードでは、なぜそのような仕組みが意味をなさないのでしょうか？冗長性は、[[nodiscard]]ほとんどどこでも使用しない唯一の理由ですか？ [*]理論的には、[[maydiscard]]代わりに属性のようなものがありprintf、標準ライブラリの実装のように関数にさかのぼって追加することもできます。

70 c++ 

テスターが何をテストするかを知らず、製品所有者として行動する複数の（2-3）人と、承認基準なしで4-5人の開発者のチームでソフトウェアをどのように共同で開発しますか？ 私たちが持っているのは、いくつかのスクリーンショットといくつかの箇条書きを含む大ざっぱな「仕様」だけです。 簡単だと言われているので、これらは必要ありません。 どのように進むべきか迷っています。 追加情報 厳しい締め切りが与えられました。 顧客は社内にいるため、理論上は製品所有者がいますが、ソフトウェアをテストする少なくとも3人が作業項目を失敗する可能性があります。失敗するまで実際にテストしているもの。 製品の所有者は、質問に答えたり、フィードバックを提供したりすることはできません。定期的な会議や電話会議はありません。フィードバックには数日かかる場合があります。 完璧な仕様を作ることはできないことは理解できますが、各スプリントで実際に取り組んでいるものの受け入れ基準を持つことは「普通」だと思いました。

70 project-management 

C＃で書かれたプログラム内でJavaScriptやPython（または何か）を使用している人々の状況をいくつか聞いたことがあります。JavaScriptのような言語を使用してC＃プログラムで何かをする方が、C＃でそれを行うよりも優れているのはいつですか？

70 scripting 

プロジェクトやコードを測定するには、The Joel Testを使用できることを理解していますが、プログラマーの素晴らしさを測定およびフィルタリングできる単純な標準テスト（Joel Testなど）はありますか？ 私の計画は、より詳細なテストに進む前に、最初にこのテストをクイックフィルターとして使用することです。

70 interview 

私の幼少期には、MK-61 ソビエト電卓でプログラムを作成していました。4つの操作レジスタ（X、Y、Z、T）と15のストレージレジスタがありました。プログラムには105ステップあります。 思い出すと、次のようなコマンドがありました。 XおよびYレジスタを交換する シフトレジスタ（ZからT、YからZ、XからY） ストレージレジスタ（1..15）からXへのコピー Xからストレージレジスタへのコピー（1..15） X <0の場合、プログラムステップ##に進みます。 XおよびYの値を使用して操作（+、-、*、/）を実行し、結果をXに書き込む このコマンドはアセンブリ言語を設定していますか？このデバイスを使用して、アセンブリ言語の基本的なアイデアはありましたか？ 「キーストロークプログラミング」と呼ばれるものであることがわかりました。 おもしろい事実：1988年に、宇宙ミッションの軌道計算用のバックアップハードウェアとして、同様の計算機（これと似ていますが、エネルギーに依存しないメモリを使用）が使用されました。

70 programming-languages  assembly 

私はソフトウェア製品会社で働いています。当社の製品を実装する大企業のお客様がおり、サポートを提供しています。たとえば、不具合がある場合は、パッチなどを提供します。つまり、かなり典型的なセットアップです。 最近、製品のクラスター化された実装での同時データベースアクセスに関係するログファイルでお客様が発見した例外に関してチケットが発行され、私に割り当てられました。したがって、このバグの発生には、この顧客固有の構成が重要になる可能性があります。顧客から得たのは、ログファイルだけです。 私がチームに提案したアプローチは、顧客と同様の構成設定でバグを再現し、同等のログを取得することでした。ただし、バグを再現する必要はありません。過度に時間がかかり、VM上のサーバークラスターをシミュレートする必要があるため、彼らは私のアプローチに同意しません。私のチームは、単純に「コードをたどって」スレッドおよび/またはトランザクションに対して安全でないコードがどこにあるかを確認し、単純なローカル開発で動作する変更を行うことを提案します。バグの起源。 私にとっては、目に見える形の顕在化（実行時の再現）ではなく、抽象的な設計図（プログラムコード）で作業するのは難しいようです。そのため、一般的な質問をしたいと思いました。 すべての欠陥を再現し、それを診断および修正する前にデバッグすることを主張するのは合理的ですか？ または： 私が上級開発者であれば、アプリケーションを実行したり、さまざまなユースケースシナリオを実際にテストしたり、ステップスルーしたりするのではなく、マルチスレッドコードを読んで、すべてのユースケースシナリオでそれが何をするかについての心構図を作成できるはずです行ごとにコード？または、私はそのような作業環境を要求するのに貧弱な開発者ですか？ sissisのデバッグはありますか？ 私の意見では、インシデントチケットに対応して提出された修正は、可能な限り元の環境に近くなるようにシミュレートされた環境でテストする必要があります。それが本当に問題を解決することを他にどのように知ることができますか？それは、エアバッグが実際に機能することを実証するためにダミーで衝突試験することなく、車両の新しいモデルをリリースするようなものです。 最後になりますが、私に同意する場合： 私のアプローチが合理的で、保守的で、より防弾であることをチームに納得させるために、チームとどのように話し合うべきですか？

70 testing  debugging  bug  technical-support  defect 

私はいつもこれを疑問に思っており、おそらくプログラミング言語に関する良い歴史のレッスンが必要です。しかし、最近のほとんどのコンパイラはCで作成されているため、最初のコンパイラ（C以前の別名）はどのように作成されましたか？ とはいえ、最初のアセンブリ言語がどのように行われたかはまだわかりません、アセンブリ言語とは何ですか？コマンド（などmov R21）または同等のバイナリに設定されたw / e？

70 programming-languages  history  assembly 

同僚のコードを読んだところ、彼はさまざまな例外を頻繁にキャッチし、代わりに常に「RuntimeException」をスローすることがわかりました。これは非常に悪い習慣だといつも思っていました。私が間違っている？

70 java  exceptions  exception-handling 

私たちのコードは悪いです。常に悪いとは考えられていなかったかもしれませんが、悪いことであり、下り坂になっています。私は大学を卒業してから1年も経たないうちに、コードの多くの部分が信じられないほど困惑しました。最初は、新しい人として、コードベースについてもう少し学ぶまで口を閉ざしておくべきだと考えましたが、それが悪いことを知っていることはたくさんありました。 ハイライトのいくつか： まだフレームを使用しています（クエリ文字列から何かを取得してみてください、ほとんど不可能です） VBScript ソースセーフ .NETを「使用」します。つまり、COM DLLを呼び出す.netラッパーがあり、簡単にデバッグすることはほとんど不可能です。 すべてが基本的に1つの巨大な機能です コードは保守できません。各ページには、新しいページが作成されるたびに作成される複数のファイルがあります。メインページは基本的にResponse.Write（）を何回も実行してHTMLをレンダリングします（runat = "server"？方法はありません）。その後、クライアント側（VBScript）に多くのロジックがあり、最終的にページはそれ自体に送信し（多くの場合、多くの情報を非表示フィールドに保存します）、そこで保存などの処理を実行できる処理ページに投稿しますデータベースへのデータ。 私たちが得た仕様は笑えます。多くの場合、フィールドYまたはフィールドZを選択するタイミングを指定せずに、「フィールドYまたはフィールドZのいずれかを使用してフィールドXを自動入力」などを呼び出します。 これのいくつかはソフトウェア会社に雇われていないことの結果だと確信していますが、ソフトウェアを書いている人は少なくともコードの品質に注意を払うべきだと思います。期限が迫っているので、何かがすぐに行われるということを考えたとしても、想像もできません。しかし、私たちは悪いコードを書き続け、悪い慣行を使い続けています。 私に何ができる？どうすればこれらの問題を持ち出すことができますか？私のチームの75％が私に同意し、過去にこれらの問題を提起しましたが、何も変わりません。

70 language-agnostic  ethics 

オブジェクト指向コードに使用される「デザインパターン」という用語を聞いたことがあるだけで、GoFパターンにはOOPデザインパターンのみが含まれていますが、デザインパターンは一般的に発生するプログラミング問題のエレガントなソリューションです。OOPに限定する必要があると言っていることは何もありませんが、ありますか？ オブジェクト指向プログラミングの領域外のデザインパターンの例をいくつか見たいと思います。あなたがいずれかを持っている？そのようなものさえ存在しますか（GoF本のような本は、必ずしも書かれている必要はなく、単に使用されるべきです;それで十分です）？ それらは特定のプログラミング言語に固有のものである場合がありますが、オブジェクト指向以外のパラダイムの一般的な（パラダイムレベル）パターンが優先されます。

70 design-patterns 

このシナリオを見てください： プログラマーが言語を作成して問題を解決します。 その後、この言語をリリースして、他の人がそのような問題を解決できるようにします。 別のプログラマは、実際にはいくつかの異なるカテゴリの問題の方がはるかに優れていることを発見しました。 この新しいアプリケーションのおかげで、言語は主にそのアプリケーションで人気になります。 これが実際に発生している例はありますか？ 別の言い方をすれば、言語の本来の目的は、実際にどのように使用されるのか、それが一般的になるのかということと関係がありますか？言語に宣伝された目的があることさえ重要ですか？

70 programming-languages  history 

「抽象クラス」と「インターフェース」は類似した概念であり、インターフェースはより抽象的な概念です。1つの差別化要因は、抽象クラスが必要なときに派生クラスのメソッド実装を提供することです。ただし、C＃では、この差別化要因は、インターフェイスメソッドの実装を提供できる拡張メソッドの最近の導入によって削減されました。別の差別化要因は、クラスが1つの抽象クラスのみを継承できる（つまり、多重継承がない）が、複数のインターフェイスを実装できることです。これにより、インターフェイスの制限が緩和され、柔軟性が高まります。それでは、C＃では、拡張メソッドを備えたインターフェイスの代わりに抽象クラスをいつ使用すべきでしょうか？ インターフェイス+拡張メソッドモデルの注目すべき例はLINQです。ここではIEnumerable、多数の拡張メソッドを介して実装されるすべてのタイプに対してクエリ機能が提供されます。

70 c#  design  interfaces  inheritance  abstract-class 

私は約2年間underscore_caseを使用してきましたが、最近新しいジョブのためにcamelCaseに切り替えました（後のジョブを約2か月使用しており、underscore_caseは多くのプログラマーが関与する大規模プロジェクトに適していると思いますが、主にコードが読みやすいためです）。 現在、職場の全員がキャメルケースを使用しています（コードがよりエレガントに見えるためです）。 camelCaseまたはunderscore_caseについてどう思いますか ps私の悪い英語を許してください 編集 最初にいくつかの更新： 使用されているプラ​​ットフォームはPHPです（ただし、厳密なPHPプラットフォーム関連の回答は期待していませんが、誰が使用するのが最善であるかについての考えを共有することができます、それが私が最初にここに来た理由です） 私はキャメルケースをチームの他のエブリバディと同じように使用します（ほとんどの人が推奨するように） キャメルケースも推奨するZend Frameworkを使用します いくつかの例（PHPに関連）： Codeigniterフレームワークはunderscore_caseを推奨しており、正直なところコードは読みやすいです。 ZFはcamelCaseを推奨しており、ZFコードをフォローするのが少し難しいと思うのは私だけではありません。 だから私の質問は言い換えられます： プラットフォームにFooがあり、命名規則が推奨されておらず、チームリーダーが選択する場合を考えてみましょう。あなたはそのチームリーダーです。なぜcamelCaseを選ぶのですか、それともunderscore_caseを選ぶのですか？ ps今までのところ、迅速な回答をありがとう

70 naming 

優秀なプログラマーのほとんどは、テクノロジーについて学ぶために大きな本を読む習慣があります。 技術に対する真の関心は別として、技術書を読むには本当に何が必要ですか？ これらの本を読む能力を向上させるにはどうすればよいですか？

70 learning 

私は常に、ビジネスロジックはコントローラー内になければならず、コントローラーは「中間」部分であるため、静的のままであり、モデル/ビューはインターフェースを介してカプセル化する必要があると考えていました。そうすれば、他に何も影響を与えずにビジネスロジックを変更し、複数のモデル（データベース/ストレージのタイプごとに1つ）および多数のビュー（たとえば、異なるプラットフォーム用）をプログラムできます。 この質問で、ビジネスロジックを常にモデルに配置する必要があり、コントローラーがビューと深く関係していることを読みました。 私にとって、それは本当に意味をなさないし、別のデータベース/ストレージのタイプをサポートする手段を持ちたいと思うたびに、ビジネスロジックを含むモデル全体を書き直さなければならないことを意味します。 また、別のビューが必要な場合は、ビューとコントローラーの両方を書き換える必要があります。 誰かがそれがなぜであるか、または私がどこかで間違った場合に説明してもらえますか？

70 mvc  business-logic