Yuki Watanabe's Blog

Yuki Watanabe's Blog

エンジニアリングと子育てについて

エンジニア3年目までに読んで良かった書籍

未経験からエンジニアになり3年が経ちました。

この3年間はベテランエンジニアとの差を埋めるべく、プライベートの時間の大半を学習に充ててきました。幸い少しずつ成長を感じられ、業務では難易度の高い仕事を任せてもらえるようになったと感じます。このキャッチアップのために100冊以上の技術関連書籍を読んだことでしょう。

ここ最近、知人やTwitter経由で知り合った方から、私が学習に使った書籍について質問を頂くことが多いです。そこで、今後参照していただきやすいように、これまで私が読んで良かった書籍を1つの記事にまとめようと思います。

前提:エンジニアとして経験した技術

これまでソフトウェアエンジニアとして業務で経験した主な技術です。

担当領域はバックエンドがメインではありますが、フロントエンドやインフラも選り好みせずなんでもやるスタイルです。

書籍について

  • 個人的な難易度を★(易)~★★★(難)でランク付けしています
  • 2019年(エンジニア未経験独学時代)~2022年(エンジニア3年目)の間に読んだ書籍を載せていますので、初心者向けの書籍も含まれます
  • 現在ではより適した書籍があるかもしれません
  • 技術以外の内容(キャリアや業界研究等)の書籍もエンジニアのキャリア形成に役立ったので掲載しています
  • 完読していない書籍も含まれます

以下、分野ごとに書籍を紹介します。

全エンジニア向け

Web / インターネット

イラスト図解式 この一冊で全部わかるWeb技術の基本 (★)

HTMLコーダー&ウェブ担当者のための Webページ高速化超入門 (★)

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESSプラスシリーズ) (★★)

Web API: The Good Parts (★★)

Real World HTTP 第2版 ―歴史とコードに学ぶインターネットとウェブ技術 (★★)

Webフロントエンド ハイパフォーマンス チューニング (★★★)

セキュリティ / 暗号技術

暗号技術入門 第3版 秘密の国のアリス (★★)

体系的に学ぶ 安全なWebアプリケーションの作り方 第2版[固定版] 脆弱性が生まれる原理と対策の実践 (★★)

認証 / 認可

雰囲気で使わずきちんと理解する!整理してOAuth2.0を使うためのチュートリアルガイド (★)

OAuth、OAuth認証OpenID Connectの違いを整理して理解できる本 (★)

booth.pm

OAuth徹底入門 セキュアな認可システムを適用するための原則と実践 (★★)

テスト

はじめて学ぶソフトウェアのテスト技法 (★)

ソフトウェアテスト技法練習帳 ~知識を経験に変える40問~ (★)

Everyday Rails - RSpecによるRailsテスト入門(★)

https://leanpub.com/everydayrailsrspec-jp

テスト駆動開発 (★★)

コンピューターサイエンス

プログラムはなぜ動くのか 第3版 知っておきたいプログラミングの基礎知識 (★)

なるほどUnixプロセス (★★)

tatsu-zine.com

Goならわかるシステムプログラミング 第2版 (★★)

[試して理解]Linuxのしくみ ―実験と図解で学ぶOS、仮想マシン、コンテナの基礎知識【増補改訂版】 (★★)

ふつうのLinuxプログラミング 第2版 Linuxの仕組みから学べるgccプログラミングの王道 (★★★)

コンピュータシステムの理論と実装 ―モダンなコンピュータの作り方 (★★★)

Git, Linux, 正規表現

【改訂新版】Gitポケットリファレンス (★)

新しいLinuxの教科書 (★★)

反復学習ソフト付き 正規表現書き方ドリル WEB+DB PRESS plus (★)

開発の進め方、エンジニアマインド

SCRUM BOOT CAMP THE BOOK【増補改訂版】(★)

アジャイルサムライ(★★)

モブプログラミング・ベストプラクティス(★)

小さなチーム、大きな仕事 働き方の新しいスタンダード(★)

エンジニアの知的生産術 ―効率的に学び、整理し、アウトプットする(★)

達人プログラマー ―熟達に向けたあなたの旅― 第2版(★★)

