はてなブックマーク

はじめに この記事では、親テーブルと子テーブルの関係を、実質的な1対1から1対多に移行したときのDBリファクタリングを整理します。 題材は実際の移行作業を元にしていますが、テーブル名やカラム名、業務背景は抽象化しています。 主題は、親テーブルに置いていた属性を子テーブルへ移し、既存データを壊さずに関係を組み替える進め方です。 特に、データ構造で表現すべきものをアプリケーション側で無理に吸収した結果、集計や検索や更新のすべてにしわ寄せが広がり、DBを直さない方が危険になったケースを扱います。 もともとは親テーブル側に属性IDを持たせていましたが、この構造では1件の親に複数の子を自然にぶら下げにくくなっていました。 そこで、属性を子テーブル側へ移し、親子関係を整理し直しました。 アプリケーションコードも修正しましたが、この記事では特にDBスキーマ変更とデータ移行の進め方に絞って扱います。 今回

はじめに この記事では、Javaの検査例外（checked exception）と非検査例外（unchecked exception）という仕組みが、Goといった後発の言語でなぜ採用されなかったのかを整理します。 Javaから他の言語に移ったエンジニアが「なぜこの言語には検査例外がないのか」と疑問を持ったときの答えになることを目指します。 前提：Javaが設計された時代 Javaは1990年代に設計された言語です。当時の優先事項は「安全性」と「信頼性」であり、エラーを見逃さないようにコンパイラが強制するという設計は合理的な判断でした。 後発の言語の中には、この設計が実運用でどう使われたかを踏まえて設計されたものがあります。検査例外への批判の多くは、理論的な問題ではなく実際の開発現場で積み重なった経験から来ています。 Javaの検査例外とは何か Javaには例外を次の2種類に分類する仕組みが

