コードを見る目を養いたい
他人の書いたコードを見る作業というのは、なかなかにストレスが溜まる作業だ。
良いコードというのは見ていても気持ちが良いものだ。目に飛び込んできたロジックがスッと思考に馴染んで、その中で一際目立つ違和感を指摘すれば、ほとんどの場合はケアレスミスであったり、設計者との間に生じた認識のズレだったりする。
一方、悪いコードというのは目が滑って理解が遠のいていく。構築されたロジックと期待される機能のミスマッチ感が、なんとも言えない居心地の悪さを生み出しているのだと思う。その気持ち悪さを言語化し、読み解いて伝えることができれば、良いレビュアーになれるのにと常々歯がゆい。
かくいう自分が良いコードを書けているかと言われれば、苦笑いを浮かべるしかない。可読性の高さ、修正のしやすさ、処理時間の早さ等々をまんべんなく高めてくれる最適解を目指しているつもりだが、先輩エンジニア達の指摘によって、目から鱗を零したことは一度や二度ではない。
愛読書である『リーダブルコード』はボロボロであるし、コーディングやレビューをする度に指摘や改善方法をまとめたチェック項目は、かなりの数に上っている。エンジニアとして設計書なども任せて貰えるようになり、コードの指導をする立場になりつつある。
コードを書く立場を離れる日も近いかもしれないが、それでも……いや、だからこそコードを見る目を養いたいという気持ちは、日に日に強くなっている。
コーディングをする際、何をベースとするか？
答えは設計書である。要件書を眺めただけでは浮かび上がってこないロジックを、丁寧に紐解いて図や文章にまとめた "それ" は、「その通りに実装すれば要件が満たされる」ということを担保してくれる。
設計する人とコーディングする人が違った場合、両者の共通言語が設計書なのである。先輩から口酸っぱく言われた言葉に、「誰がコーディングしても同じ良いコードが生まれる設計書が良い設計書だ」というものがある。良いコードというのは良い設計書から生まれると言っても過言ではないのだ。
自分にとっての良い設計書は、先輩の残したその言葉が全てだった。
自分が作った設計書から生み出されたコードをレビューする時、コーディングルール等は勿論のこと、「自分の設計がどのように反映されたか」という観点も加わってくる。設計者が想定していないロジックが展開されていた場合、その理由を尋ねる。もしかすると、設計者が想定していないケースというものも存在しているかもしれない。そういった際の制御について、場合によっては設計からの手戻りが発生するかもしれないからだ。
良いコードであれば、そのロジックが紐解きやすく実装者と設計者間の会話もスムーズに成り立つ。結局のところ、設計書やコードというのは、ただの成果物ではなくコミュニケーションツールの一つなのである。
どうすればコードを見る目を養えるか？
結論として「コードをたくさん見る」しかないと思っている。
悪いコードを悪いコードを認識するには、良いコードを知っていなければならない。良い/悪いというのは、結局のところ、相対的な評価に過ぎないからだ。悪いコードしか見ていなければ、それが自分にとっての最適解になってしまう。
となると良いコードがたくさん見られる環境に身を置きたい訳だが……これがまた難しい。良い文章を書くには良い文章をたくさん読むしかないように、良いコードを本のように読むことができれば良いのだが。
……という訳で、GitHubで他人のコードをたまに眺めている。フリーで公開されているオープンソースも眺めていたりする。プログラムにも著作権は発生しているのでパクるのはダメだが、「こういう書き方もあるんだ！」という発想の種くらいにはしても良いだろう。
また、組込開発をしている方であれば、「MISEA-C」というソフトウェア設計標準規格も参考になる。「セキュリティ」という観点からＣ言語でプログラムを組む上で注意すべき点がまとめられている。コードをチェックする上で見るべき箇所が学べると思う。
コードを書く作業の大半が、「良いコードを書く」ということに苦悩する時間ではないだろうか。メソッドの名前、アルゴリズムの選別、etc……明確な正解は存在しないが、「これはこういう意図で書いた！」と自信を持って言えるくらいはできるようにしておくべきではないだろうか。
