Spring Framework はじめました

久しぶりにチームで開発をできることになったので、フレームワークの選定をしました。

 

フレームワークを使って実現したかったこと

  • お願いする人と作る人が互いに共通のコンテキストに基づいてイメージしながら会話が出来ること（作るときに間違いを少なくすること）

 

例えば…

僕（お願いする人）：

「まず、僕の方で○○画面にボタンを追加しておいたから、それをクリックしたらこのカンプにある画面に遷移してー（コントローラにリクエストハンドラを追加して、追加したテンプレートビューにリダイレクトしてー、イメージできてるかな？分からなかったら説明しよう）」

Aさん（作る人）：

「あぁ、コントローラにリクエストハンドラを追加して、追加したテンプレートビューにリダイレクトすればいいですね。カンプにあるテンプレートビューのベースHTMLはあります？ー」

僕（お願いする人）：

「あるよ。テンプレートにはThymeleafを、スタイルはBootStrapのを使ってね。じゃあ、新しく作る画面の説明をするね。これは■■の情報を入力する画面で、登録ボタンを押したら確認画面を表示するんだけど、遷移前に入力値のチェックをしたいんだー（よかった、バッチリだ。新しい画面については、まずカンプを参考にしてInputタグを配置して、スタイルを適用するところから始めてくれるといいな。入力値チェックはBean Validationを使ってー）」

Aさん（作る人）：

「まずは、カンプを参考にしてInputタグを配置して、スタイルを適用するところから始めますね。出来たら見てください。入力値のチェックは■■入力画面に対応するFormクラスにBean Validationを追加していけばいいですね。項目チェック仕様を見てもいいですか？ー」

 

このように、フレームワークを通して共通のコンテキストに基づいて、ユーザ要件を反映した外部設計の結果を作る人に伝える際に、お互いが同じ内部設計をイメージできると、プロジェクトが整理されるので気持ちがいいなと思います。

 

勿論、プログラム設計書を作って説明する―という手もありますよね。

開発手法に囚われすぎず、脱線しすぎず、状況に応じて仕事の進め方を変えられるように判断する為の知識を持っていられるといいな―と思います。（適切なアドバイスをしてくれるプロマネがそばに居てくれると最高ですね。）

 

  • フレームワークのコンテキストに基づき設計されたパッケージに、意図した通りコードを実装して貰えるようにすることで、後々ジョインする人がそのフレームワークのコンテキストを持っていれば、すぐにコーディング出来るようにすること（保守対象を分かり易くしておくこと）

 

例えば…

僕（お願いする人）：

「今回入った改修の説明をするね。これは■■の情報を入力する画面で、登録ボタンを押したら確認画面を表示するんだけど、遷移前チェックしている入力値のチェック仕様を変更したいんだー（入力値チェックは■■画面のFormクラスにBean Validationを使って実装されているから、そこを修正してー）」

Bさん（作る人）：

「今回の言語はJavaで、使っているフレームワークはSpring MVCですから入力値のチェックは■■入力画面に対応するFormクラスのBean Validationを変更すればいいですね。項目チェック仕様と変更仕様を見てもいいですか？ー」

 

このように、フレームワークを通して共通のコンテキストに基づいて、すぐに改修箇所をイメージしてコーディングに移れると、仕事が早くてお互いにもPOにもハッピーだなと思います。

 

経緯

今回、フレームワークの選定を自分で改めてしようと思ったのは、作る人だけに内部設計を任せっきりになっていたのを止めて、お願いする側（僕も含めて）にも内部設計出来るスキルを養いたかったからです。（少なくとも僕と同じチームになったメンバーには、そうなって欲しいなと思っています。）

 

上記では「作る人＝プログラマ」でしたが、プロジェクトの状況によっては「作る人＝別組織に所属するSE」というケースもあります。

いずれにしても、人がする仕事なので、やることは同じでもその人のコンテキストに基づいて内部設計が行われます。

 

この結果どうなるかというと、項目チェックがリクエストハンドラに実装されたり、サービスに実装されたりします。

これが繰り返されると、もう改修するのも危なくて触りたくないアプリケーションが出来あがってしまいます。

 

アプリケーションは、業務を遂行するために使われたり、サービスにおいては時には稼ぎ頭となって使われたりします。（ECサイトはその最たる例だと思っていて、店舗がオープンしていなければ売り上げは生まれません。極端ですが、僕らの給料の原資となる会社の利益も生まれません。）

 業務の効率や質を良くする為、もっと売上を増やす為に、アプリケーションは改修を繰り返していきます。

 

