エンターテイメント!!

遊戯王好きのJavaエンジニアのブログ。バーニングソウルを会得する特訓中。

2024/06/10週 気づきと振り返りなど

業務こなしての気づき

WebAPIをフロントの処理前提で作るんじゃない!!

パフォーマンスチューニングで、不要なループが回らないように処理を終了させたのだが、逆にそれがバグになってしまった。。。

テストが不十分だったのもあるが、なんでフロントの挙動前提でロジック組んでるんだ!って言いたい。
処理が複雑すぎて、イライラしながら解読してた。
複雑な処理を作るのが、偉いのではない。複雑な処理をシンプルかつ簡素に実装するのが、プログラミング能力の腕の見せ所だと思ってる。

本当は、処理が独立しているべきなのに、それが、フロントと密接に処理が絡み合ってるせいで、バグを作り込んでしまった。
これは、俺のせいなのか?
明らかなWebAPIの設計ミスだろって思うんだけど。。。
理由が分かった時のやるせなさが辛い。
フロントエンドとバックエンドが密結合されているせいで、ちょっとでも手を入れたら簡単に破綻しそう。
何のためにwebAPI化したのか、意味が分からんぜよ。。。

心の中のマグマが煮えたぎっている。
どこかに噴射したいんだが、はけ口がないな。。。

リリース後バグはメンタル削られる

リリース後障害、マジでメンタルが削られる。
何件か出てきたが、即日対応しているのだが、焦燥感がマジでヤバい。
障害が出てないときは、暇なんだけど、障害が出てきたときがキツい。

Windows11

現場のwindowsを10→11にアップデートされたのだが、右クリックが不便すぎる。
なんで、1クッション増えたんだ?って感じてる。
現場のPCだから、レジストリをイジるのもためらわれるので、毎回shift+右クリックしてる。
あのコンテキストメニュの必要性を全く感じないのだが、あれでメリット受けてる人間はいるのだろうか?

せめて、使い方が変わるのなら、設定で変更可能にしてくれって思う。

その他雑記

ポケモン

ダブルバトルのシャリタツ+ヘイラッシャ

久々に戦ったけど、あれ、卑怯すぎんだろ。。。
シャリタツが左側にいる時、間違えて選んでしまって、シャリタツに攻撃が当たらない行動をしてしまうのだが、ヘイラッシャに自動で攻撃が向くようにして欲しい。
攻撃する相手がいないときは、自動でもう片方に攻撃がいくのに、シャリタツと合体したヘイラッシャは、攻撃がスカになるのは、納得ができない。

JJUG CCC 2024 Spring 参加レポート

経緯

いつも参加しているJJUGが開かれるので参加
前日仕事で、仕事終わりに酒を補充して寝たので、朝起きれるか不安だったが、いつもの生活習慣で6時に目が覚めてもうた。
最近は、健康的な時間に目が覚めるけど、もうちょい早めに寝たい。

公式サイト

JJUG CCC 2024 Spring

JJUG CCC 2024 Spring(現地開催のみ) - 日本Javaユーザーグループ/Japan Java User Group | Doorkeeper

参加したセッション

  • 知名度は高くないけど便利なJavaライブラリ集
  • 次世代RDB劔"Tsurugi"にアクセスするJavaライブラリー・ツール

午後も出るか迷ったけど、前日仕事で出ていて明日も仕事なので、ちゃんと休暇するために午後は帰宅してゆっくりしていた。

参加セッションメモ

ほんとうにメモレベルなので、間違えてるかも。

知名度は高くないけど便利なJavaライブラリ集

