この記事はC言語での実装を否定するものではありません。私もC言語で数十万行実装した経験があります。カーネルやデバイスドライバなど、頻繁に繰り返しCPUリソースを消費するコードは、C言語は適切で、効率の面でも許容の範囲だし、Linuxの成功をみれば有効性は証明されていると思います。更にカーネルに近いところで、デーモンプロセスがC言語で記述されているのも、stdlibを効果的に叩く上で合理的だと思います。
しかし、Linuxの上にアプリケーションを開発してサービスするようなシステムを開発する場合に、C言語を選択するのは明かな技術選択ミスでしょう。このミスは後で多額の保守コスト、頻発する脆弱性問題につながり消耗することになってしまいます。
C言語のFP生産性は低い
IPAのソフトウェア開発データ白書2018-2019によると、C言語でのFP生産性の中央値は0.065 FP/人時に対して、Javaでは0.079、VBでは0.146となっています。ちなみにFPはファンクションポイントで、ソフトウェアの見積もり手法の一つのFP法の点数です。
より高級な言語を使うことにより生産性が高くなるのは、そもそもサクサクつくれることが目的だったりしますので、当たり前のことです。
VBは分かりやすい結果になっていますが、JavaのFP生産性がそれほど高くなっていないのは、設計がオブジェクト指向で必要以上に凝りすぎる傾向にあるので、言語仕様ほど生産性が上がっていないのだと思います。私もJavaで実装しているとすぐにデザインパターンを持ち出して、あーでもないこーでもないと試行錯誤して、あっという間に一日費やすようなことをしてしまっていました。
IPAのデータはもう古いですが、最近だとVBの代わりにJavaScriptだったりPythonも高いFB生産性のデータが取れると思います。
C言語のSLOC生産性は普通
IPAのソフトウェア開発データ白書2018-2019には、SLOC生産性も載っています。C言語の中央値は5.14 SLOC/人時、Javaの中央値は4.98、VBの中央値は7.24になります。SLOCはSource Lines Of Codeでコード行数のことです。
中央値だけ見ると、C言語よりJavaの方が1行書くペースが遅いというのは面白い結果です。これは先に書いたように設計にこだわる人がJavaを使うからじゃないかなと推測します。VBはそもそも短く書けるのに、一行書くペースも早いのは、それだけ適当な開発にVBを使っているからだと思います。
低水準言語と高水準言語の境界
昔々、機械語で実装することが普通だった頃、低水準言語と高水準言語というのがあって、その境目は人の目で読めるかどうかにありました。機械語も空で逆アセンブルができるつわものにとっては高水準言語というのもあるかもしれません。
2000年頃から、その境目はセキュアな実装ができるかどうかになっていると思います。CやC++ではどうしてもメモリ管理に抜けが生じてバッファオーバーフロー攻撃に対して脆弱になってしまい低水準な言語といえます。JavaやPythonなどメモリ管理が内蔵され、実装者が触れなくなっているものは高水準な言語といえます。
C言語をまともに読めない人が大多数
機械語を見ただけで逆アセンブルできるつわものはかなりレアですが、どんな汚いC言語でもすらすらと読める人は割と多いと思います。BSDも含めて昔のOSSの実装なんて、C言語を習いたて大学生が書いた汚いコードが非常に多かったです。そんなコードでもぶつぶつ言いながら読んでいくうちに、いつの間にかすらすらと読めるようになったものです。
コード読解力が高いと仕様書は必要なくて、数万行程度のコードならすぐに機能追加とかメンテナンスくらいだったらできてしまいます。
しかし今は低水準な言語ほどコーディング規約に則って綺麗に書くことが当たり前になっています。ちょっとエレガントなコードを書くと文句を言われてしまう時代になってしまいました。当然そんな中で育ってしまったエンジニアはコード読解力がとても低いのは仕方がないです。
そんなエンジニアだらけになった今、保守をするためにコードだけ渡されても何もできないと文句を言い、ドキュメントが大量に残っていても、どうせコードと対応が取れなかったり、バージョンが違ったり、間違いがあったりで、結局何もできず八方ふさがりになります。
要するにC言語で一度実装したら、実装した人がいなくなったらもう保守はできなくなるということです。できることはあきらめてリファクタリングと偽って作り直すことになって、結果的に保守コストは跳ね上がります。
まとめ
C言語は、カーネルのコードをすらすらと読めて、常に細心の注意を払いながらセキュアに実装できる一部の職人のためのものです。中途半端な人達がC言語のソースコードをメンテナンスするのであれば、バッファオーバーフロー攻撃に怯えながら、莫大な保守コストを払い続けることになります。
商用で開発するのであれば、そんなC言語を好んで選択する必要はありません。作ることだけでなく製品のライフを考えて、アプリケーションに応じて適切な言語を選択することは商品設計の基本です。
コメント