ユニットテストのコードカバレッジ（テストカバレッジ。ステートメントカバレッジやC0、C1など）は、不適切な運用が根強く見られます。多いのが、コードカバレッジの確保だけをテストの十分性目標にして、まずいテストを書いてしまうパターンです。 今回はこのコードカバレッジについて、現代的な開発を支えるための適切な運用について解説します。 コードカバレッジのみを直接のテストの十分性の目標にしてはいけない 結論から言うと、まずユニットテストは以下を目標として作成します。 ふるまいの仕様が実現されているか確認する プログラマが感じる品質リスク（いわゆる不吉な臭い等）が許容できる水準であることを確認する 法規制対応など、外部からのテスト要求に対応する コードカバレッジは、上記目標を達成することで副次的に確保されることを目指します。 注意点として、コードカバレッジの確保のみを直接の目標にすると弊害が大きくなり

こんにちは、リファクタリング大好きなミノ駆動です。 2024/07/20に発売された『ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法』を、訳者の増田亨氏よりご恵贈賜りました。 この記事は、この書籍の感想です。 著者の許可を得た上でのだいたんな意訳総評等の前にいの一番で伝えたいポイントです。 エリック・エヴァンス氏の『ドメイン駆動設計』は大変価値の高い知見が網羅されている一方、「ユビキタス言語」や「境界づけられたコンテキスト」といった独特の用語が登場したり、難しい言い回しをしていたり、読解がかなり難しい書籍です。 独自用語が登場するたびに「ユビキタス言語？なんだこれ？」とつまづきを覚え、内容理解に集中できず、読む手が止まってしまったことがある人も少なくないのではないでしょうか。 本書『ドメイン駆動設計をはじめよう』は『Learning Domain-Driv

効率的な環境保護活動に罪悪感を感じるのはなぜだろう？ 私の作ったグラフは、環境保護についてのポスターに使われるかもしれないが、私自身は環境保護活動のアイコンには絶対にならない。 私が食事を作っているのを見れば、環境破壊しているようにしか見えないだろう。ほぼ電子レンジしか使わない。調理にはほとんど時間をかけない。調理に10分以上かかる食事は〔環境保護の観点からは〕食べる価値はない。私はほぼパッケージ化されたものを食べている。アンゴラ産アボガド、メキシコ産バナナなどだ。地元で作られた食材はほとんどない。地元産かどうかについて気にして、ラベルをチェックする必要もない。 これは「持続可能」と思われている行為と正反対だ。我々の脳裏にある「環境に優しい食事」のイメージは、地元の市場からの仕入れ、有害な化学物質を使わない有機（オーガニック）農場での生産、プラスティック梱包よりも紙バッグでの持ち帰り、加工

はじめまして、tebiki現場教育のPdM/POをしている中屋です。今回は、春リリースされた新しい「スキル機能」のプロダクトゴール設定からリリースまでの道のりについて軽くまとめてみたいと思います。 新機能のスクラム開発を行っている皆様の参考になれば幸いです。 私について私はTebiki株式会社に2023年5月にPdM/POとしてジョインしました。前職では、スクラムマスターやエンジニアとして、B to Bのソフトウェア開発をしていました。 プロダクトについて現在Tebiki株式会社では、業界を問わない現場の人材教育にまつわる課題解決のためのプロダクト「tebiki 現場教育」を開発しています。 この度、この現場教育プロダクトに人材のスキルやその評価を管理できる「スキル機能」が追加されました。スキル機能では、従来のスキルマップで可視化されていたスキルの評価と教育コンテンツを紐づけて一元管理する

どうも、初めまして。 tokeと申します。 今回は自分の失敗談を話したい、と思います。 実装する前にドキュメントを読まないと、最後になってゴールに辿り着けない可能性がある そういう経験をしたのでご紹介します。 例えば、自社で集めた顧客のデータを活用し、Marketoにデータ連携したいとします。 marketoのAPIドキュメントを調べると、顧客の情報を登録する手段では以下の２パターンがあります。 POST /rest/v1/leads.jsonを使うパターン 以下のドキュメントにあるPOST /rest/v1/leads.jsonを使って、顧客のデータを送信し、連携する事ができます。 https://experienceleague.adobe.com/en/docs/marketo-developer/marketo/rest/lead-database/leads [※Marketoで

