タグ付けされた質問 「programming-practices」

プログラミングプラクティスは、ソフトウェアの開発で一般的に使用される、またはあまり使用されないプラクティスです。これには、アジャイル開発、かんばん、コーディングのショートカットなどが含まれます。

3
「高凝集」の意味は何ですか?
私はインターンとしてソフトウェア開発会社に最近入社した学生です。大学に戻って、私の教授の一人は、「低結合と高凝集」を達成するために努力しなければならないと言っていました。 低結合の意味を理解しています。これは、ある場所での変更が別の場所でコードを壊さないように、別々のコンポーネントのコードを別々に保持することを意味します。 しかし、高い凝集性が意味するもの。同じコンポーネントのさまざまな部分を互いにうまく統合することを意味する場合、それがどのように有利になるか理解できません。 凝集力が高いとはどういう意味ですか?その利点を理解するために例を説明できますか?


2
役割ベースのREST API?
異なるロールを持つ複数のユーザーが含まれるリソースにアクセスできるREST APIを構築しています。 スコープをシンプルに保つために、「student / teacher / class」ドメインを取り上げます。 GET /students アクセスするリソースです。 ユーザーには、学生や教師などの役割がある場合があります 生徒はクラスの生徒にのみアクセスできます。教師は、教えるクラスの生徒にアクセスできます。いくつかの用途は学生であり、他のクラスも教えます。彼らは彼らのクラスの生徒と彼らが教えるクラスの生徒にアクセスできなければなりません。 理想的には、これを2つの機能として実装します。ロールごとに1つ、ユーザーが複数のロールを持つ場合は「結合」します。 私の質問は、これを実装するためにどのパターンを使用すればよいですか? 外部的に ロールごとにAPIを分割する必要がありますか?GET /teacher/studentsそしてGET /student/studentsそれは右の私には思われません。 すべてを維持する私は1つのリソースです(推奨) 内部的に 内部的にどのように実装する必要がありますか? すべての方法は、BIGスイッチで開始する必要がありますか、役割ごとに行う必要がありますか 役割ごとにリポジトリを実装する必要がありますか? これを達成するのに役立つ設計パターンはありますか? 副次的なコメントとして:私はASP.NET Web APIとEntity Framework 6を使用していますが、概念的な実装には関係ありません。

9
一時的な回避策として、メソッド名にバグ番号を含めるのは悪い習慣だと考えられていますか?
シニアの同僚である同僚が、コードのレビューで私をブロックしているのは、欠陥###の回避策であるため、メソッドに 'PerformSqlClient216147Workaround'という名前を付けてほしいからです。今、私のメソッド名の提案は、PerformRightExpressionCastのようなもので、メソッドが実際に行うことを説明する傾向があります。彼の議論は「この方法はこの場合の回避策としてのみ使用され、他のどこにも使用されない」という線に沿っています。 一時的な回避策としてメソッド名にバグ番号を含めることは悪い習慣と見なされますか?

