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

ソフトウェアに抽象化が多すぎて設計パターンが多すぎる、またはその逆を言うには、どうすればもっと多くの抽象化が必要かを知ることができますか？ 私が協力している開発者は、これらの点に関して異なる方法でプログラミングしています。 いくつかの小さな機能をすべて抽象化し、可能な限りデザインパターンを使用し、いかなるコストでも冗長性を回避します。 私を含む他の人は、より実用的であることを試み、すべての設計パターンに完全に適合するわけではありませんが、適用される抽象化が少ないため、理解がはるかに速いコードを記述します。 これはトレードオフであることを知っています。プロジェクトに十分な抽象化が行われていることをどのように確認できますか？ 例、Memcacheを使用して汎用キャッシングレイヤーを作成する場合。私たちは本当に必要ですかMemcache、MemcacheAdapter、MemcacheInterface、AbstractCache、CacheFactory、CacheConnector、...またはこれは、保守が容易とまだ良いコードは、これらのクラスの半分しか使用している場合ですか？ Twitterでこれを見つけました： （https://twitter.com/rawkode/status/875318003306565633）

29 design-patterns  architecture  clean-code  abstraction  architectural-patterns 

技術的負債に関するこの記事には、次のような優れた点があります。 「技術的な問題」に取り組むことは、ストーリーによって推進されるときに最も効果的です。コードベースはおそらくどこでも作業を必要としますが、ユーザーに面した理由でコードが作業される場所でのみペイオフが受け取られます。ストーリーがなかなか難しい領域を通過しない場合、その作業はほとんど無駄になります。 したがって、私はいつものように（しかしおそらくそれよりも少ない）物語を取り上げ、あなたが見つけたよりもキャンプ場を去るという「ボーイスカウトのルール」に従うアプローチを好む。言い換えれば、ストーリーが私たちを導くところはどこでも、より多くのテストを書きましょう、より積極的にリファクタリングしましょう。 このアプローチには、少なくとも次の利点があります。 「賢明な」ストーリーの流れを維持します。 チームのすべての才能からの支援を提供します。 チーム全体がコードをクリーンに保つ方法を学習できるようにします。 改善が必要な場所に正確に焦点を合わせます。 「必要な」改善を無駄にしない; コードの品質が長期的な生産性に非常に大きな影響を与えるのを見てきましたので、技術的な負債を処理する必要があると考えています。上記の投稿は理にかなっていると思いますが、最後の2つのポイントについてはよくわかりません。たとえユーザーのストーリーに関係していなくても、技術的な負債を取り除くことで得られるメリットの実際の経験を見つけることに興味があります。 コードベースを整理し、技術的な負債をなくすことで、どのようなプラスのメリットがありましたか？仕事を成し遂げるためにどのような方法を使用しましたか？

29 code-quality  refactoring  clean-code  technical-debt 

私が書いたいくつかのコードを見てみると、次の構成要素に出会い、考えさせられました。一見、十分きれいに見えます。はい、実際のコードでは、getLocation()メソッドには、取得する場所を正確に説明する、より具体的な名前があります。 service.setLocation(this.configuration.getLocation().toString()); この場合、serviceは、メソッド内で宣言された既知の型のインスタンス変数です。this.configurationクラスコンストラクターに渡されたものであり、特定のインターフェイス（パブリックgetLocation()メソッドを必須とする）を実装するクラスのインスタンスです。したがって、式の戻り値の型this.configuration.getLocation()は既知です。特にこの場合には、それがあるjava.net.URLのに対し、service.setLocation()望んでいますString。2種類の文字列とURLが直接の互換性はありませんので、いくつかの変換の並べ替えは、丸い穴に四角いペグに合わせて必要とされます。 しかし、中に引用されたようにデメテルの法則によればクリーンコード、メソッドFクラスでCが唯一のメソッドを呼び出す必要がCによって作成または引数として渡されるオブジェクトF、およびインスタンス変数に保持されているオブジェクトC。それを超えるもの（toString()メソッド呼び出し自体の結果として作成された一時オブジェクトを考慮する場合を除き、上記の特定のケースでは最後です。この場合、法律全体が議論の余地がないようです）。 上記の制約が与えられた場合、上記のような呼び出しが推奨されない、または拒否されるべきである正当な理由はありますか？それとも、私は過度に細心の注意を払っていますか？ パラメーターとして渡されたオブジェクト（などによって返されるオブジェクト）URLToString()を単に呼び出し、結果を返すメソッドを実装する場合、まったく同じ結果を得るために呼び出しをラップすることができます。効果的には、変換を1ステップ外に移動するだけです。それはどういうわけかそれを受け入れられるでしょうか？（思わないそのすべてが少し動き回る事があるので、それは、任意の違いのいずれかの方法を作るべきではないことを、直感的に、私には。しかし、デメテルの法則の手紙で行く引用として、それはI以来、許容可能ですその後、関数のパラメーターを直接操作します。）toString()URLgetLocation()getLocation() これがtoString()標準型を呼び出すよりも少しエキゾチックなものである場合、違いが生じるでしょうか？ 答えるときserviceは、変数が属する型の動作またはAPIを変更することは実用的ではないことに注意してください。また、議論のために、戻り値の型を変更することgetLocation()も非現実的であるとしましょう。

