いまさら Lines-of-code?  　ソースコードの規模を測定する際に、最もよく使われるメトリクスはコード行数、いわゆるLines-of-code (LOC) でしょう。古くからあるメトリクスである上に、計測も簡単にできます。Linux 環境であれば、wc -l コマンド一発ですし、エディタで常時表示させることもできます。 　ただし、ご存知とおりLOC は取り扱いが難しいメトリクスでもあります。特に、LOC を作業量の見積もりや、開発チームのパフォーマンスの計測に使う場合は、使い方を誤ると批判が生まれます。例えば、2つの異なるチームが「オンラインでの支払いシステム」を開発した時に、同じ期間で1000行のコードで開発したのと、100行のコードで開発したのでは、どちらのチームがパフォーマンスがよいと言えるでしょうか。ほぼ同じ機能であるならば、開発時のコストはもちろん、その後の保守メンテナンスのことも考えれば、より少ない行数で実現できた方がよいことは疑いようがありません。最近のNo Code の流行にもあるように、全くコードを書かずに実現できれば、それが最も効率が良いとも言えます。 　LOC の問題点の一つは、単純な変数の代入も、複雑な算術演算ステートメントも、同じ1行でカウントされてしまうことにあります。この問題点を解決する一つのアイディアは、行の複雑度に応じて重み付けをすることですが、「17行目のステートメントが45行目のステートメントよりも2倍の重みを持っている」などと定量的に表現することは容易ではありません。LOC は、その名の通り単位「コードの行数」を数えただけのものであり、開発時間や、生産性や、コストに直接変換できるものではありません。 　このように、様々な問題をもつメトリクスではありますが、それでもなおLOC が有用な場面は多数あります。例えば、LOCの絶対量ではなく相対的な変化に注目してチームの開発フェーズの変化を知ることができます。前述の通り、LOCの値そのものはチームの生産性と必ずしも関連性があるとは言えませんが、同じプロジェクト、同じチームにおいて、チームの先週のLOCと今週のLOC を比較することで、増加傾向であれば「設計フェーズから実装フェーズに入った」とか、減少傾向であれば「実装が一段落してテストフェーズに入った」などと類推することができます。 　他には、LOC はテストや保守の基準値として使われることもあります。10万行のソフトウェアは、1万行のソフトウェアよりも保守やテストのコストがかかるのは同意できるところだと思います。バグの数をLOC で割ったものを「バグ密度」と定義し、ソフトウェア品質の基準値として使っているチームもあります。 　LOCの計測方法にはいくつかの定義があり、チームや組織で採用する場合は同じ定義を一貫して使うことが重要です。単純にテキストファイルとしての行数(Physical LOC)を使うこともありますが、多くの場合、空行とコメント行を除いた行数(Non-comment LOC: NLOC)や、NLOCからさらに、「2つの命令が書かれた行は2行と数える」、「括弧だけの行を除く」などの換算をした行数(Logical LOC: LLOC)を用いることが多いでしょう。コメントの行数をComment lines of…

