ゴミ箱の中のメモ帳

まだ見ぬ息子たちへ綴る手記

企業のソースコードのコメントについて

アクセス解析を見ていると、昨日から「はてなブログ構成スクリプトのコメントが生々しい」へのアクセスが多いようだ。

調べてみると、「はてなブログが遅いのはだいたいJavaScriptのせい」で先の記事と同じようにはてなブログのコメントについて言及されているようで、その記事について言及している「はてなブログのJavascriptコメント抽出してたら、なんだかプログラマあるあるネタになってた」のコメントにて私の記事にリンクを頂いているようだ。

そもそもここまで話題になったのはid:naoyaさんが「 些末なコードレビュー」を書いたことで始まった様子。

このコメントについての意見の食い違いは私がプログラムを始めた10年強前には既にあったし、id:naoyaさんが言われているようにソースコードのフォーマットについてと同じように解決されない問題になるかと思っている。若輩者の私が言うのもなんだが、私にも思うところがあるの記事にする。

「へんな会社」のつくり方 (NT2X)

「へんな会社」のつくり方 (NT2X)


まず私は前出の記事に書いたように、

私が昔に働いていた職場では、コメントをつけるのにも変数を増やすのにも、コードを削除するのにも増やすのにも全て管理番号が必要になり、コードが非常に読みづらく、コメントを残すのすら嫌になってしまう状態になっていた。

という厳格にルールが決められ、コードの「削除」が一切許されていない職場に居たことがある。先には「コードを削除するのにも」と書いているが、実際はコードの削除は許されておらず、コメントアウトにてコードを「除去」し、そのコメントアウトにもコード管理として許諾番号を割り振りコメント内に追記した。数十行のコメントとコメントの間に1行だけコメントアウトされていないコードがあることがあり、いくら読みづらくてもそのコードをコメントの上下に移動させることすら出来なかった。
コードをいじるには全て管理番号が必要になるのだが、「機能変更」が「バグ改修」以外にはコードの変更は許されておらず、「コードが読みづらい」というのは「管理番号」の発行対象となることはなかった。

そのような職場では尋常でないほど開発効率が悪く、プログラムを書く事自体にも嫌気が差す程になる。コードを新しく書くには、コメントの上に書くか下に書くか、「今後ここがコメントアウトされたらコードが分断されるので、効率は悪いがここに書いておこう」というような気を回さなければどんどんと読みづらさは増していく。そのようなプログラミングは決して楽しいものではない。いわば苦行になる。


このような経験をしているので、私は「プログラマの判断」で自由にコメントを追加できたりコードを変更出来る職場に憧れを持っている。それはプログラマの効率ややる気を上げることが出来、プログラムの品質や効率を上げることも出来ると考えている。

ただここで私の環境と異なるのは、私はその職場で携帯電話アプリケーションの下位レイヤを開発していたということになる。いくらコメントを追加し多少効率が悪いコードを書いたとしても、コメントはコンパイラによりバイナリには変換されず、効率はコンパイラにより最適化される。いくら「開発者」が読みづらいとしても「利用者」には全く影響のないこととなっている(コードの読みづらさからバグが増えるというのは別の話だが)。

今回のこの話題はJavascriptのコメントの話題になるため、Javascriptではコードがそのままユーザに届けられてしまう。コメントを書けばそのままユーザに届き、効率の悪いコードであればユーザのリソースを奪うことになってしまう。


だが私はこのコメントを残しておくことは問題はないと考え、個人としては歓迎するものになる。これは先に書いたような「自由な開発形態」はプログラマのやる気や効率にも響きコードの品質もこれにより左右されると言う考えもある。コメントの除去やコードの圧縮はバグを見つける際に不便になることもある。私は過去に圧縮後のソースと圧縮前のソースを対応させるためのIDEプラグインを管理していたことがあるが、このプラグインの管理にも人的リソースやコストがかかってしまう。

一企業としてはコストがかかればそれを回収する必要があるためにユーザからそれを回収しなければならない。そうなると価格の上昇や広告の増加などにもつながってしまう。先の私の職場ではコード分析にIBMのピューリファイを利用していたのだがそのライセンス費用は莫大なものとなる。結局それらは全て端末の購入費用につながる結果になる。

そして、一プログラマとしてはコメントが残っていた方がコードを解析する際にわかりやすく、更には圧縮されていなければコードパッチも送ることが可能となる。私は「はてなブログ グループ スクロールの不具合」のように過去に何度かはてなにバグ報告をしているが、それらは「ソースコードが見えている」からこそ追求できた問題であり、これがminifyされていたら原因を探そうという気力も起きなかったかと思う。


このように私は実体験からもはてなソースコードのコメントが削除、圧縮されていないことに感謝しており、これによる多数のバグ報告から「利用者」がバグに遭遇する可能性や、そのバグ改修も短期間で済むようになっているのではないかと思っている。

コメントをつけるにも「口語」ではなくて「ルールをつけろ」と考える方もいるかもしれないが、結局そのルールを厳格につけてしまうと開発効率に響く結果となってしまう。ルールを決めた以上それからズレていると「バグ報告」としてコメントの改修も必要になり、時代に合わせてルールを変えていくと「コメントの改修」が必要にもなっていってしまう。ゆるいルールは必要かもしれないが、厳格なルールは邪魔になってしまうことすらある。

「企業としてゆるいルールは…」ととも言われるかもしれないが、それは「企業の考え方」でありそれが企業の特色になる。実際にコメントを削除しコードの圧縮を行っている会社もあればそれを行わない会社もある。それがそれぞれの企業の考え方なのである。

問題があると考えれば不平をたらたらと言っていないで、自分の出来る範囲の行動を起こすべきだ。悪だと思うのであれば問い合わせをすればいい。


だが今までに何度かバグ報告した中で返事がもらえないという残念な経験がある。バグ報告一件に付きステッカー一枚でも貰えたら手元に蓄えているバグ報告を進んでするのにな。

「へんな会社」のつくり方 (NT2X)

「へんな会社」のつくり方 (NT2X)

はてなの花 (愛蔵版コミックス)

はてなの花 (愛蔵版コミックス)