読みやすいコードに対するエンジニアのレベル

「ソフトウェアエンジニアの心得」で説明している資料からの引用です。

---

1. 読みやすさどころではない
   • 初心者の場合には、読みやすさまでは注意がいかないし、コーディングが終わった後でも、読みにくいかどうかが判断つかないレベル。
   • プログラムは動作すればよいと考えてしまい、デバッグが終わったら読み易さに対して無頓着。
2. コーディング中に気づかない
   • コーディング中はコードを書くことにのみ意識がいき、読みにくいコードや重複したコードを書いているかどうかまで注意が回らない。しかし、コーディングが終わった後で、見直してみたらそれに気づき、修正するレベル。
   • プログラムは動作すればよいと考えてしまい、デバッグが終わったら読み易さに対して無頓着。
3. コーディング中に書き直す
   • コーディング中でも、常に読みやすさや改善すべき点に気づき、コーディング中にどんどん修正するレベル。
4. デバッグ後も重要だと認識している
   • 単体テストでデバッグが終わっても、コーディングが終了したとは考えない。さらにコードを書き直して出来る限り綺麗に読み易くして、コーディングが終了したと考える。
   • 常にコードをクリーンにすることを心がけている（ボーイスカウト・ルール）。

このおおざっぱなレベル1からレベル4ですが、社会人となってどのような開発組織でソフトウェア開発を行ってきたかによって、4、5年以上のソフトウェア開発経験があっても、レベル1かレベル2程度であったりします。

さらに、テスト駆動開発によるリファクタリングを経験したことがない人は、テスト駆動開発でリファクタリングが安心してできる開発に移ってきても、「Red-Green」で終わってしまい、「Red-Green-Refactor」ができなかったりします。

読めないコードは書き直せ

プログラマー”まだまだ”現役続行 (技評SE選書)

• 作者: 柴田 芳樹
• 出版社/メーカー: 技術評論社
• 発売日: 2010/09/04
• メディア: 単行本（ソフトカバー）

第4章「読みやすいコードを書く力」からの引用です（p.79）。

読めないコードは書き直せ

　もちろん、コメントやドキュメントを書くこと自体を否定するつもりはありません。
　ただ、本来コメントやドキュメントというものは、プログラムが十分読みやすく書かれていることを前提に、プログラムを読んだだけではわからない事柄を補足するために書くものであって、読みやすさを考慮していない複雑なプログラムを読むための手がかりとして書くものではありません。
　つまり、読めないプログラムにコメントやドキュメントを書くぐらいなら、プログラムそのものを読めるように書き直すべきです。そして、可能なら、最初から読みやすいプログラムを書くべきなのです。
　しかし、ほとんどの人は、最初から読みやすいプログラムを書くことはできません。
　なぜなら、「どのようなプログラムが読みやすく、どのようなプログラムが読みにくいか」を認識していないと、自分が書いているプログラムが他人にとって読みやすいかそうでないかを、自分で判断することはできないからです。
　そのため、自分では読みやすいプログラムを書いているつもりでも、実は他のエンジニアにとっては読みにくいプログラムを書いてしまうのです。
　この判断能力を身につけるには、自分が書いたコードを他のエンジニアにレビューしてもらうのが最適ですが、どうすれば自分のプログラムを改善できるかを、書籍を通して学ぶことも有効です。お勧めの書籍としては、『プログラミング作法』『コードコンプリート第２版』『リファクタリング』『クリーンコード』『実装パターン』などがあります。
　レビューしてもらったり、本を読んだりして、常に読みやすいコードを書くことを意識して行う必要があります。そして、意識して行うことを継続することで、無意識に読みやすさに注意を払うようになるまで習慣化することが必要です。

プログラムは「臭う」

　初心者にはわからないかもしれませんが、ソースコードを見たり、ＵＭＬで描かれたクラス図を見たりしていると、「何か臭う」ことがあります。ある程度きちんとしたソフトウェア開発経験を積んでいる人の成果物であっても、「少し臭う」ことがあるかもしれません。
　その場合、「何か臭うな」と感じて、プログラムの動作や、さまざまな境界条件を考慮しながら、頭の中でそのプログラムを実行すると、間違いや抜け漏れに気づく場合も少なくありません。
　あるいは、間違っていなかったとわかる場合もあり、その場合には、なぜ臭いを感じたのかを検討し、臭わないようにプログラムの改善方法を考えたりします。
　一方で、プログラミング経験が浅い人や、プログラムの読みやすさに注意を払わないで長年ソフトウェア開発を行ってきている人のプログラムなどは、「悪臭」を放っている場合があります。
　ソフトウェアの設計やプログラムの臭いに対する最低限の嗅覚を身につけるには、個人差はありますが、数年は要します。
　これは新卒などに限った話ではなく、変な癖がついてしまった中堅の人たちにも当てはまります。むしろ、変な癖を身につけてしまっている分だけ厄介かもしれません。　幸運にも職場の先輩で優れた人がいる場合には、悪臭を放たないソフトウェアを開発するために、いろいろとレビューしてもらったり指導してもらったりすることができるかと思います。
　　そうでない場合には、書籍等で学習し、それを日々のソフトウェア開発に自分で意識しながら応用することで、地道に身につけていくしかないかもしれません。
書籍としては、最低限以下の書籍を読んで、自分自身でソフトウェア開発に応用する努力を行ってもらう必要があります。

