Skip to main content

· 4 min read
Hiroki Ihoriya

ドメイン駆動設計(DDD)には,さまざまな用語が登場し,それぞれが重要な意味が持た されています.

この記事では,DDD を学ぶ際に登場する用語を整理します.用語の意味が間違えている, 不適切であるといった点がございましたら,@unvalley_までお知らせください.

ドメイン駆動設計#

Wikipedia

ドメイン駆動設計(英: domain-driven design, DDD)とはソフトウェアの設計手法で あり、「複雑なドメインの設計は、モデルベースで行うべき」であり、また「大半のソ フトウェアプロジェクトでは、システムを実装するための特定の技術ではなく、ドメイ ンそのものとドメインのロジックに焦点を置くべき」であるとする。この名称は、 Eric Evans が同名の著作で用いた。

ユビキタス言語#

ユビキタス言語とは,ドメインを語るためにプロジェクトに関わる全員が利用する共通言 語のこと.

  • ユビキタス言語によって,ドメインモデルと言語が強く結びつくようになる
  • モデリングの作業全体を通して,開発者とドメインエキスパートとのコミュニケーショ ンを楽にする
  • 設計に関するその他のあらゆる判断と同様,技術的な判断についても,ユビキタス言語を優先させるようにしよう.DDDにおいては,ビジネスドメインのモデルが最優先となる.実践ドメイン駆動設計 p.306

ドメインモデル#

現実世界を抽象化したモデルをコードで表現する

戦略的設計#

コアドメイン#

コアドメインとは,システム内で最も価値の大きい中心的なモデルのこと.

サブドメイン#

サブドメインとは,.

境界づけられたコンテキスト(Boundary Context)#

境界づけられたコンテキストとは,

戦術的設計#

値オブジェクト(ValueObject)#

値オブジェクトとは,(一意である必要のない)ドメインの属性を表現するオブジェクト のこと.

エンティティ(Entity)#

エンティティとは,一意性を保証するオブジェクトのこと.

  • ドメインモデルに必須のオブジェクト

サービス#

モジュール#

ファクトリ(Factory)#

リポジトリ(Repository)#

集約#

集約とは,トランザクション整合性を保ちながら更新を行うオブジェクトのまとまりの こと.「実践ドメイン駆動設計」から学ぶ DDD の実装入門

  • 集約は,エンティティや値オブジェクトを内包する境界を定義する

  • 集約は,内部のオブジェクトが変更される場合,トランザクション整合性を正しく保つ

  • 境界内部のエンティティは集約内で一意となる?

    • どういう意味だ

ドメインイベント#

参考文献#

· 9 min read
Hiroki Ihoriya

「行動を変えるデザイン」という本を読んだ.書いて学ん だことと感想を記しておく.

読む目的#

以下を達成すること.

  • 行動変容のために,データとデザインをどうシステムに組み込むべきか理解する
  • 行動変容を促すデザインの理論的な背景知識を得る

行動変容デザインの流れ#

  • 心の働きが行動決定にどう作用するのか,またそれが行動の変化にどう関係するかを理 解する
  • 企業やユーザの目標を踏まえて変えるべき行動を探索する
  • 設定した行動に向けて,プロダクトをデザインする
  • 慎重な測定と分析に基づいて,プロダクトの効果を改善する

行動変容デザインに必要なもの#

  • 行動研究(行動経済学と心理学)
  • プロダクトデザインの専門性(プロダクト開発と UX)
  • データ分析(定量と定性データの分析)

行動を変える効果的なプロダクトをつくるために必要な 3 つのこと#

  • 人が実際に好むものをつくれる,プロダクトとデザインの専門スキルがあること
  • ユーザの行動とそれに影響を与えるやり方をはっきりと理解すること
  • 徹底的にプロダクトをテストし,データが教えてくれる事実に耳を傾けること

挙げられていた行動経済学者・心理学者#

感想#

目的の振り返り#

読む目的を振り返ってみる.

  • 行動変容のために,データとデザインをどうシステムに組み込むべきか理解する -> 達 成
  • 行動変容を促すデザインの理論的な背景知識を得る -> 未達成

「行動変容のために,データとデザインをどうシステムに組み込むべきか理解する」#

