コードを書き直すということ

まず初めにこれはリファクタリングの話ではありません。既に動いているコードがある場合の書き直し＝リファクタリングについてはすべてをひっくるめたコストパフォーマンスを重視するのは当然の話です。この記事を書き始める前に少しググってみたらすぐに色々と記事が出てきたので、そちらを参考にしてもらえばと思います。

この記事での「コードを書き直す」場面というのは初期開発（設計〜土台構築＋αくらいまで）の話で、このフェーズの設計をミスると後々かなり大きな負債になるので、見積もりの範囲内であればガンガンコードを書き直すべきじゃないかという話です。

拙いコードの共通点

これまでの仕事を通して色んなプロダクトのコードを見てきた中で、拙いコードにはいくつか共通点があります。筆頭はもちろん「命名を軽んじている」（正しく表現していない、英単語の並び順が不適切、同じ意味を表す単語の表記揺れ）で、これについてはわたしも十家言くらいはあり（そもそもプログラミング＝定義なんだから名前を正しくつけないとまともなコードになるわけないじゃんとか...）、一度きちんとした記事を書きたい気持ちもありつつ、リーダブルコードを筆頭にQiitaなどでも良い記事が色々あるのでそちらを見てくれという感じなのですが、その次が「コードを書き直すことのハードルを上げすぎている」なんじゃないかと強くおもいます。

もちろん設計から見直してコードを書き直しテストまで実行するとなるとそれなりの時間がかかるので、拙いからこそ、そんな時間を捻出できずにそうなってしまっているのかもしれないです。

しかし個人的な経験則ではありますが、初期段階に自身で設計して書いたコードはほぼ脳内にイデアが出来上がっているので、書き直しには思ったより時間がかからないですし、書き直すことで未来の負債を減らすための大きな一手になります。そして設計・コード品質についてのイテレーションが1周することは、書き手にとっても大きな成長の機会になります。

良いコードを書くということ

結局のところ良いコードを書くということは、世の中にどのような悪いコードがあるのかを知り、なぜ悪いのかを知り、どうすればよくなるのかを知り、あるいは想像し、実際に手を動かした「分量」がものをいいます。（もちろんここに頭の回転が早いとか、想像力が優れているとか、3を知って10を学べるとかの素質による係数はかかるとは思いますがそんなことを議論しても仕方がない。）

この「分量」を稼ぐことこそが良いコード、プロダクトの品質向上にも繋がるので、良いコードが書けなくて困っている人は、まずはタイピングの練習から始めましょう！（丸投げ）