　ソースコードレビューは、近年のソフトウェア開発プロセスに不可欠な要素ですが、リリース時期が迫りメンバーが多忙になると、十分にコードの確認ができなかったり、レビュー自体がスキップされてしまうことも起こりがちです。そのような忙しい場合でも品質を一定に保つためには、レビューの効率を上げる必要があります。この記事では、コードレビューの効率を上げるために、現在(2020年)広く導入されているコードレビューツールを7つご紹介します。 ソースコードレビューとは？ 　ソースコードレビューが行われるタイミングは様々です。ソースコードマネージメントツールとしてGitHubやGitLab を利用している場合は、最も一般的なコードレビューのタイミングはPull Request (GitLab の場合Mearge Request) のタイミングでしょう。組み込み系開発などでは、ある程度まとまった単位でのコードを、メンバー全員で時間をかけてレビューするやり方もあります。コードレビューを行う主たる目的は以下のとおりです。 不具合の発見: マルウェア、バグ、パフォーマンスの問題、セキュリティホールなど、コードの欠陥を見つけることは、コードレビューの最もな重要な要素です。 コード品質の向上: ソースコード単体の不具合を見つけるだけではなく、プロジェクト全体の品質を改善します。「機能している」からといって、改善する箇所がないわけではありません。コードレビューによってリファクタリングが必要な箇所がみつかることもあるでしょう。 学習・ナレッジシェア:  新人開発者や品質保証エンジニアは、コードレビュープロセスを導入することで、開発者の意図を学ぶことができ、スキルアップにもつながります。また、チームの誰かがなんらかの理由で抜けることになっても、他のメンバーがバックアップ可能になります。 連帯感の向上: コードレビューは、チームワーク、責任感、コミュニティの形成に役立ちます。 コードレビューツール7選 　今日の市場には数十種類ものコードレビューツールが存在し、その中から組織のニーズに最適なものを選ぶのは難しいでしょう。以下では、汎用性が高くかつ堅牢なコードレビューツールを紹介します。 GitHub GitHubはプルリクエストの画面にコードレビューツールが付属しています。すでにGitHubを使ってGitレポジトリをクラウドで管理している場合、プルリクエストを使ってコードをレビューするのはもはやあたりまえになっているかもしれません。無料でも利用可能ですが、保持できるデータ量や月ごとに行えるアクション数に制限があるため、チームや企業で利用する場合は有料のオプションを選択することになるでしょう。 GitHubでは、レポジトリへのアクセス権を持つメンバーをプルリクエスト毎にレビュアーとして割り当てることができます。プルリクエストを提出した開発者は、管理者にコードレビューを依頼することもできます。変更履歴の確認だけでなく、プルリクエストの議論やdiffの分析、インラインでのコメントも可能です。コードレビューツールでは、GitにおけるコンフリクトをWebインターフェイスで解決することもできます。さらに、マーケットプレイスを通じて追加のレビューツールと統合することで、レビュープロセスの機能を拡張することもできます。 GitHub付属のコードレビューツールは、あなたの組織がすでにGitHubを利用している場合には最適なツールです。すべてが組み込まれているので、追加のインストールや設定は必要ありません。 Review Board Review Board は、このWebベースのオープンソースのコードレビューツールです。コードレビューとドキュメントレビューの両方が利用可能で、コード比較をグラフィカルに表示することができます。ウェブサイトでデモ版を試すこともできるし、ソフトウェアをダウンロードして自分のサーバーにセットアップすることもできます。Review Board の初期バージョンはかなり前にリリースされたものですが、依然として活発な開発が行われています。…