この点に関しては,「行動変容デザインに必要なもの」を用意し,「行動変容デザインの 流れ」に沿って実践すれば,再現できると感じた.一方で,行動研究・プロダクトデザイ ンの専門性・データ分析の能力は, 一人で全て身につけるのはかなり時間がかかりそう .

「自分のスキル・知識」と「行動変容デザインに必要なもの」のギャップを見てみる.自 分が現状持ち合わせているスキル・知識は以下である.

  • 学部研究で触れた程度の行動経済学の知識(行動研究)
  • 業務 1~2 年程度の Web 開発(プロダクトデザインの専門性)
  • 良し悪しの判断基準が感覚的な UX の知識(プロダクトデザインの専門性)
  • 小粒程度の統計スキル(データ分析)

まだまだ身についたとは言えない要素ばかり.色々加味すると,この中で直近手を付ける べきなのは,データ分析だと思う.その理由は,データを分析し,知見を得る能力が無い と,「データに基づいたデザイン」ができないと考えるからである.

「データに基づいたデザイン」こそ,「行動変容デザイン」と言っても過言ではないのか なと感じたりした.

どういったスキル・知識を持って,どのように組み込めばよいのかというのは書籍を通し て理解できたため,達成できたといえる.

行動変容を促すデザインの理論的な背景知識を得る#

ざっと読んだ感じでは,ビジネス応用としてのプロダクトにフォーカスしている.

人間というのは元来こういうもので…といった心理学・経済学的な説明の詳細は他書に任 せられているため,他書を当たるのがよい.

若干求めた内容が違ったので,達成できていない.ただ,参考書籍として色々挙げられて いたので,それらを当たろうと思う.

行動変容を促すプロダクト#

行動変容を促すプロダクトは面白い.巻末には日本版オリジナルの行動変容を促すプロダ クトがいくつか紹介されていた.そこには,マネーフォワード ME・あすけん・CureApp など知っている企業が取り上げられていた.

ユーザ体験を行動経済学・心理学の観点から考えているプロダクトはいまだ数少ないと思 う.そういうプロダクト開発は,機能実装にも理論的な納得感があって楽しそうだと感じ た.

研究とビジネス応用#

所属している研究室の活動にて,よく CHI や UIST の論文を読んでいる.当然だが,シ ステムを提案する論文では,関連研究や手法の点で,がっつりと理論背景が書かれている .

行動変容デザインを再現したプロダクトに積極的に触れる機会を持ちたいと思った.紹介 されたプロダクトに拠るものだが,医療・スポーツ・プロダクティビティ・金融分野が多 そうだと感じる.

何かおすすめアプリがあれば,教えて下さい.

終わりに#

UX の一歩先にあるのが,行動を変えるデザインなのかなと思いました.

心理学や行動経済学の知見を利用して,プロダクトをデザイン(開発)したい方は読まれ ると学びがありそうです.

下記の書籍公式ページから,「行動を変えるデザインツールキット」というのが無料でダ ウンロードできます(Google Drive で pdf が公開されている形).

行動を変えるデザイン - 心理学と行動経済学をプロダクトデザインに活用する

このデザインツールキットはプロダクトデザインの際に有用そうだなと感じました.

ぜひ書籍を読んでほしいですが,時間がなければデザインツールキットの方を眺めてみて ください.

· 15 min read
Hiroki Ihoriya

この記事には,実践ドメイン駆動設計の各章のまとめと感想が書かれています.(2021 年 5 月現在執筆中です)

実践ドメイン駆動設計とは#

『エリック・エヴァンスのドメイン駆動設計』は、2003 年の刊行だったにもかかわら ず、大型ソフトウェア構築時につきまとう不透明感を払拭するための指針として現役技 術者に多大な影響を与えた。ある意味、エリック・エヴァンスの先見性によって、今日 、必要とされるパタン/アンチパタンが整理されていたためだ。とはいえ、それからす でに 11 年。ベースとなるオブジェクト指向はそれほど大きな変革はないものの、この 10 年の間にコンピューティングの対象は大きく増え、さらにドメイン駆動設計をコト バでは知っているものの、経験値のまだ低い技術者の増加もあり、理論だけではなく現 状に則した形で体得する必要性が増している。本書は DDD の考え方はもちろん、コミ ュニティや実際のビジネスシーンのなかから実践的な方法論を精錬し、いわば 21 世紀 (初頭)型ドメイン駆動設計を伝授するものであり、現在のニーズに合致する内容で構成 されている。(amazon 商品説明より)

