良いコード/悪いコードで学ぶ設計入門がステップアップに最適だった

はじめに

上記の参加記事になります。

良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方

今回は巷で話題のこちらの本について内容とどういった方が読むと幸せになれるのかという観点で紹介したいと思います。

私自身がこの本を読んだ動機は 「メソッドの共通化や命名には気をつけてコードを書いているけど、より長期的な目線でコードを書けるエンジニアになりたい」 と思ったからでした。自分のようなコードは書けるようになってきたけどそれ以上にステップアップしたいエンジニアにとって設計入門という響きは魅力的なものでした。

ぜひ私のようなエンジニアにこの本を読んで欲しいので興味を持っていただけたら大変嬉しいです!

前提

まず参考程度に私は開発経験1年のソフトウェアエンジニアです。業務ではRuby on Rails, React, Angular, TypeScript あたりの技術を用いてフロントバック両方のウェブプロダクト開発を担当しています。(k8sとかもちょっと触る)

全体的な感想

まずは全体的な感想から。私はこの本を読んで

「リーダブルコード+オブジェクト指向 という思想をもとにクラス設計を積極的に取り入れて保守性・可読性共に高水準なコードを書きましょう。」

という印象を受けました。概念的な考え方をもとにして実際のコードをもとに悪いコード/良いコードが記載されているので非常にわかりやすいです。業務にも活かしやすいと思います。私は早速ストラテジーパターンが使えないか考えたりもしてました。

ただ積極的にクラス設計を行おうとするのでJavaのようなオブジェクト指向言語での開発向きの考え方ではあると思いました。

読んで欲しい対象層

• 新人エンジニア(開発経験1~3年)
• 既存のコードの読みづらさに苦しんでいる人
• オブジェクト指向は何となくわかるけど業務であまり考えたことがない人
• 比較的大規模なバックエンド開発に携わっているエンジニア

上記の内いくつか該当している方はドンピシャなのでぜひ読んでみると良いと思います。逆にプログラミング初心者の方であれば少し早すぎる気もしますし、オブジェクト指向をクラス設計に落とし込めるようなベテランエンジニアであれば自然と身についている考え方ではあると思います。

この本を読む前に読んでおくと理解が深まる本

• リーダブルコード

  • 散々言われているエンジニアのバイブル的な本ですね。命名へのこだわりや共通化の基本は全体的な感想でも述べた通り、リーダブルコードの影響が強いと思うので読んでおくとよりグッと理解に繋がると思います。

• スッキリわかるJava入門 第3版

  • こちらの本も読んでおくといいかもしれません。理由は二つあります。一つ目は良いコード/悪いコードで学ぶ設計入門のサンプルコードがJavaで書かれているから。二つ目はこちらの本はオブジェクト指向の考え方を学ぶこともできるからです。
  • なんでJava?とも思う方もいると思いますが、既に他言語でガンガン書いている方はマストで読む必要はないとは思います。ただJavaを全く書いたことがなく、オブジェクト指向が何なのか全くわからなければこの本の後半の章だけでも読めば同時に理解できるので一石二鳥ではないかと思いました。

感想

さてここから気になった考え方や解説をまとめていきたいと思います。

• 自己防衛責務

  • クラスは単体で正常に動作するように設計することが推奨されています
  • dataとその振る舞いをまとめることをクラスの責務とする考え方ですね
  • JS/TSだと関数言語寄りだからか考え方は少し異なりますね。

• イミュータブル

  • 値はイミュータブル(不変)にして再代入を避けましょうという考え方ですね
  • こちらはJS/TSだと自然と身につきますね。
  • array.shift 等よりもmapなんかを自然と使いますよね
  • 元の値を変えてしまうと予期せぬ箇所でエラーが起こるのでどの言語でも避けるべきだと思います

• 条件分岐

  • ifネストが増えるとつらみは増しますねやはり
  • 早期returnはすぐ使えるテクニックだと思います

• strategyパターンを使う

  • switch文がいくつも必要になった時検討すべき考え方の一つのようです
  • interfaceを用いたポリモーフィズム的テクニック
  • React開発でも使いたいなと思ったんですけど使っていいものなんですかね？

• 密結合

  • 単一責任の原則を意識すること
    • 自分の分担の範囲内のみ行うことですね
    • UNIXの思想でもあり、実装を考えていると気づいたら責務のことばっかり考え始めてしまいますね
  • DRY原則
    • この本の中ではDRY原則の誤用について取り上げています
    • 同じ処理は繰り返すなという認識が生まれがちですが、同じ概念を用いているときだけ共通化すべきと行っています。
    • ※書籍内でも語られているようにこの考えは「達人プログラマー」からの引用です
    • 達人プログラマーについてより深く知りたい方は僕が記事を書いているのでぜひご覧ください

• 継承は非推奨

  • この本では継承より移譲を推奨しています
  • 継承はオブジェクト指向の重要な考え方の一つなので使わないという考えは新鮮でしたね

• モデリング

  • システムは目的達成の手段
  • 目的駆動で名前設計することが、適切に目的達成するモデルを設計することに繋がる
  • システムは何らかの目的を達成するために作られるのであり、責務よりも目的が先に来る
  • モデリング：表からは見えないUIデザイン
  • 上記Qiita記事ではフロント面でのモデリングについて語られています
  • モデリングはバックエンドのクラス設計だけでなく幅広く通用するテクニックだとわかります

感想のまとめ

雑多に書き連ねましたが、プログラミングにおいてよく聞く抽象的なフレーズをコードに落とし込まれているのでこの記事だけ見てもよくわからない概念は書籍を買って読んでみると必ず理解できると思います。

実際に取り入れた方が良いのかは置いておいて、オブジェクト思考をコードに落とし込むとどうなるかという点で勉強になりました。

おわりに

この本を読んでより設計に対しての興味が湧いてきました。
最後の方に取り上げられているいくつかの本を読んでみたいと思います。
ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本 とかですね。

この記事を読んでくれた方々にも何か参考になれば幸いです。

参考文献