ソフトウェア工学

ユーザーがサーバーに1つのHTTPリクエストで複数のアクションを実行するように要求できるAPIを構築しています。結果は、アクションごとに1つのエントリを持つJSON配列として返されます。 これらの各アクションは、互いに独立して失敗または成功する場合があります。たとえば、最初のアクションが成功し、2番目のアクションへの入力のフォーマットが不適切で検証に失敗し、3番目のアクションが予期しないエラーを引き起こす場合があります。 アクションごとに1つのリクエストがある場合、ステータスコード200、422、および500をそれぞれ返します。しかし、リクエストが1つしかない場合、どのステータスコードを返す必要がありますか？ いくつかのオプション： 常に200を返し、より詳細な情報を本文に記載します。 リクエストに複数のアクションがある場合にのみ上記のルールに従うのでしょうか？ すべてのリクエストが成功した場合は200を返し、そうでない場合は500（または他のコード）を返しますか？ アクションごとに1つの要求を使用し、余分なオーバーヘッドを受け入れます。 まったく違うものですか？

72 api  http 

私はサーバーアプリケーションのマイクロサービスアーキテクチャについて多くのことを読んでおり、内部ネットワークの使用がモノリスアーキテクチャに比べてボトルネックや重大な欠点ではないことを疑問に思っていました。 正確さのために、2つの用語の解釈を以下に示します。 モノリスアーキテクチャ：すべての機能、データなどを処理する単一言語の1つのアプリケーション。ロードバランサーは、アプリケーションの1つのインスタンスを実行する複数のマシンにエンドユーザーからのリクエストを分散します。 マイクロサービスアーキテクチャ：機能とデータのごく一部を処理する多くのアプリケーション（マイクロサービス）。各マイクロサービスは、（同じマシン上のプロセス間通信または共有メモリとは対照的に）ネットワークを介してアクセスされる共通のAPIを公開します。API呼び出しは、主にサーバー上でページを生成するためにスティッチングされますが、おそらくこの作業の一部は、個々のマイクロサービスを照会するクライアントによって行われます。 単純な想像では、マイクロマシンアーキテクチャは、同じマシン（メモリとディスク）の高速リソースとは対照的に、低速ネットワークトラフィックを使用するようです。内部ネットワークを介したAPIクエリにより、全体の応答時間が遅くならないようにするにはどうすればよいですか？

72 architecture  server  microservices 

アプリケーションの構成には常にJSONファイルを使用しています。私は多くのJavaをコーディングしたときからそれらを使い始めましたが、現在は主にサーバーサイドとデータサイエンスのPython開発に取り組んでおり、JSONがこれ以上正しい方法であるかどうかはわかりません。 Celeryが実際のPythonファイルを構成に使用するのを見てきました。当初、私はそれについて懐疑的でした。しかし、構成に単純なPythonデータ構造を使用するという考えは、私に成長し始めています。いくつかの長所： データ構造は、通常コーディングしているものと同じです。そのため、心のフレームを変更する必要はありません。 私のIDE（PyCharm）は、構成とコードの関係を理解し​​ています。Ctrl+ Bを使用すると、構成とコードを簡単に切り替えることができます。 IMOの不要な厳密なJSONを使用する必要はありません。二重引用符、末尾のコンマ、コメントはありません。 作業中のアプリケーションでテスト構成を作成し、変換やJSON解析を行わずに簡単に構成ファイルに移植できます。 本当に必要な場合は、構成ファイルで非常に簡単なスクリプトを実行することができます。（これは非常に制限されるべきですが。） だから、私の質問は次のとおりです。切り替えた場合、どのように自分の足を撃ちますか？ 熟練していないエンドユーザーが構成ファイルを使用することはありません。構成ファイルへの変更はすべてGitに現在コミットされており、継続的な展開の一部としてサーバーにロールアウトされています。緊急事態があるか、開発中でない限り、手動で構成を変更することはありません。 （私はYAMLを検討しましたが、それについて何かが私をいらいらさせます。それで、今のところ、それはアメリカのテーブルから外れています。）

72 python  json  configuration  configuration-management  python-3.x 