9
シングルトンパターンの代替
シングルトンパターンに関するさまざまな意見を読みました。一部の人は、すべてのコストで回避する必要があると主張し、他の人は、特定の状況で役立つ可能性があると主張しています。 シングルトンを使用する1つの状況は、特定のクラスAのオブジェクトを作成するためにファクトリー(たとえば、タイプFのオブジェクトf)が必要な場合です。ファクトリーは、いくつかの構成パラメーターを使用して一度作成され、その後、タイプAがインスタンス化されます。したがって、Aをインスタンス化するコードのすべての部分は、シングルトンfをフェッチし、新しいインスタンスを作成します。たとえば、 F& f = F::instance(); boost::shared_ptr<A> a = f.createA(); 一般的な私のシナリオは 最適化の理由(複数のファクトリオブジェクトは必要ありません)または共通の状態を共有するためにクラスのインスタンスが1つだけ必要です(たとえば、ファクトリはAのインスタンスをいくつ作成できるかを知っています) コードのさまざまな場所でFのこのインスタンスfにアクセスする方法が必要です。 このパターンが良いか悪いかについての議論には興味がありませんが、シングルトンの使用を避けたい場合、他にどのようなパターンを使用できますか? 私が持っていたアイデアは、(1)レジストリからファクトリオブジェクトを取得するか、(2)プログラムの起動中のある時点でファクトリを作成し、パラメータとしてファクトリを渡すことでした。 ソリューション(1)では、レジストリ自体がシングルトンであるため、シングルトンを使用しないという問題を工場からレジストリに移行しました。 (2)の場合、ファクトリオブジェクトの元となる初期ソース(オブジェクト)が必要なので、別のシングルトン(ファクトリインスタンスを提供するオブジェクト)に再びフォールバックするのではないかと心配しています。このシングルトンのチェーンをたどると、他のすべてのシングルトン を直接または間接的に管理する1つのシングルトン(アプリケーション全体)に問題を減らすことができます。 この最後のオプション(他のすべての一意のオブジェクトを作成し、他のすべてのシングルトンを適切な場所に注入する1つの初期シングルトンを使用)は、許容できる解決策でしょうか?これは、シングルトンを使用しないことを勧めるときに暗黙的に提案される解決策ですか、それとも他の解決策は何ですか? 編集 私の質問の要点は一部の人によって誤解されていると思うので、ここにいくつかの情報があります。ここで説明するように、シングルトンという言葉 は、(a)単一インスタンスオブジェクトを持つクラスと、(b)そのようなオブジェクトの作成とアクセスに使用されるデザインパターンを示すことができます。 物事を明確にするために、(a)には ユニークオブジェクト、(b)にはシングルトンパターンという用語を使用します。だから、私はシングルトンパターンと依存性注入が何であるかを知っています(最近、私は作業中のコードからシングルトンパターンのインスタンスを削除するためにDIを多用しています)。 私のポイントは、オブジェクトグラフ全体がmainメソッドのスタックにある単一のオブジェクトからインスタンス化されない限り、シングルトンパターンを通じていくつかの一意のオブジェクトに常にアクセスする必要があるということです。 私の質問は、完全なオブジェクトグラフの作成と配線をメインメソッドに依存させること(たとえば、パターン自体を使用しない強力なDIフレームワークを使用すること)が、シングルトンパターンを使用しない唯一のソリューションかどうか です。

11
一部のタスクで会社でサポートされていない言語を使用しても大丈夫ですか?
COBOL、VB6、C#、Javaなどの複数の言語をサポートする会社で働いています。 私はこれらの言語を主な仕事に使用しますが、Pythonでいくつかのマイナープログラム(スクリプトなど)をコーディングすることにしばしば気づきます。 たとえば、アナリストが複雑なCSVファイルを提供していくつかのDBテーブルにデータを入力するため、Pythonを使用して解析し、DBスクリプトを作成します。 どうしたの? 主な問題は、これらの迅速で汚いスクリプトのいくつかの部分が徐々に重要性を増していることです。 私の会社はPythonをサポートしていません バージョン管理されていません(別の方法でバックアップします) 私の同僚はPythonを知らない アナリストは、電子メールでそれらを参照し始めています(「エクスポートするスクリプトを起動します...」)ので、私が最初に思っていたよりも頻繁に必要になります。 これらのスクリプトは、メインプロジェクトの一部ではない単なるユーティリティであることを付け加える必要があります。単純なタスクをより短い時間で完了するのに役立ちます。私自身の小さなタスクのために、彼らは多くのことを助けます。 つまり、私が宝くじに当たって事故に遭った場合、同僚はこれらのスクリプトがなくてもプロジェクトを維持する必要があります。たとえば、手作業でCSVエラーを修正するのに時間がかかります。 これは一般的なシナリオですか?私は何か間違っていますか?私は何をすべきか?