著者の情報は,vaughnvernon.comに,まとまっています .

Blog や Podcast にて,ドメイン駆動設計のみならずマイクロサービスアーキテクチャや リアクティブアーキテクチャについての発信活動もされているようです.

どのような人が読むと良さそうか#

下記のどれかに当てはまる方がターゲットと思います.

  • ドメイン駆動設計を実務で実践したい人
  • ドメイン駆動設計の実装方針を掴みたい人
  • アプリケーションコードの設計改善のヒントを得たい人

僕は,DDD の実装方針を掴んで,アプリケーションコードの設計改善が行えるようになり たいと思ったので読んでいます.本記事は 『「実践ドメイン駆動設計」から学ぶ DDD の実装入門』も 参考にしています.

各章のまとめ#

第 1 章 DDD への誘い#

追記予定

ロードマップ

重要と思った点

疑問と回答

第 2 章ドメイン,サブドメイン,境界づけられたコンテキスト#

追記予定

ロードマップ

重要と思った点

疑問と回答

第 3 章コンテキストマップ#

追記予定

ロードマップ

重要と思った点

疑問と回答

第 4 章アーキテクチャ#

追記予定

ロードマップ

重要と思った点

疑問と回答

第 5 章エンティティ#

この章は,エンティティを適切に重視する方法・エンティティの設計に関するさまざまな テクニックについて書かれている.

ロードマップ

  • 一意なモノをモデリングする必要があるときに,なぜエンティティが適切な場所なのか を考える
  • エンティティ用の一意な識別子を生成する方法を調べる
  • 設計の現場に立ち寄り,チームがユビキタス言語をとらえたエンティティを設計するよ うすを見る
  • エンティティの役割と責務を表現する方法を学ぶ
  • エンティティの検証と永続化の実例を見る

エンティティには一意な識別子があって,変化するという特性がある.これが値オブジ ェクトとは異なる点だ.

重要と思った点

  • 値としてモデリングすべき概念をエンティティとしないように注意しよう
  • エンティティ設計の初期段階は,一意に特定するためのポイントとなる属性や振る舞い だけに注目しよう
  • 一意な識別子の作成方針はメリデメを持った複数の選択肢があるので適切なのを選ぼう (書籍では 4 種類を紹介)
  • 一意に識別可能である && 変更に対応する => エンティティ
  • エンティティと値オブジェクトをどちらにするか判断する際の鍵は,「変更」という言 葉
  • 委譲は,設計を簡単にする場合にのみ選択すべき技術
  • 不変条件は集約の関心事ではあるが,集約のルートは常にエンティティなので,エンテ ィティが不変条件を保持することもある
  • 単一の属性あるいはプロパティに,不適切な値が設定されないようにするためには,自 己カプセル化が推奨される

疑問と回答

  • なぜ一意に特定することを最重視するのか?
    • そもそも,システム内の他のオブジェクトとの区別が必須である時に,ドメイン の概念をエンティティとして設計する
    • エンティティの目的であるオブジェクトを一意に特定することが最重視される
  • そもそも,なぜオブジェクトを識別する必要があるのか?
    • ?
  • バリデーション・アサーションの文脈で登場した「契約による設計」とは何か?
    • コードの利用条件を定めることによって,エラーの位置を明確にし,設計の安全性を 高める手法(?)
    • D 言語のドキュメントが分かりやすい → 契約プログラミング

第 6 章値オブジェクト#

ロードマップ

重要と思った点

  • あるモデル要素の属性のみが関心の対象となるなら,値オブジェクトに分類される
  • 「一意に識別して変更を管理する必要が無いモノ」を値オブジェクトとする
  • 「計測/定量化/説明・不変・概念的な統一体・交換可能性・等価性・副作用のない振る 舞い」の全てを満たす

疑問と回答

