Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Save syguer/d37e27691b2488702cc208723b1a858d to your computer and use it in GitHub Desktop.
Save syguer/d37e27691b2488702cc208723b1a858d to your computer and use it in GitHub Desktop.
この記事はQiitaに2015年12月22日に投稿した記事です

なぜこんな記事を...?

ここ数ヶ月、エンジニアとして生産性高めるにどうしたらよいかをずっと考えています。というのも今スタートアップでエンジニアをやっているのですが、エンジニアの数が増えるよりも早く仕事の量が増えていくという嬉し涙目な現実に直面しているためです。 対策として単純に会議を減らそうとしてみたり、タイマーやToDoリストといった効率化ツールを色々試してみる等思考を凝らしてみましたが、どれも最初は効果を感じるものの、気づくとそれ自体を続けるのが目的になっていて効率化できているかわからなくなっていました。 そんな中で毎日続けられて効果を感じ続けられるものは、もっと基本的なことで。そもそも保守性の高いコードを書くことではないかという考えに落ち着いてきました。 そこで何番前じかわからない内容ではあるものの、自分なりに保守性の高いコードを書くために気をつけていることをまとめてみました。

※ 想定読者として保守性の高いコードの書き方がわからない、という温度感の方を対象としているのでエキスパートな方には退屈な内容かもしれません ※ 筆者はRubyを最もよく使っているのでRubyに傾倒した内容かもしれません

保守性が高いとは

保守性が高いが何を指すかは人それぞれ思うところがあると思うので、僕が信じている保守性の高いコードとはこういうものだというのを示します。 以下のようなものです。

  • 後から読んだ時、他人が呼んだ時に何をしているかわかりやすい
  • 変更を加えやすい
  • 再利用しやすい

なぜこの3点かというと、自分が開発している中で時間を無駄にしているなと感じるとき、即ち開発効率が落ちているなと感じるときはこの逆のことが起きているからです。 つまり、

  • さっと読んだだけでは何をしているのかさっぱりわからないのでコードを読み込まないといけない
  • 変更したら他の場所が壊れた。または変更するときの影響範囲が広すぎて迂闊に変更できない
  • ベタ書きされている、もしくは密結合になりすぎていて同じような処理を別な場所でするときに1から書かざるをえない

といったことが起きます。このようなことが起きていると生産性が著しく下がるので、これらを回避するために前述の3点を守る必要があるのです。 ここからはこの3点を守る習慣を身につけるためにどうすればよいかを紹介します。

テストコードを先に書く

まずテストを実装よりも先に書くことをススメます。 保守性の低いコードはテストを書くことが困難になりがちです。 逆に言うとテストコードから書くことで実装はシンプルにならざるを得なくなります。

例えば、テストが書けないコードは大体こういうコードになっていると思います。

  • 内部で分岐が多い
  • 副作用が多い
  • 責任範囲が複数ある

このようなコードは総じてテストケースが多くなったり、テストコードを書くためのデータの用意等が無駄に複雑になるため、テストが簡単には書けません。 テストを先に書くことで1メソッドで多くのことをやり過ぎていたり、複雑過ぎるコードになりそうというのが実装前にわかるので、シンプルで良い実装を選択するようになります。つまり日常的にテストコードを書くことでシンプルな実装とはどんなものかが自然と身につきます。 また、当然ですがテストが整備されるので後から改修する場合もやりやすくなります。

静的解析ツールを活用する

lint系の静的解析ツールを使うことで言語ごとの慣習に沿った良い書き方を知ることができます。 Rubyの場合はRubocopが一般的です。 https://github.com/bbatsov/rubocop

特に複数人で開発する際は、このようなツールに指摘される事項を揃えることでコードの個人差を減らすことができるので有効です。 余談ですがこのような作業は手作業ではなく、自動化した方が良いでしょう。 こちらの記事が参考になります

なるべくライブラリのコードを使う。そしてコードを読む

自分で実装する前にまず同じことをするライブラリがないかを確認し、あれば使うべきです。 保守性の高いコードを書く前に自分で保守しないのが一番なので。 また、よく使われているライブラリのコードは洗練されているため、中を読んで見ましょう。 ライブラリとしての特性上、モジューラブルで副作用が少なくなるようなコードが書かれているはずです。 そのようなコードを日常的に読んでいると、自分が書くコードもそれに似たような書き方をしたくなります。 自分で保守するコードを減らした上に、自分が書くコードの質も上がるので本当にオススメです。

※余談ですが、ライブラリを使うことを推奨するものの、車輪の再発明をしてみるのも同時にススメます。 自分で作ってみると意外とハマったりするものですが、その時にライブラリ側と比較することで自分の中の問題解決のネタが増えるからです。 もしハマらずにいいものが作れればそのまま公開してしまえば良いので、時間さえ許すならいいことしかないです。

まとめ

自分で書いていても当たり前のことだなぁと思うものの、当たり前のことを続けることは意外と難しいものです。 特にリソースが足りない忙しいときにこういったことをサボってしまったが為に、後で回収するときには何倍にも膨れ上がっていてどうにもできなくなっている、なんてケースが多いように思います。 時間がないからこそ、後で時間を食わないようにやりきるのが重要です。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment