Kashibuchi’s blog

勉強のこと、趣味のこと、日々のこと

やりたいことメモ(備忘録)

アプリを作りながら勉強したい

なんのアプリ?

稼働時間入力アプリにしよう

実現したいこと

  • ログイン機能
  • プロジェクト名を入力して登録
  • 登録済プロジェクト名を選択して時間計測
  • カレンダーから週毎、月間の累積稼働時間を参照
  • 計測した時間を修正

やること

画面作成

  • HTMLとCSSのみでひとまず作成

アプリ機能作成

  • SpringBootを使用
  • DBはとりあえずインメモリ
  • TDDで開発

ちょっとリッチに

  • モーダルウィンドウで確認メッセージ表示(モーダルのライブラリ選定)
  • 時間計測を非同期で処理(JavaScriptJQuery?Vue.js?)

書籍の感想「テスト駆動開発」

shop.ohmsha.co.jp

以前、私が参加しているJavaのサロン(で合ってる?)JPINにて読書会があり、そこで感想を共有したのですが、業務を通じて自分の中で改めて持った感想をここにまとめようと思います。

まず、やってみよう

読み終えた最初の感想は、自分一人でもやってみたいし、ある程度テストが書ける人が相手であれば、ポイントを押さえた説明をすれば曲がりなりにも複数人で実践できそうな気がすると感じました。 読み終えたタイミングで、派遣先プロジェクトのリーダーさんにTDDを読んだうえでやってみる旨を話したところ、ぜひぜひということですぐに取り掛かれました。 そして、他のメンバーにもなるべく具体的になるよう作業説明をして実践していただきつつ、自分でもやってみました。

実際に作ってみると、書いた実装を読み解きながらテストを書くよりもスムーズかつ、漏れが起きないように感じました。 スムーズというのは、「処理としてはザルなんだけどとりあえず期待値を返す」状態から、動いてほしい処理のwhenやverify(JavaなのでMockitoを使っています)を書いてから実装に反映させるので、無駄なモックを作らない感じがしました。 漏れが起きないというのも、テスト対象が依存している処理の呼び出し有無判定が抜けないので、より正確に書けていると感じました。

利用しているクラスのテストはどうする?

ちょっと悩んだのはこの書籍のやり方だと、今まで自分がテストを書く際にやっていた、テスト対象ソースとテストソースが1対1になる、対になる状態にはならないことが気になりました。 ただ、テスト駆動であるおかげで必要な処理バリエーションはきちんと確認できているので問題はないはずなんですよね。 この後感想を書くつもりである『良いコード/悪いコードで学ぶ設計入門―保守しやすい 成長し続けるコードの書き方』も踏まえてテストを書いていくと、DTO(※的なものとしておきます)はただのGetter/Setterだけを持つクラスにはならずに判定処理やデータ加工のメソッドを持つようになったんです。 そして、このクラスに対してのJUnitテストソースが必要かなと思ったのですが、DTOの利用クラス側のテストで十分にパターンは網羅できたので、その結果としてテストソースの量が減るならば喜んでよいのではないかなと思うのです。 この辺はTDDの書籍を読んだことのある人が管理者側にいるか、自分がつよつよエンジニアになれば納得してもらえるようになるのかなあ、とぼんやり思いました。

ウォーターフォールにも合う

TDDって、正直アジャイル的な手法だと思っていました。 ですが、これはウォーターフォールにも適用可能な手法なんだと実際に試して理解することができました。 結局単体テストで動作を定義しながら実装を作っていくのって、デバッガを使用したり、ローカルでアプリそのものを起動して動作確認しながら実装していくのと変わらないと感じたんです。 それに、

  • 実装期間中に単体テストも着手できる
  • テストソースを書いているため、自分の実装した処理による結果が明確にされている
  • 手戻りがあっても、『テストを正しい方に変更→実装を変更』の流れで柔軟に対応できる

ということで、実装を終えてから単体テストソースを書くよりも良いことが多かったです。 「テストを書きながら実装をするんだから、工数的には多くなるじゃないか、余計に時間がかかるのではないか」という印象もあったのですが、ありませんでした。 前述した『デバッガを使用したり、ローカルでアプリそのものを起動して動作確認』の時間がテストソース作成の時間に置き換わるだけでした。

