タイプミスなどを回避するには？
私は初めて、オープンソースソフトウェアのコーディングを行って、コミットする前にすべての作業をレビューします。レビュー作業は簡単な作業ではないので、レビュー担当者の時間と労力を無駄にしたくありません。しかし、コードに変更を加えている間、多くの場合、私は愚かなタイプミスや他の種類のエラーを作ります。
たとえば、前回いくつかの古いコードをリファクタリングしたときに、あるクラスから別のクラスにコードを移動しましたが、そのチェックを忘れていました$thisは古いクラスでのみ機能し、今すぐ変更する必要がありました。
単体テストを実行しますが、これらのエラーを見逃すことがあります（現在、テストカバレッジが不完全です）。そして、仕事をより早く終わらせるためだけに、変更を急いで提出することが多いことに同意します。
しかし、レビュアーの時間を無駄にするだけでなく、これは実際に開発プロセスを遅くし、私の信頼性を低下させます（小さなエラーは、良い仕事に対する賞賛を隠すことさえあるかもしれません）。
このようなシナリオを回避する最良の方法は何ですか？つまり、他の誰かが行う前に自分のコードをどのように確認できますか？
編集：私はNotepad ++ for PHPを使用しています。IDEすぐに変更するように依頼しないでください。ただし、説得力があれば提案を歓迎します;）
あなたはすでに自分で質問に答えました。
開発時に常に覚えておかなければならないことがいくつかあります（机上にある言語、IDE、プロジェクトに関係なく）。
-開発するときは、自分が取り組んでいるプロジェクトについてonlyを考えてみてください。仕事をうまくこなせば得られる賞賛を含め、他のすべてはしばらくの間忘れられるべきです。そのような考えはあなたの注意をそらすだけで、結果としてあなたはもっと間違いをするでしょう。
-急いではいけません（プロジェクトにとって重要でなければ）。時間をかけて、すべてを適切にテストしてください。あなたが言ったように、速く書かれているがバグがいっぱいのコードは誇りに思うものではありません。そんなに急がなければ、たくさんのバグを自分で発見できると思います。
そして、他の回答で述べたように、単体テストを実行します。そしてもう一つ。常にバグがあります。誰も完璧ではありません。しかし、これらの2つのルールはそれらの量を減らすのに役立ちます。
テストを実行しますが、これらのエラーを見逃すことがあります（テストカバレッジが不完全）。
エラーが発見されたら、将来の貢献者がこのエラーを繰り返すことを防ぐ新しいテストを追加することを検討してください。
正しく実行された場合、テストカバレッジと 回帰テスト を改善することで、間違いによる損害を十分に補償できます。
-常識的なアプローチはtaking your time作業を完了とマークする前に、コードに再度アクセスしてください。さらに、maximize your focus/concentration割り当てられた仕事の平和のために。
-最初の実用的なアプローチは、re-factoring tools like JustCodeまたは1回類似。彼らはimprove your productivityそして、構文エラーのために調整することができます。
-2番目の実際的なアプローチは TDDアプローチ を使用します。それはあなたのコードが機能するために適切なテストを持っていることを確認します（必要なすべてのユニットテストに合格します）、そうでなければ失敗します。
TDDは、必要に応じて既存のコードを実装してリファクタリングするのに時間がかかりますが、信頼性のある確実なコードを作成するためのクリーンな方法です。
それはプログラミング言語に依存します。厳密な静的型付けとビルドプロセスのコンパイル手順を備えた言語は、ほとんどのタイプミスをキャッチします。言語が厳密であるほど、タイプミスが無効な構文を引き起こす可能性が高くなります。極端な例は、Haskellプログラミング言語です。Haskellプログラマーは、冗談めかして、Haskellプログラムがコンパイルされると、通常は正しく、バグがなくなると主張します。しかし、ネットをすり抜けるタイプミスはまだあります。有名な例は、C/C++の=と==です。コーディングスタイルは、いくつかの追加の保護を提供できます。静的コード分析により、疑わしいコードが検出される場合があります。オートコンプリート機能を備えたテキストエディターにより、タイプミスの可能性が低くなります。しかし最終的には、実際のテストに代わるものはありません。
動的言語を使用する場合、事態はより困難になります。通常、コンパイル手順はないため、allエラーは実行時エラーとして表面化しますが、本質的にデプロイメントを妨げるものはありません。さらに悪いことに、問題のあるコードが実行されて初めて多くのエラーが通知されます。これにより、厳密な静的コンパイル言語を使用する場合よりも、（自動化された）テストがさらに重要になります。
しかし、自動化されたテストには、カバレッジという独自の問題があります。自動テストですべてのエラーをキャッチするには、100％のコードカバレッジが必要です（つまり、テストはコードのすべての1行に触れる必要があります）が、100％の入力カバレッジも必要です（テストでは、可能なすべての入力セットで各ユニットを呼び出す必要があります） 、コンテキストのすべての可能な状態で）。 100％のコードカバレッジは実行可能ですが、重要なものすべてに対して100％の入力カバレッジは不可能に近いものです。あなたの最善の策は、Edgeケースにヒットする可能性のある入力のセットについて知識のある推測を行い、見逃さないことを願うことです。また、テストは（必然的に）人間によって作成されるため、テスト対象のコードを記述しているときと同じように、テストを記述しているときに間違いを犯す可能性があります。幸いなことに、たいていの場合、テストのバグはテストされたコードのバグをキャンセルするのではなく、テストを二重に失敗させます。
入力ミスを防止および軽減するためにできることは次のとおりです。
- すべてをユニットテストすることについて信仰を持ちましょう。
- すべてのテストを自動的に実行するように開発環境をセットアップします。継続的インテグレーションシステムを導入している場合は、ビルドごとにすべての単体テストを実行するように構成し、テストが失敗した場合はビルドが壊れていると見なします。それ以外の場合は、変更を上流にプッシュする前に、ソース管理フックまたは同様の機能を使用してテストを実行することを検討してください。
- 防御的にコード化し、「巧妙な」トリックを避け、保守的に動的機能を使用します。
- プログラミング言語にもっと厳密なオプション（たとえば、VisualBasicの
Option StrictおよびOption Explicit）がある場合は、それらをオンにします。 - プログラミング言語が疑わしいコードについて警告できる場合は、それを（本番システムではなく）警告し、すべての警告を致命的なエラーとして扱います。
- 言語に組み込まれている保護手段（PHPの型のヒントなど）を活用します。
- オートコンプリートを提供するコードエディターを使用します。これを使って。
- 識別子に名前を付けるときは、「ニアミス」を避けます。同じコンテキスト内で
$Userと$userを使用しないでください。 - スコープをできるだけローカルかつ小さいままにします。グローバルな状態を避け、必要なものだけを公開し、副作用などを避けます。これにより、完全に関連のない場所で誤って触れることを防ぎ、コードのテストを容易にします。
- 他の誰かにあなたのコードをレビューしてもらいます。
これらのどれも完全に防弾ではありませんが、それらを組み合わせると、ほとんどの基地がカバーされ、できればリスクを許容レベルまで削減できます。
私は同様の愚かな間違いを犯し続けました。私が見つけた解決策はユニットテストでした。一連の自動テストをセットアップして、コードを記述するときにコードの正確性をチェックします。
コンパイル済み言語でコードを記述します。
編集：これは防弾ソリューションであることは提案していませんが、多くのタイプミスを回避するのに役立ちます。
Hunspell または Aspell などのスペルライブラリをプログラムに統合できます。
library(hunspell)
# Check individual words
words <- c("beer", "wiskey", "wine")
correct <- hunspell_check(words)
print(correct)
# [1] TRUE FALSE TRUE
あなたの編集者：
またはビルドパイプライン：
spell check HTML:
image: tmaier/hunspell:latest
script:
- export HUNSPELL_FINDINGS=`hunspell -l -i UTF-8 -d de_DE_neu,en_US -p .words -H public/**/*.html | sort | uniq`
- echo $HUNSPELL_FINDINGS
- test "$HUNSPELL_FINDINGS" == ""
dependencies:
- build
stage: test
allow_failure: true
選択したエディターの「辞書に追加」機能を使用して、プロジェクト固有の専門用語をスペルチェックするカスタム辞書ファイルを作成します。
参照
恥ずかしがらずにコードをレビューできる人を見つけてください。
問題の1つは、プロジェクト全体がコードをレビューしてエラーを見つけると、顔が見えなくなっていると感じることです。おそらく、プロジェクトに誰かがいて、コードを確認するためにペアリングできる人がいるのではないでしょうか。画面共有、スクリーンキャスト、パッチ、別のブランチでの作業など、これらの方法のいずれかを使用して、プロジェクトチームの他のメンバーが見る前にコードを共有できます。
もちろん、見返りとして、その人に同じまたは他のサービスを提供する必要があります。たとえば、アーティストを兼ねている場合は、アイコンや必要なものをすべて提供できます。
過去の間違いが二度と起こらないようにしてください
これは型付き言語ではより簡単ですが、たとえば、$ thisではなく$ thsiをときどき書く場合は、エディターのスペルチェッカーを有効にします。より複雑な場合は、それをキャッチするテストケースを作成してみてください。
たとえば、国際化に使用するプロパティファイルの編集を数回間違えたため、一部のキーに英語の値がありませんでした。私はファイルを修正してから、すべてのキーを一度にロードし、不足しているキーがある場合は失敗するテストを作成しました。
より良いツール/言語への投資
使用しているエディタよりも優れたエディタがある場合は、それを使用してください。使用している言語よりも優れた言語がある場合は、それを使用してください。もちろん、「より良い」とはさまざまな要因に依存しますが、その1つはプロジェクトにすでにあるコードです。ターゲット言語が本当にひどい場合は、より優れた言語からコードを生成することもできます。そうすることで失うものがいくつかありますが、そのオプションを知っておくことは良いことです。実際には、これを1回だけ実行する必要があり、非常に反復的なJavaコードを完全に文書化する必要があるコードに対するいくつかの要件が与えられた場合、3000行のJava別の言語の50行からのコード。