開発部全体を見てるあのすごい人が、ある1つのチームのマネージャだったらどんな感じなんだろうなぁ？仕事がやりやすいんだろうなぁ？って考えることがある。それが今、僕のいるチームで起こっている。 VPoEの経験もあるいくおさんと、カケハシの同じチームで仕事をしている。いくおさんが1つのチームのエンジニアリングマネージャとしてついてくれているのって、とても贅沢だなぁと思っている。実際に仕事はめちゃくちゃやりやすいし、それだけじゃなくて、僕やチームみんなの心の支えになってくれている。 いくおさんが書籍を出した そんないくおさんが書籍を出した。この本がとてもいい本なので、みんなに読んでほしい。どうしていくおさんと一緒だと仕事がやりやすいのか、なぜ自分の持ってる力が引き出されるのか、その理由がこの本には書かれている。 www.shoeisha.co.jp いやー目標って苦手なんだけど・・・ 目標って聞く

エンジニアの佐野です。バンドルカードではポチっとチャージという後払いの機能を利用する際に年齢確認が必須となりました。通信キャリアや銀行との連携等によって年齢確認ができるようになっています*1。今回はこの機能の開発を題材に普段開発でどのようなことを考えて開発し、本機能の開発ではどのようなフローを構築して進めていったかを書きます。 少し概要を書くと、本件についてはウォーターフォールモデル "のような" 開発フローで行いました。事業上の理由でビッグバンリリースが必要でした。要件をしっかり決めてステップバイステップで開発を行いすべての機能を同時にリリースする...案件の性質を考えるとウォーターフォールが開発フローの候補の1つだと思っていたためです。ただそのまま一般的に思われているウォーターフォールを導入するのではなく、その欠点や面倒な点を解消しつつ、認識齟齬なしに設計と実装を行い、納期を死守しつつ

