【新人君物語】第2話 どうして同じ処理をまとめるの?編

先輩さんが新人君のソースレビューをしている時です。先輩さんがむむっとうめいて話し始めました。

先輩さん「おや?ここのコードだけど違うメソッドで同じ処理がされているよ?なんでかな?」

確かにここは全く同じ処理をしているロジックがある。それは自分でも把握していた。

新人君「確かにここは同じ処理をしていますが、AメソッドではA画面のパラメータを受け取っていて、BメソッドではB画面のパラメータを受け取っています。違う画面の処理なのでそれぞれ分けました。」

先輩さん「なるほどね。ただ全く同じ処理を複数書くということはよくないことなんだ。なんでかわかるかい?」

新人君は動いていればいいんじゃないの?という思を隠しながら、どうして駄目なのか考えてみました。

 

解説


確かに新人君の言うとおり動いているからいいじゃないかという思いもわからなくはありません。ただ、一度作ったプログラムはこの先改修をされる可能性が高いと言う事がポイントになります。そう考えるとなぜ同じ処理を複数個所で書くのがいけないのかわかると思います。

変更に弱いシステム


例えばほぼ同じ機能をもったA画面とB画面にそれぞれ「備考」という項目が増えたとします。その場合「備考」項目を受け取る処理が追加になります。プログラムを見てみると受け取る処理は全く同じなのに別々にプログラムが書かれていました。ということは改修は2箇所になります。

今回は2箇所だからまだいいですが、何箇所も同じ処理が散乱していると修正漏れがあるかもしれません。画面項目なら動かせば修正漏れがあったとわかるからいいですが、あまり気がつかないような処理であればバグの原因がわからずただの修正漏れに時間がかかってしまう可能性もあります。

つまり変更に弱いシステムになってしまうのです。

テスト地獄


また処理が増えるということはこの後実施するであろうテストにも影響が出ます。全く同じ処理(コピペしたソース)だったとしてもそれぞれテストの必要性があります。

例えば「世界のナベアツ」クラスと「日本のナベアツ」クラスがあったとします。どちらの機能も『画面に入力した数字に対し3の倍数であれば画面に表示する』という機能だったとします。

テストでは1~100の数字を1つずつ画面に入力して網羅することになりました。「世界のナベアツ」クラスは問題ありませんでした。ふぅ終わった終わったと思ったのもつかの間、今度は「日本のナベアツ」クラスに対し同じ作業をする必要があるのです。

上の例は極端ですが、同じ処理が複数あるということは同じテストをその個数分必要になる可能性があるということです。

共通化しよう


ということで同じ処理は共通化してしまいましょう。具体的には引数だけ渡して同じ処理を呼ぶとか、そもそも違うクラスで共通クラスを作るのもいいかもしれません。

もしかしたら上手く共通化できないということもあると思います。実際に同じ処理だからといって機能的に共通化できないこともあります。

ただ理由が「自分の技術では難しそう」ということであれば少し頑張って考えてみてほしいです。もしくは先輩に聞いてもいいかもしれません。長い目で見るとそれだけ時間をかける意味はあります(納期以内でね!)

 


新人君「先輩さんの言ったように上手く共通化することができました!」

先輩さん「お疲れ様。コードも短くなってすっきりしたし、よかったよかった」

新人君「先輩さんにレビューをしてもらいよかったです」

先輩さん「そうだね。これからもどんどんレビューしていくからね」

新人君「よろしくお願いします!」

先輩さん「よろしくね。(新人君のコードはレビューしないと危な過ぎるからね…)」

続く…

スポンサーリンク

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です