第 7 章サービス#

第 8 章ドメインイベント#

第 9 章モジュール#

第 10 章集約#

この章は,集約を用いる意義とその実装テクニックについて書かれている.

ロードマップ

  • SassOvation とともに,集約を不適切にモデリングしたときの悪影響を経験する
  • 集約の経験則をベストプラクティスの指針として,設計について学ぶ.
  • 実際のビジネスルールに沿って,整合性の教会内のシンの不変条件をモデリングする方 法をつかむ.
  • 小さな集約を設計するメリットを考える
  • 集約から別の集約を参照する際に,その識別子を使うよう設計すべき理由を学ぶ
  • 集約の境界の外部で結果整合性を使うことの重要性を見つける
  • 集約の実装テクニックとして,「命じろ,たずねるな」やデメテルの法則などを学ぶ

重要と思った点

  • 集約とは,トランザクション整合性を保ちながら更新を行うオブジェクトのまとまりの こと
    • オブジェクトの集まりの境界線という意味で使われる
  • 外部からは集約ルートエンティティのみを参照できる
  • 小さな集約を作るべき
    • トランザクションの衝突可能性を小さくできる
    • 他の集約ルートには,識別子のみを参照する
  • 集約のコーディング時に役立つ法則
  • デメテルの法則
  • Tell-Don't-Ask の指針
  • 集約での依存性の注入を避ける
    • 参照先の集約の情報を永続化層から読み出す場合は,集約の外から事前に呼び出して おく方式が推奨されている

疑問と回答

  • トランザクション整合性と結果整合性の違いとは?
    • トランザクション整合性(= DDD の集約):同期的に整合性を保つ必要のある処理
    • 結果整合性:
  • 巨大な集約を作ることで起きる問題は?
    • トランザクションの衝突可能性が著しく高くなる

第 11 章ファクトリ#

ロードマップ

重要と思った点

  • DDD におけるファクトリは「ユビキタス言語を用いて集約をシンプルに生成する」とい う意味合いが強い
  • 一貫した(不変の)状態のオブジェクトのみを返すという制約がある

疑問と回答

第 12 章リポジトリ#

リポジトリは,エンティティや値オブジェクトから構成される「集約」の格納と取得を担 当する.通常,集約とリポジトリは一対一になる.

ロードマップ

  • 二種類のリポジトリがあることと,それぞれをどんなときに使うのか学ぶ
  • Hibernate や TopLink,Coherence,そして MongoDB でのリポジトリの実装方法を見る
  • リポジトリのインターフェイスに追加の振る舞いが必要になる理由を理解する
  • リポジトリを使う際の,トランザクションの扱いかたを検討する
  • 型の階層がある場合にリポジトリを設計する際の,注意事項を知る
  • リポジトリとデータアクセスオブジェクト[Crupi et al.]の根本的な違いを見る
  • リポジトリをテストする方法や,リポジトリを使ったテストを行うためのいくつかの方 法を検討する

重要と思った点

  • リポジトリには「コレクション指向のリポジトリ」と「永続指向のリポジトリ」の二種 類がある
  • 認証・アクセスコンテキストのような,一対一のマッピングを使った集約の削除の際に は,関連の両側にあるオブジェクトを,明示的に削除する必要がある.
  • 関連するオブジェクトの削除が面倒になるので,一対一の関連は避けるべき.
  • 永続化は,リポジトリだけに任せておきたい(集約に管理させたくない)
  • 複数のリポジトリ上でユースケースに最適化したクエリを使うファインダーメソッドを 数多く作る必要が出てきたら,それは集約の境界の判断を誤り,さまざまな型の集約を 設計するチャンスを見落としていた兆候
  • ドメインモデルの永続化に関するトランザクションは,アプリケーションレイヤを用い てとりまとめる
  • ストアドプロシージャの濫用は,実装がモデリングチームに見過ごされる可能性がある ため,DDD の秩序を乱す可能性がある