Googleのソフトウェアエンジニアリング(★★)

Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち(★★)

サーバーサイド開発

オブジェクト指向アーキテクチャ

リーダブルコード(★)

オブジェクト指向でなぜつくるのか(★)

UMLモデリングレッスン(★)

リファクタリング:Rubyエディション(★★)

リファクタリング 既存のコードを安全に改善する 第2版(★★)

現場で役立つシステム設計の原則(★★)

ドメイン駆動設計入門 ボトムアップでわかる!ドメイン駆動設計の基本(★★)

オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方(★★)

モノリスからマイクロサービスへ(★★)

Rubyによるデザインパターン(★★★)

ソフトウェアアーキテクチャの基礎(★★★)

データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理(★★★)

Ruby

プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発デバッグ技法まで(★)

メタプログラミングRuby 第2版(★★)

Effective Ruby(★★)

現場で使える Ruby on Rails 5速習実践ガイド(★★)

独習Ruby on Rails(★★)

パーフェクト Ruby on Rails 【増補改訂版】(★★)

Go

初めてのGo言語(★★)

実用 Go言語(★★)

Goプログラミング実践入門(★★)

改訂2版 みんなのGo言語(★★)

SQL / DB設計

SQL 第2版 ゼロからはじめるデータベース操作(★)

SQL実践入門(★★)

達人に学ぶDB設計 徹底指南書(★★)

SQLアンチパターン(★★)

関数型言語

プログラミングの基礎(★★)

フロントエンド開発

JavaScript / TypeScript

改訂新版JavaScript本格入門 ~モダンスタイルによる基礎から現場での応用まで(★)

JavaScript Primer 迷わないための入門書 (アスキードワンゴ)(★★)

プロを目指す人のためのTypeScript入門 安全なコードの書き方から高度な型の使い方まで(★★)

Vue.js / Nuxt.js

Vue.js入門 基礎から実践アプリケーション開発まで(★★)

みんなのVue.js(★★)

Nuxt.jsとFirebaseを使って爆速で何か作る前に読む本(★★)

HTML / CSS

HTML&CSSとWebデザインが 1冊できちんと身につく本(★)

HTML5 & CSS3 デザインレシピ集(★)

CSS設計完全ガイド(★★)

デザイン UI/UX

Bootstrap 4 フロントエンド開発の教科書(★)

Atomic Design(★)

UI/UXデザインの原則(★)

インタフェースデザインのお約束(★)

インフラ

ネットワーク

図解まるわかり ネットワークのしくみ(★)

DNSがよくわかる教科書(★)

Linuxで動かしながら学ぶTCP/IPネットワーク入門 (★★)

マスタリングTCP/IP 入門編(第6版)(★★)

AWS / GCP

Amazon Web Services 基礎からのネットワーク&サーバー構築 改訂版 (★)

AWS認定アソシエイト3資格対策~ソリューションアーキテクト、デベロッパー、SysOpsアドミニストレーター~ (★)

Amazon Web Servicesクラウドデザインパターン設計ガイド 改訂版 (★★)

実践Terraform AWSにおけるシステム設計とベストプラクティス (★★)

エンタープライズのためのGoogle Cloud クラウドを活用したシステムの構築と運用 (★)

CI / CD

CircleCI実践入門 (★)

GitHub Actions 実践入門 (★)

コンテナ

さわって学ぶクラウドインフラ docker基礎からのコンテナ構築 (★)

イラストでわかるDockerとKubernetes (★)

Kubernetes完全ガイド 第2版 (★★)

監視

入門 監視 (★★)

データエンジニアリング

Google Cloudではじめる実践データエンジニアリング入門 (★)

実践的データ基盤への処方箋〜 ビジネス価値創出のためのデータ・システム・ヒトのノウハウ (★★)

技術以外の学問、キャリア関連

英語、数学

プログラマの数学第2版 (★)

プログラミング英語教本 (★)

プログラミング英語教本

プログラミング英語教本

Amazon

キャリア

CAREER SKILLS ソフトウェア開発者の完全キャリアガイド(★)

SOFT SKILLS ソフトウェア開発者の人生マニュアル(★)

エンジニアとして世界の最前線で働く選択肢(★)