Cは、世界で最も広く使用されている言語の1つです。既存のコードの大部分を占め、膨大な量の新しいコードに引き続き使用されます。ユーザーに愛されており、非常に広く移植されているため、Cを実行できることはプラットフォームの非公式な定義の多くに当てはまります。 それでは、すべてのコンパイラはどこにありますか？ デスクトップには、（現実的に）GCCとClangの2つがあります。数秒間考えてみれば、おそらくインテルも存在していることを覚えているでしょう。他の人はほんの一握りで、平均的な人が名前を付けるにはあまりにもあいまいで、ほとんどの場合、最近の言語バージョン（またはよく定義された言語サブセット、単に「サブセット」）をサポートすることをほとんど気にしません。このリストのメンバーの半分は歴史的な脚注です。残りのほとんどは非常に特殊化されており、実際には完全な言語を実装していません。実際にオープンソースであると思われるものはほとんどありません。 SchemeとForth-ファンに愛されている他の小さな言語-はおそらく実際のユーザーよりも多くのコンパイラを持っています。SMLのようなものでも、Cよりも「深刻な」実装を選択できます。一方、検証を目的とする新しい（未完成の）Cコンパイラの発表では、実際にかなり否定的な応答が見られ、ベテランの実装は、 C99。 どうして？Cの実装はとても難しいですか？C ++ではありません。ユーザーは、それがどの複雑なグループに属するかについて非常に歪んだ考えを持っているだけですか（つまり、実際にはSchemeよりもC ++に近いということですか）。

72 c  compiler  implementations 

私は通常、「Legacy Cod eで効果的に作業する」という本のアドバイスに従うようにしています。依存関係を壊し、コードの一部を@VisibleForTesting public staticメソッドと新しいクラスに移動して、コード（または少なくともその一部）をテスト可能にします。そして、新しい関数を変更または追加するときに何も壊さないことを確認するテストを作成します。 同僚は、私はこれをすべきではないと言っています。彼の推論： 元のコードはそもそも適切に動作しない可能性があります。また、開発者もテストを理解して変更する必要があるため、テストを作成すると将来の修正や変更が難しくなります。 何らかのロジック（〜12行、2〜3 if / elseブロックなど）を備えたGUIコードの場合、テストは簡単ではないので、テストを行う価値はありません。 同様の悪いパターンは、コードベースの他の部分にも存在する可能性があります（私はまだ見ていませんが、かなり新しいです）。1つの大きなリファクタリングですべてを簡単にクリーンアップできます。ロジックを抽出すると、この将来の可能性が損なわれる可能性があります。 完全なリファクタリングの時間がない場合、テスト可能な部分を抽出してテストを書くことを避けるべきですか？これに不利な点はありますか？

72 unit-testing  refactoring  legacy-code 

最初のコンパイラは1952年にグレース・ホッパーによって書かれ、Lispインタプリタは1958年にジョン・マッカーシーの学生スティーブ・ラッセルによって書かれました。コンパイラを書くことは、インタプリタよりもはるかに難しい問題のようです。もしそうなら、最初のコンパイラが最初のインタプリタの6年前に書かれたのはなぜですか？

72 history  compiler  interpreters 

私の同僚に言語の厳密さとパラダイムの違いを説明して、私は次のように断言しました： 動的言語やインタープリター言語などのトレラント言語は、プロトタイプや小規模プロジェクト、または中規模のWebアプリケーションに最適です。Node.jsでPythonやJavaScriptなどのエレガントな動的言語を選択する場合の利点は次のとおりです。 迅速な開発、 定型コードの削減、 Javaのような「企業言語」から逃げる若くて創造的なプログラマを引き付ける能力。 静的に型指定された/コンパイルされた言語は、ビジネスに不可欠なアプリや、中規模から大規模のアプリ向けのアプリなど、より厳密なものが必要なアプリケーションに最適です。 数十年にわたって開発された有名なパラダイムとパターン、 静的チェックの容易さ、 数十年の経験を持つ多くのプロの開発者を見つける能力。 Haskell、Adaなどの厳格な言語、またはC＃のコードコントラクトなどの手法は、ライフクリティカルなシステムや非常に安定していると予想されるシステムなど、柔軟性よりも安全性を重視するシステム（Has​​kellが非常に柔軟である場合でも）に適しています。利点は次のとおりです。 コンパイル時に可能な限り多くのバグをキャッチする機能、 静的チェックの容易さ、 正式な証明のしやすさ。 しかし、大企業が大規模プロジェクトに使用している言語と技術を見ると、私の主張は間違っているようです。たとえば、Pythonは、YouTubeやその他のGoogleアプリケーションなど、重要な量の厳密性を必要とする大規模システムに使用されています。 プロジェクトの規模と使用すべき言語/パラダイムの厳密さとの間にはまだ相関関係がありますか？ 考慮するのを忘れた3番目の要因はありますか？ 私はどこが間違っていますか？

