コードレビュー練習会に参加してみた
最近このブログではローコードプログラミングツールのNode-REDに関する記事が多めですが、普段はコードを書く機会の多いそれなりにハイコードな生活をしています。
先日、会社で開催された「コードレビュー練習会」なるものに参加するため少しだけコードを書いてみました。
普段コードを書いているわりにレビューをする機会はないので、若手メインでいろいろな方のコードを見ることができるのはありがたかったです。今回はコードレビューとコーディングについて思うことをつらつらと書いてみます。
前提条件
最近仕事で一番使うのはPHP、次いでNode.jsとシェルスクリプトです。ちょっと前によく書いていたRuby、Java、C#はめっきり使わなくなりました。Pythonはやむを得ず読む機会は多いですが、普段書くことはありません。最近触り始めたGolangはとても使いやすいと思っています。CやC++、Fortranは20年くらい前に書いていましたが、もう忘れました。
偉そうなことを書いているようですが、自分自身、ダメなコードを書いてしまうことがよくあるのは自覚しています。時間の都合上省略したり、練りが足りなくてあとから読みづらいコードを書いてしまってごめんねー、ってなってしまったり。今回の記事に誰かを攻撃する意図はなく、理想的にはこうだったらいいなって話です。
書き慣れていない方のコードの特徴
書き慣れていない方のコードを見ていると以下の特徴があるように思います。
- 変数や関数の名前から意図が読み取れなない
- 変数名「flag」だけでは何のフラグか読み取れない
- 慣例やスタイルガイドラインにならっていない
- 定数が小文字になっている
- エラー発生時にreturn 0している
- 関数名が名詞になっている
- 変数名と実態がずれている
- 誰向けのログか意識していない
- アルゴリズム中にエンドユーザ向けのログを出力している
- 関数の利用者（他の開発者）、関数を組み込んだプログラムの利用者（エンドユーザ）どっち向けのログか意識してなさそう
- コメント無しでマジックナンバーを使う
- 「97」とか「116」とかがいきなり出てくる
- 行数が少ないコードが優れていると勘違いしている
- 三項演算子の中に複雑な計算式とか入れるのやめて欲しい
- きっとコンパイラがなんとかしてくれるから、読みやすいコードを書くことに注力してほしい
- if地獄、case地獄
- 3つくらい入れ子になったらヤバさを感じとって欲しい
コードを書く上で重要なこと
なによりも重要なのは読みやすいコードを書くことだと思っています。アルゴリズムが斬新でなくても全然問題ありません。普通が一番です。短くて動いているけど何が書いてあるか読み取れないコードは要注意です。後から誰も手を入れられなくなるので。基準としては、自分がそのコードを修正しなくてはいけない立場になったときに「何やってるかサッパリわかんね。全部書き換えた方が早いな。」って思わないものを書くといったあたりでしょうか。
どうすれば改善できるか
- Effectiveシリーズを読んでみる（例：Effective Java、Effective Ruby、Effective Go）
- プログラム言語に備わっている機能の適切な使いどころ、慣例を学ぶことができる
- 各言語向けに似たようなものは出ているはず
- スタイルガイドラインを読んでみる（例：Python、Google Java Style Guide）
- 単なるスタイル調整であればLint系ツールを導入することである程度改善できそう
- スタイルガイドライン自体に優劣はないと思っている
- 何でも良いから統一されていれば考えなくてはいけないことを減らせる
- オープンソースのコードをチラ見してみる
- ユニットテストを書いてみる
- 強制的に見通しのよいコードを書かざるを得なくなるはず
- 他の開発者が利用するライブラリを書いてみる
- 利用者を絞り込めるので、考慮しなくてはいけないことを減らせる
- 開発者からみて使いやすいインターフェイスを書く練習になる
- とにかくたくさん書きまくる
- 知識だけ蓄えても使えないと意味がない
- 書いたものを少し時間を置いて触ってみて意味不明なところが出てきたら直すのを繰り返してみるとより良いかも
さいごに
最近、義務教育でもプログラミングの授業が始まっていますが、みなさんは読みやすいコードの書き方っていつ、どこで学ぶんでしょうね。基本的には日本語や英語などの自然言語で文章を書くのと一緒で、それを読む他の誰かに意図が伝わることが重要なんだろうと思います。意図したとおりに動くのは最低条件で。
コメント
コメントを投稿