ベンチャー / スタートアップ

僕は君の「熱」に投資しよう(★)

渋谷ではたらく社長の告白(★)

センスのいらない経営(★)

2025年を制覇する破壊的企業(★)

STARTUP 優れた起業家は何を考え、どう行動したか(★)

その他、いろいろ

コンサル一年目が学ぶこと(★)

技術者のためのテクニカルライティング入門講座(★)

個人開発をはじめよう!クリエイター25人の実践エピソード(★)

参考

学習ロードマップや技術書のおすすめ記事を読み、技術学習の指針を立て、適した書籍を選んでいます。

特におすすめなのはこちらのロードマップ。

roadmap.sh

さまざまなエンジニア向けに必要な技術が列挙されていて、今の自分に不足している技術を知るのに最適です。

まとめ

現役エンジニアの方やエンジニアを目指している方にとって、少しでもお役に立てたなら嬉しいです。

『ソフトウェアアーキテクチャの基礎』を読みました

『ソフトウェアアーキテクチャの基礎』を読みました。今年読んだ技術書の中でもトップクラスに刺さった本でしたので、感想を書きます。

読み初めの動機

本書を読み始めた動機はこちら。

  • 所属している会社では大規模サービスの開発・運用の一端を担っており、なぜそのアーキテクチャが選定されたのかをより深く理解したい
  • 中長期的に、アーキテクチャ選定を担えるようになりたい

最近の技術的な興味として、インフラ構成を含めたソフトウェアアーキテクチャ面への興味が強く、また現時点では知見が少ない分野でもあります。

感想

まず、複数のソフトウェアアーキテクチャを学べたのが良かったです。特に、

アーキテクトは、すべての選択の良し悪しを冷静に評価しなくてはならない。決まったものをいつでも選べばよいといった、都合の良い話は現実世界には存在しない。すべてはトレードオフだ。

とあるように、どのアーキテクチャにもメリット、デメリットがあり、ユースケースごとに適したアーキテクチャが異なる、というのが刺さりました。 私はこれまで、ベストプラクティスを知って満足してしまう傾向がありました。本書をきっかけに、「この方法は一見良くない手法に見えるが、メリットもあるのではないか?」と自問するようになり、洞察力が深くなってきているように感じています。

さらに、アーキテクトしてのマインドセット、振る舞い方についても多くを知れました。

学習の必要性やステークホルダーとの調整の方法など、アーキテクトとならずとも、いちエンジニアとして今後の振る舞い方に参考になる点が多かったです。

構成として、最後に本書の内容の理解度を評価するためのチェックリストといて、「自己評価のためのチェックリスト」が用意されているのが良いですね。

参考として、訳者の方のスライドは本書の予習・復習として、コンパクトにまとまっていてよかったです。

speakerdeck.com

今後

今後は、アーキテクチャ選定の実践やより具体について知っていきたいと考えています。インプット面では、同じ著者の方々の続編『ソフトウェアアーキテクチャ・ハードパーツ』や以前読んだ『データ指向アプリケーションデザイン』の読み直しをしつつ、アウトプットとして業務に活かしていきたいです。

O'Reilly Japan - ソフトウェアアーキテクチャ・ハードパーツ

yuki0920.hatenablog.jp

『アジャイルな見積りと計画づくり』を読みました

アジャイルな見積りと計画づくり 価値あるソフトウェアを育てる概念と技法』を読みました。アジャイルなプロジェクトを推進するにあたって重要なことを学べ、読んでよかったので感想を書きます。

読み始めの動機

本書の読み始めの動機は、アジャイルなプロジェクトにおける見積もりや計画づくりを、体系立てて知っておきたいと考えたからでした。 これまでは、アジャイル開発に強みを持つ受託開発の会社で働いていたので、周りのエンジニアが見積もりや計画づくりに慣れているエンジニアが多く、その方々が計画をリードしていました。 私も見積もりや計画づくりには参加しており、個々のプラクティスについては知ってはいましたが、

  • なぜそのプラクティスが重要なのか?
  • 他にはどんな方法があるのか?

などを知っておき、自分でも見積もりや計画づくりをリードできるようになっておきたいと考えました。