72 programming-languages  dynamic-typing  language-choice  static-typing  static-analysis 

私は上司に教えられています（学校を卒業したばかりで、彼は少しプログラミング経験のある人が欲しかったので、彼はその会社が専門とするものについて私に訓練することを選択しました）、ASP.NET MVCアプリケーション、いくつかのHTMLとCSSでの作業を開始しました。彼が私に提供してくれたWebデザインには問題ありません（明確にすることなく理解するのは非常に簡単です）。 しかし、たとえば、彼は私にASP.NET MVCに関連するタスクを提供してくれました。しかし、彼は私に与えたコードでは何も説明しません。（私たちはVisual Studio 2013でソース管理を使用しています）、文字通り何百行ものコードであり、何をすべきかについての背景はありません。私が見ている種類のコードは、今まで見たことのないコードなので、試してみて理解するのは本当に難しいです。 私は彼にさらに質問をしようとしますが、彼は常に仕事をしています（彼自身の仕事です）。 それで、物事を把握するまで私を助けてくれる何か、上司に彼に与えられたコードにコメントを入れるように頼むにはどうすればいいですか？

72 comments 

私は3か月前にプロジェクトに取り組んでいましたが、突然別の緊急プロジェクトが現れ、注意を向けるように頼まれました。 明日から、古いプロジェクトに戻ります。私は自分が何をしていたかを正確に覚えていないことに気付きます。どこから始めればいいのかわかりません。 振り返るときはいつでも、離れた場所から数分以内にプロジェクトを文書化できます。ベストプラクティスはありますか？

72 project-management  documentation 

いくつかの異なるエディションを持つ製品があります。違いはわずかです。異なる文字列があり、一方のロジックはほとんど追加されておらず、もう一方のロジックはほとんど違いがありません。ソフトウェアの開発中は、ほとんどの変更を各エディションに追加する必要があります。ただし、そうでないものと異なる必要があるものがいくつかあります。release-editionAおよびrelease-editionB（..etc）ブランチがある場合、ブランチの有効な使用ですか？落とし穴はありますか？良い習慣？ 更新：皆さんの洞察に感謝します。多くの良い答えがここにあります。一般的なコンセンサスは、この目的のためにブランチを使用することは悪い考えだと思われます。不思議に思う人にとって、この問題に対する私の最終的な解決策は、構成として文字列を外部化し、プラグインまたはスクリプトとして異なるロジックを外部化することです。

72 git  branching 

多くの人がCode Completeを読む価値のある本だと言っているのを聞いたことがあります。残念ながら、私はとても忙しいので読む時間がありません。だから、この本の重要なポイントは何か教えてもらえますか？

72 code-complete 

私の理解では、このpartialキーワードはクラスを複数のソースファイルに分割することを許可するだけです。コードの整理以外にこれを行う理由はありますか？生成されたUIクラスで使用されているのを見ました。 キーワード全体を作成するのは不十分な理由のようです。クラスが複数のファイルを必要とするのに十分な大きさである場合、おそらくあまりにも多くのことを行っています。どこかで完了させる別のプログラマーのためにクラスを部分的に定義するために使用できると思いましたが、抽象クラスを作成する方が良いでしょう。

72 c#  design  language-design 