また、テストをすでに書いているので、処理をメソッドや別クラスに切り出すといったリファクタリングにも対応できるのが嬉しいポイントでした。

結論「TDD、怖くない」

テストを書いて動作を定義しながらの実装は良いことずくめでした。 最高。

仕事での開発で感じたこと

はじめに

ようやっと業務でJavaのソースを触れる、単なる修正ではなく機能追加を行うので構造を考えて実装ができる、ということで喜んでお仕事しましたが、既存のソースで気になる点があるため、自分ならどう作るのか考えをまとめることにしました。

ただし、具体的な実装方法は勉強しないとわからないので、そこは宿題。 つまり、以下は自分の宿題リストも兼ねる。

一応、前提はJava(SpringBoot)。

ログ出力の分離

設計にて実現したい機能とログ出力内容を定義するけど、ソース上は一つのメソッドに処理もログも書いてある。 その為、ログのメッセージ内容なんてものは単体テストレベルで文字の一致を確認できれば間違いがないのに、テストソースが煩雑になったりしてやりにくい。

FATAL、ERROR、WARN、INFOログの出力は処理を書いたメソッドとは別に実現したほうがテストもしやすいんじゃないかなあ。 ビジネスロジック内で書いてもよいのはDEBUGのみ。

リポジトリ(MybatisのMapper)の試験はインメモリDBではなく、実際に使用するDBで試験する

インメモリDBでSQLの試験ができるなんていいじゃん!と思っていたのですが、DDLが実際に使用するMySQLPostgreSQLと異なるので、インメモリDB用のschema.sql作成しないといけない。 異なる種類のDDLを保持するのはもったいし、間違えそうなのでテストでもインメモリDBは使いたくないなと感じた。 CIでどのように動作させようかな、とは思うが。

JJUG CCC 2022 Fallにオンラインで参加しました

今までは視聴して手元のメモに書き留めるのみだったのですが、 折角オンラインでセッションをしちょいうできるのなら、見ながら記事を書いてしまえ、と思いやってみます。

AWS環境におけるSpring BootアプリケーションのCI/CDをCircleCIで構築した話

視聴を決めた私の動機

  • CI/CDに興味があるがどうやるの?
  • 配属先でCodeCommitを使用しているので、導入ハードルは低いので自分にもできるかなあ

メモ

アプリの構成

  • AWS × Spring Boot × CircleCI
  • EC2にてSpring Bootアプリを配置
  • ECSにてSpring Batch/Spring Boot
  • Gradleのマルチプロジェクト

CircleCIの構成

  • DBUnitでCircleCIにてMySQLを起動して実行(H2と微妙にことなるのでDBUnitが通らない)
  • SpotBug、CheckStyle、Unitテストの実行は並列実行

自分の感想

  • 調べたら、CircleCIって有料なのね。でも考え方は他の何を使っても一緒だろうし、お手本になるかも。
  • テストデータ投入は別途手で行うとあった。事故の元だということで。もう一度、その部分だけ聞き直したいかな。

聞きながらググったもの

circleci.com

Git 未経験者が GitHub Actions で CI/CD できるようになるまで

視聴を決めた私の動機

  • CI/CDに興味

メモ

  • ブランチ戦略を明確に定義しておく事が肝要
  • 無料分を枯渇させないのは大事(有料でも予算的に許される範囲で使う)

自分の感想

  • 新しいことの導入の苦労はあるよなあ。調査検討して、あとは教えて習熟してもらっての流れはちゃんと作らないと回らないなあ。

LINE NEWSにおけるJava移行の5年間の歩みとこれから

視聴を決めた私の動機

  • Javaを選ぶってどういうことなのかな、という興味
  • LINE NEWSってJavaなんだ!びっくり!

メモ

  • なぜJava
    • Perlエンジニア不足
    • LINE社内ではJVM言語向けのエコシステムが充実している
  • 機能開発を止めないために
    • 新機能はJavaで、機能改修もできるだけJavaへリプレイス
    • API仕様は変えない
  • Perlを理解できないと既存の実装の理解が難しい
    • Perlエンジニアが実装をドキュメントに起こす
  • 使われなくなったAPIの削除
  • 発生した問題
    • 言語仕様差分については開発時にローカルで解消できたのであまり問題にならなかった
    • 負荷の問題
      • GC
      • Memory leakやRace Comdition
      • 負荷テストは実行基盤を整えて、CI/CDで自動化、デイリー実行しているそう(QAより)