感想

見積もりや計画づくりのプラクティスの目的や背景については知らないことが多く、勉強になりました。また、個々のプラクティスについても、具体的にかつ様々なパターンが書かれており、今後のプロジェクトにも適用できそうだなと感じました。

構成としては、各章ごとにまとめがあるため、復習し易くなっている点が良いですね。また、各章ごとに「話し合ってみよう」の項があり、書籍の内容をチーム内でどう落とし込んでいくかを議論しやすくなっているのも、今後の活用の余地がありそうです。

読書メモ

  • 進捗はフィーチャーで計測すべきであり、作業によるべきではない
  • 規模と期間の関係性は、見積もった規模から期間を導出するというものである
  • 見積もりにゼロを使うのが便利な場合もある
  • ベロシティ算出の目的は、長期間でのチームの平均速度を把握することである
  • ストーリーポイントでの見積もりは、チームが職能横断的に仕事を進めていくことを促進する
  • ストーリーの優先順位は、金銭価値、コスト、得られる知識、低減できるリスクのバランスで決める
  • ユーザーストーリーは扱うデータの境界やストーリーで行う操作にに沿って分割する
  • アジャイルな計画づくりは、リリースプランニングからイテレーションプランニングを経て、より詳細な計画をたてていく
  • 精緻なスケジュールを立てられない場合は、フィーチャーかスケジュールにバッファをもたせる
  • ベロシティのポイントに加算できるのは、イテレーション終了時点で完了しているストーリーのポイントだけにする
  • 個人単位でベロシティを測定したりトラッキングしてはならない。
  • アジャイルな計画づくりは複数のレベルにわたっておこなわれる。 複数のレベルとは、リ リース、イテレーション、「今日」の 3 つである

【2022年】エンジニア3年目 転職活動振り返り

このたび転職活動を実施し、ソフトウェアエンジニアとして希望の会社から内定を頂けたため、振り返り記事を書きます。エンジニアの方々の転職記事を日々興味深く読んでいたので、誰かの参考になれば嬉しいなと思い、自分も書いてみます。

これまでの経歴

これまでの経歴は、新卒で非IT企業に入社し経理の仕事をした後転職し、2年半の開発業務経験を積んだエンジニアです。

  • 2013/03 大学卒(経済学部)
  • 2013/04~2019/10 地方ガス会社入社(経理6年→情シス6ヶ月)
  • 2019/11~2022/07 受託開発企業入社(プログラマ) ※以降、前職と表現します

2013年に大学を卒業後、新卒で地元のガス会社に入社し経理部員として6年ほど決算業務に携わりました。経理業務の傍らで手掛けた決算業務の効率化をきっかけに、ITやプログラミングに興味を持ち、エンジニアとしての就職を志すことにしました。

仕事をしつつプログラミングの勉強と転職活動を行い、2019年に受託開発を行う企業に入社をしました。Rubyアジャイルによる開発スタイルで、5つほどのプロジェクトを経験しました。

業務領域的にはRubyでのサーバー開発をメインに、直近1年はVue.jsでのフロントエンド開発にもトライし、バックエンドからフロントエンドまで幅広くソフトウェアの開発に携われるようになりました。

転職活動の結果

転職活動の結果は、エンジニア未経験時代とは比較にならないほどスムーズに終わりました。

  • カジュアル面談 20社
  • 選考を受けた会社 6社
  • 内定を頂いた会社 4社
  • 途中辞退した会社 1社
  • お祈りされた会社 1社

いわゆるメガベンチャーと呼ばれる企業群からも数社内定をいただき、その内の1社であるメルカリへ入社を決めました。

転職活動スケジュール

  • 2021/12~2022/01 カジュアル面談、コーディングテスト対策
  • 2022/02~2022/03 選考
  • 2022/07 入社

本格的な転職活動をしたスケジュールは上記の通りですが、2021年初めくらいから転職を意識し始めました。定期的に職務経歴書をブラッシュアップしては転職ドラフトへ登録し、市場価値の確認をしていました。 また2021年5月頃には、1ヶ月ほど集中して、コーディングテストを見据えたアルゴリズムとデータ構造の勉強を実施しました。

なぜ転職をするか

