1. 雨宿りとWEBの小噺.fm
  2. Season 1-16.「仕様変更でロ..
2022-04-19 04:52

Season 1-16.「仕様変更でロジックにif文を入れるのは最終手段」

はい。今回は以下のツイートを見てとても共感を覚えたため、思わず収録してしまいました(笑) エンジニアなら一度はやってしまう道だと思いますが,用法用量を守って行きたいですねー

  • プログラミング
  • 条件分岐
  • 設計
  • ロジック
  • if文
  • クラス

ではでは(=゚ω゚)ノ

ツイート:
https://twitter.com/MinoDriven/status/1516203223203598336


See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

00:03
はい、みなさんこんばんは。keethことくわはらです。本日もやっていきましょう。 keethのエンジニア雑談チャンネルです。この番組では、ウェブ業界に関することや、エンジニアについての雑談などの情報を発信していきたいと思います。
第16回ですね。まあ第16回は、ちょっとこの前ですね、この前って学系さんなんですけど、Twitterを見てましてですね、一つ面白いタイムラインが流れてきて、それについて僕も確かに思うところがあったので、まず言及してみようかなと思いましたけど、
その人のツイートをもう一回読ませていただきますと、使用変更時に既存ロジックに即座にif文を付け足すのが地獄の一丁目だと思っているというツイートをしてましてですね、
まあこれがそこそこバズられていて、でも確かに共感を得る一言だなというふうに思っておりますと、
本当にそのまんまで、わかりやすくその使用変更であったりとか、ビジネス的な要望であったり、事情があって、何かロジックに手を入れなきゃいけないとなったときに、
先に思いつくのはもちろんif文なんですよね。こういうイレギュラーパターンとかこういうケースが、新しいケースが見つかったというので、そのパターンについての処理を切り出して書かなきゃいけない。
けど関数を切り出すとか、クラスを切り出すとかっていうことでもないなというふうな判断をしたときに、同じ関数がないとかでif文を付け加えて、
その中の別の処理をして、あとは元のメインスレッドの処理に戻しますよみたいなことをやってしまうことはあると思うんですけど、
これは本当僕も地獄だと思っていて、じゃあ違うパターンが今後生まれたときにまたif文を生やすのかっていう話がありますよね。
ifelse、ifelseでどんどん条件分岐が増えていく可能性もありますし、新しいパターンが既にある既存のパターンとちょっと相互に影響しなきゃいけなくて、
if文の中にさらにifelseがあったりとかして、どんどんif文のネストが始まるとか、泥沼にはまっていくっていうのがあると思うんですね。
ですので、そもそもif文を真っ先に入れるっていうのはわかりやすいし、特感的に対応ができるので、
まっすぐにデリバリーをするっていう意味ではいい選択肢というふうに見えちゃうんですけど、
果たしてそれが本当にいいのかっていうのはしっかり設計しなきゃいけないなと僕は思ってますので、
皆さんはどういう意見だと思いますけども、
そもそもif文を入れることは果たして本当に必要なのかっていうのと、それが根本解決なのかっていうところに立ち戻って考えていくのがいいんじゃないかなと思います。
設計って言うとちょっと大げさかもしれないですけども、
もしくは悪種かもしれないです、バッドパターンかもしれないですけど、それ専用のメソッドに切り出してしまって、
似たような処理がほとんどあるんですけど、一部だけ違うけど同じような処理をもう一個関数を増やすとか、
もしくはもう内容次第ではもう1個クラスごと分けてしまうとかですかね、
でもありかと思います。
もしフロントエンドとしたらそのコンポーネントで分けてしまうとも一つありかもしれないですね。
03:01
あとは条件によっては、例えば関数の引数ですね、もう1個増やさなきゃいけないとなったときに、
ifで増やしたりするとかじゃなくてオプショナルに1個追加して、
なかったらいつも通りの処理、あればあるだけで処理をするっていうのも可能性としてはあるかもしれないですね。
ある場合はその処理をするっていうのはやはりその中の、
関数の中にif分を増やす可能性はありますけど、
それはそれで仕方ないかなっていうケースもなくはないですが、
あくまでif分を本当に入れるのが正しいのかっていうのはちゃんと認味していくのが本当にいいのかなと思ってます。
極力ロジックに合わせたif分を増やすっていうのはとにかく避けるっていうのが簡要というか、大事だなと思ってます。
要所もないパターンとか、本当に超ニッチなケースでこれしかもう起きませんっていうのが見えてるんであれば、
if分を増やすのは僕は別に間違いではないと思います。
しっかりその代わり、コメント文を残すとかでして、
なんでこれが増えたのかっていうところだけ書くのはいいと思います。
ただ影響範囲が大きいんであれば、それはもちろんif分レベルじゃなくて、
本当に設計レベルになると思うのでそれは大丈夫だと思いますけど、
結構微妙なパターンとかそういうのってだいたい曖昧であったりとか、
そのケースバイケースなんですよね、要は。
ですのでその辺をしっかり義務にして、
先にif分ではなくて、もっと別のパターンで考えられないかっていうのを加味して、
最終手段としてif分を使うのがいいのかなと思いました。
ちょっと長々と語ってしまったんですけど、結論はそんな感じですかね。
今日はそんなお話をしたくなりました。
プログラマーの一つの課題というか、永遠の課題だなって思って、
ちょっとしゃべりたくなったので収録しました。そんな感じです。
今回は収録は以上で終わりたいと思います。
また何か話して欲しいことが聞いてみたいことがあったらいつでもコメントなりご意見いただければなと思っております。
はいでは次回の収録でお会いしましょう。
バイバイ。
04:52

コメント

スクロール