paint-brush
コードの臭い部分を見つける方法 [パート XXXIV]@mcsee
771 測定値
771 測定値

コードの臭い部分を見つける方法 [パート XXXIV]

Maximiliano Contieri7m2023/04/07
Read on Terminal Reader

長すぎる; 読むには

においがするのは、編集または改善できる場合が多いためです。これらの臭いのほとんどは、何かが間違っている可能性があることを示しているだけです。したがって、それ自体を修正する必要はありません… (ただし、調べておく必要があります。) 以前のコードのにおい以前のすべてのコードのにおい (パート i - XXXIII) は、ここで見つけることができます。
featured image - コードの臭い部分を見つける方法 [パート XXXIV]
Maximiliano Contieri HackerNoon profile picture

においがするのは、編集または改善できる場合が多いためです。


これらの臭いのほとんどは、何かが間違っている可能性があることを示しているだけです。したがって、それ自体を修正する必要はありません…(ただし、調べておく必要があります)。

前 コードの匂い

以前のすべてのコードの匂い (パート i ~ XXXIII) は、ここで見つけることができます。


続けましょう...


Code Smell 166 - ユーザー インターフェイスの低レベル エラー

致命的なエラー: キャッチされていないエラー: クラス 'logs_queries_web' が /var/www/html/query-line.php:78 に見つかりません


スタック トレース: #0 {main} が /var/www/html/query-line.php の 718 行目にスローされる


TL;DR: エラーをキャッチします。あなたが期待していないものでさえ。

問題

  • 安全


  • エラー処理


  • エラーログ


  • 悪い UX エクスペリエンス

ソリューション

  1. トップレベルのハンドラーを使用します。


  2. リターン コードを優先する言語は避けてください。


  3. データベースと低レベルのエラーが予想されます。

コンテクスト

2022 年になっても、カジュアルなユーザーにスタックやデバッグ メッセージを表示する「深刻な」Web サイトを見ることができます。

サンプルコード

間違い

<? Fatal error: Uncaught Error: Class 'MyClass' not found in /nstest/src/Container.php:9

<? // A user-defined exception handler function function myException($exception) { logError($exception->description()) // We don't show Exception to final users } // Set user-defined exception handler function set_exception_handler("myException");

検出

  • [×]自動

突然変異テストを使用して問題をシミュレートし、それらが正しく処理されているかどうかを確認できます。

タグ

  • 安全

結論

私たちは成熟し続ける必要があります。


私たちのソリューションは、ずさんであってはなりません。



真面目なソフトウェア エンジニアとしての評判を改善する必要があります。

関係

Code Smell 72 - リターンコード

より詳しい情報

フェイルファスト

免責事項

Code Smells は私の意見です。

クレジット

Unsplashjesse orricoによる写真


私の問題の 80% は単純な論理エラーです。残りの問題の 80% はポインター エラーです。残りの問題は難しいです。

マーク・ドナー

ソフトウェアエンジニアリングの名言


Code Smell 167 - ハッシュの比較

ハッシュは、2 つのオブジェクトが異なることを保証します。それらが同じであるというわけではありません。


TL;DR: ハッシュをチェックする場合は、等価性もチェックする必要があります

問題

ソリューション

  1. ハッシュをチェック (高速) してから、等価性をチェック (低速)

コンテクスト

2022 年 10 月 7 日、大規模なブロックチェーンの 1 つを停止する必要がありました。


ほとんどのブロックチェーンは定義上分散化されているため、 このニュースは衝撃的でした。


ここで完全な記事を読むことができます:

ハッカーがコードの匂いを悪用して 5 億 6,600 万ドルを盗んだ方法

サンプルコード

間違い

public class Person { public String name; // Public attributes are another smell @Override public boolean equals(Person anotherPerson) { return name.equals(anotherPerson.name); } @Override public int hashCode() { return (int)(Math.random()*256); } // This is just an example of non-correlation // When using HashMaps we can make a mistake // and guess the object is not present in the collection }

public class Person { public String name; // Public attributes are another smell @Override public boolean equals(Person anotherPerson) { return name.equals(anotherPerson.name); } @Override public int hashCode() { return name.hashCode(); } // This is just an example of non-correlation }

検出

  • [x]半自動

多くのリンターには、ハッシュと等価性の再定義に関するルールがあります。


ミューテーション テストを使用すると、同じハッシュを使用してさまざまなオブジェクトをシードし、テストを確認できます。

