設計書がある現場って関数分割いらなくね？

概要

いわゆるSIerに転職して1年が経過した。

入社してすぐに大規模案件にアサインされ、1年経った今も同じプロジェクトに所属している。

そのプロジェクトでは、全てのAPIについて詳細設計書が存在している。

で、1年間そんな現場で仕事をしていて「詳細設計書がある現場って関数分割いらなくね？」と思うようになった。

ちなみに、ここで関数分割いらなくね？と言っているのは1つのサービス層内のビジネスロジックを細かく複数の関数に分割しなくてもよいのでは？という話である。

責務を分割するためにコントローラー層やリポジトリ層を作るなという主張ではない。

複数のサービスで横断的に使われる機能を抽出してコンポーネント化するなという主張でもない。

そこのところをご理解ください。

というわけで、なぜ関数分割が不要だと思ったかの理由について以下に述べる。

詳細設計書が上から下へと処理の流れが一方向に続いているのに対し、関数分割をされたコードでは処理が上に行ったり下に行ったりする。

基本的にAPIの改修をするときは詳細設計書を見て、実装と照らし合わせて、そこからようやく修正が始まるのだが、関数分割されたコードではこの照らし合わせの作業が非常に面倒になる。

一般に関数分割のメリットとして可読性の向上があげられるが、これについては詳細設計書にどのような処理をしているかの記述があるので詳細設計がある限りにおいては関数分割をしなくても特に可読性は落ちないと思っている。

むしろ、前述したように関数分割していない方が詳細設計書とコードの対応が取りやすくて可読性が上がると思う。

次に関数分割のメリットとして良くあげられる再利用性だが、そもそもAPIを作っていて同一サービスクラス内でそんなに再利用する関数ってあるかな？というのが個人的な疑問である。

一番再利用性の高い機能はDBとのやり取りだと思っているが、これはリポジトリ層に責務分離されているのでサービス層側で関数を分割する必要はない。

次に再利用性が高いのはメール送信機能やビジネスルールの検証機能だと思うが、こういうのはサービス層内で関数分割するのではなく、新規にコンポーネントを作成してサービス横断的に利用できるようにしてしまう。

ちょっと考えてみてもサービス内でのみ繰り返し利用される関数があまり思いつかなかった。

まあこれは自分の経験が浅いだけかも。

最後に関数分割のメリットとして良くあげられるテスト保守性だが、そもそもJava等で関数を分割する場合はprivateメソッドに処理を分割するはずで、privateメソッド単体のテストをすることはできないので、結局はビジネスロジック全体のテストをすることになると思う。

なので特にテスト保守性が落ちることもないのではないかと思う。

まあこれは設計書うんぬんの話ではなく、privateメソッドが存在する言語においては結局こうなっちゃうよね、という話だな。

かかってこいよ、リーダブルコード！！

#PR

リーダブルコード