知名度は高くないけど 便利なJavaライブラリ集 - Google スライド

  • jilt
    • ビルダークラスを生成する
    • lombox
      • バイトコード直接生成してる
      • アップデートで挙動が変わるが、見た目では分からないのでハマりやすい
    • 今年から注目されていされている
    • ビルダーにすることで必須項目の設定ミスに気付けないことがある
      • 対策としてStage Builderがある
        • 段階的に設定できる項目が決まっている。
        • アノテーションで設定できる
        • 必須フィールドが抜けることが検知できる
        • 可能な限りStage Builder使った方がいい
  • yavi
    • ラムダベースのバリデーションライブラリ
    • 既存のアノテーションチェックは、動かさないと定義ミスに気付けない
    • Arguments Validator
    • インスタンスができる前に、引数のチェックができる
    • 設定ミスを減らしたい
  • logbook
    • httpリクエストレスポンスのロギング
    • カスタマイズ性が高い
    • クライアント視点、サーバー視点のログが出てくる
  • Nullaway

    • ヌルポ解析の静的解析ツール
    • ヌルポが起きるコードをコンパイルエラーにできる
    • オーバーヘッドが小さい
    • デフォルトnon nullが前提
    • nullを許容すると連鎖的に対応する箇所が増えるので、null前提の実装にしないような習慣が着く
  • ライブラリの見つけ方

    • x経由で見つけてる
    • springの社内slackで見つけたりしている。

感想

  • Nullaway作ってる人、神経質っぽい気がする※個人の感想です
  • logbook/Nullawayは、さっそく個人開発してるプロジェクトに導入したい
    • Nullaway導入した結果、エラー出まくったら立ち直れないかも知れない
    • いきなりコンパイルエラー出すのは厳しそうなので、まずは警告状態でもいいから入れてみる?

次世代RDB劔"Tsurugi"にアクセスするJavaライブラリー・ツール

  • OSSRDBMS
  • インメモリDB
  • トランザクション分離は、SERIALIZEのみ
  • 実態はKVSだけと、RDBMSのように使える
  • jdbcは提供してない。代わりに、ライブラリを提供している
  • IPC接続/TCP接続

感想

  • 分離レベルの概念は、知っているのだが、足を踏み入れると沼りそう。
  • かなりのスペックが要求される?個人向けPCだと無理そう?
  • ライブラリ経由でのアクセスのみってのは初めて見た
  • jcommander/jlineが気になってしまった。
  • 企業枠での参加なので、例の灰色のブログのことはちょっとかすめた程度の説明だった

感想

前日が仕事は、辛たん。。。
早めにスケジュール確認して、休日出社ズラしてもらうなどをするべきだった。
直前に変わるってのが無理だったからな。。。

すぐ帰っちゃうのもあれだから、Oracleのアンケートに答えて、JavaTシャツもらった。
まぁ、部屋着用だな。
たぶん、着てても気づかれないと思うが、分かる人は分かるだろう。

知らないライブラリがいくつか知れたのが収穫だった。
とりあえず、自分の個人プロジェクトに入れて、効果を試す。
情報を得る一方で思ったこととしては、アンテナの張り方は、一考の余地ありだね。。。
今までは、知る機会がこういうイベントか、見てる雑誌だけど、もうちょい攻めた情報収集がしたい。今までだと、受動的だからね。
GithubやQiitaの検索機能使えばなんとかできそうな気がするので、調べてみる。

【翻訳+意訳・要約】プログラマーがやってはいけないこと

※本記事は、ChatGPTによる意訳+翻訳を活用し、レイアウト調整したものです。
※感想は、オリジナルです。

原文

Things Every Programmer Should *NOT* Do - DEV Community

意訳+要約

プログラマーがやってはいけないこと

