SQL Server Management Studio でInsert文を自動生成する（たぶん何億番煎じかくらいだと思う）

テストコード用のテストデータを手組しているという話題

永続化層込のTestを行っている場合、container上でテストコードを動かす際に、セットアップでテストデータを投入する必要がある

「パワーのあるチームは、適切にマスクを行った検証用Databaseのサンプルが常にcleanな状態に存在していて、そのDBからデータ同期をすれば良いのだろうか？？？ 」 と想像しつつも、自分のチームはチーム外のコードベースやテストを触ることがままあるため、そこまでの運用ジャンプを相手に強いようとすると、付いてこれなくなる恐れがある。

一方で、

「SQL書くの大変だ！」

って話すらあるのも理解できる。

「テスト用の永続化層instanceのcontainerを上げてから、データ入れてって、Management Studioからリバース生成するだけちゃうんちゃうん？」

と聞いたところ、意外とやり方を知らないという空気だったので自分の記憶整理も兼ねて書いてみることにした。（もうちょっと洗練した仕組みに出来たほうがいいんだろうと思いつつ、運用を他チームにお願いする以上、ジャンプの大きさは、頑張れるギリギリを狙うしかない。というのが、近年での学びとしてある。）

SQL Server Management Studio でInsert文を自動生成していく（SSはSSMS v.18で取得しているため、バージョンの新旧によっては、メニューの配置変更があるためあらかじめ留意する事）

スクリプトの生成ウインドウを表示させる

SSMS上でServerへの接続完了後、Insert文を自動生成したいDatabaseを右クリック => タスク => スクリプトの生成 を選択し、スクリプトの生成ウインドウを表示する。

Insert文のリバース生成を行う

スクリプトの生成ウインドウで、[ 次へ ] をクリック => オブジェクトの選択画面に切り替わったら [ 特定のデータベース オブジェクトを選択 ] を選択

特定のデータベース オブジェクトを選択

Insert文をリバース生成したい対象のテーブルを選択し [ 次へ ] をクリック => スクリプト生成オプションの設定画面に切り替わったら [ 詳細設定 ] をクリック => スクリプト作成の詳細オプションを表示する。
[ スクリプト作成の詳細オプション ] の、[ スクリプトを作成するデータの種類 ] を [ データのみ ]に変更して [ OK ] をクリックする。

ここまで来たら、あとは任意の設定で[ 次へ ]を押して行けば、Insert文のリバース生成が完了する。（どこに吐き出したいかはお好みで。）

エンドポイントのリソース設計と404について考える

ステータスコード論争によく巻き込まれる

個人的には、管理するエンドポイントによってWayが異なることは勘弁してほしいという気持ち。

前提条件

URLはリソースである。

404について考える

case1: hoges/

=> hogeのコレクションリソースを返す

case2: hoges/1/fugas

=> hoge=1にぶら下がるfugaのコレクションリソースを返す

case3: hoges/1/fugas/1

=> hoge=1にぶら下がるfuga=1のリソースを返す

としたときに、

case2, case3については、指定したIdリソースがない場合、404。
case1 はリソースのId指定が含まれていないので200 ないし 204

というのが個人的な感覚。

大体、物言いが、開発外から付く

よくあるのが、コレクションリソースを返すというケースで404にしてくれって話を貰うパターン。
URLがリソースである以上、requestを投げる側でコントロールが出来ないものに関しては400系を返すべきではないというのが個人的な感想になる。

基本的に使いやすければOKでは？

基本的に使いやすければ良いのでは？というアドバイスを先輩から頂いた。 githubのApiの定義をひとまず見に行こうかなという気持ち。

ボーイスカウトルール

野山をきれいにする

久しぶりにプログラマが知るべき97のことを読む

個人的に好きなのはボーイスカウトルールの項

コードをチェックアウトした時よりもチェックイン後の方が美しくなるようにする。

これは、自分のためのみならず、他人のために必要なこと。
お互いにコードを美しくしていくことが必要。
たとえ自分が書いたコードではなかったとしても、美しく直す必要がある。
もちろん、すべてを完璧にする必要はない。
インクリメンタルな改善を入れていけば良い。

ボーイスカウト活動をするにあたってテストコードが必要

リファクタリング a.k.a. コードクリーンアップは絶え間なく行う必要がある。
絶え間なく行うために何が必要か？

仕様を保護してインクリメンタルに変更をいれる必要がある。

仕様を保護して安全に変更を入れるためにはテストコードが必要だ。
ファッショナブルにリファクタリングと言う前に泥臭くテストコードを書こう。
我々は別におしゃれのためにテストコードを書くわけではない。
一発でいいコードが書けないから、絶え間なく改善を行うためにテストコードを書くんだ。

テストコードをインストールするためにはまず書き続けられることが大事

ジャンプが大きすぎてやめてしまっては元も子もないので注意して対応を行う。
あらゆる機能のインストールについても同様で、開発組織がインストール速度に耐えられなければ破綻してしまうことに注意が必要になる。

VisualStudio2022でようやく改行設定が試験的に追加されて嬉しい話

今まで「不要な改行✂」みたいなくそコメントを人間がわざわざコードレビューで書いていたんですが、ようやく.editorconfigで制御できるようになりそうで嬉しい。
が、試験段階だからなのか、まだコードクリーンアップには対応してないみたい。
dotnet formatには対応しているようなので、しばらくはこちらに頼る予定。

