Reactで読みやすいコードを書くための心得

読みやすいコードの書き方のススメ

わたなべゆう氏：こんばんは。わたなべゆうと言います。今日は「読みやすいコードの書き方のススメ」ということで、読みやすいかどうかを気をつけていこうという内容のLTとなっております。

（スライドを指して）こちらが概要で、あとで見ていただければと思います。ちなみに先ほどTwitterのハッシュタグと、connpassの管理ページにもスライドのURLを貼っておいたので、もしよろしければあわせてご覧になってください。

僕は、株式会社g&hというところでエンジニアをやっています。あとはフリーランスというか、個人的に趣味でWebやアプリをいろいろやっていたりします。

基本的にエンジニアが僕1人なので、何でも屋というかたちです。「技術書典5」で本を出して、それがそのまま商業本として出るかたちになりました。

実践Expo　React NativeとFirebaseで、SNSアプリを最速ストアリリース！ (NextPublishing)

弊社の紹介です。3名でやっていまして、（メインは）「ストリートカルチャー×IT」ですね。「音楽とIT」「ダンスとIT」みたいな感じのサービスを運営しています。

今のメイン事業は「Weddy Weddy」というダンスアプリです。これはダンサー向けのプラットフォーム系アプリで、もしよろしければご覧になってください。

読みやすいコードとは？

では本題ということで、今日のテーマの「読みやすいコード」についてです。

僕としてはざっくり2つあります。ほかの人と作業をするときに流れが理解しやすいとか、「半年ぶりに触るぞ～」みたいなときに迷わないというか、悩まないというか……コメントやファイル名、ディレクトリ構造、果てはコンポーネントの粒度、デザインシステムといった話にもなってきますね。

今回はもうちょっと簡単というか、パパッとやっておけばいいよねという内容になっております。

（スライドを指して）これはわかりづらい例というかたちで出しています。ライフサイクルのメソッド。これがどこにあるのかもよくわからない。didUpdateが一番上にあったり、didMountが一番下にあったりと、これはちょっと迷っちゃいますね。

例えばrenderメソッドの中のインデントの位置がすごくわかりづらい。あと、コンポーネントがmapされて書き出されているけど、これがどういうものなのかがパッとわからない。

あと、三項演算子ですね。入れ子にはできるんですけれども、入れ子にしちゃうと、「あれがこうで、これがああで」みたいなかたちでちょっと読みづらくなっちゃいます。

さらにもう1個例を出すと、importの順番がすごく適当になっている。だいたいの人はimport Reactから書くと思うんですけれども、こうやって書かない人も中にはいるだろうと。

また、パッケージ自体というか、コンポーネント自体が相対パスで書かれている。そうするとファイルの構造を変えたときにメンテナンスするのが大変だよねというところがあったりします。

そして、コンポーネントに名前がついていない。このexportしているコンポーネントの名前がついていないと、エラートレースといったときに、結局どこでこの問題が起こっているのかがわかりづらかったりします。

さらに、コンポーネントにpropsとして何が渡るのかなといったことがわかりづらかったりします。

読みやすいコードにするためのポイント

これらを踏まえて、読みやすいコードにするためのポイントとして「3つプラスα」というかたちで紹介していきたいなと思ってます。

1つ目が、eslint-config-airbnbの導入です。

みなさんは、eslintとかは導入していたりすると思います。eslint-config-airbnbに関しては、ReactだろうがReactNativeだろうが、どちらでも使えるというか、どちらも推奨されています。

右上のコマンドで、そのままインストールしてもらえればよいです。基本的に行間やインデント、ライフサイクルメソッド、さらに三項演算子の中身うんぬんと、細かいところで言うと、分割代入するかしないかなど、いろいろあったりはします。

これらに関して、通常のeslintで設計すると、自分たちのマイルールみたいなかたちで、「これってどうだろうね？」「あれはこうだよね？」と、だいたいゆるくなりがちです。

だけど、eslintのairbnbに関しては、本当にガチガチです。これを導入されると困るような人もたくさんいるとは思うんですけれども、これで書くと基本的には誰もが似たような書き方になります。自分が半年前に書いたものでも、例えば変数の位置、分割代入されてるか、三項演算子がちゃんと三項だけになっているかが、わかりやすくなっています。