2
コードの文書化の方法とソフトウェアの文書化が不十分な場合が多いのはなぜですか?
java apiなど、よく文書化されたコードの良い例があります。しかし、gitや企業の内部プロジェクトなどの公開プロジェクトのコードの多くは、文書化が不十分であり、初心者にはあまり適していません。 私のすべてのソフトウェア開発スティントでは、文書化が不十分なコードを処理する必要がありました。次のことに気づきました- コード内のコメントはほとんどまたはまったくありません。 メソッド名と変数名は自己記述的ではありません。 コードがシステムまたはビジネスプロセスにどのように適合するかについてのドキュメントはほとんどまたはまったくありません。 悪い開発者を雇うか、良い開発者を指導しない。シンプルでクリーンなコードを書くことはできません。したがって、開発者を含む誰にとってもコードを文書化することは困難または不可能です。 その結果、多くのコードを調べて、多くの人と話して物事を学ぶ必要がありました。これはみんなの時間を無駄にすると感じています。また、プロジェクトへの新規参入者向けのKT /ナレッジ転送セッションの必要性も生じます。 次の理由により、ドキュメントには値する注意が払われていないことを学びました。 怠惰。 開発者はコード以外は何もしません。 雇用保障。(コードを簡単に理解できる人がいない場合、簡単に交換できない可能性があります。) 期限が厳しいため、文書化する時間がほとんどありません。 ですから、会社やプロジェクトで優れた文書化の実践を奨励し、実施する方法があるのだろうかと思っています。プロジェクトの複雑さに関係なく、システムの適切なドキュメントとプロジェクトのコードを作成するために使用する戦略は何ですか?最小限のドキュメントが必要な場合やドキュメントが不要な場合の良い例はありますか? 私見、私は私達がプロジェクトが渡された後文書の検討があるべきであると感じます。単純で簡潔、説明的で使いやすいものでない場合、開発者または技術文書エンジニアがその責任を負い、修正する必要があります。私は、人々が最初の本のようにユーザーフレンドリーになることを望んではなく、ドキュメントの連を作ることを期待していませんが、何時間もの分析と無駄なKTセッションの必要性を排除すると期待しています。 この狂気を終わらせる、または軽減する方法はありますか?「ドキュメント駆動型開発」でしょうか?

2
循環的複雑度の範囲[閉じた]
循環的複雑度のカテゴリーは何ですか?例えば: 1-5:維持しやすい 6-10:難しい 11-15:非常に難しい 20+:近づきにくい 何年もの間、私は10が制限であるという仮定を行ってきました。そしてそれ以上のものは悪いです。私は解決策を分析しており、コードの品質を判断しようとしています。確かに循環的な複雑さだけが測定値ではありませんが、それは役立ちます。循環的複雑度が200以上のメソッドがあります。私はそれがひどいことを知っていますが、上の例のように、より低い範囲について知りたいです。 私はこれを見つけました: カーネギーメロンの前述の参照値は、循環的複雑度値の4つの大まかな範囲を定義しています。 1から10までの方法はシンプルで理解しやすいと考えられます 10から20の間の値は、より複雑なコードを示しますが、依然として理解しやすいかもしれません。ただし、コードが取り得る分岐の数が多いため、テストはより難しくなります。 20以上の値は、非常に多数の潜在的な実行パスを持つ典型的なコードであり、非常に困難かつ労力をかけてのみ完全に把握およびテストできます。 50を超えるなど、さらに高くなるメソッドは確かに維持できません ソリューションのコードメトリックを実行すると、25未満の場合に結果が緑色で表示されます。これには同意しませんが、他の入力を取得することを望んでいました。 サイクロマティックの複雑性について一般に受け入れられている範囲リストはありますか?

15
プログラマーは時々複雑なコードを意図的にオーバーしますか?[閉まっている]
現在のところ、この質問はQ&A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または詳細な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 6年前に閉鎖されました。 スタックオーバーフローでは、多くの場合、人々(特にプログラマー)は、元の問題よりもはるかに複雑なソリューションの問題の解決を過度に複雑にする傾向がありますか?私は決して専門家ではありませんが、最も簡単な解決策を試してみます(そして明らかにこれはどこでも機能しません)が、人々が思われる仕事で簡単な解決策を提案することでかなりの成功を収めましたもっと複雑なソリューションを見落とすことはありませんか? これはプログラマーにとっては普通のことなのでしょうか.....または、私は正しい見方で考えているだけではありませんか。

7
HTML5、ネイティブおよびハイブリッドモバイルアプリのアプローチの長所と短所は何ですか?
モバイルアプリケーションを開発したい。最近、Telerik Forumの記事を読みました。この記事では、3種類のモバイルアプリケーションを比較していますが、どちらを選択すればよいかわかりません。以下は、さまざまなモバイルデザインの選択の長所と短所を説明する画像です。 これらの設計の選択を決定するために、図にリストされている各アーキテクチャの選択の長所と短所をよりよく理解したいと思います。各アーキテクチャアプローチの長所と短所は何ですか?