VisualStudio2022でProject毎にタブを色分けする

地味に嬉しいProject毎のタブ色分け機能

ここにチェックを入れる。

VisualStudio CodeのPeacockの時も感じましたが、視覚的にわかりやすいのは良いですね✨

PRのつくり方を考える

ここ数年くらいPRのつくり方について、尊敬する先輩に教えて頂いたりと色々試行錯誤があったので折角なので纏めていく。

TL;DR

• big commitは避ける。1story /taskに対してPRは複数用意していい。とにかくbig commitは避ける。
• review結果は反映するものではなく取り込むもの。
• Testは頑張って書く。ひたすら頑張って書く。良いコードを一発で書けないからこそ頑張って書く。
• コード解析やフォーマッティング等、気付きを自動化できる仕組みは積極的に使う。楽をして、浮いた時間は別なことに使う。

big commitをなるべく避ける

big commitというかbig pull requestというか。。。
change setをなるべく小さく、小口でPRを作成することが大事。

なぜbig commitを避けるのか

big commitは

• review業がそもそも大変になる
• 大変になるとどうしても見落としが出てくる
• 大変なので後に回されやすくなる

といった感じになると実感している。

1Story / Task に対して 1PRである必要は全然ない

１PRは1Storyじゃなくて良い
という気付きを得てから、改めて理解したが、人間が気を付けられる量なんてたかが知れている。

例えば50ファイル、3000Lineとかchange setを出されたところで、正直見ようと思えなかったりする。（仕事だから見る努力はするけど、実際大味なレビューになるんですよね。）

なので、

• コードベースを良くしていきたいのであれば、PRはどんどん分けたほうがいい。
• 一方で、PRをチェインすると、最初のほうのPRで指摘があるとrebase業が死ぬほどダルくなることがある。
• この辺は、git力を少し上げることで改善が可能なので、少しずつ頑張る。

みたいな感じで進めていくのが筋が良いように思う。
特に、git力については避けて通れない。もしチーム内でgit力が足りていないと感じたらラーニングしていくと運用が改善していくのでオススメ。

review結果は反映するものではなく取り込むもの

レビュー結果反映とか指摘結果反映とかレビュー指摘事項修正みたいなcommit comment
は、

• 対応内容が明示されていないことが問題
• レビュー結果について納得せずに、「はいはい、指摘されたから直しましたよ、これでいいんでしょ。」っていう感じになるのが問題

の２つの意味で筋が悪い。 特に後者の気持ちでは、人は育たないので気を付けたほうが良い。指摘事項反映（詳細な文章）みたいなのも、後者の問題に引っ掛かるので筋が悪い。

Testを頑張って書く

品質を語るならまずTestを書け。は本当にその通りで、

• PRを出すときにはゴールデンパスのTestを頑張って書こう。
• 業務アプリケーションの場合は永続化層込のTestを頑張って書こう。

が本当に大事。 reviewでもtestがなければ超緊急時を除いてapproveしないほうが筋が良い。

UNDONE: Testの効率とかは、まだまだ考えられてない

今の時代、Docker上での自動Testが主流なのだから、今のところ雰囲気で使ってるDockerをもっと理解することで改善が進むんだと思う。

dependabotはいいぞ

dependabotは、自動Testがいてくれることで、nuget packageのアップデート時のリスクがある程度何もしなくても可視化されてく感じがして素晴らしいと感じている。
一方で、どうしてもreleaseまでのgit のbranch modelを考えると、mainへのPR作成は、良し悪しというか、チームのパワーには若干合ってないとも感じるので、実際は、自分でPR作りなおすこともままある。（これはたぶん私が雰囲気で運用しているからというのもあると思う。）

github actionsでも、dotnet formatをかけて差分をPRにするworkflowを動かすようにしているが、結局のところコードベースがヘルシーな状態かどうかのインジケーターなんて多くて困ることはないからどんどん頑張ればいいんだと思う。

EF Core 6 のリバースエンジニアリングがNull許容参照型に対応したのが嬉しい話

EF Core6 は.NET6実装

EF Core5は.NET Standard 2.1での実装だったので、.NET Core 3.1以降であれば利用が可能でした。
対してEF Core 6は.NET 6での実装なので.NET 6での利用に限定されます。 これは、.NET Core 3.1が2022年11月、.NET5が2022年2月?でEOLになるからそらSupportしないよねという感想。

EF Core5のリバースエンジニアリングはNull許容参照型は未対応だった

EF Core5は制約事項として、リバースエンジニアリングでのEDM＆DBContext生成時Null許容参照型はdisableでした。
この辺結構嫌というか、令和の言語はnull安全であってほしい（基本的にはフロー解析ではじきたい）ので、enableになればいいなーと2年くらい思っていました。
※ 誤解のないように書くと、EF Core5はすごく出来の良いORMだったし、performanceもずいぶん改善されて来たので、1joinくらいならEF Coreでいいかなーというお気持ちでした。（CommandはEF Core、QueryはDapper派）

EF Core6はリバースエンジニアリングでもNull許容参照型に対応した

なので、今回嬉しいポイントはここでした。
csprojに<nullable>enable</nullable>を書かなきゃいけないですが、そんなものいくらでも書きます。
というか、vs2022になって、csprojを直接書くだけじゃなく、GUIを使ってもいいかと思えるようになるくらい、vs2022はUIが良変更ですしね。