まとめです。eslint単体というよりも、airbnbのeslintを使うことで、基本的に「安心安全のairbnb」というか……Reactと言えばairbnbみたいな勢いもあるので、そういったかたちでいろいろとチームとしてまとまりやすいのかなと思います。

（スライドを指して）さらにこのESLint。おそらくご存じの方も多くいらっしゃると思います。VSCodeと組み合わせると、VSCodeのExtensionでESLintがあるので、それを一緒に組み合わせることでオートで自動整形してくれます。

例えば、vscode/settings.jsonというファイルを作ってあげれば自動的に保存時に整形してくれるので、その都度ワーニングとかエラーとかがいろいろチェックできるのでおすすめです。

defaultPropsを使う

次にdefaultPropsを使おうということです。defaultPropsの前に、コンポーネントを自分で作ってみようというかたちになっています。

（スライドを指して）これはまだわかりやすい方なんですけれども、テキストの中に、カラーやフォントサイズ、行間などをいろいろ設定できます。

でも、中にはもっとわかりづらいコンポーネントがあったりします。その場合にpropsを判断するとき、だいたいみなさんはコードの中身から判断していたりすると思います。

ほかの人が作ったものだと、命名規則にクセがあってちょっと困る。このコンポーネントを使いたいんだけど、そこに10分も時間をかけるんだったら、パッと判断したいよねということもあると思うので、defaultPropsを使いましょうというかたちになっています。

（スライドを指して）こちらは、カラーあたりの初期値として入れておきたいものを定義しておこうということです。何が便利かと言うと、VSCodeを使っている部分にマウスオーバーすると、（スライドを指して）このようなかたちで値の型とかが出てきてくれます。

TSを使っている方とかなら、なかなか想像が……まあTSを使っている方だと、そもそもpropsに型を定義したりするとは思うんですけれども。

普通のJSで書いている場合だとそれがないけれど、defaultPropsを設定してあげることで、VSCodeの方で判断してくれるので、なかなか便利かなということで、紹介でした。

importの整理

次にimportの整理です。importは、特に順番は決まっていないですし、どういった順番で読み込もうが、なんでもいいとは思います。

正直を言うと、ちょっと上から相対パスのものとか、Reactの位置がいつもどおりの位置にないと気持ち悪いとか、そういったこともあったりします。

とくに、今流行りのAtomic Design、Atomic Componentのかたちでやるか……Atoms、MoleculesとかOrganismsなど、いろいろあったりします。判別しづらいわけではないけれど、気持ち悪いなあみたいな思いもあったりします。

それらに関してまずやるべきこととして、package.jsonのnameをちゃんと付けてあげましょう。nameを付けてあげると、そもそもpackageとして認識してくれるんですね。

例えば、（スライドを指して）これだったら「app」という名前で登録していますが、ほかの一意な名前を付けると、そこから絶対パスとして指定できるので迷いにくいです。

ファイルのディレクトリ構造が変更されたり、いろいろとリプレイスしているときでも、困らないというかたちになりますね。

次にimport ReactやModal、AtomsやOrganismsあたりも、結局上から順番にルールを付けておくといいよね、みたいな話です。

これはただのチーム間での共有や、自分の中の整理になると思うんですけれども、ちょっと気をつけてあげると、わかりやすい感じがします。

読みやすいコードの条件

その他、まずはコンポーネントを返すメソッドをJSX内に書かないということです。例えば（スライドを指して）左側だったら、this.renderAnimalsというかたちで関数で中身を書いていたりはするんですけれども、なんとなく概要が掴みづらくなっています。

constAnimalsみたいなかたちで、renderの中に入れてリターンでコンポーネントとして返してあげると、例えば再利用がある……ほかの画面で再利用性があるよねといった場合に、そのまま簡単にコンポーネントとして分離しやすくなるので、これはなかなかいいんじゃないかなと思っています。

次に、コードの記述量を減らすということで、関数を使いましょうということですね。

React Nativeに限っては、画像などをrequireするとコード量が増えたり、一元管理しなければならないので、いろいろ面倒くさかったりします。一元管理すると、キャッシュ化も簡単にできたりしておすすめです。

今回のまとめです。

「読みやすいコードとは？」や「読みやすくするためのポイント」などをいろいろまとめてありますので、もしよろしければスライドをご確認いただければと思います。以上です。ありがとうございます。

（会場拍手）