23 language-agnostic  clean-code 

ソフトウェア腐敗のウィキペディアの定義は、ソフトウェアのパフォーマンスに焦点を当てています。これは私が慣れているものとは異なる使用法です。コードの清潔さとデザインの観点から、コードのすべての標準品質特性（読みやすさ、保守性など）を考慮して、それ以上に考えていました。何が起こっているのか誰も知らないからです。しかし、ソフトウェアの腐敗という用語には、パフォーマンスに特別な言及がありますか？または私はそれがコードの清潔さを指していると思うのは正しいですか？または、これはおそらく、用語の複数の感覚が一般的に使用されている場合です。ユーザーの観点からは、パフォーマンスに関係しています。しかし、ソフトウェア職人にとっては、コードの読み方をより具体的にする必要がありますか？

22 performance  clean-code  definition 

テストと実際のコード間でデータを複製するのは良いですか、悪いですか？たとえば、FooSaver特定の名前のファイルを特定のディレクトリに保存するPythonクラスがあるとします。 class FooSaver(object): def __init__(self, out_dir): self.out_dir = out_dir def _save_foo_named(self, type_, name): to_save = None if type_ == FOOTYPE_A: to_save = make_footype_a() elif type == FOOTYPE_B: to_save = make_footype_b() # etc, repeated with open(self.out_dir + name, "w") as f: f.write(str(to_save)) def save_type_a(self): self._save_foo_named(a, "a.foo_file") def save_type_b(self): self._save_foo_named(b, "b.foo_file") 私のテストでは、これらのファイルがすべて作成されたことを確認したいので、次のように言いたいと思います。 …

20 unit-testing  coding-style  clean-code 

3 のルール（新しいc ++標準の5のルール）の状態： デストラクタ、コピーコンストラクタ、またはコピー割り当て演算子のいずれかを明示的に宣言する必要がある場合は、おそらく3つすべてを明示的に宣言する必要があります。 しかし、一方で、マーティンの「クリーンコード」は、すべての空のコンストラクターとデストラクターを削除することを推奨しています（293ページ、G12：Clutter）。 実装されていないデフォルトのコンストラクタはどのような用途に使用されますか？役目を果たすのは、意味のないアーティファクトでコードを混乱させることです。 だから、これらの2つの反対意見をどのように扱うのですか？空のコンストラクタ/デストラクタを実際に実装する必要がありますか？ 次の例は、まさに私が意味することを示しています。 #include <iostream> #include <memory> struct A { A( const int value ) : v( new int( value ) ) {} ~A(){} A( const A & other ) : v( new int( *other.v ) ) {} A& operator=( const A & other ) …

20 c++  clean-code  rule-of-three 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 閉じた3年前。 ですから、私は最初のプロジェクトをC ++でコーディングしていますが、単に機能するのではなく、コードを「クリーン」にするのにより多くの努力が必要と思われます。つまり、C ++が、いが動作するコードを「許可」しているように見えます。 考えさせられた プログラミング言語は、設計によってクリーンなコードを実施できますか？そのような言語はすでにありますか？ また、これはプログラミング言語の開発/理論の設計原則としてどのように組み込まれていますか？どのような手段が使用されていますか？

