タグ付けされた質問 「code-quality」

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 私はgithubプロジェクトをブラウズしていて、1万行を超えるこのモジュールを見つけました。 単一のモジュールにそのようなコードを含めることは一般的な習慣ですか？ これは複数のモジュールに分割する必要があるように思えます。データベースエンジンごとに1つかもしれません。 開発者は、このような1つの巨大なモジュールを作成すること（「すべてを1か所にまとめる」以外）からどのようなメリットを得ますか？

21 python  code-quality  modules 

メソッドチェーンを使用してオブジェクトをセットアップするパターンを頻繁に使用しますが、Builderor Prototypeパターンに似ていますが、各メソッド呼び出しで新しいオブジェクトを作成せず、代わりに元のオブジェクトを変更します。 例： new Menu().withItem("Eggs").withItem("Hash Browns").withStyle("Diner"); このパターンに名前があるのか​​、それがアンチパターンと見なされるのかどうか疑問に思うだけです。なぜなら、より流に読むことができても、長いメソッドチェーンにつながる可能性があるからです。

21 design-patterns  coding-style  code-quality  patterns-and-practices  method-chaining 

現在、かなり複雑な会社向けに新しいアプリケーションをコーディングしています。期限に間に合うように、機能はかなり打ち上げられており、起動する準備ができています。 私は今月末までにバージョン1を立ち上げて実行するタスクを与えられました。私は開発のほぼ半分であり、終わりが見えてくるようになりました。 昨日、要件の1つに対する非常に優れた簡単なソリューションを思いつくのに時間を費やし、その結果を非常に誇りに思っています。今朝、バージョン2のドキュメントが送信されました。そこには、昨日書いたコードを破壊するか、大幅に変更する必要があるという要件があります。そのままにしておくと、将来多くの作業が必要になります。現在のソリューションをより堅牢にするためにもう1日かかるため、v2機能をはるかに少ない労力で追加できますが、必要な追加のコーディングには少し遅れが出ます。 v2を実行するかどうかはわかりません。私の場合もあれば、同僚の場合もあれば、インターンの場合もあります。 あなたが私の靴を履いていたら、将来それをより簡単にするために今時間を費やしますか、それともあなたのソリューションを残して、時間が来たときにそれを処理しますか？

21 code-quality  future-proof 

私は最近、バージョン管理のないチームで働き始めました。ほとんどのチームメンバーは、どのようなバージョン管理にも慣れていません。私は自分の仕事を追跡するためにMercurialを個人的に使用しています。私は他の人にそれを採用することを奨励し、少なくとも彼らが変更を開発するときに彼らのコードのバージョン管理を開始したいと思います。mercurialなどの分散バージョン管理の採用をどのように奨励できるかについて、誰にでもアドバイスをいただけますか。DVCSのマネージャーを含む人々を獲得する方法に関するアドバイスは大歓迎です。

21 version-control  code-quality 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 言語のショートカットを使用して、コードをより簡潔にすることができます。 たとえば、三項およびヌルの合体演算子はコードの量を減らすことができますが、間違いなく読みやすさを損ないます： C＃の場合： Person newGuy = new Person(); if (boss == null) { newGuy.Boss = GetDefaultBoss(); } else { newGuy.Boss = boss; } 機能的に同等です： Person newGuy = new Person(); newGuy.Boss = boss ?? GetDefaultBoss(); しかし、明らかにもっと冗長です。 簡潔さと読みやすさの点では、どこで線を引きますか？

21 code-quality  readability 

