LoginSignup
42
35

More than 1 year has passed since last update.

システム設計の原則を読んだことで実装についても考えるようになった話

Last updated at Posted at 2022-01-02

初めに

初めて保守の案件を任されたときのサービスは
5年以上続いているものでした。
LaravelとPHPで構築されています。
初めてということもありソースコードを見たときは
僕自身の理解力が足りなくて難しく見えているだけだと思っていたのですが
徐々に知識がついてきて
割とクソコードなんだなと思うようになってきた。
だけどそんなクソコードに対してどうにかしたいという気持ちはあっても
何をしたらいいのかもわからずただただ思うだけで過ごしていました。
そんな状態で過ごしているときに @MinoDriven さんとお話しする機会があり
そこから設計について改めて学びたいなと思い
「現場で役立つシステム設計の原則」
を読んでみて眼からうろこが出続けてしまったので
みんなにも同じように体感してほしいと思ったので纏めました。
僕自身の解釈、表現をしているので書籍が伝えたいこととは違うように
伝わるかもしれませんので正しい情報はしっかりと書籍を読むことをお勧めします。

「実装ができる」だけは自己中な状態

僕自身は異業種からプログラマーに転職をしたのですが
転職を成功させるためにとにかく「実装ができる」状態を目指して勉強していました。
おかげさまでプログラマーになることもできたし実装自体はできるねと言われることもあります。
そんなときに一つの保守対応を任されたのですが
なんともソースコードがクソなわけなのです。
何がクソかというと一つの機能に対して修正を行ないました。
初めにソースコードを読み解くのにも時間がかかりながらも改修したのですが
他の機能にも影響を及ぼしていて障害に繋がってしまったのです。
え!?保守怖い!
ってなったのですが僕自身の力不足も起因しているのは間違い無いです。
でも未然に防ぐことはできなかったのか、
障害になったとしても障害範囲を限定的にできなかったのだろうか。
「実装ができる」としてそのときは良くても半年なのか1年後なのか
時間をあけて何かしらの負担が自分もしくは他の人に返ってくる。
「実装できる」だけにならないようにしていきたい。

クソコードを書かないようにしたい

自分では会心の出来のコードでも
第三者から見たらクソコードなんてことは
よくあることだろう。
いきなりはできないにしても少しずつ
クソコードを書かなくなれたら
個人的にも
チームとしても
そしてサービスを利用する人にとっても
不満の少ない状態にできるようになるはずです。

クソコードはとにかく影響範囲が広かった

一覧を表示するのに時間がかかるということで
「一覧を表示する」処理に対して改修を行った。
なのに別の画面で障害が発生する

僕が体感したクソコードの一つだが
何が悪いかというと
「一覧を表示する」ことに対して修正をしたのに
他に影響を及ぼしていること。
変な部分を共通化してしまったことによる弊害だ。
例えば

  • ユーザー一覧画面でユーザー全てを一覧で表示する

    • IDの昇順で表示する
  • 商品一覧画面で商品全てを一覧で表示する

    • IDの昇順で表示する

といったことがあったときに
「一覧で表示」の処理を共通化したようなイメージ
改修したいことは商品を人気のある順で表示するようにしたい。
だけどユーザー一覧画面のIDの昇順で表示のことを知らずに改修したら
ユーザー一覧画面の表示がおかしくなる。
やりたいことはただ商品を人気のある順にしたいだけなのに
ユーザー一覧画面のことも気にしないといけなくなる。
これは無駄なことだ。

何でも共通化するのは悪手である

オブジェクト指向をかじり始めるとなんでも共通化したくなる
共通化自体は悪いことでは無いにしても無鉄砲に行ってはクソコードの助長になる。
共通化するにあたってやりたいことをしっかりと考えよう。
「業務の関心事」を整理するといい

ユーザー一覧画面
- 全てのユーザーを表示
- IDの昇順

商品一覧
- 全ての商品を表示
- 人気のある商品順

それぞれのやりたいことがわかった。
「表示する」という部分は似ているが
やりたいことは全然違う
なので上記の2つの画面に対して互いに共通化した処理を使うのは
そもそもで悪手である可能性が高い。

業務の関心事に対してしっかりと考える

実装する機能に関してしっかりと何をするのか、したいのかを考える
ただ、開発者だけで考えてしまうとクライアントが求めることとズレが生じてしまう。
可能な限りクライアントの求めることも聞いて理解した上で考える

別な話になるけどプログラマーは人と関わらなくてもいいみたいな話があるけど 関わらないでもコードは書ける。 ただ間違いなくクソコードを製造しているだろうとは思う。

詳しくは書籍を読んでほしいけど
スタートラインとしては
「業務の関心事」について考えて書き出すことから始めるといいと思う。

過度な共通化を避ける事でのメリット

過度な共通化を避ける事で僕のように改修をして
障害を起こすことはなくなるだろう。
障害が起こったとしても被害は必要最低限になるはず。
オブジェクト指向を身につけ始めは特に注意をして
共通化を図ってほしい

僕の話ですが「業務の関心事」を意識して考えてから実装したコードは
改修するときにシンプルに考えて改修することができました(別な案件での話)

注意

僕自身の解釈で表現をしているので理解しづらい部分が多いと思います。
しっかりと理解したい方は書籍を読んでください。
「現場で役立つシステム設計の原則」

42
35
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
42
35