ブログ記事「Things Every Programmer Should NOT Do」では、プログラマーが避けるべき行動について具体的に説明しています。以下に主要ポイントを箇条書きでまとめます。

  • エラーメッセージを無視しない:

    • エラーメッセージは問題の兆候です。無視せず理解し対応することが重要。
  • スパゲッティコードを書かない:

    • 読みやすく保守しやすいコードを書くことが大切。コーディング標準に従い、コメントを追加する。
  • 計画フェーズを飛ばさない:

    • 計画なしにコードを書くと問題が発生しやすい。プロジェクトの構造とフローを事前に計画する。
  • バージョン管理を怠らない:

    • 小さなプロジェクトでもGitなどのバージョン管理を使うこと。早めに頻繁にコミットする。
  • テストを軽視しない:

    • テストは必須。コードのバグを防ぐためにテストを書く。自動テストが有効。
  • 休憩を取るのを忘れない:

    • 長時間の連続作業は生産性を下げる。定期的に休憩を取ることが大切。
  • 助けを求めるのを恐れない:

    • 困ったときは他人に助けを求める。仲間やフォーラムを活用する。
  • 学習を止めない:

    • 技術は常に進化している。新しい技術を学び続けることが重要。

プログラミングはコードを書くことだけでなく、これらの落とし穴を避けることも含まれます。ミスを笑い飛ばし、そこから学び、前進し続けましょう。

ChatGPTへのQA

Q:意図せずともやってしまうことがあると思うのですが、その場合は、どのように対策すればいいでしょうか?

意図せずにこれらのミスをしてしまうことがありますが、以下の対策を講じることで防ぐことができます。

  • エラーメッセージへの対応:

    • エラーログを詳細に確認し、理解する時間を設ける。
  • コードレビューの習慣化:

  • 計画の徹底:

    • 小さなタスクに分け、進捗を管理するツールを活用する。
  • バージョン管理の自動化:

    • Gitの自動コミットやブランチ戦略を使用し、頻繁にコミットする。
  • テストの自動化:

    • CI/CDツールを導入し、コードの変更が自動でテストされるように設定する。
  • タイムマネジメント:

    • ポモドーロ・テクニックなどの方法で定期的な休憩を取り入れる。
  • コミュニケーションの強化:

    • 困ったときは早めにチームメイトやコミュニティに相談する文化を作る。
  • 学習の継続:

    • 新しい技術やツールを定期的に学ぶ時間をスケジュールに組み込む。

これらの対策を実践することで、ミスを最小限に抑え、効率的にプログラミングができるようになります。

Q:言うは易く行うは難しだと思うのですが、簡単に実現するにはどうしたらいいでしょうか?

自省を簡単に実現するためには、小さなステップから始めることが重要です。以下の方法を試してみてください:

  • 日記をつける:

    • 毎日数分だけ、自分の作業や気づきを簡単に記録する。
  • フィードバックの習慣化:

    • 毎週1回、同僚や上司と短いフィードバックセッションを設ける。
  • 簡単な目標設定:

    • 短期的で達成可能な目標を設定し、達成度を週ごとに確認する。
  • アラームやリマインダーの利用:

    • スマホのアラームやリマインダーを使い、自己チェックの時間を忘れないようにする。
  • マインドフルネスアプリの活用:

    • 瞑想や深呼吸のガイドを提供するアプリを活用し、日々のリフレクションを取り入れる。

これらの方法で、自省の習慣を無理なく日常に取り入れることができます。

Q:一人でこれらの避けるために、有効な補助ツールはありますか?

プログラミングにおいて、避けるべき行動を減らすために有効な補助ツールはいくつかあります。以下にいくつかの例を挙げます。

  1. 静的コード解析ツール: コードの品質や潜在的な問題点を検出するのに役立ちます。例えば、Pylint(Python向け)、ESLint(JavaScript向け)、FindBugsJava向け)などがあります。これらのツールは、未使用の変数や関数、潜在的なバグ、コーディングスタイルの問題などを指摘してくれます。

  2. コードフォーマッター: コーディングスタイルを一貫させるために使用します。例えば、Prettier(JavaScript向け)、Black(Python向け)、clang-format(C/C++向け)などがあります。これらを導入することで、コードの可読性を向上させることができます。

  3. バージョン管理システム: 例えばGitを使用することで、コードの変更履歴を追跡し、過去のバージョンに戻すことができます。また、コードレビューやチームでの協力的な開発を支援します。

  4. 自動テストツール: ユニットテスト、統合テスト、機能テストなどを自動化するツールがあります。JUnitJava向け)、pytest(Python向け)、Jest(JavaScript向け)などがあり、コードの品質を保証し、バグを早期に発見するのに役立ちます。

  5. IDEの支援機能: 統合開発環境IDE)には多くの補助機能があります。自動補完、シンタックスハイライト、リファクタリングツールなどが含まれ、効率的なコーディングをサポートします。