疑問と回答

  • コレクション指向のリポジトリとは?
    • 更新系のメソッドを持たないクラス
    • RDB やインメモリで格納する
  • 永続指向のリポジトリとは?
    • 更新系のメソッドを持つクラス
    • 集約のキーをもとに,集約の階層構造を 1 つのデータとして NoSQL に保存する
    • こちらでは,永続化処理を全てリポジトリに詰めることができるので高凝集となる
  • リポジトリと DAO の違いは?
    • リポジトリ:ドメインモデルと組み合わせて使われる
    • DAO:データベースのテーブルに対するラッパーとして使われる
  • トランザクションスクリプトとは?
  • get と find の違いは?
    • get:取得(そのメソッド内で特に何も処理をせずに値を取得,値がなければエラー )
    • find: 検索(そのメソッド内で何らかの処理をして値を取得.値がなければ null)

学習のためのリンク

第 13 章境界づけられたコンテキストの統合#

ロードマップ

重要と思った点

疑問と回答

第 14 章アプリケーション#

ロードマップ

重要と思った点

疑問と回答

追記予定

全体の感想#

思っていたより読みやすいと思う.

参考文献#

· 3 min read
Hiroki Ihoriya

英語力を維持・向上させるための習慣をリスト化しました.

具体的な学習方法ではなく,習慣として行えることにフォーカスしています.

背景#

僕の現状の英語力は TOEIC で 885 点程度です.

ここ数年ほど,英語学習のモチベーションは高くありません.それでも英語力は必要と思 うので,楽に維持・向上できる方法を探りたいです.

Reading#

基本的に,目に入るもの全てを英語にすればよい.

  • まず英語で検索する
  • 英語と日本語のある Web サイトでは優先的に英語を読む
  • Wikipedia を利用する際は,英語版を利用する
  • 洋書を読む
  • 全てのシステム設定を英語にする
  • 日本語を読む時間を減らす

Listening#

基本的に,耳に入るもの全てを英語にすればよい.

  • 海外の Podcast を聴く
  • 邦楽を聴くのをやめ,洋楽を聴く
  • 海外製の動画コンテンツを楽しむ(YouTube, Netflix など)
  • 日本語を聴く時間を減らす

Writing#

基本的に,何かを執筆する際には全て英語で書けばよい

  • 短文のメモなどは英語にする
  • 「英語で何ていうんだろう?」と常に考える
  • 日記・ブログ・論文などを英語で書く時間を増やす
  • 日本語を書く時間を英語を書く時間に変える

Speaking#

基本的に,日本語ではなく英語を話せばよい.

  • オンライン英会話を利用して,英会話の時間を増やす
  • 英語で独り言を言う
  • 日本語を話している際に,「英語で言うなら…」と常に考える
  • 日本語を話す時間を減らす

上記に列挙したことを継続的に行えば,英語力は維持・向上するはず.

· One min read
Hiroki Ihoriya

この記事では,React のテストに関する OSS をリストアップしていきます.

随時更新予定

Test tool#

React のテストを書くときに触れそうなものを集めます.

Web App#

testing-library などを利用して,テストが書かれているものを集めます.

· 4 min read
Hiroki Ihoriya

この春になってブログを刷新した.旧ブログには,いくつかを除いて駄文ばかりで,記事 を移行しようと思えなかった.

このブログには,文章が短い記事であったり,完成していない WIP 状態の記事であった りを複数公開している. SEO の観点からは,おそらくこの状態でインデックスされてし まっているので,あまり良くないかもしれない .とはいえ Google の個人ブログへの扱 いは相変わらず厳しいという印象があるので,もう気にしないことにした.

「検索エンジンに評価されるためには,2000 字以上は書こう」みたいなテクニックは今 も有効なのかもしれない.そういう意図が見え透ける無駄に長い記事はたくさんあるし, これからも増え続けると思う.

僕も実際に,一記事 2000 文字以上は書こうと思ってたし,そのまま無駄に長い記事が出 来上がってしまっていた.これからは,実験的に短い記事もアップしていこうと思う.

短い記事をアップしようと思い立った理由はいくつかあるが,すぐに思いつくのは以下の 通り.

  • 長い記事を読むのは疲れる
  • 長い記事を書くのは疲れる
  • 長い記事を書かないといけないと思うと,書かなくなる

読み手にも書き手(僕)にも優しいのは,短い記事.短くても何かしら役に立つ情報がま とまっていれば OK とする.

