🙄

cloc: プロジェクト内のコードの行数を種類別にカウントするだけのツール

2024/03/08に公開

(※)直近立て込んでいるけれど、ある程度ブログは更新したいとの考えから生まれた記事だが、素面の状態で読み直すと結構Publishに躊躇する内容となっていた。

しかし、少なくとも嘘大袈裟な内容は無いようなので投稿。

あと最近の記事は、書くのも読むのもしんどい化が加速している感があるので、少し気分転換に。


colc(Count Lines of Code)とはコードカウントツールである。

Macのhomebrewを使用している場合、以下のコマンドでインストールできる。

$ brew install cloc

その他のインストール方法はこちら

利用方法はいたって単純で、cloc .コマンドを実行することで、プロジェクト内のコードの行数をプログラム言語別やファイル拡張子別に集計したものを表示してくれる。

長年育ててきたプロジェクトに対して実行することで、これまでの努力や成果を実感出来るといった用途で主に使用される。

例として、前回作成したインフラプロジェクトに対してclocコマンドを実行すると、以下のような結果になる。

$ cd /path/to/infra-testing-google-sample
$ cloc .
     384 text files.
     270 unique files.
     119 files ignored.

github.com/AlDanial/cloc v 1.92  T=0.39 s (687.8 files/s, 39461.4 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
HCL                            179            831           2454           4983
Markdown                        47            898              0           2270
YAML                            20             31            256           1752
Go                              13            109            182            604
Bourne Shell                     5             41             46            289
Python                           1             78             88            262
JSON                             4              0              0            219
make                             1             11             23             64
-------------------------------------------------------------------------------
SUM:                           270           1999           3049          10443
-------------------------------------------------------------------------------

ちなみにまだGoのコードを1行も書いていないにも関わらずコードカウントされていたり、HCLのコードを5,000行近くも書いた記憶がなかったりするが、これはterraform init実行時に取得してきたモジュールの中にGoで書かれたテストコードやHCLのコードが含まれているためである。

つまりterraform init時に作成される.terraformディレクトリなどを除外しなければ、自分が実装したコードだけを正確にカウントすることは出来ないので、もし正確なコード行数が必要な場合はREADME.mdに記載されているオプションなどを確認してほしい。

しかし実務においてコードの行数を厳密にカウントしたいケースがあるかといえば、少なくとも自分は一度も遭遇したことはない。

基本的にclocコマンドのオプションを一切調べずに利用し続けているが、この後で触れる活用方法を含めてもcloc .を覚えておくだけで十分というのが個人的な感想となる。

一応コードの行数が金銭に関わる事例として、自分がエンジニアになりたての頃に"ステップ単価"という言葉があったような気もするが、その辺りの事情はパンチカードでプログラミングが出来る年季の入った方々に説明を譲ることにする。

clocの活用

(このまま記事を終えるには流石に内容が薄すぎるので、自分が実務でclocコマンドを利用する事例でも紹介する)

組織内のシステム群を管理するために、マイクロサービスによる分業化という手法が一般的に採用されていると思う。

マイクロサービスはシステム管理の粒度を一定以内に抑えられる点やシステムの部品化からもたらされるメリットがある一方で、連携先のシステムが自分の管轄に無い場合、動作仕様がブラックボックスになるというデメリットもある。

デメリットの具体例として、自分の担当するシステムに機能追加等を行うケースで説明する。

もし仮にシステムの機能追加が3~4ホップ先のマイクロサービスにまで影響を及ぼすような大きな改修だった場合、基本的な進め方としては関係者を全員集めて改修影響の聞き込みや作業の段取りなどを話し合って改修を行っていくのが一般的な進め方だと思われる。

しかしこの進め方ではかなりの高確率で認識の齟齬や考慮漏れが後に発覚する。

理由としては、連携先のマイクロサービスの担当者が自分の改修に対する影響を正確には教えてくれないという点が挙げられる。

もちろん悪意を持ってそうしているわけではない。

自分の仕事が多忙な中で、他の人が管理するシステムの改修影響を聞かれたとしても、伝えられた要件と聞かれた質問の範囲でしか回答しないというのは至極当然のことである。

一方で、ブラックボックスの外にいる人間(つまり自分)が作る要件書や質問リストというのは、どうしても想像の世界から生み出されたものに近いものとなってしまいがちである。

ブラックボックス内にいる人なら確実に気づけたであろう問題のヒントとなる情報を、要件書や質問リストに記載が漏れてしまうことによって、それが後々発覚するというのがこの問題の発生過程の本質となる。

ではこのような問題をどうすれば回避出来るのかを考える必要があるが、おそらく唯一の解決策はブラックボックスをブラックボックスでなくする、つまりは連携先のソースコードも可能な限りすべて自分で調べた上で連携先の担当者とコミュニケーションを取るしかないと個人的には考えている。

よってブラックボックス内のソースコードを1行ずつ確認していくことになるが、自分の場合はまず真っ先に対象のソースコードプロジェクトに対してclocコマンドを実行している。

clocの実行結果からメインのプログラム言語のコードの行数を確認して、数千行単位なら全部読む、数万行単位なら時間と相談しつつ出来る限り全体のコードを抑える、十万行を越えるようなら自分のシステムとの連携パス上に存在するコードだけをまず確認して、その周辺にあるクラス名やメソッド名、改修における重要なキーワードなどでプロジェクト全体検索を行って、さらにコードを読み進めるーー

といった方針でブラックボックスのシステムの解析を行なっている。

ちなみに、自分がどの言語のソースコードをどれくらいの速度で読めるかを常に把握しておくと、後々同じ言語で構築されたシステムに対して調査を行う際や、オープンソースの調査の工数見積り時にある程度は役立つことからも、clocコマンドによるソースコードの行数確認はやっておいて損はない。

(そして何より自分のスキルを定量的に確認できて面白い)

なお自分が使ったことのないプログラム言語で作成されたプロジェクトの調査は現実的ではないとの反論があるかもしれないが、プログラムとは入力と出力の関係が順次、分岐、反復の3要素で記述され続けているだけという点では同じなので、少なくとも1つの言語でしっかり読み書きが出来る人であれば、あとは分からない部分を都度翻訳すればいいだけなので、自分を信じていない/やらないだけで本当は出来る人はかなり多いと個人的には考えている。

この意見に対して、宣言型言語は上記のように一般化出来ないだったり、そもそも違う職種領域のソースコードの場合、短期間で理解できるはずがないという更なる反論も出てくるとは思うが、そこはもう成長するチャンスなので気合い入れて頑張れとの激励と共にこの話を終わらせる。

ステップ数にまつわるこぼれ話

以上の話題で挙げたように、コードを読む力はプロジェクトの成否に関わる重要な能力である。

仮に就職面接で「あなたの自信のあるスキルを1つだけ教えてください」という質問に対して、「あらゆる言語のコードを規模問わず正確に解釈できます」と答えて、なおかつ付随する質問にも正しく答えられるようならば、即採用しても良いレベルのエンジニアだと個人的には思っている。

読解可能なコードの行数は個人的に非常に興味のある話題なので、ここからはそれらに関する興味深いトピックをいくつか紹介していく。

最初の話題として、天才エンジニアであるデニス・ネドリーは、ChatGPTクラスの歴史的発明が行われている施設のシステムを、たった8台のサーバーと約200万行のコードで構築して、なおかつほぼワンオペ状態で運用している。

常人がコントロール可能なソースコードの行数はせいぜい7~8万行/年程度しか増えないことを考えると、あの若さでその域に到達したという事実は、厳然たる格の違いを思い知らされる。

もし仮に同等のスキルを有するエンジニアが実在するなら、CEOよりも高額な報酬とインセンティブを与えて、なおかつ出社BGMをジュラシックパークのテーマ曲にしても許されるレベルだと思う。

しかし世の常として、上には上が存在する。

人生1つでは収まり切らない規模のソフトウェアといえば、まず真っ先にOSが思い浮かぶ。

AndroidやiOS、Windows、macOSのコード行数はいったいどのくらいなのか気になり調べてみたところ、以下の記事を発見した。

(OSのコード行数の他に、戦闘機や宇宙望遠鏡の行数についても触れていて、非常に面白い内容となっている)

https://interestingengineering.com/lists/whats-the-biggest-software-package-by-lines-of-code

この記事によると、2021年時点ではあるものの、Androidが推定1,200~1,500万行で、Windows10が約5,000万行、Mac OS X Tigerが8,000万行以上であると解説している。

この規模になると、各開発コミュニティにおける最も多くのコードを理解している人間は、いったいどれくらいの行数を把握しているのか非常に気になる。

この世には理解の及ばない能力を持った人間が一定数存在することから、すべてのコードを把握している人間が実は存在する可能性もけしてゼロではないと自分は勝手に思っている。

業務連絡として、もし上記の能力を有する方がいらっしゃっるのなら、是非何かしらの方法でその存在を教えていただけると幸いである。

(もし本当に現れたならば、個人プロジェクトの1つであるエンジニアSETIは完遂と成る)

おわり

以上がclocコマンドについての解説となる。

次こそはインフラプロジェクトのテストコード書く予定。

Discussion