これらのツールは、プログラマーがより効果的にコーディングするための手助けとなります。適切に導入し、定期的に利用することで、品質の高いコードを保つことができます。

感想+雑記

いろいろやり取りはしたけど、新しい発見はなかったな。。。
基本的に、一人作業が多いから、一人でもなんとかチェックできる体制を作りたいんだけど、全部実施済みだった。
やるとしても、日記付けだな。
最初はやってたんだけど、めんどくさくて辞めちゃった。
毎日、刺激的なことばかりじゃないからね。
書くことが辛くなる。

ゆっくりと死んでいくだけのオレの心を、誰か生き返らせてくれねぇかな?

【翻訳+意訳・要約】効果的なノート整理法

※本記事は、ChatGPTによる意訳+翻訳を活用し、レイアウト調整したものです。
※感想は、オリジナルです。

原文

Organization schemes for note taking - DEV Community

意訳+要約

効果的なノート整理法

ブログ「Organization Schemes for Note Taking」では、ノートを効率的に整理する方法について説明しています。重要なポイントを以下にまとめます。

ファイルとフォルダーによる整理

  • ファイル:各ノートを個別のファイルとして管理(例:「MeetingNotes.md」や「ProjectIdeas.txt」)。
  • フォルダー
    • Inbox:一時的なノートやクイックメモ用。
    • Archive:完了したノートや閲覧頻度の低いノートの保存。
    • Projects:プロジェクトごとにフォルダーを作成(例:「ProjectA」、「Personal」、「Work」)。
    • Reference:長期的に参照する資料用(例:研究論文、マニュアル)。

ラベルとタグの使用

  • ラベル:ノートに説明的なラベルを付ける(例:「Urgent」、「Important」、「Review」)。
  • タグ:クロスリファレンス用のタグを付ける(例:「Meeting」、「Ideas」、「Code Snippets」)。

メタデータの活用

  • 作成日:ノートの作成日時を記録。
  • 作成者:共同作業の場合に有用(例:「Created by John」)。
  • 場所:関連がある場合に記録(例:「Conference Notes - Seattle」)。

リンクの活用

  • 内部リンク:ノート内で関連する内容をハイパーリンクで接続。
  • 外部リンク:ウェブページや記事など外部リソースへのリンクを追加。

フォルダー構造の例

  • Inbox:未整理のノートが最初に入る場所。定期的に確認し、適切なフォルダーに移動。
  • Archive:完了したノートや歴史的なノートを保存。あまりアクセスされないが価値がある。
  • Projects:各プロジェクトやトピックごとのサブフォルダー。
  • Reference:特定の種類(例:「Research」、「Tutorials」)ごとのサブフォルダー。

ノート整理の構造は、自分のニーズや好みに合わせて調整することが重要です。継続的に同じ方法を使用することが成功の鍵です。

ChatGPTへのQA

Q:メモ帳としてObsidianを使っているのですが、メモにラベルを張ることはできますか?

Obsidianを使ってメモにラベル(タグ)を貼ることは可能です。以下の方法でタグを追加できます。

タグの追加方法

  • タグの形式#タグ名 の形式でメモの任意の場所にタグを記載。
  • タグの管理:左側のサイドバーにある「タグペイン」で全タグの一覧や使用頻度を確認可能。
  • リンクの追加:特定のタグページを作成し、タグのリンクをクリックすることで関連ノートを一覧表示。

Q:ノートの管理方法として有名なフォルダ構造を教えて下さい