別に長い記事を書かないというわけではない.読むのも書くのも疲れるかもしれないが, 複数の記事に分散するよりも,1 つの記事にまとまっている方が良い場面は多々ある.そ ういう場面では,記事は長くなるべきであり,その方が便利だと思う.

なんか最近は,開発に関係ない普通の調べごとをしようと思うと,欲しい情報の書いてい ない無駄に読みにくい記事ばかりが上位に表示される.もっとこう,箇条書きで重要な点 だけを書いたブログ記事とかがあって良くて,それが検索エンジンに評価されてほしい.

いつの間にか思ったより長くなってしまったので,ここで終わる.

· 6 min read
Hiroki Ihoriya

最近,参画しているプロジェクトにて「E2E テストを書いていこう」という指針ができま した.

E2E テストフレームワークとして選ばれたのは,知名度も高くポピュラーな「Cypress」 です.

筆者自身,テストに興味を持っていたものの,現場での経験はありませんでした.なので ,「効果的な E2E テスト を Cypress でどのように書くか」を学ぶ必要があります.

本記事では,以下の点に着目し,Web や書籍の情報をまとめます.

  • E2E テストの必要性
  • 効果的な E2E テストとは
  • Cypress で効果的な E2E テストを実践する方法

E2E テストの必要性#

  • 手動テストのコスト削減
  • 変更による影響範囲の検知

効果的な E2E テスト#

費用対効果の低いテストを量産しても,得られる価値は少なく,無駄が生まれてしまうだ けだと思います.ここでは,Web 記事を参照し,テストコードのメンテナンスについて考 えていきます.

メンテナンス#

E2E テストコードのメンテナンス性に立ち向かう#

  • メンテナンスしやすいことと,メンテナンスが不要であることは全く違うこと
  • ロケータの定義をとっても「何を保証するか」が極めて大きくテストに反映される
  • 不適切なロケータの定義は,メンテナンスコストを大きく増やしてしまう
  • E2E テストはユーザー目線で行われるものであり,要素の選択はユーザーと同じ基準で 行われるべき」という思想に基づき,文言での要素選択を推進している
  • PageObjectPattern は運用がつらい.E2E テストの場合,そこまで再利用性は求められ ない

Cypress + TestRail による Frontend E2E テストの効率化について | メルカリエンジニアリング#

  • メルペイでも Cypress を採用している
  • 役割分担
    • プロダクト開発エンジニア:単体テスト・統合テスト
    • QA エンジニア:リグレッションテスト
  • テストケースの管理を Google Sheets → TestRail へ移行
  • TestRail を用いて,テストケースの管理・テスト結果の集計と可視化を行っている

なぜ E2E テストで id を使うべきではないのか | Autify Blog#

  • id の変更を伴う修正が困難になるため,使わないほうがよい

実践 Cypress#

基本的に,公式ドキュメントを参照すればよいと思います.

最初に読んでおきたいドキュメント#

簡訳ベストプラクティス#

  • Organizing Tests, Logging In, Controlling State
    • スペックの分離、プログラムでのログイン、状態管理を行い,速くてスケーラブルな テストを書こう
  • Selecting Elements
    • data-*attributes を使ってセレクターに文脈を与え,CSS や JS の変更から分離 しよう
    • cy.get('[data-cy=submit]').click() :変更から分離されている,この書き方が 一番良い
  • Assigning Return Values
    • クロージャを利用して,コマンドから得られる情報にアクセス,保存しよう
    • Cypress にて,const,let,var を使うことはほとんど無いので,もし使っている場 合はリファクタリングしたほうがよい
  • Visiting external sites
    • 自分でコントロールできるものだけをテストし,サードパーティのサーバーをできる だけ必要としないようにしよう
    • もし必要なら,cy.request()を利用して,API 通信を行う
  • Having tests rely on the state of previous tests
    • テストは常に、互いに独立して実行しても合格できるものであるべき
  • Creating "tiny" tests with a single assertion
    • 複数のアサーションを追加しても問題ない
  • Using after or afterEach hooks
    • afterとafterEachは利用せず,beforeとbeforeEachで状態をクリーンアップ する
  • Unnecessary Waiting
    • ルートエイリアスやアサーションを使用して、明示的な条件が満たされるまで Cypress の処理が進まないようにガードしよう
  • Web Servers
    • Cypress の実行前に Web サーバーを起動する
  • Setting a global baseUrl
    • 設定ファイル(デフォルトでは cypress.json)に baseUrl を設定する

