「コード汚くてもデザインが見えればいいじゃん」への返答という記事を読み、太古の記憶が呼び覚まされたので書きます。元ネタはたぶんマークアップエンジニア向けだと思うので、対象じゃないかもしれませんが。
さて、僕は「コードが綺麗だ」といわれたことはなく、また、そもそも問題解決能力（なんらかの達成すべきプロジェクトや目標があり、それを達成した）以外で褒められたことはありません。コードレビューをするような環境で経験を積まなかったというのも多いに関係あるでしょう。
とはいえ、「コードが汚い」と言われたり、僕自身が他人のソースを見て「汚いコードだな」と思うことはよくあるので、そのとき感じた「うわっ汚ねえ」という気持ちの源泉についてもうちょっと掘り下げてみようと思います。
書式上の見映えは本質的ではない
なんらかのソースコードをエディタで開いた時、パッと見た見映えに違和感があると「うわっ、汚ねえ」となります。ただし、この違和感については「汚いと感じた自分の心が汚れている」場合もあるので注意しましょう。
CASE 1: インデント、タブに関する規約
タブ派VSインデント派による壮絶な戦争では多くの人が命を落とし、いまなお激しい戦火が収まる気配はありませんが、その言語ごとに規約はあるので、他の言語を見たときに怒ったりしないようにしましょう。郷に入っては郷に従え。Pythonぐらいわりきってたらいいと思いますが。
また「インデントの美しさ」にはある程度共通理解があった方がいいと思います。以前、「HTMLのインデントはない方が美しい」という方がいたのですが……
<!DOCTYPE html> <html> <head> <title>タイトル</title> </head> <body> </body> </htm>
これを美しいと言い切られると、左端が揃っているからそうなのかもしれませんが、PHPとかで外部ファイル化してたりしたら、こうやって揃えろって言われても……
なので、あまり書式上の美観にこだわるのはお勧めしません。官僚のExcel芸と同じ種類の美意識だと思われます。
そうそう、はてぶでホッテントリに入ったりすると、「ソースが汚い」とか「フォントが小さすぎ／大きすぎ」みたいな捨て台詞コメントが書かれるものですが、後者はともかく、ブラウザでのソース表示にもこだわらない方がよいと思われます。GoogleもAmazonも別に綺麗じゃないので。
「速度」という面に関しては小さい外部ファイルをインライン展開したり、改行やインデントをなくした方が早いですからね。もちろん、そういうのはサーバやデプロイ時のプリプロセッサーがやっていたりするので、元のソースはGoogleもAmazonも綺麗だと思いますよ。
あまりそこら辺でギャーギャー言うと、「あ、こいつ7年ぐらい前までの知識しかないな」ってバレちゃいます。
CASE 2: Webサイトは常に工事中
「永遠のβ版」という言葉はWeb 2.0のキーワードの一つですが、どのサイトも大体改善を繰り返しており、常にアンダー・コンストラクションなわけです。昔、ローマに旅行にいったとき、遺跡が工事中でブルーシートがかかっており大変がっかりした覚えがあるのですが、Webでは日常茶飯事です。
CSSのインデントが4つだったり2つだったりする場合も、途中まで空白4つだったのが、途中からGoogle HTML/CSS Style Guideが導入され、プロジェクトの途中で方針が変わったのかもしれません。そういう場合も「うわっ汚ねえ」で終わりにするのではなく、「なんでそうなったんだろう？」と考えた方が生産的ですね。
よくよく突き詰めてみたら、「実は途中で担当者が交代していた」「前任者は新しいものを部分的に取り入れ、途中で投げ出す癖があった」などの事実がわかり、他のヒントが浮かんでくるかもしれません。
個人的には「書式上の見映えが美しいか」よりも、きちんとしたルールが存在することの方が重要です。さらに、そのルールはオレオレルールではなく、汎用性の高いもの（PHPならPSRとか）であることが望ましいです。
その規約を守っていれば、少なくとも書式上の見映えが「うわっ、汚ねえ」となることはないでしょう。残る問題点は「なぜその規約が守られないのか」にフォーカスされます。
コードの綺麗さや簡潔さが暗黙知を要求しない
コードが簡潔であることはよいことで、ぱっと見で綺麗に見えます。が、それが暗黙知を要求するのはよくありません。
Ruby on Railsをはじめとするフレームワークではたくさんの暗黙知が必要とされますが、それはドキュメンテーションされてるからいいんですよ。良くないのは、「書かれていない暗黙知が存在し、それはコードを見ないとわからない」ことです。
CASE 1: ノーコメント
メソッドやクラス名などがきちんと命名されていれば、その詳細を見なくてもわかるといえばわかるのですが（この理想を追求して口語性を目指したのがObjective-Cだが、大括弧の違和感半端ない）、よほどの天才が書いたコードでないかぎり、コメントないと初見ではなにやってるのかわかりません。
あまり具体的なことを書くと、「こいつ俺を批判してやがる」と思われてしまうのでぼかしますが、まったくコメントのないソースを任されるのはとても苦痛です。いるんですよ、変な美意識でコメント書かない人。
命名規則とか、その人の中ではそれなりに体系化されているんだとは思いますが、正直そんなにスッと腑に落ちるものではなかったりします。なんでしょう、知り合いのライブに呼ばれていったらいきなり現代音楽聞かされるような感じでしょうか。
でまあ、「読めばわかるでしょ」ってなって、コード読むわけですが、シンタックスシュガーを引きはがしまくって行った末に見えてくるのは、教則本に載っているような、どうということのない処理なわけです。
クラスの先頭に「これは◯◯の処理を行うラッパークラスです。××から呼び出されます」って書いておいてくれれば、メソッド全部読まなくても済むわけですよ。一番美しいソースコードは、読む必要さえないソースコードです。
CASE 2: 分割／読み込みのルールが自明ではない
「コードの汚さ」からは少しずれているように思いますが、そのソースコードがどのように分割され読み込まれるのかは、かなり重要な前提知識です。これをプロジェクトメンバー全員が抑えていないと、コードがどんどん汚くなっています。
たとえば、Javaい言語だとライブラリがドメインの逆になってて、com.takahashifumiki.lib.string だとプロジェクトディレクトリの com/takahashifumiki/lib/stringが読み込まれるとか、そういう言語仕様上のインポートルールというのがまずあります。
WordPressみたいなアプリケーションレベルでも、テンプレートファイルの読み込み順というのが存在します。シングルページを表示する場合、 sigle-post_type.php → single.php → index.php という順に探すようになっていて、それとは別に、テンプレートファイルが他のテンプレートファイルをインクルードする機能というのもあります。
こうした暗黙知はドキュメンテーションされているので、参加するなら読んでおいてほしいところです。これらを抑えていないとどうなるかというと……
- 自分がこれから書くコードをどこに書いてよいかわからない
- 自信がないので、とりあえずすでに読み込まれているファイルに追記する
- 1つのファイルがどんどん肥大化していく
- 長いコードは綺麗／汚い以前に読むのが大変なので、結果的に汚いコードとなる
要するに、ソースコードの分け方が自明でないと、汚いコードが生まれる原因になるわけです。公式にドキュメンテーションされているなら、メンバーに周知すれば済む話ですが（まあ、読まない人もいますが）、作った人の暗黙知となると、これがまた困ります。
他によく見るパターンだと、CSSを3つぐらいにとりあえずわけてるヤツですね。layout.cssとかstyle.cssとか、common.cssとか。
これをポンと渡されてですよ、「はてlayoutとはなんだろう？」って、わかりますかね。僕はいままで一度もわかったことないです。「commonって、なにが共通なの？ サイトで共通なの？ プロジェクト横断で共通なの？」とか、幾つもの疑問符を解消すべく、ソースを全部見るわけです。で、その結果、「ああ、このCSSを書いた人にとってのcommonってこういう意味ね」となります。
で、明確なルールが存在しないと、style.cssばっかり肥大していくんですよ。
この分け方よく見るんですけど、教則本とかTips記事とかでそうやってわけてるからという単純な理由だと思うんですよね。「俺が教則本にそう書いてあったからとりあえずそうしている」というのはその人にとっての暗黙知ですが、他の人にとってはそうではないのです。
この場合、ドキュメンテーションで知りたいことは、次のようになります。
- あるスタイルをどのファイルに書くべきかのルール
- そのルールは破ることが許されるのか、許されない場合それはなぜか
この2つが書いてあればドキュメンテーションとしてはまずまずじゃないでしょうか。
アリストテレスはすでに存在する知識を各種の学問にわけたことによって歴史に天才として名前が刻まれています。そう考えると、手元にあるソースコードを適度な粒度に分類するのはかなり知能が高くないとできないですね。プロならば言い訳せずにがんばりたいところです。
というわけで、どんな頭のいい人でも知らないものは知らないので、ドキュメンテーションをしっかりできないのならば、暗黙知を必要とするコードを書くのはやめましょう。
複雑なコードを汚いコードと決めつけるのではなく、自分の実力不足を認める
ベンダーチェンジや引き継ぎのときなどに「コードが汚い」となって、わーわー揉めて、それに営業的もくろみが加わって全部リニューアルみたいになるのを何度か見たことがあるのですが、ただ「コードが汚く、メンテナンス性が低い」という理由だけでソースを全面的に書き直すのはよくないと思います。
ほんとうにどうしようもなく汚いコードもあるにはあるのですが、たまに自分が理解できない複雑なコードを「汚いコード」と呼んでいる場合もあるからです。
いたずらに「汚いコードだ！ 殺せー！」とかやっても、お客さんにとっては「ウンコが別のウンコになってやってきた」ぐらいの価値しかなかったりするので、「なぜ汚いコードになったのか」とかを追求する方がよいですよね。
よくよく調べてみたら、「お客さんの発注フローと期待する納期がおかしいからいつも行き当たりばったりの対応になる」とかが汚いコードの原因だったりするかもしれません。そうなると、誰がやってもそれなりに汚いコードになってしまったり。
ともかく、自分が批判者になる場合は自分の実力を半分ぐらいに見積もっておくといいですね。
サッカーのワールドカップで日本代表を痛烈に批判している人たちがサッカー全然できないのを見ればわかりますが、他人に向ける刃だけを鋭くするのが人の性。「コードが汚いのではない、俺の心が汚いのだ」ぐらいの謙虚さは常に忘れずにいたいものです。
というわけで長くなりましたが、まとめとしては……
- なぜそのコードを汚いと思うのかを常に言語化せよ
- 自分の実力不足を「汚いコード」に言い換えるな
- いつも綺麗なコードを書くことを心がけよう
みんな違って、みんないい。終わり。
[429] [429] Client error: `POST https://webservices.amazon.co.jp/paapi5/getitems` resulted in a `429 Too Many Requests` response: {"__type":"com.amazon.paapi5#TooManyRequestsException","Errors":[{"Code":"TooManyRequests","Message":"The request was de (truncated...)