ユアマイスター株式会社エンジニアブログ

ユアマイスター株式会社のエンジニアが日々徒然。

「コードをはやく書くにはどうしたらいいですか?」という質問への回答

f:id:yourmystar_engineer:20181204113538p:plain

どうも。ユアマイスター星(@inase17000)です。

先日、メンバーのひとりからふと質問されました。

コードをはやく書くにはどうしたらいいですか?

なるほどどうして、自分自身も決して快速コーダーではないので、自分が1〜2年目だったころにどんなことを考え、先輩たちにどんなことを言われて育てられたかを思い出してみました。

足りない観点がありましたら是非ツイッター等にコメントもらえると嬉しいです!

コードをはやく書くには、、、大きく分けて3段階が肝心だと思います。

1個ずつ書いていきます。

1. コードを書く前の、はやくなる秘訣

道具を整える

まずは、大きなモニターや使いやすいキーボードを用意しましょう。エンジニアにとって一番付き合う時間の長い道具になるわけですから0コンマ数秒の違いも積み重ねでボディーブローのように効いてきます。おすすめはHHKBのようにコンパクトのものにしておいた方が手の小さい人は作業効率が上がります!

影響範囲を把握する

「あちらを立てればこちらが立たず」で、実装が行ったり来たりにならないように、実装の前にコードの影響調査をする時間を取りましょう。変数名やメソッド名でのgrepといった詳細なレベルのこともありますし、アプリケーション全体から考えて追加するクラスの責務などアーキテクチャに関わるレベルのこともあります。

この調査方法の種類が何個あるかというのがエンジニアとしての経験値、つまり資産になっているので積極的に自分よりできるエンジニアがどんな風にやっているか真似て自分のものにしましょう。俗に言う「バグのにおい」もこの段階で嗅ぎ分けられるようになると最終的な所要時間の短縮とクオリティアップに寄与できます。

書く順番を考える

アプリケーションを作り上げようとするときに失敗パターンの1つは、データ設計(MVCでいうM)を後回しにすることです。

全体を見通し、データベースにデータを入れる機能から作り上げていくことで、途中からテストが格段にしやすくなります。Webアプリケーションは結局の所、データベースのCRUDをユーザーのやりやすいようにUIを整えてあげるというものなので、根本のデータ設計でミスってると確実に手戻りが発生します。

あるいは、その手戻り上等で進める方法もあります。しかし、プロジェクトのリリースが決まっている場合、アサインされたエンジニアを追加しようとしても、データ設計が不十分なままで実装が進んでいるとキャッチアップのコストが増え結果的に全体の時間は増えることが多々ありました。

1スプリント内で完全版を実装できない場合は要件を区切り、データから揃えることをおぼえておきましょう。

通化、使い回しを考える

今必死にprivateメソッドで書こうとしているその処理、過去20年間誰もやろうとしなかった処理か深呼吸して考え直してみよう。だいたいの場合、実は言語が用意している基礎関数だったり、フレームワークやライブラリでちょうどいいクラスがあったり、そのプロジェクトが用意している共通コンポーネントで解決できることが多いです。

自分でロジック書き上げることに達成感はあれど、常に顧客へ価値を最速で届けることとの天秤にかけてほしいです。ここではググる力が問われるところなので、先輩たちが普段どんな風にググってるかを盗みましょう。