有名なフォルダー構造の例

PARAメソッド

Projects: 現在進行中のプロジェクト Areas: 継続的な責任や関心領域 Resources: 参考資料や情報 Archives: 完了したプロジェクトや過去の資料

GTDメソッド

Inbox: 収集するすべてのメモ Next Actions: 直近で行うタスク Projects: 複数のタスクで構成されるプロジェクト Someday/Maybe: いつかやるかもしれないタスク

Zettelkastenメソッド

メインフォルダー: すべてのノート インデックス: ノートの目次やリンク集 参考資料: 引用や参考にした文献

Q:ノートを保存するうえで重要なことは何でしょうか?

ノートを保存するうえで重要なポイントは以下の通りです。

1. 一貫性

  • 一貫した命名規則やフォルダー構造を維持。
  • テンプレートやタグを活用し、ノートの統一性を保つ。

2. アクセス性

  • 必要な時に迅速にアクセスできるように整理。
  • 効率的な検索機能を活用。

3. バックアップ

  • 定期的なバックアップを行い、データの喪失を防ぐ。
  • クラウドサービスを利用して複数のデバイスからアクセス可能に。

4. 整理と見直し

  • 定期的にノートを整理・更新。
  • 古い情報をアーカイブし、最新情報を維持。

5. セキュリティ

  • センシティブな情報にはパスワードや暗号化を使用。
  • 安全なクラウドサービスを選択。

これらのポイントを押さえることで、ノートを効果的に管理し、必要な時に迅速に活用できるようになります。

感想+雑記

自分は、メモの管理方法として、Obsidian + GoogleDriveで、擬似的にファイル共有しつつMarkdownによる一貫性のとれたテキストを保存できるようにしている。
今の問題点は、アクセス性の良さかな?それほど量がないので、問題ないんだが、増大してくるとだめかも知れない。
あと、Google Driveが、何か信用できなくなってきたのもある。Google Driveのデータ消えましたとかニュースで見たから、ちょっと信頼性は低いと感じている。
でも、無料の移行先が他にあるのかと言われると、あんまり思いつかない。DropBoxがあるけど、最近は、制限が厳しいイメージがある。

とりあえず、フォルダ構成の見直しと、メタ情報の付与について考え直したい。

なんか、こう、もっと革新的な手法が欲しいんだよね。
毎回、メモ探すのに苦労するし、文章考えるのがシンドい気分。

【翻訳+意訳・要約】JsoupでHTMLテーブルを解析する

※本記事は、ChatGPTによる意訳+翻訳を活用し、レイアウト調整したものです。
※感想は、オリジナルです。

原文

意訳+要約

JsoupでHTMLテーブルを解析する

Jsoupを使用したHTMLテーブル解析の概要

ブログの主なポイント:

  • Jsoupの概要

    • オープンソースJavaライブラリで、HTMLの解析、抽出、操作をDOM APIメソッドを通じて提供。
    • HTMLテーブルの解析が得意。
  • 利点

  • 欠点

    • Javaの知識が必要
    • JavaScriptで生成された動的コンテンツの解析に制限
    • 大規模なHTMLドキュメントではパフォーマンスの低下が起こる可能性
  • コード例

    • pom.xmlbuild.gradleに依存関係を追加。
    • HTMLテーブルの解析、更新、削除の具体例を示すJavaコード。
  • 結論

    • JsoupはHTMLコンテンツとのインタラクションにおいて強力で効率的な手段を提供し、特にHTMLテーブルのデータ抽出や操作に優れている。
    • 動的コンテンツには限界があるが、静的HTMLの解析には非常に有用。

ChatGPTへのQA

Q:利用用途としては何がありますか?

