【読書メモ】エンジニア100人に聞きましたおすすめ一冊編 ～リーダブルコードを読んで～
【今回の紹介】
以下のようなサイトで新人のエンジニア向けの書籍が紹介されている。
エンジニア100人に聞きました」〜新人エンジニアにお勧めする一冊編〜
「エンジニア100人に聞きました 〜新人エンジニアにお勧めする一冊〜」ドリコムの場合 #e100q
今回はこの中から、以下の本を読んだ。
理由は、最近業務でやっとPGを行うと機会をもらったから。
少しでもわかりやすく、品質の高いコードを生産したいため。
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
【内容】
■全体的な感想
個々のプログラミング言語に関する入門書は、飽和するくらいある。だが、本書のようにプログラミング言語の多くに通じるわかりやすいソースの書き方・礼儀・作法みたいなものを体系的に書いている書籍は少ない。汎用的な内容なので、どの言語を扱っているプログラマーでもためになるのかなと感じた。
自分でソースを積極的に書き出して、半年くらいだけど、とてもためになったと思うし、もう少し早く読めば良かったかなとも感じた。また、少し時間をおいて経験を積んだ後に、読みなおしてもよいなと感じた。
■すぐに実践できること
①良いコード＝他者が理解するのに時間がかからないコード
→短いコードがすべてよいわけではない
②命名に気をつける
→名前に情報を詰め込むことで可読性・バグの発見率があがる
・抽象的ではなく具体的
・接尾辞・接頭辞で明確にする
・汎用的な名称を避ける
・長い名前でも、わかりやすい名前を選択する
・他者が見て誤解される名前でないことを自問すること
※入力補完があれば、名前の長さは気にしない。
グローバル変数には特に気をつかう
//悪い例
var size=""; var get="";
//良い例
var size_csvfile=""; var get_fileurl=""
など
③秩序のある順序で一貫性をもって並べ、見やすくすること
→意味のある順序で並べることで、可読性・バグの発見率があがる
・引数の順番
・処理の順番
・使用する順番に宣言する
などなど
④意味のあるブロックにし、コメントすること
→ソースの羅列よりも、処理ブロックでのコメントがあると、可読性があがる
⑤コメントすべきでないこと
☆コメントすべきこと
・クラスやメソッドの要約コメント
・定数の理由を書く
・コードブロック単位でのコメント
☆コメントすべきでないこと
・コードから抽出できること
・変数名や関数名の補助するようなコメント
（わかりづらい命名そのものを変えるべき）
⑥特に読みやすい理由がなければ、条件文の条件は肯定にする（無駄に!とかは使用しない）
⑦変数の宣言に気をつける
→変数が参照範囲またはその数に気をつけることで可読性が上がる
・変数のスコープはなるべく小さくする
（スコープが多いとどこで使われているかわからず保守しずらい）
・使用しなくなった変数はすぐ消す
・変数をなるべく減らす
⑧抽出できる処理は抽出（外出し）する
→再利用・保守しやすいのため
・なるべくプロジェクトから切り離す汎用的な関数にすること
引数・返り値に気をつけること
※あくまで目的は再利用・保守しやすさのため、分解しすぎる必要はない
⑨一度に行う事は一つにする。
→処理を整理するために、処理に必要な手順の列挙し、順序付けを行う
順序付けした後はなるべく小さな部品にし、外出しできるものは外出しする
■メモ
個人の趣味として書くコードについては上記大部分が実践できそう
だが、仕事になると意識はするものも、実践できないものが少なくない。
メモレベルだけど、まとめておく。
①pjの途中からだと実践しずらい。
・既存ソースとの統一感とのバランス
・上記のようなあるべき姿が共通認識として開発メンバに理解されている必要がある
②リファクタリングに関する理解がある
既存のソースをわかりやすく変えていくことは
・保守性
・バグの発見率
などの点からよいこと。
だが、現状として、絶対必要なことでない。（既存のシステムが問題なく動いていれば）
したがって、自分が開発をする中で、
・やたら引数が多い関数
・紛らわしい変数が多い関数
・参照される箇所が多いのにべた書き
・ほぼ同様の処理内容だが、別の関数として使われている
などは見受けられるが、どうしても「今の」開発を優先する。
進捗によほど余裕がなければ、既存ソースの改善はされないだろうし、できないなと思う。
（やりたいけど）
また、ひどいコードだからこそ改善したソースの影響を調べるのにも工数がよりかかるだろう。
あと、問題ソースの作成者が近くにいるのも問題の一つ。笑
必須でない既存のソースを読みやすくしている工数をとるほど余裕がないのが現状だと思う。
あることを契機に、たとえば
・追加改修
・機能追加
・障害発生
などで、既存コードに触れてだれかが犠牲者になるだろうなーと。