この記事は、静的解析とビルドサイズ面で興味深いテーマでした。記事として自分の考えを書きます。 注意。あくまでビルドパフォーマンス視点での最適化です。強い意図があって、自分のドメインモデリングの方法論ではこれが最適なんだ、というなら元コードの方法論を止めるつもりはありません。 元記事のコードを minify するとどうなるか 元コードを参考に、それにアクセスするサンプルコードを書いてみます。 const sortingOptions = { priceDesc: { id: "priceDesc", sort: "price", order: "desc", label: "価格が高い順", }, priceAsc: { id: "priceAsc", sort: "price", order: "asc", label: "価格が安い順", }, ratingDesc: { id: "ra

ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法 作者:Vlad KhononovオライリージャパンAmazon 訳者の増田亨様より献本いただきました ありがとうございます さっそく読んでみました システムは、なぜ必要とされるか？という「why」が有り、次に何を作るべきか？という「what」が有り、それを受けての「how」が有る。 （たまに突然「what」だけが有ったり、なぜか「how」の議論だけが先行する事例も聞くけど、それは順番が間違っているだけなので、その問題はここでは触れない） この「why」と「what」と「how」が上手く繋がった状態を作り上げていくために、過去にさまざまな開発方法論が考案され、語られてきた。 「ドメイン駆動設計」は、開発方法論として「名前がついて、生き残ってきた手法」の一つであり、昨今複数の解説書が発行されている唯一の手法と言え

ソート順の選択プルダウンがある一覧系ページを実装するとき、選択肢たちの管理方法に頭を悩ませることが多いと思います。 商品一覧ページの概要 ソート順プルダウンの選択肢たち 上の画像に示したような場合だと、 《クエリパラメータ》と《選択肢》の間の相互変換 ?sort=price&order=desc <--> 「価格が高い順」 《select の状態に使うための文字列》と《選択肢》の間の相互変換 <option value={id}>{label}</option> クエリパラメータが sort order の2つあり、それらをそのまま流用できないので 最低限でも、これらの変換ロジックを用意しておく必要がありますね。 この記事では、このような「選択肢と、それにまつわる変換ロジック群」を整理する方法を、高凝集・SSoT (Single Source of Truth; 信頼できる唯一の情報源)

2024年度リクルート エンジニアコース新人研修の講義資料です

『手を動かしてわかるクリーンアーキテクチャ 』の第二章の冒頭に登場する話題に共感したので紹介。 従来の多層アーキテクチャでは、データベースを中心にアプリケーションの 開発が行なわれます。この場合、Web 層はドメイン層に依存し、ドメイン層は 永続化層、つまり、データベースに依存することになります。そうなると、す べてのものは永続化層上に構築されることになり、その結果、いくつかの要因 が絡まり合って、問題が起きやすくなります。 手を動かしてわかるクリーンアーキテクチャ　ヘキサゴナルアーキテクチャによるクリーンなアプリケーション開発 20p 手を動かしてわかるクリーンアーキテクチャ　ヘキサゴナルアーキテクチャによるクリーンなアプリケーション開発 作者:Tom Hombergs,須田 智之インプレスAmazon 著者によれば、機能開発をデータベース中心に設計すると、ドメイン層と永続化層の密結合が

2024年度リクルート エンジニアコース新人研修の講義資料です

2024年度リクルート エンジニアコース新人研修の講義資料です

builderscon 2024 で発表した資料です。以下、トーク概要です。 Webアプリケーションを開発・運用していく中で、1つのテーブルに日時カラムが増えていったり、巨大なテーブルが爆誕した、という経験はありませんか。また、これがプログラムの複雑さに繋がることもあると思います。このような事態を…

分かりやすいプログラムの構成はどうやったら設計できるのでしょうか? この本では、文脈と名前という二つの切り口でプログラムの構造とプログラマーの認識がどう結び付いてゆくのかを解き明かします。 本書は以下のような方々にお勧めです。 🤔大きくて複雑なプログラムを綺麗で分かりやすい設計にまとめることがうまくできなくて困っているプログラマー 😵他の人が書いたプログラムを読むときに、どこに何が書かれているのか手掛かりがつかめなくて迷ってしまう人 🧐DRY とか SOLID みたいなプログラム設計理論に関心があって、関連する事柄についての知識や考察を摂取したい設計オタク

2024年度リクルート エンジニアコース新人研修の講義資料です

If you’ve ever built a web service or a web app, you know the drill: pick a database, pick a web service framework (and in today’s day and age, pick a front-end framework, but let’s not get into that). This has been the case for several decades now, and people don’t stop to question if this is still the best way to build a web app. Many things have changed in the last decade: Disk is a lot faster

「ソフトウェア設計仕様書（SDD）」の作成方法、仕様書に含めるべき内容とは：優れたソフトウェア設計仕様書を作成するためのヒント ソフトウェアの設計書は、DevOpsの時代になっても、ソフトウェア開発ライフサイクル（SDLC）の重要な構成要素として位置付けられることは変わらない。ソフトウェア設計書が重要な理由、作成方法を整理する。 ソフトウェアの設計仕様書は、DevOpsの時代になっても、ソフトウェア開発ライフサイクル（SDLC）の重要な構成要素として位置付けられることは変わらない。ソフトウェアプロジェクトに着手する前に、開発チームはソフトウェアの設計仕様を考える必要がある。 ソフトウェア設計仕様書（SDD：Software Design Document）は、プロジェクトのロードマップとしての役割を果たし、プロジェクトの達成目標や目標への到達方法をチームが総合的に判断するのに役立つ。 設計

スライド概要 一見すると見過ごしがちな、しかし開発者にとって魅力的なRemixの特徴を掘り下げています。Web標準への回帰やクリアなデータフローなど、7つの「細かすぎて伝わらない」魅力を詳細に解説。さらに、Remix v3（React Router v7）への移行や将来の展望まで、普段は見落とされがちな細部にまで踏み込んでいます。Remixの隠れた魅力を探るプレゼンテーションです。