Jsoupを使用したHTMLテーブル解析の利用用途

  • データスクレイピング: ウェブサイトからテーブルデータを抽出。
  • ウェブクローリング: 複数のページから統一フォーマットでデータ収集。
  • テスト自動化: HTML出力の検証。
  • データ変換: HTMLテーブルを他のデータ形式CSVJSONなど)に変換。
  • コンテンツ管理: ウェブコンテンツの一部を動的に更新。

Q:HTTP Clientとの違いは何でしょうか?

JsoupとHTTP Clientの違い

  • Jsoup

    • 主な機能: HTML解析・操作、スクレイピング
    • 用途: HTML文書のパース、DOM操作。
    • 特徴: HTMLから特定の要素を抽出しやすい。
  • HTTP Client

    • 主な機能: HTTPリクエストの送信・レスポンスの取得。
    • 用途: サーバーと通信してデータをやり取り。
    • 特徴: JSONXMLのレスポンスの解析が得意。

まとめ: JsoupはHTML文書の解析・操作に特化し、HTTP Clientはネットワーク通信に特化しています。

感想+雑記

Jsoupは、利用したことがあるんだけど、CSSの知識が乏しいと、扱うのは難しい。
少なくとも、俺は難しく感じた。
得意ではない領域は、手を付けると、思い通りにいかなくて、イライラしちゃうよね。

CSSって、どうやったら上達するんだ?
使って覚えるしかないのだろうか?
適用したい箇所のルール作るのは良いんだけど、毎回、同じようなものを乱立してしまうんよな。。。
Bootstrap使っているけど、あれは、CSS使ってるって感じがしない。
CSS適用のルールくらいは覚えたけど、Stylusとか使って覚えた。
問題は、アニメーションの仕方を覚えたりしたいとは思っているが、楽な方に逃げてしまうんよ。
だいたい、どこかのサイトのコピペ使ってる。

話がそれたが、jsoupは、オリジナリティがあり、代価しにくい印象がある。
データスクレイピングするなら、jsoupが候補にあがるけど、データ取得するためだけに使うかと言われるとNoだな。
なかなか使い所が難しい。
アイディアとしては、画像の取得とかで使ってみたい願望がある。

【翻訳+意訳・要約】コードカバレッジ: テストの有効性の測定

※本記事は、ChatGPTによる意訳+翻訳を活用し、レイアウト調整したものです。
※感想は、オリジナルです。

原文

Code Coverage: Measuring the Effectiveness of Your Tests - DEV Community

意訳+要約

コードカバレッジ: テストの有効性の測定

この記事は、ソフトウェアテストの効果を測定するためのコードカバレッジについて詳しく説明しています。以下に重要なポイントをまとめます。

コードカバレッジの概要

  • コードカバレッジは、テストスイートがプログラムのソースコードをどの程度実行しているかを示す指標です。
  • 高いコードカバレッジは、未検出のバグが少ないことを意味します。

カバレッジの種類

  1. ラインカバレッジ:実行されたコード行の割合を測定。
  2. ステートメントカバレッジ:各ステートメントが実行されたかを確認。
  3. ブランチカバレッジ:すべての分岐が実行されたかを確認。
  4. 条件カバレッジ:条件文の各ブール式が真偽両方で評価されたかを測定。
  5. 関数カバレッジ:各関数が呼び出されたかを確認。
  6. パスカバレッジ:すべての可能なコードパスが実行されたかを確認。

利点

  • コード品質の向上:未テスト部分を特定し、包括的なテスト作成を促進。
  • デッドコードの検出:実行されないコードを特定し、保守性と性能を向上。
  • テストスイートの強化:包括的なテスト作成を促進し、バグ検出能力を向上。
  • 信頼性の向上:高いカバレッジにより、ソフトウェアの安定性と信頼性を確保。

制限

  • 虚偽の安心感:高カバレッジはバグがないことを保証しない。
  • カバレッジ vs. 質カバレッジを上げることに集中しすぎると、実質的なテスト品質が低下する可能性。
  • 複雑さとコスト:100%カバレッジを達成するのは難しく、コストがかかる。
  • 減少するリターン:一定ポイントを超えると、カバレッジを上げる努力に対するリターンが減少する。

