プログラムは動けば問題ない

 Qiitaには、「コードの書き方」みたいな記事がよく上がっていますし、初心者プログラマが読んでおくべき本の中には、「リーダブルコード」みたいなコードの書き方的なものがあげられます。しかし、タイトルにもあるように、僕は「プログラムは動けば問題ない」と思っています。

きれいなプログラムは必要ない

 もちろんきれいなプログラムが書けるなら書いたほうがいいのですが、無理にきれいに書こうとして時間をかける必要はありません。例えば、文字を書くときも同じで、きれいに書けたほうがいいけど、伝われば問題ありません。役所に行って書類に汚い字で名前を書いたからといって、よほどひどくない限り、書き直しは受けませんよね。それと同じく、プログラムもきれいに書くことにこだわるよりも、ユーザに使ってもらえる方が大事なんです。

 初心者のうちは、1冊、コードの書き方の本を読んでおいてもいいとは思いますが、ある程度経験があるなら、コードの書き方よりも、何を作るかという設計の部分や、マーケティングのスキルを身につけたほうがいいでしょう。

何がきれいなのかは人それぞれ

 ふにゃっとした文字を見て、芸術的できれいな文字だと思う人もいれば、汚いと思う人もいるでしょう。僕が書く字も自分ではきれいだとは思っていないのですが、きれいな字だねと言われることがあります。
 プログラミングも同じで、どれだけきれいに書いたと思っていても、人によって感じ方が違うのです。会社によってコードを書くルールは違いますし、コードレビューをする人によっても違うでしょう。めっちゃきれいに書いたつもりなのに上司の機嫌が悪いという理由だけで書き直しになることだってあるかもしれません。
 それなら、とりあえず動くものを書いちゃったほうがいいですよね。急いでいればそれでもOKがもらえるかもしれませんし。

リファクタリングは基本いらない

 コードの分量が多くなった時点で、コードをきれいにする作業を「リファクタリング」といいます。僕はこのリファクタリングは必要ないと思います。エラーが頻発するようならもちろん修正は必要ですが、動いているならいいじゃないですか。
 逆にリファクタリングをしてしまったことで、思わぬところでエラーが出てしまう可能性だってあります。時間をかけて掃除したのに、そのせいでほこりが出てしまうんです。

 新たな機能を開発するときに複雑だなと思ったらついでに手直ししていけば、勝手にリファクタリングは完了します。わざわざ掃除するぞ!と意気込む必要はなくて、通りかかったときにほこりが落ちていたら拾うだけで十分です。

初心者は下手にコードを直すな

 初心者のうちは基本的にコードをきれいに書こうとする必要はありません。無駄に時間がかかってしまいますし、きれいに書こうとしても、ベテランエンジニアに直されるだけです。ベテランエンジニアが書いたコードをコピペしたり、参考にしているだけで勝手に書けるようになってくるので、わざわざ時間をかけてきれいに書こうとするのは無駄になります。

 エンジニアとして評価されるのはどんな人かというと、早く仕上げられる人です。きれいに書ける人ではありません。とりあえず動くものが書ければ、あとはレビュワーに任せましょう。そうして開発のサイクルを上げていけば、「あいつはすぐに完成させてくるな」という印象ができます。
 いつまでも考え込んで、完成させないままでいると、「あいつは何をやっているんだ」と思われて、使えない人というレッテルを貼られてしまいます。

自社サービスや個人開発は特にスピードが大事

 大企業で大規模システムを作っているなら、多少はコードをきれいに書かないといけないかもしれませんが、自社サービスをやっているベンチャー企業や個人開発の際は、完成させるスピードが何よりも大事です。
 結局ユーザは、どんなプログラムが書かれているかは気にしていないですし、多少穴があっても、小さなサービスに攻撃をしかけてくる人は少ないですから、どんどんアウトプットしましょう。

 個人開発の際も同様です。転職の時のポートフォリオ用に作るのだとしたら、特にコードのきれいさは関係ないです。面接官はコードのきれいさなんて見ないどころか、コードすらも見ません。見るのは動いているものだけです。
 だって、一人一人のコードを見るなんて面倒ですからね。

ごちゃごちゃになるならテストコードを書こう

 コードが汚くなると、開発するにも複雑すぎてわけわからんというなら、テストコードを書きましょう。テストコードは、プログラムが動くことを担保してくれるので、あんしんして汚いコードを書くことができます。

 僕はスピードを重視するので、テストコードすらも書く必要はないと思っているのですが、リファクタリングよりは、有効だと思います。