コードを読みにくくすることなくパフォーマンスを向上させるために簡単なルーチンを記述する方法について話している...たとえば、これは私たちが学んだ典型的なものです： for(int i = 0; i < collection.length(); i++ ){ // stuff here } しかし、私は通常、a foreachが該当しない場合にこれを行います。 for(int i = 0, j = collection.length(); i < j; i++ ){ // stuff here } lengthメソッドを一度だけ呼び出すので、これはより良いアプローチだと思います...私のガールフレンドはそれが不可解だと言います。自分の開発で使用する他の簡単なトリックはありますか？

21 code-quality  performance 

数日前、私はソフトウェア工学博士号の候補者と話をしていましたが、ある時点で彼女は私に言いました。 クラスとメソッドをできるだけ小さくしてください そして、これは常に良い習慣であるのだろうか。 たとえば、クラスに属性が2つしかないことは価値があるのでしょうか？たとえば、いくつかのメソッドでは、整数のペアを使用する必要があります。「PairOfIntgers」クラスを作成する必要がありますか？ この考え方は、あまりにも多くの部分でコードを「壊す」ことができますか？

20 code-quality  coding-style 

80％のテストカバレッジ（すべてのテストに合格）を持つコードがある場合、テストカバレッジのないコードよりも品質が高いと言ってもいいでしょうか？ それとも、それがより保守可能であると言うのは公平ですか？

20 code-quality  test-coverage 

init()型のメソッドを宣言する目的はありますか？ 私はコンストラクタよりも優先init()すべきかどうか、または宣言を避ける方法をinit()尋ねていません。 メソッドを宣言する背後に何らかの理由があるのかinit()（それがどれほど一般的かを見て）、それがコードのにおいであり、避けるべきかどうかを尋ねています。 init()イディオムは非常に一般的ですが、私は、任意の真のメリットを見ていません。 メソッドによる初期化を促進する型について話している： class Demo { public void init() { //... } } これはいつプロダクションコードで使用されますか？ コンストラクターがオブジェクトを完全に初期化せず、部分的に作成されたオブジェクトを生成することを示唆しているため、コードの匂いがするかもしれません。状態が設定されていない場合、オブジェクトは存在しないはずです。 これは、エンタープライズアプリケーションの意味で、生産をスピードアップするために使用されるある種の手法の一部である可能性があると信じさせてくれます。それは私がそのようなイディオムを持つことを考えることができる唯一の論理的な理由です。

20 java  object-oriented  object-oriented-design  code-quality  code-smell 

私は本当に単体テストとTDDに夢中になりました-私はテストに感染しています。 ただし、ユニットテストは通常​​、パブリックメソッドに使用されます。ただし、プライベートメソッドでもいくつかの仮定（アサーション）をテストする必要がある場合があります。これは、それらの一部が "危険"であり、リファクタリングがそれ以上役に立たないためです。（フレームワークをテストすることでプライベートメソッドをテストできることはわかっています）。 したがって、プライベートメソッドの最初の行と最後の行の両方がアサーションであることが私の習慣になりました。 ただし、パブリックメソッド（およびプライベートメソッド）でアサーションを使用する傾向があることに注意してください。パブリックメソッドの前提条件は、ユニットテストフレームワークによって外部からテストされるため、これは「テストの重複」でしょうか。 誰かがあまりにも多くのアサーションをコードの匂いだと考えることはできますか？

19 testing  code-quality  tdd  code-smell  assertions 

複雑さの相対的な価値を生み出すルールを含む静的ソースコード分析のコンテキストを定義できると私には思えます。ソースコードには「エネルギー」がないため、物理的な意味ではそうではないことはわかっていますが、少なくとも学問的には類似性を引き出す努力が行われていると確信しています。これについての知識はありますか？

19 code-quality  static-analysis 

一緒に仕事をしている優秀な開発者が、私たちが継承したコードに機能を実装するのに苦労したことを最近教えてくれました。彼は、問題はコードを追跡するのが難しいということだと言いました。そのことから、私は製品をより深く見て、コードパスを確認することがどれほど難しいかを理解しました。 非常に多くのインターフェースと抽象レイヤーを使用していたため、物事の始まりと終わりを理解しようとするのは非常に困難でした。私は過去のプロジェクト（きれいなコードの原則に気付く前に）を見ていた時間について考えさせられ、主にコードナビゲーションツールが常にインターフェイスに到達するため、プロジェクトを回避することは非常に困難であることがわかりました。具体的な実装や、プラグインタイプのアーキテクチャで何かが接続されている場所を見つけるには、さらに多くの労力が必要です。 この理由から、一部の開発者は依存性注入コンテナを厳密に拒否しています。ソフトウェアのパスを非常に混乱させるため、コードナビゲーションの難易度は指数関数的に増加します。 私の質問は次のとおりです。フレームワークまたはパターンがこのように多くのオーバーヘッドを導入する場合、それは価値がありますか？実装パターンが不十分な場合の症状ですか？ 開発者は、フラストレーションを乗り越えるために、抽象化がプロジェクトにもたらすものの全体像を調べる必要があると思います。しかし、通常、彼らにその全体像を見せることは困難です。IOCとDIのニーズをTDDで販売できなかったことを知っています。これらの開発者にとって、これらのツールを使用すると、コードの可読性が非常に低下します。

19 testing  code-quality  tdd  code-smell  dependency-injection 

現在、5か月前にコア開発を終了したが、依然として高レベルの欠陥があるプロジェクトを検討するよう求められています。約10個の欠陥が修正されるごとに発生するのは、少なくとも4個、場合によっては8個の欠陥が発生することです。 ベンダーでのコーディング慣行は貧弱であり、これについては一般的な合意があると思います。しかし、ソフトウェアに構造的な問題があるかどうか疑問に思っていますか？欠陥密度は有用な尺度ですが、コアソフトウェアの作成が不適切な場合は、ベンダーが行っていることはすべて問題を解決することです。 インフラストラクチャでは、何かが不完全に構築されている場合、より明確に定義されていますが、LOCごとの欠陥のほかに、ソフトウェアにどのような測定値を使用できますか？ この製品は4か月間欠陥修正フェーズにありますが、重大な欠陥はまだ十分に解決されていません。回帰の問題を修正するだけで、新しい機能を注入することはありません。 これは開発品質の問題を示しており、満足していません。ただし、製品自体に根本的な欠陥がある場合、それは別の問題です。懸念されているのは、コアコードベースの作成が不十分であり、ドキュメントが限られているため、外部の開発者はすべて、問題をAからBにシフトしているだけです。機能的にします。 サードパーティから製品を受け入れ、サポートを求められた場合、標準を定義するためにどの受け入れ基準を使用しますか？ リード開発者にリリースごとのコードのピアレビューを行わせることに加えて、他に何ができるかわからない？

18 code-quality  metrics 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 もちろん、エラーメッセージまたは警告にログフレームワークを使用することは非常に有効です。ただし、短時間で新しいことを試してみたい場合は、System.out.println（）を使用することがあります。 System.out.println（）を使って簡単なテストを行うのは本当に悪いのでしょうか？

18 java  programming-practices  testing  code-quality  source-code 

pc-lintやQACなどのツールを使用して、コードベースで静的コード分析を実行できます。 私の経験では、静的解析はしばしば大量のノイズ、つまり実際のバグではないが特定のルールセットのルールの1つに違反するものに関する警告を生成します。特定のルールを無効にする（ルールセットで有効にするか、コード内の特別なコメントを使用する）ことは、本当に面倒なプロセスです。 静的コード分析の本当の利点は何ですか？

18 code-quality  static-analysis