「コードを書く自分」と「コードを読む自分」を切り替えながら

アプリケーション実装者は「コードを書く」と「コードを読む」を繰り返しながら実装を進めていく。
コードを書く技術も、コードを読む技術も、業務での実装だったり、OSS や趣味で実装だったり、数をこなすことで身についてくる。
いわゆる良いコードを書く「ベストプラクティス」だったり、良いフィードバックをする「レビュー観点」だったり、「先人たちが残してくれた、こうするといいよ知見」は Web や書籍にいろいろ転がっている。
この記事ではそれらは考えずに、実装中の思考に関して書いてみる。
個人的な意見満載なので、あくまで一個人の見解であるということを踏まえながら読んでほしい。

コードを書けている現在の前提を一旦忘れる

コードを書けている現在、あなたは機能要件をもとに、比較的明確に処理の流れをイメージできていると思う。
しかし、来週の自分はどうだろうか。もしくは明日の自分は？現在コードが書けている前提がない人の立場になると、今書いているコードは果たして読みやすく、処理が追いやすいものなのだろうか。

実装中に自分を頻繁に切り替える

「コードを書く自分」と「コードを読む自分」を切り替えながら実装を進める。
このとき、コードを読む自分は「急にレビューすることになった開発者」を意識するようにしている。こうすると、とても明確になっている実装の流れのイメージを一旦退避させ、客観的にコードを見ることができる。
実装の熱を一旦冷ましてコードを眺めるのが大事。

実装の将来を考えて先に手を打っておく

客観的になると見えてくる景色がある。これによって、いろいろとできることがある。

「将来勘違いしそうだな」と思って処理を細分化したり、説明変数や要約変数を使う
「将来リファクタしそうだな」と思ってコメントを残しておいたり、先に issue 化する
実装のドキュメントとして、テストを書く
プロジェクトの構成をドキュメント化しているのであれば、それに追記する

人に優しい実装を

チームで実装していたり、長期に渡って運用されるサービスだったり、「今の自分以外」の実装者が再度コードに手を加えることがある場合、極力ストレスをなくしたいものである。
コードを読む立場になっていろいろ手を打っておくと後が楽なので、めんどくさくてもやっておくことを忘れないでおく。