また、3回以上やる処理は後のために共通化にTRYはしましょう。DRY(Don't Repeat Yourself)大事。

2. コードを書いてる最中の、はやくなる秘訣

カラム名、変数名、メソッド名などの名付けに命をかける

リーダブルコードにも「2章 名前に情報を詰め込む」「3章 誤解されない名前」と本の大部分を使って説明されているくらい大事なことです。

  • 明確な単語を選ぶ
  • 汎用的な名前を避ける(あるいは、使う状況を選ぶ)
  • 抽象的な名前よりも具体的な名前を使う
  • 接頭辞や接尾辞を使って情報を追加する
  • 名前の長さを決める
  • 名前のフォーマットで情報を伝える

これらの観点をちゃんと体現できるようになると、自分も他人も迷わないコーディングが可能となり、手戻りも大幅に減らせるようになります。名付けは大事。

できるだけ早期にコードレビューを入れる

相手の時間を奪うことになるのでためらいがちですが、あとあとまとめてドンとレビューを頼まれて、もっさり指摘をするよりは、その実装をしている段階で相談されたほうが全体最適な場合が多くあります。

早期にコードレビューを入れないと何が起きるかと言うと、コードレビューを体験した人なら誰しも感じたことがあると思いますが「こんなにたくさんファイルがあるんじゃ、いちいち全部見きれないよ・・・」とモチベーションが下がるのと同時に、レビューが返却されてくるまでのリードタイムも増えるので、自分だけでコントロールできない時間も増やすことになります。

その解消のためにユアマイスターでは、最近、部分的ではありますが、ペアプロも行っています。実装しながらついでにレビューも済ませてしまう唯一解だと思っているのでドンドンやっていったら良いと思います。それまで自分では思いつかなかった方法やショートカットキーの所作ひとつまで、他者から見習うところはたくさんあります。

ショートカット、スニペットを活用する

ほんの小さな工夫なんですが、コーディングする中で毎回書かなくていい部分って肌感で2割〜3割くらいあると思います。それをいちいちコピペをしたり諳んじて書き起こすことは、なんとなくエンジニアやってる感はあるんですが効率はよくありません。

弊社のエンジニアは下記のようなスニペットを登録していました。各自の環境に応じて必ず毎回打ってる物があると思います。それがどんなものがあるか、スニペットに登録するならどうするか、考えて準備しておけば資産として今後活用し続けられるでしょう。

例)

  • this と打ったら $this->
  • now と打ったら date('Y-m-d H:i:s')
  • set と打ったら $this->set(compact(''))

3. コードを書いた後の、はやくなる秘訣

他人のソースコードをいっぱい読む

便利な世の中で他人の書いたソースコードを読む機会はどんどん増えています。自分の興味のある領域で、スターがたくさんついてるレポジトリーを覗いてみるとか秒でできます。

https://github.com/trending

あとは、利用しているOSSソースコードを読んでみるのも理解が深まり、実装時の加速に寄与します。

例えばユアマイスターではCakePHP3系を利用しているので、毎回バージョンアップのたびに、リリースノートを眺めながら改修があった機能やその経緯をGitHubを追いながらチェックしておくと、「共通化、使い回しを考える」にも活かされるので継続的にやることをオススメします。まずは自分たちが使ってる道具の特性を知るところから。

指摘、工夫点、新知識をアウトプットする

新しい観点を取り入れたり、知らないことを知ったりしてインプットしただけで成長感を感じることが少なくありません。しかし、インプットした情報を2週間で3回以上アウトプットしないと実は定着しません。(出典:アウトプット大全)

この頻度を意識して、1回目どこかにメモをとり、2回目誰かに話してみて、3回目Qiitaやブログに残す。そんなサイクルが理想的で、同じところでループするのではなく螺旋状の成長ができます。

実際、コードをはやく書くことに意識が集中していると、コーディングしている時間以外のところに目を向けなくなったりしがちですが、このアウトプットが次回のコーディングの迷いを減らしどんどん加速していける下支えとなること間違いありません。


と、ここまで書いてきて違和感を感じた方もいらっしゃったと思いますが、僕があえて「はやく」と平仮名で書いていたことには意味があります。

スピードがはやくなる「速い」だけが重要ではないから、あえてこう書いてみました。3段階の準備をしっかりやることで、各工程を「早く」に終わらせる事もできるようになると思います。浮いた時間で、新しい技術のキャッチアップや、新たに得た知見のアウトプットに使えると、自身がさらにパワーアップできるようにできると良いスパイラルに入っていけると信じてます。

本文中に記載した本のリンクも貼っておきます。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

学びを結果に変えるアウトプット大全 (Sanctuary books)

学びを結果に変えるアウトプット大全 (Sanctuary books)

以上、今日は天気が良くて暖かい!