ベストプラクティス

  • 現実的な目標設定:プロジェクトに応じた適切なカバレッジ目標を設定。
  • 重要なコードの優先:クリティカルなコード部分を優先的にテスト。
  • カバレッジツールの統合:JaCoCoやIstanbulなどのツールを使用して自動計測。
  • 定期的なレビューとリファクタリング:テストスイートを見直し、テストの有効性を向上。
  • 他の品質指標との併用:複雑度や欠陥密度などと併用して包括的な品質評価を実施。
  • 継続的インテグレーション:CI/CDパイプラインにカバレッジチェックを統合。

結論

コードカバレッジはソフトウェア開発において重要な指標ですが、唯一の評価基準ではありません。高カバレッジとともに、効果的で意味のあるテストを書くことが重要です。

ChatGPTへのQA

Q:質に繋がらないとなると、やる意味はあるのでしょうか?

コードカバレッジは、ソフトウェアテストの品質向上に貢献するものの、一部の課題もあります。カバレッジの数値が高くても、必ずしもコードの質が保証されるわけではなく、カバレッジだけに頼ると虚偽の安心感を与える可能性があります。しかし、適切に活用すれば、未テスト部分の特定やデッドコードの発見に役立ち、テストの包括性を向上させることができます。

コードカバレッジの利点

  • 未テスト部分の特定:テストが不足している部分を明らかにします。
  • デッドコードの検出:不要なコードを見つけて保守性を向上させます。
  • 信頼性向上:テストスイートの充実により、ソフトウェアの安定性が向上します。

Q:カバレッジからは、ソフトウェアのどのような状態が読み取れるのでしょうか?

コードカバレッジからは、ソフトウェアの以下の状態が読み取れます:

  1. テストの充実度:テストがコードのどの部分をカバーしているかを示し、未テスト部分の特定が可能です。
  2. デッドコード:実行されないコードを特定し、削除や修正が必要な部分を明らかにします。
  3. バグの潜在性:低カバレッジの箇所はバグが潜んでいる可能性が高くなります。
  4. テストの優先順位:どの部分のテストが不足しているかを確認し、テストの充実に役立ちます。

これらの情報を基に、ソフトウェアの品質向上や保守性の向上を図ることができます。

感想+雑記

カバレッジでわかるのは、質ではなくテストの充実度ってことね。
テストがやられているから、質も担保されていると感じるのは違うってことだ。

質の担保が弱そうなところにあたりがつけられるのが、最大のメリットだろうな。
指標をどうつかうのが正解なのか、個人的にはよく分からん。
たぶん、これだけを使うだけでは、品質の評価はできないような気がする。
指標出すのはいいんだけど、ちゃんと使われてんのかな?って疑問に思うこともある。

カバレッジ100%は、マジで労力と成果が見合ってない。
ほんの数パーセントのために、かなりの労力を使うんだよね。。。
クラス設計をちゃんとしてても、数パーセント残ることをよくある。
テストしやすいようにロジック組めばいいんだけど、そんなに現実は甘くない。
現実は非常である。

個人開発では、コードカバレッジと、ソース評価系のツール使って、品質高めるようにしている。
最近、JUnit5を使いこなせていないことに気づいたので、徐々にテストコードを変えようと思ってる。
あとは、セキュリティ的な観点でのチェック入れるようにしてる。

【翻訳+意訳・要約】ビジネスコードを他から切り離す

※本記事は、ChatGPTによる意訳+翻訳を活用し、レイアウト調整したものです。
※感想は、オリジナルです。

原文

Keep your business code separate from the rest - DEV Community

意訳+要約

ビジネスコードを他から切り離す

まとめ: ブログでは、古いコードベースの現代化を進める際、ビジネスロジックを他のコードから分離することの重要性を強調しています。これにより、将来的なフレームワーク変更時にもビジネスロジックを簡単に移行できるようになります。具体的には、ビジネスロジックを独立したフォルダーに保管し、データ処理層を分けて管理することが推奨されています。