私はこの主題が少し物議を醸すことを知っています、そして、インターネットの周りに浮かんでいる多くの様々な記事/意見があります。残念ながら、それらのほとんどは、その人がNULLと空の文字列の違いを知らないことを前提としています。そのため、結合/集計を使用した驚くべき結果についてのストーリーを伝え、一般にもう少し高度なSQLレッスンを行います。これを行うことで、彼らは絶対に全体のポイントを見逃し、したがって私にとって役に立たない。したがって、この質問とすべての回答が主題を少し前進させることを願っています。 個人情報（名前、生年月日など）を含むテーブルがあり、列の1つがvarchar型の電子メールアドレスであるとします。何らかの理由で、一部の人々は電子メールアドレスを提供したくないかもしれません。このようなデータ（電子メールなし）をテーブルに挿入する場合、2つの選択肢があります。セルをNULLに設定するか、空の文字列（ ''）に設定します。あるソリューションを別のソリューションよりも選択することの技術的な影響をすべて把握しており、どちらのシナリオでも正しいSQLクエリを作成できると仮定します。問題は、両方の値が技術レベルで異なっていても、論理レベルでまったく同じであることです。NULLと ''を見た後、私はただ一つの結論に達しました：その男のメールアドレスがわかりません。どんなに頑張っても NULLまたは空の文字列を使用して電子メールを送信できなかったため、明らかにほとんどのSMTPサーバーは私のロジックに同意します。そのため、値がわからない場合はNULLを使用する傾向があり、空の文字列は悪いことだと考えます。 同僚との激しい議論の後、2つの質問がありました。 不明な値に空の文字列を使用すると、データベースが事実について「嘘をつく」ことになりますか？もっと正確に言うと、何が価値で何がそうでないのかというSQLの考えを使用して、結論が出るかもしれません。しかし、その後、電子メールを送信しようとすると、矛盾した結論に達します。いいえ、電子メールアドレスがないため、@！＃$データベースは嘘をついているはずです。 空の文字列 ''が重要な情報（値と値なし以外）の非常に優れたキャリアになる可能性のある論理的なシナリオはありますか？空の文字列を実際の値やNULLと一緒に使用するのが良い場合があると主張する多くの投稿を見てきましたが、これまでのところ（SQL / DB設計の観点から）論理的なシナリオは見ていません。 PS一部の人々は、個人的な好みの問題であると答えたいと思うでしょう。私は同意しません。私にとって、それは重要な結果を伴う設計上の決定です。だから、これについての意見がいくつかの論理的および/または技術的理由によって裏付けられている答えを見てみたい。

72 design  database  sql  strings  null 

私はすぐにプログラミングの大学の学位を取得しており、私のキャリアをさらに進めるための次のステップを模索しています。私が検討してきた1つのオプションは、私が働きたい開発分野での認定または一連の認定を取得することです。 これらの認定には時間とお金の価値がありますか？雇用主は彼らに多くの価値を置いていますか？

72 skills 

あなた自身の研究で（あなた自身で、またはクラスで）、最終的に、本当にポインターを理解した「あはは」の瞬間がありましたか？特に効果的と思われる初心者プログラマ向けの説明はありますか？ たとえば、初心者がCで最初にポインターに出会ったとき、コンパイルされるまで&sと*sを追加するだけです（私自身もそうでした）。おそらく、あなたやあなたの学生のためにポインタを「クリック」させたのは、写真、または非常にやる気のある例でした。それは何でしたか、それがうまくいかない前に何を試しましたか？トピックの前提条件（構造体、配列など）はありましたか？ つまり、&sおよびの意味を理解するために必要なのは*、自信を持ってそれらを使用できる場合ですか？構文と用語やユースケースを学ぶだけでは十分ではなく、ある時点でアイデアを内部化する必要があります。 更新：私はこれまでのところ答えが本当に好きです。どうぞ来てください。ここには多くの素晴らしい視点がありますが、概念を内面化した後、私たち自身にとって多くは良い説明/スローガンだと思います。私はそれがあなたに夜明けになったときの詳細なコンテキストと状況を探しています。 例えば： Cでは、ポインターを構文的に少ししか理解していませんでした。2人の友人がポインターを別の友人に説明しているのを聞きstructました。最初の友人は、それをどのように参照および変更する必要があるかについて話しましたが、それは私にぶつかった他の友人からの短いコメントでした：「より効率的です」。16バイトではなく4バイトを渡すことが、私が必要とする最後の概念的なシフトでした。

72 computer-science  pointers