19 programming-languages  programming-practices  clean-code 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 これは非常に単純化された例です。これは必ずしも言語固有の質問ではありません。関数を作成できる他の多くの方法、およびそれに加えられる変更を無視してください。。色はユニークなタイプです string CanLeaveWithoutUmbrella() { if(sky.Color.Equals(Color.Blue)) { return "Yes you can"; } else { return "No you can't"; } } 私が出会った多くの人々、ReSharper、およびこの男（コメントから、しばらくの間これを尋ねようとしていることを思い出した）は、コードをリファクタリングして、elseこれを残すブロックを削除することをお勧めします。 （私は大多数が言ったことを思い出せない、そうでなければ尋ねなかったかもしれない） string CanLeaveWithoutUmbrella() { if(sky.Color.Equals(Color.Blue)) { return "Yes you can"; } return "No you can't"; } 質問：elseブロックを含めないことで複雑さが増しますか？ 私はelse、両方のブロックのコードが直接関係しているという事実を述べることにより、意図がより直接的に述べられているという印象を受けています。 さらに、特に後日コードを変更した後は、ロジックの微妙な間違いを防ぐことができます。 私の単純化された例のこのバリエーションを取り上げます（orこれは意図的に単純化された例であるため、演算子を無視します）。 bool CanLeaveWithoutUmbrella() { if(sky.Color != Color.Blue) { …

18 coding-style  code-quality  coding-standards  complexity  clean-code 

ずさんな方法で製品の既存のコードベースを継承しました。基本的な設計は非常に不十分であり、残念ながら完全なリファクタリングなしではほとんど何もできません（高結合、低凝集、コードのof延する複製、技術設計文書なし、単体テストではなく統合テスト）。この製品には、歴史、リスクに対する許容度が最小限の重要な「現金牛」クライアントへの高い露出、ギリシャ人を赤面させる技術的負債、非常に大きなコードベースと複雑さ、そしてチームによるバグへの戦い疲れた敗北主義アプローチがあります私。 古いチームは別の部門に船をジャンプして、別のプロジェクトを台無しにする機会を得た。プロジェクト管理の失敗とは対照的に、技術的な無能なプロジェクトの失敗を経験することは非常にまれですが、これは確かにそれらのケースの1つです。 今のところ、私は一人でいますが、私には多くの時間、意思決定の自由、将来の方向性、そして私を助けるためにゼロからチームを構築する能力があります。 私の質問は、機能要件の収集段階で自由時間があるときに、このようなプロジェクトでの影響の少ないリファクタリングについて意見を集めることです。何千ものコンパイラ警告があり、それらのほとんどは未使用のインポート、未読のローカル変数、型チェックの不在、および安全でないキャストです。コードの書式設定は非常に読みにくく、ずさんなため、コーダーはパーキンソン病にかかっており、特定の行でスペースバーを押した回数を制御できませんでした。通常、さらにデータベースとファイルリソースが開かれ、安全に閉じられることはありません。無意味なメソッド引数、同じことを行う重複メソッドなど。 次の機能の要件を待っている間、私は、影響が少ない低リスクのものを掃除しながら、時間を無駄にしているのか、正しいことをしているのかと考えました。新しい機能が以前に時間を費やしたコードを削除することを意味する場合はどうなりますか？私はアジャイルのアプローチを開始するつもりであり、これがアジャイル開発中に絶えずリファクタリングするのは許容可能であり、普通であることを理解しています。 これを行うことによるプラスまたはマイナスの影響を考えてください。

17 language-agnostic  refactoring  clean-code 

私は過去3年間ソフトウェアを開発してきましたが、最近、自分が良い慣習にどれほど無知であるかに目覚めました。これにより、Clean Codeという本を読み始めることになりました。これは私の人生をより良い方向に変えていますが、プログラムを書くための最良のアプローチのいくつかについて洞察を得るのに苦労しています。 Pythonプログラムがあります。 argparse required=Trueを使用して、両方ともファイル名である2つの引数を適用します。最初は入力ファイル名、2番目は出力ファイル名 readFromInputFile入力ファイル名が入力されたことを最初に確認する機能があります writeToOutputFile出力ファイル名が入力されたことを最初に確認する機能があります 私のプログラムは十分に小さいので、＃2と＃3のチェックは冗長であり、削除する必要があると信じるようになるため、両方の機能を不要なif状態から解放します。しかし、「二重チェックは大丈夫」であると信じるようになり、引数の解析が行われない別の場所から関数を呼び出すことができるプログラムでは正しいソリューションになるかもしれません。 （また、読み取りまたは書き込みが失敗した場合、try except適切なエラーメッセージを生成する各関数があります。） 私の質問は、すべての冗長な状態チェックを避けるのが最善ですか？プログラムのロジックは非常に堅固であるため、チェックは一度だけで済みますか？これまたはその逆を説明する良い例はありますか？ 編集：答えてくれてありがとう！それぞれから何かを学びました。非常に多くの視点を見ると、この問題にどのようにアプローチし、自分の要件に基づいて解決策を決定する方法についての理解が深まります。ありがとうございました！

16 clean-code  methodology 

現在、Robert MartinのClean Codeを読んでいます。私はそれが素晴らしいと思うし、OOコードを書くとき、私は彼の教訓を心に抱いている。特に、意味のある名前の小さな関数を使用するという彼のアドバイスは、コードの流れをよりスムーズにするものだと思います。次の引用文で簡単に要約できます。 [W] eは、TO段落のセットであるかのようにプログラムを読むことができます。各段落は、現在の抽象化レベルを記述し、次のレベルで後続のTO段落を参照します。 （クリーンコード、37ページ：「TO段落」は、不定詞で表明された文で始まる段落です。「Xを実行するには、ステップYとZを実行します。」「Yを実行するには、...」など。 ） 例えば： RenderPageWithSetupsAndTeardownsでは、ページがテストページであるかどうかを確認し、テストページである場合は、セットアップとティアダウンを含めます。どちらの場合でも、ページをHTMLでレンダリングします 私は自分の仕事のために機能的なコードも書きます。この本のMartinの例は、まるで段落のセットであるかのように読んでおり、非常に明確です。 。 Haskell標準ライブラリから例を取り出します： maximumBy :: (a -> a -> Ordering) -> [a] -> a maximumBy _ [] = error "List.maximumBy: empty list" maximumBy cmp xs = foldl1 maxBy xs where maxBy x y = case cmp x y of GT -> …

16 design  functional-programming  clean-code 

アプリケーションのソースコードには非常に多くの場所があり、1つのクラスには同じ名前で異なるパラメーターを持つ多くのメソッドがあります。これらのメソッドには、常に「前の」メソッドのすべてのパラメーターと1つ以上のパラメーターがあります。 それは長い進化（レガシーコード）とこの考え方の結果です（私は信じています）： 「Aを実行するメソッドMがあります。A+ Bを実行する必要があります。わかりました。新しいパラメータをMに追加し、そのための新しいメソッドを作成し、Mから新しいメソッドにコードを移動します。 1つの以上のパラメータで、あそこA + Bを行うと、新しいパラメータのデフォルト値をMから新しいメソッドを呼び出します。」 以下に例を示します（Javaに似た言語）： class DocumentHome { (...) public Document createDocument(String name) { // just calls another method with default value of its parameter return createDocument(name, -1); } public Document createDocument(String name, int minPagesCount) { // just calls another method with default value of its parameter …

16 refactoring  clean-code  legacy-code 

ここで何が尋ねられているかを伝えるのは難しいです。この質問は曖昧、曖昧、不完全、過度に広範、または修辞的であり、現在の形式では合理的に答えることができません。この質問を明確にして、再開できるようにするには、ヘルプセンターに アクセスしてください。 7年前に閉鎖されました。 そう思うのはおそらく私だけではないでしょう。しかし、私は「完璧なプログラマーの症候群」と呼ぶ傾向があります。多くの人が言うのは完璧主義者と同じですが、この場合はプログラミングの領域です。ただし、プログラミングの領域は、このような症候群には少し問題があります。 プログラミングをしているときに、コードがきれいで、ほとんどのベストプラクティスに従う優れたコードであるという自信がない、または自信がないと感じたことはありますか？従うべき非常に多くのルールがあるので、どういうわけか圧倒されるような気がします。もちろん、私はプログラマーであり、プログラミングが大好きであるというルールに従うことを好まないというわけではありません。これを芸術と見なし、ルールに従う必要があります。しかし、私もそれが大好きです。私がしたいことを意味し、自分がやっていることが正しい方向に進んでいるという良い感覚を得るためにルールに従うのが大好きです。ベストプラクティスと優れたコードに関する。 多分それは組織の欠如ですか？たぶん、それは経験不足ですか？たぶん練習不足？たぶん、誰かが指摘できる何かが欠けているのでしょうか？どういうわけかその症候群を取り除く方法はありますか？

16 performance  clean-code 

当社のチームは最近、各チェックインに対してコードレビューの実施を開始しました。 チームのリーダーとして、私はあまりにも多くの提案を提供し、開発者をいらいらさせ、チームの出力を減らし、コードを手放すというバランスを見つけようとしています。 有用なアプローチを示唆する、よく知られた情報源からの証拠、研究、またはガイダンスはありますか？

15 code-quality  code-reviews  clean-code  team-leader  process-improvement 

セットクラスのadd演算子は、ブール値を返します。ブール値は、追加する要素がまだ存在しない場合はtrue、そうでない場合はfalseです。書いています if (set.add(entry)) { //do some more stuff } きれいなコードを書くという点で良いスタイルと考えられていますか？あなたは一度に2つのことをするので、私は疑問に思っています。1）要素を追加し、2）要素が存在したかどうかを確認します。

15 java  coding-style  clean-code