ChatGPTへのQA

Q:フォルダ構成は、どうあるのが最適でしょうか?

最適なフォルダ構成の例:

  • src/
    • business/
      • services/
      • models/
      • repositories/
    • controllers/
    • middlewares/
    • routes/
    • utils/
    • config/

詳細:

Q:businessフォルダーを分けるのは良いんですが、そこまで破壊的な変更は発生するのでしょうか?

確かにフレームワークが変わる場合、すべてのコードが問題なく移行できる保証はありません。しかし、以下のようにビジネスロジックを分離することで、移行の際の影響を最小限に抑えられる可能性が高まります。

理由

推奨フォルダ構成

  • src/
    • business/:
      • services/: ビジネスロジック(純粋なJavaScript/TypeScriptで書く)
      • models/: データモデル(可能ならPOJO/POCOを使用)
      • repositories/: データアクセス(抽象化レイヤーを使う)
    • controllers/: フレームワーク依存のコントローラー
    • middlewares/: リクエスト処理の前処理
    • routes/: ルーティング定義
    • utils/: ヘルパー関数(フレームワーク非依存)
    • config/: 設定ファイル

移行時のポイント

  1. フレームワークに依存しないコード設計: ビジネスロジックフレームワークに依存しない形で設計する。

  2. テストカバレッジの確保: ビジネスロジックに対する単体テストを充実させ、移行後も動作が保証されるようにする。

  3. 抽象化レイヤーの活用: データアクセスやサービス呼び出しなどを抽象化し、フレームワークに依存しないインターフェースを設ける。

Q:各フォルダ構成の依存関係について説明お願いします

以下は各フォルダ構成の依存関係についての説明です。

フォルダ構成と依存関係

  1. src/

  2. business/

    • services/:
    • models/:
      • ビジネスデータモデルを含む。
      • 他のビジネスロジックやデータアクセス層から利用される。
      • 独立しているが、他のサービスやリポジトリから参照される。
    • repositories/:
      • データアクセスロジックを含む。
      • データベースや外部APIとのやり取りを担当。
      • フレームワークに依存する可能性があるため、抽象化レイヤーを使用する。
  3. controllers/

  4. middlewares/

    • リクエストの前処理や認証を行う。
    • ルーティングやコントローラーに依存。
    • フレームワークに依存することが多い。
  5. routes/

  6. utils/

    • ヘルパー関数を含む。
    • 他のすべてのフォルダから利用可能。
    • フレームワークに依存しない汎用的なコードを含む。
  7. config/

    • 設定ファイルを含む。
    • 他のすべてのフォルダから参照される。
    • フレームワークに依存する設定も含まれる。

依存関係の概要

  • businessフォルダのコードはフレームワークに依存しないことが推奨されます。
  • controllersmiddlewaresroutesフレームワークに依存する部分が多いです。
  • utilsはどこからでも参照され、フレームワークに依存しません。
  • configはアプリケーション全体の設定を含み、すべてのフォルダから参照されます。

このようにフォルダを分けることで、フレームワークの変更時にもビジネスロジックの再利用がしやすくなります。

感想+雑記

何度かやり取りしたけど、フォルダ構成の正解が分からん。
そもそも、サービスのロジックをどこからするのか、すごく迷うんだけど、俺だけ?
個人開発してるのは、ビジネスロジックがほぼないから、あんまりメリットないので、特に分けることはしてない。
FWが変わることがほぼないので、それなら、フォルダ階層が一貫性あるものがいいと思うんだが。
結局、この構成って、ControllerとServiceが1:1になるから、意味あるのか?って毎回思ってしまう。

未だに納得出来ないんだよな。。。
フォルダ構成で戦争起きてしまいそうな気がする。
たぶん、ガンジーでも戦争起こすと思うね。