SonarQube Server automates code quality and security reviews and provides actionable code intelligence so developers can focus on building better, faster. Deployed by you where you work: on-prem or in the cloud.

はじめに 数年ぶりにSonarQubeを触ってみたくなり、試したところかなり簡単だったので、その感覚を残したく記事化してみました。 SonarQubeとは SonarSourceのプロダクトの一つであり、コード品質、コードセキュリティのチェックを実施するツールです。 さまざまな使い方ができるのだと思いますが、簡単に使うためにはJenkinsなどのツールと同じようにSonarQube用のサーバーとして1プロセス立ち上げ、その中でチェックと、チェック結果を確認・参照することができます。 今回やりたいこと MavenでビルドしているJavaプロジェクトに対して、ソースコードの品質が不安なので第三者チェックしてほしいと思うことがあると思います。その際に頼めるレビューアーがいないので最低限確認するためにツールにレビューをお任せしたい、ということがやりたいことです。 JenkinsのようなCI環境も手
当社はCookieを使用して、お客様が当社のWebサイトでより良い体験を得られるようにしています。引き続き閲覧する場合は、プライバシーポリシーに同意したことになります。
こんにちはー!こねひとちほーのえんじにあのフレンズ@Utmrerだよー! 今回はPull Requestを自動でチェックしてくれるDangerについて紹介します。 Pull Requestでのコミュニケーション Pull Requestのレビューは不具合の指摘やコーディングスタイルの統一、より良いコードのための提案などのために行われます。 ですが、次のようなコミュニケーションをしたことはありませんか…? タイトルにIssue Idを含めてもらえますか? WIPみたいなんですがレビューして大丈夫ですか? Base branchが間違ってます、変更してください。 変更履歴のdocsを更新してください。 このような「実装とは関係のない指摘」はできるだけ減らし、自動化したいものです。それを実現するのがDangerです。 Dangerとは DangerのGitHubには次のように書かれています。 F
Elixir コードもレビューしてくれるサービス Ebert が Plataformatec から以前にリリースされていたので、そちらを紹介します。 GitHub の公開リポジトリであれば無料で使えるとのことで早速使ってみました。 概要 タイトル通り Elixir コードもレビューしてくれるサービスです。 対応言語は最初 Elixir だけかと思っていましたが、実は結構いろいろとサポートしているようです。 Elixir については Credo を使ってレビューしてくれます。 レビュータイミングは日ごとと Pull Request が来た時です。 レビュー結果の例として ecto のリポジトリで試した結果があるので参考になります。 設定方法 add a new repository から画面上の指示に従って作ることができます。 GitHub 認証でアカウントを作った後、連携のための GitH
抽象解釈(ちゅうしょうかいしゃく、英: Abstract interpretation)は、コンピュータプログラムの意味論の健全な近似の理論であり、順序集合(特に束)における単調関数に基づいている。全ての計算を実施することなく、プログラムの部分的な実行(ある種の部分評価)をするものと見ることができ、それによりプログラムの意味に関する情報(例えば、制御構造、情報の流れなど)を獲得する。 主な応用として、形式的な静的コード解析があり、プログラム実行に関する情報を自動抽出するものである。このような解析には次の2つの利用法がある。 コンパイラ内部で、対象プログラムを解析し、特定の最適化やプログラムの変換が可能かどうかを決定する。 デバッグ時や、特定の種類のバグが存在しないことを保証するとき。 抽象解釈は、Patrick Cousot と Radhia Cousot によって定式化された。 コンピュ
モデル検査(モデルけんさ、Model Checking)とは、形式システムをアルゴリズム的に検証する手法である。ハードウェアやソフトウェアの設計から導出されたモデルが形式仕様を満足するかどうか検証する。仕様は時相論理の論理式の形式で記述することが多い。 モデル検査はハードウェア設計に適用されることが最も多い。ソフトウェアに対するモデル検査は決定不能であるため、アルゴリズム的な手法だけでは完全ではなく、証明も反証もできない場合がある。 モデルはハードウェア記述言語や専用の言語で記述されたソースコードの形態となるのが一般的である。そのようなプログラムは有限状態機械に対応付けられ、ノード(接点)とエッジから成る有向グラフで表される。原子命題の集合は各ノードと対応し、一般にメモリ要素の内容に対応する。ノードはシステムの状態を表し、エッジはある状態から他の状態への遷移可能性を意味する。その場合、原子
査読(さどく、英: peer review、ピア・レビュー)とは、学術雑誌に投稿された論文を、その分野を専門とする研究者が読んで内容の妥当性などをチェックし、掲載するか否かの判断材料にする評価や検証のことである[1][2]。研究助成団体に研究費を申請する際のそれも指すことがある。審査(しんさ、refereeing)とも呼ばれることがある。 学術雑誌における査読では専門性のほかに客観的評価が必要なため、編集部が査読者を手配して、論文著者に誰が査読するかは知らせず、査読者への接触も禁じるのが通例である[1]。 投稿前に、論文の原稿を共著者や同僚にチェックしてもらうこと[2]も査読と呼ばれる。ただし学術論文誌に掲載されるためには通常、前述・後述のようにその論文誌が定める査読を別途受ける必要があり、単に査読と言う場合は通常こちらを指す[3]。 学術雑誌や専門誌においては寄せられた原稿が全て掲載され
ソフトウェアインスペクション(英: Software inspection)とは、ソフトウェア開発プロジェクトで作成された成果物(仕様書やプログラムなど)を、実際に動作させることなく人間の目で見て検証する作業を言う。 通常のテストでは見つけられない欠陥、具体的にはコーディングルールに対する違反や極めて限定された条件でしか発生しない誤動作に繋がる問題点が検出されることがあり、プログラムを動作させて行うテストと補完関係にあるとされる。一般的に、プログラムを動作させて行うテストを動的テスト、インスペクションやウォークスルーなどのようにプログラムの動作を伴わないテストを静的テストと呼ぶ。 静的テストにはインスペクションの他に、ウォークスルーやピアレビューと呼ばれる技法がある。他の技法とインスペクションの違いは以下の通り。 責任者としてモデレーターが任命され、インスペクション作業全体を統括する 検出
この記事には複数の問題があります。 改善やノートページでの議論にご協力ください。 出典がまったく示されていないか不十分です。内容に関する文献や情報源が必要です。(2021年8月) 脚注による出典や参考文献の参照が不十分です。脚注を追加してください。(2021年8月) 出典検索?: "コードレビュー" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL 書き下ろされたばかりのソースコードや十分なテストがされていないコードは、潜在的にバグやセキュリティホール[注釈 1]などの不具合や問題が入り込んでいることが多い。また、直接的な不具合はなくとも、命名規則に従っていなかったり、モジュール分割のような構造設計が不適切だったりと、可読性やメンテナンス性に問題があることもある。最適化されていないコードは、メモリやプロ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く