釣りキチプログラマー翔平の備忘録 
はじめに
良いコード/悪いコードで学ぶ設計入門第２章 設計の初歩を読んで、
８年間現場で設計をしたり、設計に関する勉強会への参加や技術書を読んできた自分の観点で、
特に重要だと感じたポイント、気付き、今後参考にしていくべきだと感じたことをまとめてみました。
良いコード/悪いコードで学ぶ設計入門を読んでのまとめ記事も作ってみたので
こちらも是非みてください！！
良いコード/悪いコードで学ぶ設計入門を読んでみて(まとめ記事)｜気付きと現場で取り入れたいことについて
良いコード/悪いコードで学ぶ設計入門第２章を読んでの気付きなど
２章では設計の基本的な考え方を簡単なサンプルコードを例に解説されていました。
現場に配属されて悪い設計で作られたシステムを保守開発してた１年目の自分に
見せたかった。。。。
変数の名前は省略せず意図の分かる名前で目的ごとに用意する
良いコード/悪いコードで学ぶ設計入門第２章にはこのようなことが書かれていました。
「変数をaとかcnt(countの省略)とかで書くと、
長い名前の変数より楽に素早くコードが書けると感じるかもしれないが、
トータルで考えると開発に時間がかかってしまう。」
今まで自分も現場で誰かが名付けた謎変数名に出会したことが何度もありますが。。。
その度に変数名をこだわって付けないとこうなるよな、、、と痛感します。
例えば、
新規機能を自分一人で作り始めるそのタイミングは長々と変数名を書かなくても
さほど問題ないように思われるかもしれないですが、
たとえば、
１ヶ月後そのコードを見返す、
１年間そのコードを保守をし続ける、
人が入れ替わって新規参入者がそのコードを保守する
などなどを想定すると、初見の人は変数名だけでは、
なにをしようとしているのかイメージがつかず
１からコードを入念に読み込まなければならなかったり、
忘れた頃にそのコードに仕様変更が入る場合にも謎の変数名だらけのコードは
思い出したりコードを読むのに時間がかかります。
当然ミス(バグ)も起きやすくなります。
過去に参加した設計関連の勉強会でも変数名の重要性については
ほぼ毎回話に出ます。例えばこの勉強会とか
「普通のプログラマの普通の設計」(勉強会)に参加してみた感想
当たり前だけどそれを徹底するのが難しい・・・・
変数名に限らず、
パッケージ名、クラス名、関数(メソッド)名などなどにも同じことが言えるし、
もっというと、
同じ概念に別の名前をつけたり、同じように見える別の概念に同じ名前をつけるといったことも
注意が必要！！！と自分は感じています。
また変数関連で、
良いコード/悪いコードで学ぶ設計入門第２章にはこのようなことも書かれていました。
「変数は目的ごとの変数を用意するべき。
計算途中の結果を同じ変数に入れて変数の用途を変えると
読み手が混乱したりバグを埋め込んでしまう可能性がある。」
個人的にはこれに現場で出会した経験は、謎変数名に出会した経験よりは少ないですが、
これに出会すと保守の難易度が無駄に上がりバグを埋め込む可能性が高くなる印象です。
超巨大共通メソッドとかでこれやられるとなかなかの苦行です、、、
たとえば、
100行のコードだとして20行目までは合計金額のための変数、
21行目以降は消費税込の合計金額のための変数、
ただ変数名はsumみたいなのを想像すると、
影響調査でコードを斜め読みする感じで頭から読んでいくと、
この変数は合計金額を表すんだと思って調査が進んでしまって・・・
結局影響調査漏れや仕様変更時の対応が漏れてバグを埋め込むことになる。
とか、
巨大共通クラスで１つの変数の状態が10回以上変わるし、
条件分岐によって状態が変わるバリエーションも10パターン以上ある・・・
となってくるともう調査に相当時間がかかるし複雑すぎて
デバックで変数の状態を追いかけるとかにまでなることも。。。。
それだけ変数名の意味と実態が変わるとか、
処理のとあるタイミングで変数の状態が暗黙的にコロコロ変わるのは
無駄に難易度を上げてしまうので危険だと個人的には思っています。
この本でもそういうことが言いたかったのかなと思いました。
意味のある単位で１つのメソッドに｜関係し合うデータとロジックを１つのクラスに
良いコード/悪いコードで学ぶ設計入門第２章にはこのようなことが書かれていました。
「ベタ書きで書くと処理単位を跨いでごちゃごちゃになってしまう可能性がある。」
「強く関係するデータとロジックを１つのクラスにまとめることで、
あちこちロジックがバラバラになることも探し回ることもなくなる。
さらにコンストラクタに取り扱う値の範囲を制限してやると頑強なクラス構造になる。」
ここに記載されていることは自分も普段から強く意識していることです。
逆にこの意識が足りておらず、
結果同じロジックを至る所に散らばらせている大変なコードの保守開発を
何度もさせられてきました。。。。
どれもだいたい、
getterとsetterだけのデータクラスを巨大共通クラスで
むりやり共通化してて引数の数が多かったり、わかりずらいフラグで処理モードを
いくつも分岐させたり・・・といったケースが多かったです。
本でも述べられている、
強く関連するデータとロジックを１つのクラスにという考え方で全体を俯瞰して設計できていれば、
１つの概念に関するは１つのクラスに集まり、
むりやり共通化した巨大共通メソッドが生み出されずに、
仕様変更時の影響箇所もその１つのクラスに閉じ込められているので
変更が安全で保守しやすくなります。これが良いコードの設計で、
逆に悪いコードの設計では、
巨大な共通クラスだといろんな概念を１つのクラスで取り扱うのでいろんなフラグや処理モードが
入るような設計のことだと個人的には思っています。
仕様変更時にその巨大な共通クラスに手を入れるのが危険で、
そのため品質担保のためのテストケースもかなり必要になります。
(もっというとデータクラスがデータに強く関係するロジックを持たないところから
この悪いコードの設計は始まっていますが・・・その辺りはまた今度)
まとめ
良いコード/悪いコードで学ぶ設計入門第２章 設計の初歩では、
良いコードを書くための設計の基本的な考え方と、
逆にコードを書いてしまう設計についてがわかりやすいサンプルコードと共に説明されていました。
この章の内容は、
ただプログラム言語を学んで一人でアプリを作った直後くらいだと
理解できる人とできない人とが出るかも・・・と少しだけ思いますが。
現場の泥臭いところを経験して自分なりに現状を改善するにはどうしたらいいか？？
と試行錯誤１度はしてみた人はとても良い学びになるだろうなと感じました。
以前、良いコード/悪いコードで学ぶ設計入門の著者のトークでもありましたが、
ビジネスのスピードが速い現代では、
ビジネスの要求を分析して保守しやすく成長し続けるコードに落とし込めるスキルは
githubを使えたりAWSを使えるのと同じくらい必須のスキルだという話がありました。
設計のスキルはそれほど重要だと僕も考えています。
こういった本を通じてプログラマーやエンジニアの設計スキルが上がり、
現場で変更が危険なシステムと出会す機会が減り、
設計についていろいろ語り合えるプログラマーやエンジニアが増え、
そういう方と一緒に仕事ができることを期待しています！！！
