＃特に主張するエントリではありません
キミのコードが汚い理由 - ITmedia エンタープライズ
最初のタイトルから見て、何か強めの主張したいらしい。わざわざ邦訳までされている。
読む前から予想できることは少なくない。
このエントリは、何らかのパラダイムの信奉者が「俺らの方が良い」と言いたいためのエントリで、多少の政治的パワーが入っているということだ。
特に挑発的なタイトルならばそう。ただの凡夫ブロガーなら「汚い」みたいな言葉をタイトル入れて生き残るのは大層難しい。このエントリが生き残ったということなら、何か著者にバックグラウンドがあるのだ。
こういう場合は最初に著者名で検索をかけてみる。するとこの人はアジャイルな何かの本を書いた人だと言うことが分かる。もうこの時点でどういう主張をするかの一部が大方予想できる。「アジャイル的なリファクタリングがコードに良い影響を与えるであろう」という主張を絶対に外さない。
クリーンなコードを書くことを自分のプロセスに取り入れる。
Agileコミュニティーにおいては、コードをクリーンしておくことは原則の1つだと高く評価している。その1つが以下だ。
優れた技術とデザインに常に留意することがアジリティを強化するこの原則は、eXtreme Programming（XP）の連続リファクタリングなどの手法の中で明示されている。XPのチームに参加するプログラマーは、常に時間をかけ、コードを可能な限りクリーンかつエレガントなものにすることが期待されている。
な？
まぁこの主張自体に文句をつけるつもりはない。ただ読む前にこの部分は予想が可能、というだけ。タイトルが挑発的でも、言いたいことはその周囲で主張される「いつものなにか」ということでもある。
コードのクリーンさというところに目が行くであろう、ということから、論点になりそうな話も見えてくる。「クリーンの基準は何？」というもの。コードの汚さ/クリーンさ(ほぼ等価)を判定する明解な基準を提示していて、かつそれが納得できるのなら、このエントリは離れ技を演じていると言って良い。たいていは「定義はないんだ」と表明するエントリになるか、間違った独善的な価値観を押しつけるものになる。まぁ今回は前者だろう。
クリーンなコードとは、美しさのように、見る人によっていろいろな意味で異なる。経験豊かなプログラマーがプログラムのソースコードを見れば、それが読みやすいかどうか分かる。彼らはさらに、コードが効率的かどうか、十分に構造化されているかどうか、そして簡潔性の面でエレガントかどうかについても素早く意見を出せる。これらの特性はどれも定義が難しいが、クリーンかそうでないかは、ソフトウェア開発者にコードを見せれば大抵は一致した意見が得られる。
幸いなことに、この後のコード例二つは画像を最大化するまでもなく「後者がナイスじゃね？」と思えるもので、正直読んでいて安心できる内容だと言うのがここで分かる。
疑問点は残る。「コードのクリーンさを学習でもって習得せよ」という中身なのだが、「クリーンさ」を定義しきれていない。
うまく書けるようになるためには、うまく読めなくてはならない。書き方に堪能になりたいときは、まずは特定の言語で利用される標準と成句の両方の読み方を理解する必要がある。コードの読み書きも同じだ。その言語と、それのうまい使い方を学ぶ必要がある。そして、優れたコードを書けるようになりたいなら、コードをうまく読めるようになる必要がある。学生に対し、コードを読んでよく考え、その品質やエレガンスについて議論しろという時間が不足しているのだ。筆者が一緒に働く光栄にあずかれた最も優秀なソフトウェア開発者の1人は、膨大な量のコードを読む。彼は、さまざまなプロジェクトのコードを読み、どうすればそれを改良できるか考えることで、うまくプログラミングするための方法を学んでいるのだ。
「うまく読める」ことが「クリーンさ」に通じる、という話なのだが、うまく読めるって何だという点がうやむやになっている。たくさん読んでも駄目な場合はたくさんある。読み方が間違っていることもあれば、読むコードが駄目な場合もある。
また、コードのクリーンさを保つためには、うまく読めるようになるだけでなく、アーキテクチャや初歩の離散数学といった別の側面に目を向けなくてはならないという主張もある。上の記事ではそこには踏み込んでいない。Write Great Codeはそういった側面に目を向けようとした本で、私が卒業した学科ではアーキテクチャの授業も回路の授業も離散数学の授業もあった。
まぁそこらへんに突っ込めないのも読む前に予想可能と言えば予想可能だ。アジャイル信奉者としての主張に「アーキテクチャの知識が必要だ」なんて言葉が入るはずもない。
各種教育機関におけるプログラミングの講義概要を見ると、講義の名称や目標にプログラミングスタイルが含まれるものもいくつかある。しかしよく見ると、目標に向けて最後までやる講師はまれであるように思える。課題や成績評価基準にも、クリアで読みやすく、うまく書かれたコードに対する評価を加味した内容がない。
定義がないものにを評価に組み入れるのは、教育機関としては難しいところだろう。私の知っている演習担当者で、コーディングスタイルによって減点するのを当たり前と思う人はいないように見える。実際どう評価したかは教えてもらってないが。
OS演習の例だが、評価者は非常に入り組んだテストをかけることで「間接的に」クリーンさを評価していたように見える。「クリーンさを保ってなければ課題にバグも仕込むだろう」という前提に立つのもありなのではないか？
我々の代ではcpの実装の正解者は0人でした(つД｀)
雑感としては大体そんな感じ。
