開発効率を追い求めた実装プラクティス集
この記事は MICIN Advent Calendar 2023 の24日目の記事です。 前回はSaneさんの「データ基盤チームで社内インターンをやってみて」でした。 はじめに abekohです。MICINでMiROHAの開発をしております。 本記事では、書籍等から得た設計・実装パターンの知識や、実際にプロダクト開発で試して得られた経験などから編み出した、開発効率向上のためのWeb API開発のプラクティスを紹介します。 筆者が関わっているMiROHAは治験の業務支援を取り扱うプロダクトです。MiROHAの開発における特性として、以下のようなものが挙げられます。 治験業務に関するドメインが特有で複雑 前例が少なく、MVPを追求中。プロダクトのアプローチが頻繁に変わる 外部品質は高い水準が求められる これらの特性を意識して開発を促進させるために日々試行錯誤しております。 複雑なドメインに対す
DBの状態に依存したロジックを純粋関数にしたらテストしやすくなった
この記事は MICIN Advent Calendar 2023 の17日目の記事です。 前回は小泉さんの「エンジニアがfigmaに入門してデザインを加速させる」でした。 MICINのDTx事業部でアプリケーションエンジニアをやっている佐藤です。直近で、認知行動療法を行うアプリケーションの開発を担当していました[1]。本稿では、そのテストコードの実装の際に考えたことを書きます。 重要なケースを網羅するテストコードを書きたい 今回のアプリケーションでは、考慮すべき状態の数が多く、その状態に基づく画面表示の条件分岐も多いため、仕様を整理するだけで大変でした。これに対応するテストケースの数は当然多くなります。だからこそ、ロジックの単体テストで、重要なケースを網羅しておきたいと考えました。 以下、本記事での説明のために必要な要件などを簡単に示しておきます。 要件 アプリケーションの要件は、以下のよ
DBスキーマはtblsのViewpointsで整理しよう
この記事は MICIN Advent Calendar 2023 の 5日目の記事です。 前回は竹内さんの、Socket.ioコンテナオーケストレーションハンズオン でした。 tblsはいいぞ🦍 筆者はtblsの大ファンであり、特にViewpoints機能が他のツールとは一線を画していると思っています。今回はその良さをお伝えできればと思います。 TL;DR tblsは実際のスキーマからDBのドキュメントを生成するツール ER図が巨大化しても、tblsのViewpointごとに分割することでDBの全体像が理解可能になる Viewpointの粒度に困ったら一旦トランザクションと集計の単位に設定する 個別のテーブルとViewpointは相互に参照できる CIに組み込むことでドキュメンテーション忘れを防げる なんのためにDBのドキュメンテーションを行うか DBのドキュメンテーションはそれなりにコ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
