私は普段、お客様のチームに入り込み、SEとして仕事をしております 今日はそのチームで実際に起こった出来事からなぜか勝手に敗北感を味わった話をしたいと思います まずなにがあったか 普段すでに本番運用がされているシステムに新規要件を実装してまして、定期的に新機能をリリースするようなそんな運用となっています そんな中のある日、定例（朝会）の中で、直近リリースで発生したインシデントの共有がありました えーっと実は昨日〇〇という障害が本番環境で発生してその対処をしてました 調べてみた結果、原因は〇〇さんのこのプルリクでして （私：おいおい個人名だすのか！！ このファイルのこの行でNullチェックが漏れてました （私：わわわわ、公開処刑だぁぁぁ まぁたしかにこの辺はほげほげふがふがで （私：ふむふむさすがにフォロー入るかぁ でもテストやレビューでちゃんとカバーしときたかったですね （私：全員巻き込んで

■イベント 急成長するSaaSを支えるエンジニア成長支援の取り組み https://sansan.connpass.com/event/293441/ ■登壇概要 タイトル：エンジニアの成長に向き合う評価と目標設定 登壇者：技術本部 Bill One Engineering Unit　⽊村 祐也 ■Bill One エンジニア 採用情報 https://media.sansan-engineering.com/billone-engineer

最近、昔作ったTest Doubleの解説資料を参照・引用してくれる方がちらほら出ていて恐縮しているのですが、見直してみると結構わかりにくい資料なので今回文章としてまとめたいと思います。内容は世間一般的に言われているMock、Stub、Fake、Dummyといった言葉の定義になります。 Test Doubleとは Test Doubleとは、テスト実行時に、テスト対象が依存しているコンポーネントと置き換わるものです。「テスト代役」と訳されることもあります。世の中でMock、Stub、Fake、Dummyなどと呼ばれているものの総称に位置づけられます。 簡単な例を以下に示します。このコードでは、テストメソッド「テストコード()」がメソッド「テスト対象()」をテストしています。また「テスト対象()」は、中でメソッド「外部メソッド()」を実行しています。なお「外部メソッド」はテスト対象でないとし

はじめに 現在、N予備校バックエンドチームでは、現行のRails製アプリケーションからKotlin製の新アプリケーションへ一部移行する計画を始めました。 N予備校サービス構成図 移行の主な対象は、上記の図の紫の部分の 教材管理サービス まわりになります。 移行の目的 今回の移行は、主に次の2つの問題の解決を目指しています。 DBスキーマを含めたモデルの再設計 N予備校はサービスの仕様が十分に固まらないうちから基本設計が開始されたため、必要以上の柔軟性を持つ形で設計されている部分も多く、現在の事業ドメインの知識がモデルで十分に表現されているとは言い難い面があります。 特にコンテンツデータ同士の参照関係については、階層構造の大きな変化1にも対応できるように、多くがActiveRecordのポリモーフィック関連を使って実装され、コードやDBスキーマからデータ構造を読み取るのが非常に難しくなってい