  • 身元
  • 安全

結論

すべてのパフォーマンスの改善には欠点があります。


キャッシュとレプリケーションは注目すべき例です。


私たちはそれらを注意深く使うことができます(しなければなりません)。

関係

Code Smell 49 - キャッシュ

Code Smell 150 - 等しい比較

より詳しい情報

等価性とハッシュ

Java のハッシュコード

ハッシュコードと等しい

免責事項

Code Smells は私の意見です。


読者の中には驚かれる方もいらっしゃると思いますが、私の主な関心はコンピューターのセキュリティではありません。私は主に、意図したとおりに動作するソフトウェアを作成することに関心があります。

ヴィーツェ・ヴェネマ

ソフトウェアエンジニアリングの名言


Code Smell 168 - 文書化されていない決定

いくつかの変更を加える必要があります。その理由を明確にする必要があります

TL;DR: 設計または実装の決定は宣言的に行います。

問題

  • コード コメント
  • テスト容易性の欠如

ソリューション

  1. 理由を明確にしてください。
  2. コメントをメソッドに変換します。

コンテクスト

ときどき、簡単にテストできない恣意的なルールを見つけることがあります。


失敗するテストを書くことができない場合は、コメントの代わりに優れた宣言的な名前を持つ関数が必要です。

サンプルコード

間違い

// We need to run this process with more memory set_memory("512k) run_process();

increase_memory_to_avoid_false_positives(); run_process();

検出

  • [x]半自動

これはセマンティックな匂いです。


コメントを検出して警告することができます。

タグ

  • コメント

結論

コードは散文です。そして、デザインの決定は物語的であるべきです。

関係

Code Smell 05 - コメント乱用者

Code Smell 75 - メソッド内のコメント

免責事項

Code Smells は私の意見です。

クレジット

UnsplashGoh Rhy Yanによる写真


プログラムは、人と同じように古くなります。老化を防ぐことはできませんが、その原因を理解し、その影響を制限し、損傷の一部を元に戻すことはできます.

マリオ・フスコ

ソフトウェアエンジニアリングの名言


Code Smell 169 - 接着方法

一度に 2 つ以上のものを作成しないでください。

TL;DR: メソッドでできるだけアトミックになるようにしてください

問題

  • 結合コード
  • テストが難しい
  • 読みにくい

ソリューション

  1. メソッドを壊す

リファクタリング

https://maximilianocontieri.com/refactoring-002-extract-method

コンテクスト

「And」を使用してメソッドに名前を付けた場合、抽出してブレークするメソッドの機会を逃している可能性があります。

サンプルコード

間違い

calculatePrimeFactorsRemoveDuplicatesAndPrintThem() // Three responsibilities

calculatePrimeFactors(); removeDuplicates(); printNumbers(); // Three different methods // We can test them and reuse them

検出

  • [x]半自動

一部のリンターは、「and」という用語を含むメソッドについて警告することができます。

タグ

  • カップリング

結論

メソッドを作成するときは、ゴム製のアヒルの話をして、物事が正しく作成されているかどうかを確認することが非常に重要です。

関係

%[ https://maximilianocontieri.com/code-smell-85-and-functions ]

免責事項

Code Smells は私の意見です。

クレジット

UnsplashScott Sankerによる写真


プログラミングの芸術を学ぶことは、他のほとんどの分野と同様に、最初にルールを学び、次にそれらを破るタイミングを学ぶことから成ります。

ジョシュア・ブロック


Code Smell 170 - 機能変更によるリファクタリング

開発は素晴らしいです。リファクタリングは素晴らしいです。同時に作らない

TL;DR: 機能の変更とリファクタリングを同時に行わないでください。

問題

  • ソリューションのレビューが難しい
  • 競合をマージ

ソリューション

  1. リファクタリング中に機能を変更しない

コンテクスト

場合によっては、さらなる開発のためにリファクタリングが必要であることがわかります。


私たちは学習の専門家です。


解決策を保留にする必要があります。リファクタリングに取り組み、ソリューションを続行します。

サンプルコード

間違い

getFactorial(n) { return n * getFactorial(n); } // Rename and Change factorial(n) { return n * factorial(n-1); } // This is a very small example // Things go works while dealing with huge code

getFactorial(n) { return n * getFactorial(n); } // Change getFactorial(n) { return n * getFactorial(n-1); } // Run the tests factorial(n) { return n * factorial(n-1); } // Rename

検出

これはリファクタリングの匂いです。

  • [×]マニュアル

タグ

  • リファクタリング

結論

物理的なトークンを使用する必要があります。


リファクタリング段階または開発段階のいずれかにいます。

免責事項

Code Smells は私の意見です。

クレジット

UnsplashDanny Jingによる写真


私がコードを勉強しているとき、リファクタリングは、他の方法では見逃していたより高いレベルの理解につながります。理解のリファクタリングを無用なコードのいじくりとして片付けている人は、混乱の背後に隠れているチャンスに気づいていないことに気づいていません。

マーティン・ファウラー


さらに 5 つのコードの匂いが間もなく登場します…