今後やりたいことが明確になり、前職では実現が難しいと考えたため転職を決意しました。

具体的にやりたいことは下記の2つが挙げられます。

1. 会計とエンジニアの両方のバックグラウンドを活かした開発をしたい

前職では技術的に優れたエンジニアがたくさんおり、その中で自分が技術だけで生き残っていくのは難しいと考えるようになりました。 一方で、私にはエンジニアの中では希少な経理の実務経験があり、会計に詳しい自負があります。

そのため、会計知識を要するソフトウェアエンジニアのポジションに就ければ、自分のバリューを最大化できるのはないかと考えました。 実際に前職で会計関連の機能開発を担当した際は、ビジネス要件を手にとるように把握でき、開発面に加えて仕様策定でも貢献することができ、この思いを強くしました。

さらには、様々な企業の方とカジュアル面談をする過程で、フィンテック業界を中心に自分のような会計ドメインの知識を持ったエンジニアは非常に需要が高いことを知りました。

自分の得意な会計というドメインの需要の高さを知れたので、直近数年は「エンジニア×会計」という掛け合わせのスキルを深堀りしたいと考えました。

2. Go言語を使った開発をしたい

個人で勉強したときから数えると3年以上RubyJavaScriptといった動的な型付け言語を使った開発をしています。 一方で、周りの優秀なエンジニアはというと、Javaなどの静的型付け言語での開発をみっちりと積んだ方が多い印象です。

そこで、いつからか「静的型付け言語を学べば必ず優秀になれるというわけではないものの、Rubyとは異なるパラダイムの言語での開発経験を積むことで、自身の技術レベルを着実にかつ効率的に上げられるのではないか」と思うようになりました。

静的型付け言語の中でもGoは、Web開発での採用事例が多く需要が高いことに注目しました。 実際に学んでみると、記法がシンプルで可読性を保ちやすい点に好感を持ち、Go言語での開発に注力することを決めました。

働き方・待遇面で大切にしたこと

0歳児の子育てをしているので、働き方・待遇面でも大切にしていたことがありました。

  • フルリモートであること
  • 現年収+α以上であること
  • 入社時点で有給休暇が付与されること(子供の急な看病に備えるため)

求人内容やカジュアル面談から、これらの条件を満たしている確度が高い会社のみ応募しました。結果的に、内定を頂いたほとんどの会社が上記の条件を満たしていました。

情報収集どのようにしたか

カジュアル面談と書籍、口コミサイトの3本柱で情報収集をしました。

カジュアル面談

カジュアル面談を20社ほど実施しました。

業界研究に役立てられ、とても有意義でした。

書籍

面接やコーディングテスト対策のためにキャリア系の書籍を数冊読みました。

なかでもこちらの書籍が良かったです。

エンジニアとして世界の最前線で働く選択肢 ~渡米・面接・転職・キャリアアップ・レイオフ対策までの実践ガイド

ホワイトボードコーディングテストへの向き合い方など学ぶことが多くあり、実際の面接で役立つ場面が多かったです。

他にも業界研究のために、興味のあるフィンテック関連の書籍も読み漁りました。

口コミサイト

選考を受け始めたタイミングで、OpenworkやGlassdoorを使い、企業の年収や働きやすさを調べました。

応募は求人媒体か直接応募か

どのように企業に応募したかについては、メインでは媒体を使いつつ、数社ほど直接応募をしました。

  • 媒体は、FindyやLapras、転職ドラフト、Meetyを利用し20社ほどカジュアル面談や選考を実施しました
  • 直接応募は、3社ほどでした

媒体はいいね機能やメッセージ機能があり、スムーズに企業と連絡が取れて便利です。一方で、入社が決まった場合は企業から媒体への成果報酬支払われるため、オファー提示年収が上がりづらい傾向があるように感じました。 直接応募は、応募の手間はかかるものの、オファー提示年収が高いなどの傾向を感じました。

ちなみに、入社を決めた会社はMeety経由でカジュアル面談を実施し、その後直接応募をしました。

評価していただいた点