はじめに 業務システムのDBを読んでいると、一つのテーブルに複数のステータスカラムが同居しているケースをよく見かけます。 CREATE TABLE orders ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, user_id INT UNSIGNED NOT NULL, order_status TINYINT NOT NULL, -- 1:受付 2:審査中 3:処理中 4:完了 5:停止 payment_status TINYINT NOT NULL DEFAULT 1, -- 1:未請求 2:請求済 3:収納済 4:失敗 external_status TINYINT, -- 外部システムのステータス（1〜4, 9） external_code VARCHAR(2), -- 外部機関ごとにコードが異なる processed_at VARCHAR(8

はじめに Javaをメインに使ってきたエンジニアが、Goを業務で使い始めて気になった点を整理します。 言語仕様の違いから来る戸惑いと、慣れてみると納得できた部分の両方を書きます。 自分の言語経験 大学時代にPythonでデータ分析からプログラミングを始め、業務・趣味を通して次の言語・フレームワークを触ってきました（※転職後に挙げているSpring BootとFastAPIは趣味で触ったものです）。 新卒入社時： 言語：Java、VBA、JavaScript、TypeScript、Python フレームワーク：Spring Batch、Angular、Vue、Express 転職後： 言語：Java、VB.NET、JavaScript、TypeScript、Go、Python フレームワーク：Spring Boot、Java EE、React、Angular、Gin、FastAPI Java

はじめに この記事では、クリーンアーキテクチャでモックをどこまで使うべきかを整理します。 主張はシンプルで、モックは必要な境界に限定した方が運用しやすい、です。 この記事は、理想的な依存逆転の教科書的整理より、Go + GORM + MySQL の業務アプリで実DB integration test を前提にしたとき、どこまで抽象化とモックを入れるのが現実的かを扱います。 特に次の条件のチームを対象にしています。 Go GORM MySQL 業務アプリ Repository実装は実質1つ SQLの正しさが重要 実DBのintegration testを回せる この前提では、Repository interfaceを先に増やすより、実装とテストをまっすぐ置く方が失敗しにくくなります。 これはクリーンアーキテクチャそのものを否定する話ではなく、実装が1つで実DB検証が可能な現場では、抽象化を増

はじめに この記事では、現場でよく見る「読みにくいExcelやCSVの表」がなぜ広く定着したのかを、業務慣行、組織文化、評価軸の観点から整理します。 最初に、論点を次の2層に分けて扱います。 技術的・構造的な層: 読みにくいCSVは、どこがデータ構造として壊れているのか 文化的・運用的な層: なぜExcel中心の運用が続き、壊れた構造が再生産されるのか CSVは本来データ交換形式であり、人間が直接読む前提の形式ではありません。 問題はCSVそのものより、CSVを人間に読ませる運用と、帳票都合をデータ構造に持ち込む運用です。 あわせて、列を圧縮して見栄えを優先してしまう理由と、そこから抜けるための実務的な改善策を扱います。 以下のようなCSVは、公的データや実務データでも実際に見かけます。 見た目はそれらしくても、分析や連携の段階で扱いづらくなるのが問題です。 この記事でいう「ダメなCSV」

はじめに ウォーターフォールは、要件定義から順番に進める前提で語られることが多いです。私も最初はそのイメージで進めていました。 ただ、実務で何度か痛い目を見て、結局は先の工程に早めに触れないと成立しない場面が多いと感じるようになりました。 この記事で言いたいことはシンプルです。 工程を崩したいのではなく、前工程の精度を上げるために、先の工程の情報を先に取りにいく必要があるという話です。 よくある前提 ウォーターフォールの説明では、次のような順序が理想形として置かれます。 要件定義 基本設計 詳細設計 実装 テスト この順序自体は間違っていません。 ただし、既存システム改修では、前工程に必要な判断材料が実装側に埋まっていることが多いです。 良い設計は既存コードの理解がないと作れない 設計の質を上げようとすると、既存コードの読み込みは避けられません。 仕様書だけを見て設計すると、実装上の制約や

はじめに CTEはSQLを整理しやすくする便利な構文です。 それでも実務では、CTEよりサブクエリや一時テーブル中心のクエリをよく見かけます。 これは好みの問題だけではありません。 歴史的背景、データベースの最適化特性、チームのレビュー体制、ORMの使い方といった複数の要因が重なって起きています。 この記事では、現場でCTEが少なくなりやすい理由を客観的に整理します。 結論 CTEが使われにくいのは、次の4つが積み重なるからです。 歴史的に、CTEを使えない時代が長かった クエリ次第で、実行計画が不利になることがある 読み手とレビュワーの習熟度に差が出やすい ORM中心の開発では、生SQLでCTEを書く機会が少ない つまり、現場でCTEが少ないのは主観ではなく、技術と組織の両面に理由がある現象です。 1. 歴史的背景 たとえばMySQLでは、CTE（WITH句）のサポートは8.0系からです

はじめに 既存コードの修正は、実装を先に触りたくなりがちです。 ただ、先に現行仕様をテストで固定しておくと、結果として修正の安全性と速度が上がることが多いです。 この記事では、なぜこの順番が有効なのか、生成AIを使った実装やリファクタリングの文脈も含めて整理します。 特に最近は生成AIで修正案を作る機会が増えたので、この順番の重要性を以前より強く感じるようになりました。 先に現行仕様のテストを書く理由 今の挙動をチームで共有できる形で残せる 変更時の退行を自動で検知できる 仕様なのかバグなのかを切り分けやすくなる 修正範囲の見積もりが現実的になる 仕様変更の意図をテスト差分から追いやすくなる ビジネスサイドとエンジニアの現行仕様認識のズレを可視化しやすくなる コードコメントや口頭説明より、テストのほうが「何を守るべきか」が明確です。 実装だけを読むより、テストの追加や更新を見るほうが「今回

はじめに 多くのシステムでは「区分値・マスタ値」をどこで管理するかが議論になります。 特にステージング環境（QA環境）で区分値を保持しているケースでは、 「環境にあるからコード側には不要」という運用が起きがちです。 実務だと、区分値は「仕様」に近い扱いになることが多く、コード側でも保持しておいた方が安全なケースが多いです。 ここでいう「コード側」は enum だけを指すのではなく、SQL の seed（INSERT 文）やマイグレーションに含めて リポジトリで管理することも含みます。 この記事では以下を扱います。 区分値を環境管理のみで運用した場合に発生する問題 コード側管理のメリット・デメリット（enum だけでなく SQL seed を含む） 現実的な棲み分け指針 1. 区分値を「環境（QA/ステージング）だけ」で管理する場合の問題点 1-1. 環境ごとの差分が発生しやすい 環境依存で

はじめに master と feature だけで回すブランチ運用は、シンプルで分かりやすい反面、 規模や変更の幅が少しずつ広がると「限界」が見え始めます。 本記事では、よくある落とし穴と、今は大丈夫に見えてしまう理由、 そしてどのタイミングで次の一手を考えるべきかを整理します。 複数修正の一括リリースとブランチ戦略の関係 1. 前提の開発フロー ブランチ構成 master：本番相当の安定ブランチ feature/○○：機能開発用ブランチ（タスク単位で作成） 運用フロー 古い master から feature/○○ を作成 対象の feature ブランチを QA 環境にデプロイしてテスト QA 完了後、feature → master にマージ develop や staging ブランチはなく、 master ＋ feature だけのシンプル構成になっている。 2. 一般的に起きや