12
業界には情熱的なプログラマーがいませんか?[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 私は、マネージャーがあなたがいるなら、 製品会社、それから一般的に製品を微調整し、時にはいくつかの機能を追加するのに時間を費やします、または サービス会社、それからあなたは繰り返しの事をし続けます 業界はニュースを作成し、難しい問題を解決するのが好きな人にとっては場所ではないと感じさせます。 業界は情熱的なプログラマーの場ではありませんか?これは国ごとに変わりますか? 更新して、本来の意味とは異なる方法で理解できるものを明確にします。 ここで調整するのは、クライアントが必要とする行数と列数を含むテーブルが製品にあることを確認することです。顧客向けにカスタマイズします。 ここでの新しい「機能」は新しい機能ではありません。美的レベルの変更のみ。そしてそれは時々です。 彼が繰り返し言った意味はわかりませんが。彼は、UIを何度も何度も作成しなければならないようなものでした。(しかし、繰り返しはありません。別のUIが必要な場合は、別の UIを設計する必要があります。古いものを使用できる場合は、とにかく多くのことを行う必要はありません。)

8
どのようにしてconstの正しい変換になりましたか?[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 閉じた3年前。 15年間のC ++の後、私はまだconstを使うことを愛することを学んでいません。私はそれが使用されていることを理解していますが、実際にconstが正しいことで私が直面していた問題を回避できる状況になったことはありません。 それでは、どのようにconstの利点を愛するようになりましたか?

7
実際の90のルール
コードの最初の90%が開発時間の最初の90%を占めています。コードの残りの10%は、開発時間の残りの90%を占めています。 —トムカーギル、ベル研究所 それは実際にはどういう意味ですか?プログラマーはかなりの量の仕事をしており、180%を自分たちから与えているのですか?

8
1日1回のユーザーアクション:24時間のリセットと真夜中のリセット[終了]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 12か月前に閉鎖されました。 ユーザーが1日に1回しかアクションを実行できない場合(たとえば、コンテストの無料チケットを取得する場合)、私の経験で出会った2つの可能性があります。 1)24時間リセット 1日目の午後11時45分にアクションを実行する場合、2日目の11時45分以降にのみアクションを実行できます。彼は2日目の11:44にそれを行うことができません。 2)ミッドナイトリセット(または任意の固定時間) ユーザーが1日目に何時にアクションを実行しても、深夜になり2日目が始まるとすぐに、再びアクションを実行できるようになります。 どちらもユーザーが1日に1つのアクションしか実行できないように制限しますが、ほとんどの場合、方法1に遭遇します。 最初に私は時間を待たなければなりません 長い期間にわたって2番目に、アクションを実行する私のタイムスタンプは、数秒または数分後にそのタイムスタンプで毎日正確にアクションを実行することができないため、ますます遅くなります。 私の意見では事前に述べたユーザーにとっての重大な不利益はありますが、方法1を好むという技術的な理由はありますか? 編集して、指定します。特に、現在の 24時間ごとに1つのフリースピンを獲得するTheory11のフリースピンイベントのように、24時間の実際のタイムギャップは明らかに必要ではない例について話しています。入賞時。

8
コードレビュー中にテストを書くことは有益ではないでしょうか?
私の同僚が、私が面白いと思うアイデアを思いつきました。 TDDを行わないと想定してレビューを行う人が、コードレビュー中にテストを書くことは有益ではないでしょうか。 この質問では、これは純粋にアカデミックなプロジェクトであり、命にかかわることはないと想定しています。さらに、チームは4人です。誰もが言語を知っており、使用されるすべてのツール/ライブラリ/フレームワークに精通しており、テストを書くことができます。したがって、基本的には、上級のフルスタックではない人が忍者のエンジニアをリードしていますが、まともなコーダーです。 私が見つけた長所: レビュー中にコードのより深い理解を促し、意味のあるテストを作成します。 次に、テスト対象のコードの作成者が行ったテストのコードレビューを追加できます。 短所: コードの作成とテストの間のフィードバックループが拡大します。 編集:私はそれが「通常の」Webアプリケーションではうまく動作しないことを知っています。私が念頭に置いていたのは、細部に注意を払う必要のある複雑で科学的なアルゴリズムを実装するコーナーケースです。独自のグラフライブラリ、NLPなどの実装のようなものを想定しましょう。作成しているコードがデータベースから分離されているなど、理解するのが非常に難しいのは、ソースを理解する必要のある他の人ではありませんコードを作成し、意味のあるテストを行い、プロセス全体を、アプリケーションをクラッシュさせず、最終的に結果をゴミにするようなそれほど明白ではないバグを起こしにくくしますか?

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