釣りキチプログラマー翔平の備忘録 
はじめに
良いコード/悪いコードで学ぶ設計入門第１章 悪しき構造の弊害を知覚するを読んで、
８年間現場で設計をしたり、設計に関する勉強会への参加や技術書を読んできた自分の観点で、
特に重要だと感じたポイント、気付き、今後参考にしていくべきだと感じたことをまとめてみました。
良いコード/悪いコードで学ぶ設計入門を読んでのまとめ記事も作ってみたので
こちらも是非みてください！！
良いコード/悪いコードで学ぶ設計入門を読んでみて(まとめ記事)｜気付きと現場で取り入れたいことについて
良いコード/悪いコードで学ぶ設計入門第１章を読んでの気付きなど
１章ではまずは良い設計とは何かを知ることで悪い設計を知覚できるようになりましょう。
ということが書かれていました。
また、
悪い設計の例と、その設計で進めていき、
後に仕様変更が入るとどんな悲惨な結末が待っているかということを
サンプルコードと共に説明してありました。
個人的には現場でどれもよく見かけたり、
実際に悲惨な目にあったような例がコードベースで解説してあり
当時のことを思い出したり。。。
良い設計を知り、悪い設計の弊害を知ることが始まり
良い設計とは何か？？悪い設計の弊害とは何か？？
まずはそれを知り、
なんとかせねばと意思を持つことが良い設計にしていく始まりなのだと本には書かれていました。
駆け出しプログラマーだった頃の自分を振り返ると、
プログラム言語を習得して新人研修を終え、
現場に配属され、
悪い設計で作られたシステムの保守開発などを新卒でさせられ・・・
大量のデータクラス、低凝集、
トランザクションスクリプトが全て、プリミティブ型への固執、
神サービス、神クラス、使い方が謎の巨大共通クラス
などなど・・・
ただそれが理由で複雑だったのに
プロのエンジニアが書いたソースはこういう複雑なものだ。
これが複雑と感じるのは自分が未熟だからだ。
と考えていました。
プログラム言語習得後に、
現場でソースコードを読んで面食らいならがもしばらく保守開発をした後に、
この本(良い設計とは何で悪い設計の弊害とは何かの情報)と出会えていれば。。。。
データクラスは悪い設計に繋がりがち
データとそれを出し入れするgetterとsetterだけを持つデータクラスは
様々な弊害を引き起こす原因になりがち。
データクラスを用意するということは、
それを使った判断・加工ロジックが必要なケースがほとんど。
つまり判断・加工ロジックをデータクラスとは別クラスなどに作ることになる。
別の場所に判断・加工ロジックを作っているのに気づかず、
(バラバラなデータと判断ロジックなどの繋がりを全て読み解くのは難易度が高い)
別のエンジニアがまた同じようなロジックを作る。
それが積み重なり同じようなチェックロジックが至る所に作られ、
仕様が変更になった際は量産されたそれら全てを漏れなく修正する必要がある。
また、
データクラスは不正な値や正しい初期化なしでインスタンス化ができてしまう。
そうなると、データクラスを使う側が正しい初期化をしてやることが前提となったり、
使う側の複雑さが増す。データクラスを使う側とはたいてい至る所にあり、
つまり至る所に複雑な初期化処理などが量産され、メンテナンスし辛い状態に陥る。
少し自分の解釈も混ぜていますが、
本にはこのような悪い設計になぜデータクラスが繋がるのかが
サンプルコードと合わせて説明されていました。
おそらく新卒で配属された初めての現場で、
データクラスだらけのトランザクションスクリプトで全て書かれて
至る所に同じ判断や加工ロジックが書かれていたソースコードを見た後で
この説明を聞けていたら、
設計の重要性に気付き、設計に深く興味を持ち、
プログラマーやエンジニアとして早く成長できたかもなと思います、、、
まだ良いコード/悪いコードで学ぶ設計入門を全て読んだわけではないですが、
駆け出しプログラマーやエンジニアの方でも現場での経験が少しあれば読むことができ、
中級以上のプログラマーやエンジニアを目指している方にも役立つ情報がわかりやすく書いてあります。
なにより、設計における重要な基礎の部分について分かりやすくまとめてある本は、
個人的には現場で役立つシステム設計の原則と、
この良いコード/悪いコードで学ぶ設計入門の２冊くらいかなと感じています。