• プログラミング作法
• 達人プログラマー
• リファクタリング
• アジャイルソフトウェア開発の奥義
• コードコンプリート第２版
• パターン指向リファクタリング入門
• クリーンコード
• 実装パターン

　『プログラミング作法』は、ソフトウェア開発に関係するさまざまな観点からまとめられています。
　『達人プログラマー』には、実践的なプログラマーが心がけて、日々のソフトウェア開発に応用すべきことが書かれています。
　『リファクタリング』には、ソフトウェアの機能を変更することなく、プログラムの構造をどのように改良するかについて書かれています。そして、書かれているリファクタリングの手法の多くが、ＥｃｌｉｐｓｅなどのＩＤＥによってサポートされています。
　『アジャイルソフトウェア開発の奥義』には、オブジェクト指向開発において習得しておくべきさまざまな設計に関する事柄がまとめられています。
　『コードコンプリート第２版』では、プログラムの読みやすさについて、プログラミングのさまざまな観点からまとめられています。
　『パターン指向リファクタリング入門』では、プログラムをリファクタリングすることでデザインパターンを適用するという観点から、多くのリファクタリング手法が紹介されています。
　『クリーンコード』では、読みやすくクリーンなコードとはどのようなコードであるかを、豊富な例を用いて説明しています。
　『実装パターン』は、著者のケント・ベック氏がコードを書くときに、なぜそのような書き方をするのかをまとめたものです。サンプルコードが少ないので、初心者向けではありませんが、多くの観点が紹介されています。
　職業としてソフトウェア開発に従事する以上は、このように多くの良書から、自分自身で技術を習得していく必要があります。ここで紹介した書籍は、いずれも１９９８年以降に原著や翻訳本が出版されたものです。
　しかし、実際のソフトウェア開発の現場では、継続して自己学習する習慣が身についていない人の場合、せいぜい書名を聞いたことがある程度でまったく読んだことがないという人も、残念ながらかなり多いのではないかと思います。

ボーイスカウトルール

5年前に「The Boy Scout Rule」として書いている内容の英語部分を日本語にしたものです。

---

Clean Code アジャイルソフトウェア達人の技

• 作者: Robert C. Martin
• 出版社/メーカー: アスキー・メディアワークス
• 発売日: 2009/05/28
• メディア: 大型本

読みやすいコードを書くことの重要性については、拙著（『プログラマー現役続行』）の中でも述べていますが、書籍『Clean Code』には、次の記述があります。

コードを上手く書くだけでは十分ではありません。コードは時間が経過してもクリーンに保たれなければなりません。時間の経過に伴ってコードが腐り、品質が低下するのを誰しも目にしてきています。したがって、我々はこの品質の低下を防ぐために積極的な役割を演じなければなりません。

アメリカのボーイスカウトには、我々の職業に適用できる単純な規則があります。

キャンプ場を、来た時よりも綺麗にして帰ること

コードをチェックアウトした時よりも少しでも綺麗にしてチェックインすれば、コードが腐ってしまうことはありません。綺麗にするのは大げさでなくても良いのです。より良くするために変数名を変更したり、大きすぎる関数を分割したり、if文の連なりを綺麗にしたりするのです。

時間の経過に伴ってコードが本当に良くなっていくプロジェクトに従事することが想像できますか。これ以外のやり方が、プロフェッショナルだと思いますか。継続した改善こそが、プロとしての本質的な部分ではないでしょうか。

ここで述べられているように、些細な改善であっても、常に改善する心がけにより、コードは腐ることなく、時間の経過に伴って良くなっていくことになります。

今日では、テスト駆動開発により、開発しているソフトウェアの機能を確認するためのテストコードが書かれているプロジェクトも多いと思います。そのような開発では、コードの改善による機能のデグレードがないかをテストコードの実行により容易に確認可能であり、このボーイスカウト・ルールが容易に実践できることになります。

また、テストファーストによる開発では、最初にテストコードを作成して、そのテストに合格するように実装してくわけです。そして、すべてのテストに合格したら、実装が終了と思っているエンジニアは多いのではないでしょうか。しかし、そこで実装が終了と思っているようでは、駄目です。

コードがクリーンに書かれているかを見直し、そうでなければクリーンにするためのリファクタリングを行う必要があります。そして、自分で見てもある程度納得できるクリーンなコードになったら、最初の実装が終了となります。誰でも最初からクリーンなコードを書けたりはしません。したがって、テストコードによる動作確認が済んでも実装は終わりではなく、コードをクリーンにする作業を行って実装が終了と考えることは、ソフトウェアエンジニアにとっては重要なことです。