プログラミングをするときのお作法。キレイなコードを書くには？〜プリンシプルオブプログラミング〜
まだまだコードを書いた経験の少ない方というのは、
「変数名ってどういう名前をつければよいの？」
「この処理はどこに書けばよいの？」
っていうところが全然わからないと思うのですが、そういった方にはまずこの二冊の本を読むことをおすすめしておきます。
プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則
これらの本をちゃんと読もうとするのもなかなか大変ではありますが、（途中で飽きてくることもあるかもしれません）時間をおいて読んでみたりしながら何度も読み直すのが大切です。 また、本はよむだけでは意味がないのでこれらの本に書かれていることに留意しながらコードを書いていくことも大切です。
ちなみに、リーダブルコードについてはこちらの記事で書いています。
プリンシプルオブプログラミングの概要
プリンシプルオブプログラミングはその名の通り、プログラミングを行う上で留意しておくべき原理・原則がざーっと紹介されています。
この本では7つのカテゴリで区切られており、カテゴリは以下のようになっています。
- 前提 〜プログラミングのの変わらぬ真実〜
- 原則 〜プログラミングのガイドライン〜
- 思想 〜プログラミングのイデオロギー〜
- 視点 〜プログラマの観る角度〜
- 習慣 〜プログラマのルーティン〜
- 手法 〜プログラマの道具箱〜
- 法則 〜プログラマのアンチパターン〜
プリンシプルオブプログラミングでは、実用的なコードはほぼでてこないのですが、コードが出てこない分どっしりとPCの前でコード書きながら向き合う必要がなく「プログラミング界隈ではこういった考え方が重要視されているのだな」ということをインプットできます。 それこそ、通勤中や移動中に繰り返し目を通すような読み方をお勧めします。
以降では私が大事と思われるものをピックアップして紹介します。
プリンシプルオブプログラミングからのピックアップ
コードは必ず変更される
これはよく言われることですが、仕事としてプログラミングを行うようになると身に沁みてくるので紹介したというのと、「コードは必ず変更をされる」という前提のもと変更に強いコードを書くためにオブジェクト指向や設計手法を学んでいくのでまずこの前提を紹介しました。
現代のシステムでは作った後に変更がくわらないシステムというのはなく、ユーザからの要望や不具合などで必ずコードは変更されます。そのときに変更を行いやすいコードをかけるというのが優れたプログラマーです。 また変更に強くシンプルなコードというのは読みやすく不具合時の原因究明時に短時間で原因を特定するのを役立ちます。
プリンシプルオブプログラミングでもコードは書いている時間よりも、読んでいる時間の方が長いということを書いていて、Webエンジニアとして仕事でプログラムを書く以上、変更に強いシンプルなコードを書くというのをしっかりと気にとめておきましょう。
この他にも原則を紹介していきますが、これらがこのコードは必ず変更されるという前提に立ち、変更に強いコードを書くための原則となるのでそちらも留意しおいてください。
DRY原則 | ロジックの重複を避ける
これはRailsの設計の基本原則の一つになっていますが、DRY原則はRailsに限らず他のフレームワーク、他の言語でコードを書く際にも必要な考え方です。
DRYというのはDon't Reapeat Yourself(繰り返すな）ということなのですが、ロジックの重複をさけよという意味です。ロジックの重複というのはどういうことかというと例えばECサイトでログインユーザが出品者なのか購入者なのかを判断するロジックを考えるとすると、それぞれのページやコントローラにログインユーザが出品者か購入者なのかを判断するロジック（ user.type == 1のような）を繰り返し書くというのはアンチパターンです。
この場合の正しい方法はuserオブジェクトにis_buyer?のような購入者であればtrueを返すようなメソッドを定義して、それを呼び出すようにする方法です。こうしておけば後から、購入者であることを判断するロジックに変更が加わった場合でも、メソッドの宣言部分を書き換えるだけで済みます。
コードを書いているときに
「これはあそこからのコピペで済むな」
「なんかおなじようなコード何回もかいているな」
と思ったらこのDRY原則を思い出してみてください。そして、ロジックを共通化できないか立ち止まって考えてからコードを書いていきましょう。
SLAP | 抽象レベルの統一化
みなさんがノートをとるときも見出しなどをつけて、大項目、中項目、小項目のように分類をすると思うのですが、コードを書くときも同様です。
一つのモジュールやクラスでは同程度の抽象度の処理を行うように意識します。RailsでもDBからデータを抽出するためのクエリを作成する部分と実際にデータをオブジェクトにマッピングする部分は別れています。
メソッド単位でも抽象度のレベルを揃えることが必要で、以下のようなイメージでコードを書いてきます。
function 高水準 () {
中水準1()
中水準2()
}
function 中水準1() {
低水準1()
低水準2()
}
function 低水準1() {
// 処理();
}
・
（略）
関心の分離 | 関心ごとにコードを分離
関心とはそのモジュールの機能や目的のことです。プログラミングはなるべく小さい単位バラバラの関心を持ったパーツを組み合わせて一つのシステムを作り上げていきます。
設計技法の多くは関心の分離の実現を目標としており、Web開発で一般的なMVCという概念もこれを目標としています。
プログラムの多くの変更は、関心を単位として発生するのでコードが適切に関心によって分離されているとプログラム変更による影響がそのモジュール内でとどまります。また、チーム開発においては関心単位であらかじめモジュールを分割しておけば分業して並行して開発を進めることができます。
参照の一点性 | 定義は一度きり。再代入を行わない
モジュールの要素について宣言され定義されるのは1回限りにします。変数を宣言した後にその値を書き換えるというのは極力さける必要があります。
これを意識することで副作用の少ないプログラミングが可能になります。副作用とは、ある処理が状態を変化させることですが副作用をもたなくなると状態に変化がなく状態に依存したバグが発生することを防ぐことができます。
変数の値が広い範囲でしようされ頻繁に値が変更されるような場合は今この変数がどういう状態なのかを意識しながら読まないといけないので、コードを読むことが大変になります。
分割統治 | 大きな問題を小さく割る
初心者のコードというのは、一メソッドが100行もあるような巨大モジュールを作ってしまうようなことがあるのですが、変更に強いコードを書くには小さいメソッドに分割することが大切です。巨大なコードは副作用も埋め込まれやすく、非常にテストしづらいです。変更を加える際にはその大きなモジュール全体を考えながら変更を加えないといけないので非常に神経をつかいます。
この項目は関心の分離ともかぶる項目ではありますが、一つのメソッドでは一つの処理しか（一行ということではない）行わず、それらを寄せ集めてより大きなメソッドを作るという考え方が大切です。
メソッドが適切に分割されていれば、それを一つずつテストコードでカバーすることができ、すべてのテストコードにパスしているので、それらの寄せ集めのメソッドも適切に動作するということが証明できます。巨大モジュールは悪でしかないので責務を考えて適切に分割してコードを書くようにしましょう。
プログラマーの三大美徳
プログラマーの三大美徳は「怠惰」「短気」「傲慢」です。
ぱっと見よくわからないかもしれませんが、ざっと説明すると
プログラマは怠慢なので面倒で何度も繰り返せる仕事をプログラマによって自動化します。
プログラマは短気でコンピュータへの指示役なのでコンピュータのリソースが適切に使われていないことをしったらコードを修正してコンピュータが適切に動くようにコードを書き直します。
プログラマは傲慢なので、高いプライドを持ち人様に対して恥ずかしくないコードを書きます。
というような形です。先ほど、変更に強いコードを書くということがプログラマの目標なことを書きましたが、繰り返し行われる作業はどうすれば自動化できるのか、パフォーマンスの悪いシステムはどうすれば効率よく動くのか、変更に強いシンプルで綺麗なコードをはどのように書くのかという三つを意識しながら勉強しろということでしょうかね。
これからWebエンジニアになる人にここまでは要求されないと思いますが、晴れてエンジニアになった後にも必要な要素ではあるかなと思います。
まとめ
ここまでプリンシプルオブプログラミングの内容をかいつまんで書きましたが、関心の分離とDRY原則はこれを読んだ後からすぐに意識してコードを書いて欲しいなと思います。
Webエンジニアとして転職する際にも、どのようなことを考えながらコードを書いているかというのは提出したコードをなどで判断できるのでぜひともここに書いてあることやプリンシプルオブプログラミングに書いてあることを実践してもらえればと思います。
ここに書いたのはプリンシプルオブプログラミングの一部なので、これからWebエンジニアとして転職を考えている方はぜひとも購入して一読いただければと思います。