そんな時に、直す箇所を誰も知らないアプリケーションがあったらどうでしょうか。Aさんのように最初に作ってくれた人がいつまでも居るわけではありません。

 

改修を担当することになったCさんは、まず改修箇所を探す事から始めます。

ようやく見つけた箇所を直したと思ったら、別の箇所がおかしくなったと声が掛かり―なんてやっていると、改修結果が反映されるまでいくら時間があっても足りません。

（危ないから）テストケースを増やそうといった、工数を増やすような判断―この場合や状況に応じては正しいかもしれませんが―に至ってしまいます。

 

一方、すぐに直す事が出来て、改修をリリースできたら、少しでも早くから売上や利益を作る時間を確保できます。

 

カッコつけっぽいですが、一応はこういう意識で仕事をしてます。サービスを運用して稼ぐビジネスでは、運用する人たちは稼ぎ頭ですし。彼らの運用効率が下がれば、時間が掛かり余計なマンパワーが発生して利益は下がります。

僕たちが声を聞くし、それを素早く形にするから、そっちもそれに応えてね―って気持ちです。こう考えて仕事（開発・保守）をした方が楽しいです。

 

だから、正確に品質を保ちつつ開発し、すばやく保守する為に、フレームワーク選定を通して必要なポイントを身に付けようと考えました。

 

選定条件

  1. お願いする人は、何を作ればいいかを明確に説明できること
  2. 作る人は、説明を聞いて何を作ればいいか明確にできること
  3. アプリケーションが完成してなくてもテンプレートビューのデザインを確認できること
  4. コミュニティに参加して、他のユーザと話ができる環境があること
  5. 自分たちが使える言語であること

 

1、2番は共通認識を持てる概念が整っていて、理解しやすければOKです。

 

3番は画面イメージを作ったらすぐにフィードバックを貰いたかったので、JSPは避けたいと思いました。

また、メンバーのスキルを考えたときに、デザインを確認するために、画面の作り方（スタイルの適用）、サーバアプリケーションの仕組み・作り方を一気に説明して混乱させるより、HTMLを書いたら画面をすぐに確認出来た方が、ステップバイステップで教えられるので良いと考えたのもありました。

 

4番は日本 Selenium ユーザコミュニティやテストのコミュニティに参加した経験から、いろいろな方にお世話になったな―と思っていた為です。

社外の方が圧倒的にユーザ数が多いので、情報量も多いだろうと考えました。

 

技術的な条件である3番以外は、フレームワーク自身が備える性質だったり、TwitterやJJUGを通して肌で感じていたことだったので、3番を中心に調べました。

 

その節は、とても助けられました (*^｡^*) 

 

この結果、その条件を満たすThymeleafテンプレートエンジンを組み合わせて使えるフレームワーク Spring（Spring Boot）を選択しようと決めました。

 

フレームワーク決定後に気付いた大事なこと

実際に使い始めてから、いろいろな方に助けてもらいました。

 

外部データの扱いに疑問を持っていたとき

 

リリースを効率化する方法を探してたとき

 

application.ymlの 設定で困ってたとき

 

ThymeleafのValidationで困ってたとき 

 

(´;ω;`)ﾌﾞﾜｯ

僕も誰かにお返ししたいという気持ちになります。

だからコミュニティに人が集まるのでしょうね。

 

参考にしている書籍、ドキュメント

はじめてのSpring Boot―スプリング・フレームワークで簡単Javaアプリ開発 (I・O BOOKS)

はじめてのSpring Boot―スプリング・フレームワークで簡単Javaアプリ開発 (I・O BOOKS)

 

内容が濃いです。

２週目からは、痒いところに手が届いていることに気付いてゾクゾクしてきます。

１月中頃から使っていますが、時々読み返してます。

 

後は、Spring Project Documentation 、stack overflow、Blogに助けて貰ってますが、そろそろSpring Securityについてはアーキテクチャを理解して？、authenticationを独自実装したり応用したいなーと思ってます。

 

使い方を覚えるためにそれなりに時間を要しましたが、１月中頃から使い始めて直ぐにパッケージングから役割分担も出来て、フレームワーク導入は順調にスタートしました。

 

きっと、上記イメージどおりにメンバーと開発しながら、今回の選定目的を果たすことができるでしょう。これからが楽しみです。