リファクタリングとは？ 　プロのソフトウェア開発者はほぼ全員知っているが、学生やアマチュアの開発者はあまり知らない用語として、真っ先に思いつくものの一つが「リファクタリング」ではないでしょうか。 　アマチュアの開発者は、多くの場合自分のためだけにコードを書きます。コードは論文発表のためだったり、自分の作りたい実験的なシステムのためだったり、目的は様々ですが、基本的には期限付きのもので必要な時にある程度動作すればそれでよく、目的を果たした後はそのまま放置されることがほとんどでしょう。一方、プロの開発者は、チームで作業を行うことがほとんどです。プロジェクトの存続期間も長く、製品を完成させた後も、機能追加・機能改善など引き続き作業が発生します。そのため、 他人が読んで理解しやすい変更がしやすいバグが生まれにくい など、いわゆる「品質の高い」コードであるかどうかは非常に重要なポイントになります。 　リファクタリングは、ソースコードの品質を向上させる手法の一つです。リファクタリングの教科書ともいえる名著「リファクタリング(第2版): 既存のコードを安全に改善する」での定義を引用すれば、 リファクタリングとは、ソフトウェアの外部の振る舞いを保ったままで、内部の構造を改善していく作業 を指します。具体的には、様々な理由で設計が劣化し、可読性が低下してしまったソースコードを、機能毎に切り分けてクラス化・関数化したり、逆に同じ処理をまとめてクラス化・関数化したり、変数や関数名をわかりやすいものに変えたり、様々な手法を用いて人間にとって理解しやすいコードに置き換えます。この際、ソフトウェアを使うユーザー側から見える挙動は変わっていません(厳密には、処理速度が速くなったり遅くなったりすることがあるかもしれませんが、それが許容できるか、あるいは思わぬプラスの効果になるかはシステムによります)。 リファクタリングにより、以下のようなメリットが得られます。 全体的な開発スピードの向上リファクタリングにより設計が改善されると、各モジュールの影響範囲が明確になります。これにより、例えば新規機能開発の際に、どこをどのように変更すればいいか、容易に理解することができ、開発スピードが上がります。 潜在的なバグの顕在化リファクタリングの作業にはバク修正は含まれていませんが、リファクタリング作業自体を通して、そのソースコードの深く理解することができます。最終的に設計やコードをわかりやすくした結果として、いままで気が付かなかったバグが発見されることがあります。 チームとしてのパフォーマンス向上前述のとおり、多くのソフトウェア開発プロジェクトはチーム戦です。自分の書いたコードを他のメンバーがデバックすることもあるでしょう。リファクタリングを行い定常的に可読性を高めておくことは、むしろ自分以外の各メンバーにとってメリットが大きいといえます。また、新しく加わるメンバーにとっても、コードの理解が容易であれば、戦力になるまでのキャッチアップの時間を最小限にできます。 逆にデメリットとしては、リファクタリングをしている間はユーザーが受ける価値は全く変わらない、ということが挙げられます。もっと悪いケースとして、リファクタリングのやり方によっては、せっかく正常に動作しているソフトウェアに手を加えることで、動作がおかしくなってしまうこともありえます。リファクタリングは、ある意味で将来への投資であり、今、ソースコードの品質を上げるコストを支払うことで、上に挙げた将来の開発上の様々なメリットを享受する行為と言えます。つまり、リファクタリングを行うか否かは、 現在の製品がユーザーに与えている価値製品の将来ロードマップリファクタリングにかかるコストリファクタリングにより、動作している製品を改修するリスク逆にリファクタリングしない場合の、将来のバグやトラブルのリスク などを総合的に分析して決断すべきでしょう。そのような決断をする際の判断材料のひとつととして、Sider Labs を使用いただければ幸いです。 リファクタリングの方法 この章ではリファクタリングの具体的なやり方について説明します。まず最初に準備することは、リファクタリング対象となるコードについての十分なテストコードを用意することです。「動いているものには触るな」という格言があるように、正常に動いているものに手を入れるのは怖いものです。加えた変更の影響範囲が把握できずに、意図せず別の箇所でバグを生んでしまうことは十分ありえます。そのため、テストコードを用意して動作を確認をしながら安全にリファクタリングを行うことが重要になります。 　テストの作成には時間がかかりますが、コードとテストと、自分の実現したいことを2度書くこと自体が、バグを減らすことにつながります。また、GitHub, GitLab などのバージョン管理ツールを導入していない場合は必ず導入しましょう。もしなんらかの問題で、動作がおかしくなってしまっても、バージョン管理ツールで正常な状態にいつでも戻すことができます。 　テストコードの準備ができたら、いよいよリファクタリングを行います。コードの可読性を上げる手法はいろいろあります。先に紹介した、「リファクタリング(第2版): 既存のコードを安全に改善する」では、リファクタリングの手法(How) が78種類ものパターンに分類されて、それぞれの典型的な手順がまとめられています。また、リファクタリングを始めるトリガー(When) となる「コードの不吉な臭い(英: Code Smell)」についても、24種類のパターンを示しています。ここでは、我々のSider Labs…

　ソフトウェアの品質を測定するためのメトリクス(指標)はいろいろありますが、本記事ではソースコードの品質を評価する指標の一つ、循環的複雑度を取り上げたいと思います。1970年代に提唱されたメトリクスであり、現在のソフトウェア開発には合わないという意見もありますが、他の指標と合わせて使うことで依然として有用なメトリクスとなります。 循環的複雑度の定義 　循環的複雑度(英: Cyclomatic Complexity) は、その名称から、単にプログラム内のループの個数を数えるものであると誤解されていることも多いですが、実際にはプログラムの構造を「制御フローグラフ(英: Control flow graph)」で表した際のグラフ内部の循環の数に着目してソフトウェアプログラムの複雑性を測定する指標です。1976年にMcCabe によって提案されました。ちなみに制御フローグラフとは、プログラムの実行中にプログラムを通過する可能性のあるすべての経路を有向グラフで表現したもので、Frances E. Allen によって提唱されたものです。 　Fig 1 に制御フローグラフの例を示します。ここで、プログラムの開始位置をノード a, 終了位置をノード f とします。プログラム中の反復や条件分岐が開始する位置と終了する位置もそれぞれノードとなり、図の例ではノードb からe となっています。ノード間をつなぐ逐次処理の部分はエッジとなり矢印で表現されます。ちなみに、逐次処理部分は、プログラム行数が何行であっても(0行であっても) 1つのエッジとなります。 Fig 1: 制御フローグラフの例 (McCabe 1976 より転載) 循環的複雑度の定義は以下のとおりですV(G)…