自分の感想

  • トラフィック大きいな……。限られた人しか使わない業務アプリケーションしかやったことがないから、どう対処しているんだろう。負荷・性能試験とか。
  • 負荷によるRedisのレスポンスタイムアウトの件、解消までの道のりが難しい……。すごいなあ。ググって質問サイトを見るだけではなく、公式ドキュメントを読み切る力はやっぱりつけておかないとだめだよねえ…。英語の勉強しなきゃ。

聞きながらググったもの

tech.askul.co.jp

github.com

入門:テスト技法とJUnit

視聴を決めた私の動機

  • テストを書く文化を浸透させたいのでそのヒントに

メモ

  • JUnit オリジナルの作者 -> Kent Beck、Erich Gamma
  • 新規にテストを書くならJUnit5
    • すべてを4 -> 5に書き直すメリットはない
  • Extension
  • テストしやすいコード!
    • メソッドはなるべくvoidにしない
    • 副作用のあるメソッドはなるべく少なくする
    • 外部システムにアクセスする箇所はなるべく少なくする
    • 日時、ランダム値は引数で渡す

自分の感想

  • 自分が知っていることの復習だなあ、という感じ
  • 聴きながらカバレッジ100%は目指したいけど、境界値はレポートに表れないから結局ソースレビューしないと良くないよね
  • あれ?うちのチームソースレビューしてないよね???

Java開発ツールのあれこれ ~便利そうなツールを色々集めてみた~

視聴を決めた私の動機

  • 知らないツールでよさそうなのがあれば導入したいなあ

メモ

  • SpotBugs使いたいけど、コーディング中に毎回実行する営みにするか、CIができていないとだめだなあ
  • Error Prone
  • ESLint ‐ Jenkinsのトレーニング、資格なんてあるんだ!

自分の感想

  • ArchUnitってあったなあ。別のセッションというか、別のイベントで知ったが。

Javaの入門が終わったら何の勉強をすればいいの?

視聴を決めた私の動機

  • さすがにJava初心者ではないけれど、業務で必要になったなど、行き当たりばったりに学習をしているので、もっと指針を決めないとこの先つらいかなあ、と不安になっているので。
  • 業界に入るのが遅かった & あまり開発に関われなかった & 不安になった割に個人学習が足りない自覚もある

メモ

自分の感想

  • 「期限はないのでじっくりやりましょう」が心強かったです…。自分に焦りがあるので。

気になるスライド資料やブログ記事のまとめ

命名とか

irof.hateblo.jp

↑こちら、データの名称の参考に。

Docker

Docker怖い。書籍買って読んだけどよくわからないんだもの。 でもそろそろやらないと。

leap.jfrog.com

zenn.dev

テスト関連

veriserve-event.connpass.com

↑参加していないけど、こちらのイベントで発表されていた資料。 Javaで同じ考えを適用できるものも一部あるので貼付。

speakerdeck.com

speakerdeck.com

speakerdeck.com

↑の人が合わせて読むと良いとしている資料。 speakerdeck.com

blog.jnito.com

Gitワークフロー

気になる。 単なるバージョン管理にしか使っていないので。

tech.isid.co.jp

Linuxコマンド関連

コマンドはある程度分かるけど、ある程度でしかないので。

note.com

DDD

youtu.be

little-hands.hatenablog.com

2022 JJUG CCC Spring メモ

視聴しなかったけど、こちらのセッション資料で気になる点が。

speakerdeck.com

39ページ目で、「BCryptPasswordEncoderが遅い」「BCryptPasswordEncoderを使用せず自前実装に切り替えたところ1500msから350msまで改善」とあるけど、暗号化やハッシュ化回りは自前実装しないのがセキュリティ的には安心なんじゃなかったっけ?

www.websec-room.com

これこれ↑。 徳丸浩さんのツイートもあるし。

で、BCryptPasswordEncoderが遅いならPbkdf2PasswordEncoderかなあ。 SCryptPasswordEncoderはいくつか警告もあるし。

自分でログイン認証作るときは考慮しよう。

spring.pleiades.io

spring.pleiades.io