複数社に内定後のオファー面談をしていただきましたが、下記の点を評価してもらったようです。

  • 経理知識を持ったエンジニアという、掛け合わせのスキルが希少である
  • チームメンバーとコミュニケーションを取りやすい
  • 技術のキャッチアップが早い
  • 堅牢性が高いコードを書ける

1つ目の点は、以前の経理経験がそのまま活きました。 2~4点目は、前職で目の前の業務にできるだけオーナーシップを持って取り組むことを意識してていたことが功を奏したようです。

選考を通して自分に不足していると感じたこと

選考での技術面接を通して、自分には下記が不足していると感じました。

  • 1つのサービス単位の技術選定やアーキテクチャ選定を担ったことがない
  • 31歳という年齢に比べ、エンジニア経験が2年と短い
  • 0→1フェーズの経験が無い

これらの経験は、今後の課題としてクリアしていきたいと考えています。

技術テスト対策どのようにやったか

コーディングテスト

AtCoderのC問題レベルを解けるように精進しました。C問題レベルを選んだ理由は、D問題以上は自分のレベルとの乖離が大きく限られた時間で解けるようになる気がしなかったためです。

選択する言語は、使い慣れたRubyのほうが早く解けることに気づきRubyを選択しました。

AtCoder に登録したら次にやること ~ これだけ解けば十分闘える!過去問精選 10 問 ~ - Qiita

を見て要領を得た後は、B、C問題を中心に50問ほど解きました。AtCoderは、他の回答者の回答を見られるため使いやすく、自分のコードとの差分を把握することで成長に繋げやすいです。

また、選考を受けた会社がHackerRankを利用していたため、慣れるために30問ほど解きました。この慣れのための練習はかなり効きました。

データベース設計

面接によってはデータベース設計を課される場合があったため、

達人に学ぶDB設計 徹底指南書

を読み直し、知識の定着を図りました。 おかげで、面接の場でテーブル設計やインデックス設計について議論する機会がありましたが、なんとかついていくことができました。

アーキテクチャ設計

インフラやアプリケーションレベルでのアーキテクチャ設計の対策は、現状携わっているプロジェクトのインフラやアプリケーションを思い起こし、

  • なぜこのような設計をしているか
  • より改善できそうな点はなにか

を改めて考えることで対策しました。

正直アーキテクチャ設計については準備不足感がありますが、なんとかなりました。シニア、テックリードレベルのソフトウェアエンジニアのポジションであれば、より一層の対策が必要でしょう。

最後に

次の会社入社後にTwitterか入社エントリ記事を書こうと思います。 よかったら、エンジニアのキャリアについて談義しましょう!

保育園の比較ポイントまとめ

我が家では、今年の4月から子供が保育園に通っています。

近隣に保育園が複数あったため、10園以上の見学に出向きました。 その上で、入園申込みをするにあたり、志望順位を決めるのに苦労しました。

そこで、我が家にとって重視すべきポイントを妻と話し合いながら洗い出し、このポイントに沿って1位から10位までの順位付けをしました。

転居などによってまた保育園の入園申し込みをするかもしれないので、この記事では保育園を比較するために考慮したポイントを書き残します。

保育園を比較するための考慮ポイント

  • ★家からの距離
  • 園庭があるか
  • 連絡帳は紙かWEBか
  • 自転車置き場があるか
  • 職員の雰囲気は良いか
  • こどもの様子は良いか
  • 外遊びの頻度はどの程度か
  • 私物預かり(着替えなど)が可能か
  • ★3歳児以降も継続可能か
  • ★保育園の持ち物が多いか、少ないか
  • 園付近の交通状況、通園状況が安全か
  • 父母が参加する行事の頻度や曜日はいつか
  • 紙おむつのサブスクサービスは利用可能か
  • 子供のアレルギーがある場合の食事の対応はどうか

※★は特に重視した点

これらの考慮事項について、それぞれ優先順位が高い項目ごとに重み付けをして、順位付けを行いました。

我が家では、特に

  • 家からの距離
  • 3歳児以降も継続可能か
  • 保育園の持ち物が多いか、少ないか

といった点を重視しました。 家からの距離が近さや、保育園の持ち物の少なさを重視したのは、親子の可処分時間はできるだけ長くしたかったためです。また、3歳児でも保育園の入園申し込みをするのは大変なので、5歳児まで見てくれる園を重視しました。