参考文献#

· 2 min read
Hiroki Ihoriya

日々の開発で機能を実装する際の,お決まりの TODO リストを作りました.

現在参画しているプロジェクトでのルールや Web で読んだ記事を参考にしています.い つでも参照できるように,ここに残しておこうと思います.

TODO リスト#

  • 実装する機能を「追加する理由」と,「追加して得られる影響(良い・悪い両方)」を 考えてメモする
  • 変更対象となるコードの全体像を把握する
  • 実装方針を考えて,実装上の TODO をリストアップする
  • 実装上の課題になりうる点・影響範囲を考えてメモする(必要であれば共有する)
  • 実装 & テストを書く
  • (どうやったら壊れるかを考えながら)徹底的に動作確認をする
  • 必要であればリファクタリングする
  • PR(変更点・実装理由・影響範囲)を書く
  • レビューをもらう
  • 修正なければマージ(修正あれば「実装 & テストを書く」辺りに戻る)

参考文献#

· 3 min read
Hiroki Ihoriya

誰かの「一緒に働きたいエンジニア」の候補に上がるためには,どういう要件が必要か考 えます.主には,筆者自身が「こうありたい」という理想です.

自分自身ができていないことも容赦なくリストアップしているので,書いていて辛いです .

(随時更新予定)

基礎#

  • 心身ともに健康である人
  • 生産性向上への意識が高い人
    • こういう人がチームにいると,非常に助かります
  • 有限実行できる人
  • コミュニケーションを取りやすい人
  • チーム・組織・プロダクトの抱える課題に気づき,改善のための行動をとれる人
  • 失敗から学べる人
  • 情報共有を怠らない・ドキュメント化する人
  • 簡潔で,読み手に配慮した文章が書ける人
  • 一つ一つの物事に対して,「なぜそうすべきか」「なぜ必要なのか」理由を説明できる 人
  • プライベート・メンタルの状態が,仕事のパフォーマンスに影響しない人

技術面#

できるだけ領域(バックエンド・フロントエンド等)に特定されない要件を挙げます.こ ちらは特に筆者が不十分な点を挙げているので,泣きたくなってきます.

  • 実装力が高く,タスク消化が早い人
  • アプリケーションの設計指針を示すことができる人
  • リーダブルコードを書ける人
  • OSS 活動をしている人
  • 履歴書や GitHub にて,アウトプットが確認できる人
  • プライベートでもコードを書いている人
    • 単純に周りの優秀な人を見渡すと,プライベートでもコードを書いている人が多いな というだけで,必須ではない
  • チームにいると頼りになるソフトウェアエンジニアの いずれかに当てはまる人
  • 事業内容に興味がある人
    • 興味がなければ,設計が難しい気がする.DDD とかなかなかできない気がする

· 2 min read
Hiroki Ihoriya

開発で詰まった時,思考が停止して,同じことを何回も繰り返してしまうことがあります .その対処のために,詰まった時にやるべきことを残しておきます.

思考編#

  • 「なぜ詰まっているのか」を考える
  • 「問題の原因はどこにあるか」を考える
  • 「現状わかっていること」を洗い出す
  • 「現状わかっていないこと」を洗い出す
  • 「どうすれば問題を解決できるか」を考える

開発手法編#

  • 正常系のユニットテストを書く
    • 「ユニットテストが通る = 動作している」となれば,インクリメンタルに作業を進 めやすい
  • デバッガを使う
  • 動作するコードと動作しないコードの差分を見る
  • 自分が今書いているコードの動作をすべて口で説明する
    • 曖昧な理解の箇所にバグがある or 必要な実装が足りていない可能性が高い

コミュニケーション編#

  • チームメンバーに相談する
  • Slack の times に考えてることを書きなぐる

机を離れる#

  • 休憩する
  • 散歩する
  • シャワーを浴びる