一般に、コード インスペクションは次の 3 つの理由で重要です。
低レベルのバグを回避します。一般的なコードの問題が、事前に発見できない場合に発生します。コンパイルまたは実行中、コード内の構文上の問題はコンパイル エラーまたはランタイム エラーに直接つながり、開発効率とコードの品質に影響を及ぼします。
統一されたコーディング習慣: すべてのチームまたは一部のコード仕様またはコーディング習慣、後のメンテナンスと読み取りを容易にするために、作成するコードも特定の形式仕様に準拠する必要があります。 # オンライン コードの品質を確保する: バージョン管理では、コードが最終バージョンの要件を満たしていることを確認するために、送信または公開する前にコード チェック作業を自動的に実行する必要があります。
golangci-lint
golang は最高のコード検査ツールをサポートしており、golang オープン ソース ライブラリで広く使用されているため、これは説明できます。プロジェクトのより良い発展とその後のメンテナンスをより良くするために、私たちもそれを導入することを試みることができます。goalngci-lint を使用しようとしたときの問題日常の開発プロセスでは、コード -> git add -> git commit - > が通常の動作です。 ; git Push ワンストップ サービス。
の前にコード インスペクションを実行する必要があります。コミットとプッシュは毎日の操作であるため、頻繁に行われる可能性があり、この手動の方法はやや面倒です。使っているうちに、いろいろなことがあり、忘れてしまったり、面倒に感じて自分のコードに自信が持てずに直接実行しなかったりするかもしれません。ですので、全体的に使ってみても、まだ非常にエグみがあり、滑らかではないことを知っておく必要があります。 <h3 data-tool="mdnice编辑器" style="margin-top: 30px;margin-bottom: 15px;font-weight: bold;font-size: 20px;">
<span style="display: none;"></span>2. gitlab ランナー モード: <span style="display: none;"></span>
</h3>
<blockquote data-tool="mdnice编辑器" style="border-top: none;border-right: none;border-bottom: none;font-size: 0.9em;overflow: auto;border-left-color: rgba(0, 0, 0, 0.4);background: rgba(0, 0, 0, 0.05);color: rgb(106, 115, 125);padding: 10px 10px 10px 20px;margin-bottom: 20px;margin-top: 20px;"><p style="font-size: 16px;padding-top: 8px;padding-bottom: 8px;color: black;line-height: 26px;">私がこのソリューションを思いついた理由は、サーバーを使用するオープン ソース ライブラリをあまりにも多く見たためかもしれません。コードインスペクション (単なるPRですが)</p></blockquote>
<p data-tool="mdnice编辑器" style="padding-top: 8px;padding-bottom: 8px;line-height: 26px;">Dockerでgitlabを構築し、チュートリアルでランナーを設定しました。これには2日かかりましたが、gitlabとランナーのci構成を学ぶ必要がありました. ジョブの設定といくつかのツールのインストールを実行しましたが、満足のいく結果が得られない可能性があります。 </p>
<p data-tool="mdnice编辑器" style="padding-top: 8px;padding-bottom: 8px;line-height: 26px;"> サーバーチェックの結果が gitlab 上にあると考えると、基本的に開発 (最初にコードをプルするとき) は gitlab に行かないことになります。では、このエラー メッセージはどのようにして該当者に届けられるのでしょうか?あるいは、複数人で関数を作成する場合、エラーはどのように割り当てられるのでしょうか?サーバーチェックを使用したこの解決策は、完了するまでに 2 日かかりました。 </p>
<h3 data-tool="mdnice编辑器" style="margin-top: 30px;margin-bottom: 15px;font-weight: bold;font-size: 20px;">
<span style="display: none;"></span>3. ローカルの事前コミット<span style="display: none;"></span>
</h3>
<p data-tool="mdnice编辑器" style="padding-top: 8px;padding-bottom: 8px;line-height: 26px;">サーバーチェックが機能しないため、コードを送信する前にスクリプトをチェックします。コミットを許可しないことにより、エラーに対処する必要があります。ハハハ(このメカニズムは)、強制的に服従させることができるとは教えてくれません(慎重に使用してください)。 </p>
<p data-tool="mdnice编辑器" style="padding-top: 8px;padding-bottom: 8px;line-height: 26px;">これで、ローカルのコミット前スクリプトの作成が始まります。インターネットで情報を検索し、自分のニーズに基づいてプリコミット スクリプトを作成しました。主に code<code style='font-size: 14px;overflow-wrap: break-word;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;color: rgb(30, 107, 184);background-color: rgba(27, 31, 35, 0.05);font-family: "Operator Mono", Consolas, Monaco, Menlo, monospace;word-break: break-all;'>fmt
と codegolangci-lint
がチェックされます。今度は絶対に成功すると思ってました!
この時点でスクリプトは記述されていますが、サーバーにアップロードするにはどうすればよいでしょうか? .git フォルダーはデフォルトではサーバーにアップロードできないため、init.sh スクリプトを記述してアップロードするしかありません。すべての開発者 初めてプロジェクトを取得するときは、それを実行してローカルで構成するだけでよく、これは非常に簡単です。
を実行してみてください。 。 。結果はうまくいきません。ここの言葉では私の気持ちを言い表すことはできません。
一連の操作の結果、golangci-lint
は単一ファイルのチェックをサポートしていないことがわかりました。
私のスクリプト チェックの原則は次のとおりです:
現在のコミットで変更されたすべての go ファイルをフィルタリングします
各ファイルを一度実行してくださいgolangci-lint run xxx.go
これは恥ずかしいです; このスクリプトの作成は私にとって少し複雑なので(それほど難しくはありません)、最初はスクリプトを使用して、すべてのファイルが配置されているフォルダーをフィルターで除外し、そのフォルダー上でのみ実行したいと考えていました。もちろん、golangci-lint
の実行プロセスに時間がかかるという問題もあります。コミットごとに 1 分間待つ必要があるとは言えません。これにより、釣りの時間が隠れて増加します。[/ドージェ]。
何度も検討した結果、比較的以前のソリューションが最終的に誕生しました。私たちの方法です。
デフォルトの gitook
の場所を、init.sh
を通じて、作成した githooks
フォルダーに変更します。特定の操作については、スクリプトを表示できます。内容. 脚本は非常にわかりやすいと思います。
pre-commit
を通じて、fmt および import チェックと自動フォーマットを提供し、それらを自動的に追加して、自分でフォーマットすることを忘れる操作を回避します。
pre-push
を使用して、プロジェクトが使用可能な状態でサーバーにプッシュされているかどうかを確認します。プッシュはそれほど頻繁ではないため、この時点でプロジェクト全体の検査が使用されます。
以上がgolangci-lint をローカルで使用するためのソリューションの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。