一人でWebサービスを開発しているときに書いているコードと仕事で書くコードは全然違う
たまに
「実務レベルで通じるようなコードが書きたいのですが、どうしたら良いでしょうか」
といった質問がきたりするのですが、身も蓋もないことをいうとプログラマーとして仕事をしてみないと身につかないのでは.....と思っています。
プログラミング経験をちょっと積めば、なんとなく動くコードは書けるようになります。ただここから綺麗なコードを書けるようになるにはまた数段のレベルアップが必要です。
ただ、それだとちょっとあれなので一人で開発をしている時のコードと仕事で書く時のコードの違いについて説明をしてみたいと思います。
わかりやすさが大事
一人でコードを書いている時は、自分だけが理解できれば問題ありません。
でも仕事で書くコードを読むのは自分だけではありません。
今一緒に働いているエンジニアもそうですし、将来これから入社をしてくるかもしれないエンジニアも今書いているコードを読むかもしれないですよね？
今書いているコードだけをみて、動きを理解できるようになっていなければそれはわかりにくいコードです。
わかりにくいコードは理解するのに時間がかかってしまうので、それだけ開発スピードが落ちてしまいます。
わかりにくいコードは、属人化を生み出しさらに、最悪の場合誰もわからないコードに進化します。
機能追加もできず、バグが発生しても直せないかもしれないです。
メンテナンスのしやすさが大事
コードは一度書いて終わりではありません。
常に改善をし続けるものです。でもいろんなページで使われているパーツを直そうとした時、全く共通化がされておらず10ファイルも編集しなければならないのは非常に骨が折れます。
修正作業に時間がかかるし、修正漏れが発生してしまうかもしれません。
修正したファイルが多いと、その分動作確認に時間が取られてしまうこともあります。
共通化をしすぎると逆に辛いこともあるので、適切な粒度で共通化をしておくことがメンテナンス性をあげる上で大事です。
作業履歴を残すのが大事
たまにあるのですが、この実装の意図はなんなのだろう...というコードがあったりします。
ビジネス的な緊急対応で書いたコードなのか、よくわからないけどバグを直すためにとりあえず一時的に書いたコードなのか...
こうしたものはGitのコミットメッセージをきちんと書き、コミットログで何をしたかをわかるようにしておけば辿れるようになります。一人で開発している時は特に意識をしないコミットメッセージですが、何かの調査をするときに過去どんなことをしてきたのかというのがわかるととても助かる場面があるので、きちんとログを残しておくのが大事です。
わかりやすいコードをどうやって書くのか
方法はたくさんありますが、最初の頃に取り組みやすい点をあげるとすると
- 適切な機能単位でメソッドに分ける
- メソッド名、変数名をみただけで内容が理解できるようにする
という2点を最初は意識すると良いと思います。
railsでプログラミングを初めました！という方は結構メソッドに分割する、という概念自体がない方がいるイメージが結構あります。検索、登録、更新、削除といった基本機能だけであればおそらくメソッド分割するような必要もないかなと思いますがそこに色々独自の機能を追加していくとcontrollernのアクションが膨らんでいきます。
特に決まりありませんが、1メソッドの中身が20行ぐらいになってきたら、ちょっと複雑になってきたなあ〜、分割できないかなあと考えてみてください。
この辺のことは リーダブルコード を読むと丁寧に説明がされているので、まだ読んだことがない方は一読をお勧めします！
リーダブルコード