最後に

保育園選びに少しでもお役に立てれば幸いです。

『レガシーコード改善ガイド』を読みました

『レガシーコード改善ガイド』を読みました。

読み始めの動機

以前読んだ 『モノリスからマイクロサービスへ』にて下記のように紹介されていたため興味を持ちました。

既存のモノリスをビジネスドメインの境界線に沿って再編成するというルートに進むのであれば、Michael Feathersの『レガシーコード改善ガイド』が間違いなくお勧めだ。

マイクロサービス開発をするにあたり、なにかヒントを得たいと言う動機でした。

感想

自動テスト、テストコードを重視した立場から、ソフトウェアの振る舞いをかえずにレガシーコードを改善する方法をいくつも学ぶことができて良かったです。

冒頭の

私にとって、レガシーコードとは、単にテストのないコードです。

は刺さりましたね。

個人の経験と照らし合わせると、知っている、実践できていることも多かったです。『リファクタリング』や『ドメイン駆動設計入門』を愛読しており、これらと重なる部分が多かったです。『リファクタリング』と異なる点としては、『レガシコード改善ガイド』はC++Javaを題材に書かれているため、インターフェースを活かした静的型付け言語特有のリファクタリングパターンが多数紹介されていました。

他書で学んだ以外には、業務でのコードレビュー等を通して学んだ事も多く書いてありました。具体的には、

  • どのレイヤーでテストをすべきかどうかの判断
  • 外部APIやライブラリに依存したコードのテストの方法

などです。暗黙知だったことが明文化されていたため、自分の考えに納得感を持つことができました。

書籍の構成としては、

  • サンプルコードが豊富
  • 巻末の用語集が復習に最適

といった点が良かったです。

原著は『Working Effectively with Legacy Code (Robert C. Martin Series) (English Edition)』で2004年の出版のため、およそ20年前にかかれています。例題の古さを感じるものの、それを差し引いても読んでおいてよかったと感じます。

まとめ

  • テストのないソースコードはレガシーコードである
  • ソフトウェアの振る舞いを保持しながらコードを改善する方法を学べる
  • 静的型付け言語でのリファクタリングを学べる

『モノリスからマイクロサービスへ』を読みました

導入

モノリスからマイクロサービスへ ――モノリスを進化させる実践移行ガイド』を読みました。

前提

今後仕事でマイクロサービス開発に携わる予定であり、予習のために読みました。 本書は、モノリスとマイクロサービスへの移行に焦点が当てられているため、モノリスの開発経験しかなくても自身の経験と結びつけながら読める点が多そうだと考え、手に取りました。

感想

本書を読み終えて、特に下記の点を知れたのが良かったです。

  • モノリスとマイクロサービスの定義
  • マイクロサービスへの分割を念頭に入れたモノリスの設計
  • マイクロサービス移行の幅広いパターン

マイクロサービス開発をしないと役に立たないといったことはなく、モノリス開発でも役立てられる内容が多かったです。設計の幅を少し広げられたように思います。

マイクロサービスのメリットを理解しつつもトランザクションの管理がとても大変そうだとの所感を持ちました。実際に開発にするにあたって、この辺の解像度を上げていきたいなと。

また、翻訳は素晴らしく、翻訳本とわからないほどに違和感なく読み進められました。

今後の展望

マイクロサービスに使用される具体的なサービスは使ったことがないので、業務をしながら下記のようなサービスに習熟したいと考えています。

  • サービスメッシュ(Istio, etc…)
  • サービス間通信(gRPC, etc…)
  • APIゲートウェイ(Kong, etc…)

また、マイクロサービス間のドメイン境界を定義するにあたり、ドメイン自体の知識やドメイン駆動設計に関する知識も必要になるかと思うので、この辺も強化していく予定です。

余談

本書ではコンウェイの法則に言及されていましたが、システム設計と組織構造は対となるものです。組織構造の変革については本書「2章 移行を計画する」でも述べられていますが、現在併読している『ユニコーン企業のひみつ』に詳しく載っており、リンクする内容が多いのでこちらも面白く読み進められています。

www.oreilly.co.jp