はじめに

現在新卒研修中のuHoshiです。研修期間中ということで時間の余裕があり、久しぶりに技術本を読んだので、今後役に立ちそうなこと、自分の感想を残します。
目安として自分の簡単なプロフィールを記述しておきます。

学生期間中にエンジニアバイトを2年間
非情報系
メインはフロント
リーダブルコードは昔読んだが覚えていない(小声)

この本は11章から成っているが、その中でも特に勉強になった・仕事で生かせると感じたところをピックアップしていきます。

第1章：良いコードとは何か

保守性が高い

すやばく効率的に動作する

正確に動作する

無駄な部分がない

この本では、これら4つの点を満たしたコードを良いコードと定義しているが、プロジェクトやチーム構成、技術的な要素を鑑みて判断する必要があり、一概に絶対的な正解はない。

第2章:良いコードを書くための5つの習慣

読む
書く
道具を磨く
知る
聞く

どの分野にも自分だけの発想で作品を完成させる芸術界はいない。先人たちの作品を見て、影響を受けたり良いところを盗んだりして自分の中で咀嚼することでオリジナルの作品を生み出してきた。
エンジニアも同じで、良いコードが書けるようになるには、悪いコードも含めて他人が書いたコードを日常から読むことが大切である。

次の書くに関してはそのままだ。良いコードを書くには仕事でコードを書くのはもちろん、日々の単純作業を効率化するツールやスクリプトを書いたり、新しい言語やフレームワークを自分の手で動かすことが大切である。

道具を磨くのは大切である。エディタや自動化など最高の状態にしておくことで、無駄のないプログラミングが可能になる。

読むことも技術力向上には欠かせない習慣である。書籍で学習する際は原典と言われる本とHowTO本の2冊買いがおすすめである。
本以外にもリファレンスや仕様書のドキュメント、Webサイトなども有効である。

聞くことは5つの中で唯一他人を巻き込んだ動的な習慣である。最初に自分のコードや考えを誰かにアウトプットしてフィードバックを得られる場面を作る必要がある。これによって自分では気づけないフィードバックをもらうことができ、成長を加速させることができる。

第4章：スコープ

そもそもスコープとはスコープ=見える範囲=使える範囲=依存する範囲=保守性に影響をもたらす範囲とある。

→スコープを小さくすることで

覚えていけないことが減りプログラムの理解が容易になる
依存する範囲が狭くなり保守性が高くなる

第5章：コードの分割

コードを分割するメリット

可読性が向上する
保守性が向上する
再利用性が向上する

分割する手順は

ベタなコードを書いてみる
共通処理をメソッドに抽出して分割する
処理単位で分割する
状態も持つ処理をクラスに抽出して分割する

処理の分割に完璧な回答はない。試行錯誤することで少しずつ勘どころが掴めてくる。

第6章:コードの集約

大前提として、「コードの重複は悪」 と言われてきた。

なぜなら同じコードがいろんな場所に存在していると、変更が発生した時の修正作業が大変になる。
他にも重複があるとコードの見通しも悪くなり、保守性が低くなってしまうからだ。

では、それらを回避するためにどうやって抽出するかと言うと

メソッド
継承
ユーティリティクラス
サービス層
オブジェクト
定数

これらにまとめることができる。

継続的にコードをまとめてクリーンな状態に保つことが大切である。

第7章：コードのパフォーマンス

そもそもコードのパフォーマンスは計算量 で決まる。その計算量はアルゴリズム によって変わってくる。

パフォーマンスチューニング手順

測定：ログ出力やプロファイラを使用
原因特定：測定範囲を狭めていき、原因箇所を特定する
チューニング：アルゴリズム選択やSQL・テーブル設計を変更する
チューニングの測定：チューニング前と後で比較する

どのタイミングでチューニングするのがベストなのか？

→保守性を損なわずパフォーマンスが向上する場合は、常にパフォーマンスが良い方法を採用する
→パフォーマンス劣化がシステムのクリティカルな問題になる箇所は、早期に計画する

最後に

何となくでコードを書いてしまっていた自分にとっては刺さる本だった。全てが新しいことではなく、これまでの現場で先輩方のレビューで言われたことでもありました。
だから、この本を読んで先輩がどう言った意図を持ってレビューしてくれたかが少しわかった気がします。

まだ完全には理解していないので、リーダブルコードやミノ駆動本などを読んでから2周目を読んで更に理解を深めたいと思います！