kakakakakku blog

Weekly Tech Blog: Keep on Learning!

「Try Envoy」で Envoy を学ぼう!「Getting Started with Envoy」を試した

Envoy のサイトに「Try Envoy」という学習コンテンツがあり,現在は以下の「計11種類」のシナリオから選んで学べる.実際にはブラウザベースで進められる Katacoda の学習コンテンツが埋め込まれているため,特別な環境構築をせずに進められるのは便利.

  • Getting Started with Envoy(今回紹介する)
  • Migrating from NGINX to Envoy Proxy
  • Migrating from HAProxy to Envoy Proxy
  • Securing traffic with HTTPS and SSL/TLS
  • File Based Dynamic Routing Configuration
  • API Based Dynamic Routing Configuration
  • Detecting Down Services with Health Checks
  • Implementing Blue / Green Rollouts
  • Implementing Metrics and Tracing Capabilities
  • Debugging Envoy Proxy
  • Controlling load balancing policies

f:id:kakku22:20191117162057p:plain

学習コンテンツは「Try Envoy」からアクセスできるけど,当然ながら Katacoda にもある.個人的には画面レイアウトの広さという観点から Katacoda を使うと良いと思う.

www.envoyproxy.io

www.katacoda.com

「Try Envoy」のシナリオを数個試してみて,当然ながら手順通りには動くけど,Envoy 初学者には理解しにくそうな点もあった.そこで,学んだことを整理しつつ,イメージしにくそうな部分をまとめておこうと思う.

Getting Started with Envoy

今回は Envoy に入門するシナリオ「Getting Started with Envoy」を紹介する.Envoy を使ってリクエストを外部サービスに流したり,複数のアプリケーションにパスベースルーティングをする.

www.katacoda.com

手順は以下の「計4種類」ある.サイトに「Estimated Time: 10 minutes」と書いてあるけど,考えながら進めるとすぐに終わらないと思う.時間は参考レベルで見ておくと良さそう.

  • Step.1 「Create Proxy Config」
  • Step.2 「Start Proxy」
  • Step.3 「Admin View」
  • Step.4 「Route to Docker Containers」

Step.1 「Create Proxy Config」

最初は Envoy の挙動を設定する envoy.yaml を作成する.実際にエディタで envoy.yaml を書く場面はなく,手順上で Copy to Editor ボタンをクリックすると自動的にエディタに反映される仕組みになっている.Katacoda 便利!その前に基本的な用語を整理しておく.詳細はドキュメントを参照してもらえればと.

  • Listeners : リクエストを受ける設定
  • Filters : リクエストをフィルタする設定(複数のフィルタを設定できる)
  • Clusters : リクエストを転送する設定

そして envoy.yaml を読み解く前に構成図を整理しておく.コンテナとして起動した Envoy にリクエストを投げると,そのまま Google に転送される.Envoy を試す最も簡単な構成とも言える.

f:id:kakku22:20191117211922p:plain

envoy.yaml のポイントはザッと以下となる.

  • listeners
    • 10000 Port でリクエストを受ける
  • filter_chains
    • route_config にルーティング設定を書く
    • プレフィックスが / の場合に host_rewrite で HTTP Host Header 書き換える
    • service_google Cluster に転送する
static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address: { address: 0.0.0.0, port_value: 10000 }

    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        config:
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: local_service
              domains: ["*"]
              routes:
              - match: { prefix: "/" }
                route: { host_rewrite: www.google.com, cluster: service_google }
          http_filters:
          - name: envoy.router

  clusters:
  - name: service_google
    connect_timeout: 0.25s
    type: LOGICAL_DNS
    dns_lookup_family: V4_ONLY
    lb_policy: ROUND_ROBIN
    hosts: [{ socket_address: { address: google.com, port_value: 443 }}]
    tls_context: { sni: www.google.com }

admin:
  access_log_path: /tmp/admin_access.log
  address:
    socket_address: { address: 0.0.0.0, port_value: 9901 }

Envoy で HTTP を制御するフィルタ envoy.http_connection_manager の詳細は以下のドキュメントに書いてある.

www.envoyproxy.io

Step.2 「Start Proxy」

さっそく envoy.yaml を指定して Envoy コンテナを起動する.80 Port にリクエストをすると,Google に転送される.ホスト内だと curl localhost でも良いし,Katacoda だと https://xxx.environments.katacoda.com という一時的な URL も使えるため,どちらも使える.

$ docker run --name=proxy -d \
  -p 80:10000 \
  -v $(pwd)/envoy/envoy.yaml:/etc/envoy/envoy.yaml \
  envoyproxy/envoy:latest

Step.3 「Admin View」

次に Envoy の「Administration interface」機能を試す.UI は直感的に理解しにくく感じたけど,メトリクス/統計情報/ログなど,Envoy の状態を確認するときに使える.

$ docker run --name=proxy-with-admin -d \
    -p 9901:9901 \
    -p 10000:10000 \
    -v $(pwd)/envoy/envoy.yaml:/etc/envoy/envoy.yaml \
    envoyproxy/envoy:latest

f:id:kakku22:20191117181412p:plain

詳しくは以下のドキュメントに書いてある.

www.envoyproxy.io

Step.4 「Route to Docker Containers」

最後は Python アプリケーションと Envoy を組み合わせて使う.docker-compose.yml から構成を読み取ると以下となる.リクエストの URL を判断して service1service2 にパスベースルーティングをしていて,アプリケーション側は環境変数 SERVICE_NAME を表示する程度になっている.

f:id:kakku22:20191117211948p:plain

なお service1service2envoyproxy/envoy-alpine:latest イメージをベースに Python と Flask をインストールしているため,Envoy でよく使われる「サイドカーパターン」になっていない点に注意する.とは言え,今回のように Envoy を試すことが目的の場合は問題ないと言える.

version: '2'
services:

  front-envoy:
    build:
      context: .
      dockerfile: Dockerfile-frontenvoy
    volumes:
      - ./front-envoy.yaml:/etc/front-envoy.yaml
    networks:
      - envoymesh
    expose:
      - "80"
      - "8001"
    ports:
      - "8000:80"
      - "8001:8001"

  service1:
    build:
      context: .
      dockerfile: Dockerfile-service
    volumes:
      - ./service-envoy.yaml:/etc/service-envoy.yaml
    networks:
      envoymesh:
        aliases:
          - service1
    environment:
      - SERVICE_NAME=1
    expose:
      - "80"

  service2:
    build:
      context: .
      dockerfile: Dockerfile-service
    volumes:
      - ./service-envoy.yaml:/etc/service-envoy.yaml
    networks:
      envoymesh:
        aliases:
          - service2
    environment:
      - SERVICE_NAME=2
    expose:
      - "80"

networks:
  envoymesh: {}

front-envoyfront-envoy.yaml を以下に載せる.ポイントは filtersroutes に2種類の prefix が設定されている点で,URL によって転送する Cluster を変えている.

static_resources:
  listeners:
  - address:
      socket_address:
        address: 0.0.0.0
        port_value: 80
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        config:
          codec_type: auto
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: backend
              domains:
              - "*"
              routes:
              - match:
                  prefix: "/service/1"
                route:
                  cluster: service1
              - match:
                  prefix: "/service/2"
                route:
                  cluster: service2
          http_filters:
          - name: envoy.router
            config: {}
  clusters:
  - name: service1
    connect_timeout: 0.25s
    type: strict_dns
    lb_policy: round_robin
    http2_protocol_options: {}
    hosts:
    - socket_address:
        address: service1
        port_value: 80
  - name: service2
    connect_timeout: 0.25s
    type: strict_dns
    lb_policy: round_robin
    http2_protocol_options: {}
    hosts:
    - socket_address:
        address: service2
        port_value: 80
admin:
  access_log_path: "/dev/null"
  address:
    socket_address:
      address: 0.0.0.0
      port_value: 8001

実際に起動すると,期待した通りにリクエストをルーティングできた.

$ docker-compose -f ~/envoy/examples/front-proxy/docker-compose.yml up -d

$ curl localhost:8000/service/1
Hello from behind Envoy (service 1)! hostname: 211d6aaf214c resolvedhostname: 172.19.0.3

$ curl localhost:8000/service/2
Hello from behind Envoy (service 2)! hostname: 30ce9b84004a resolvedhostname: 172.19.0.2

まとめ

  • Envoy のサイトに「Try Envoy」という学習コンテンツがある
    • 現在は「計11種類」のシナリオから選べる
  • 今回は「Getting Started with Envoy」を試した
    • リクエストを外部サービスに流したり,複数のアプリケーションにパスベースルーティングをしたり,基本的な動作確認はできる
  • まだ「Envoy の良さ」を感じられる内容ではなく,引き続き「Try Envoy」を進めていく

Redash v8 を試そう!「Redash ハンズオン資料」v8 をリリースした

2019年10月末に Redash の最新バージョン「Redash v8.0.0」がリリースされた.多くの新機能と機能改善があり,既にまとめている.

kakakakakku.hatenablog.com

Redash ハンズオン資料 v8 リリース

2017年12月に公開した「Redash ハンズオン資料」も,Redash のメジャーバージョンアップごとに一緒にバージョンアップし,既に2年間もメンテナンスし続けている.個人学習用途/研修用途など,今でも様々な場面で使って頂けているらしく,嬉しい!Star はもう少しで 200 ⭐️

github.com

既にサポートしている Redash バージョン「v2 / v4 / v5 / v6 / v7」に加えて,今回さっそく「v8」もサポートした!主な変更点は以下となる.

  • 全般
    • スクリーンショットを更新した
    • UI 変更に合わせて手順を見直した
  • 機能
    • 新機能「パラメータ付きクエリ(複数値)」を追加した

f:id:kakku22:20191110121657p:plain

まとめ

「Redash ハンズオン資料」を使って Redash v8 を試そう!Happy querying :)

github.com

関連記事

includeIf を使って git config をプロジェクトごとに読み替える

GitHub と AWS CodeCommit を併用したり,プロジェクトごとに別アカウントを使ったり,リポジトリごとに git config を変える場面もある.今までは個人用 GitHub を global 設定とし,別アカウントはリポジトリごとに git config --local コマンドで設定をしていたけど,最近リポジトリが増えて,設定を忘れる場面もあり,direnv のように自動設定をする方法を探していた.

includeIf

Git Documentation を読むと,「Includes (include)」「Conditional includes (includeIf)」の説明があり,なんと includeIf を使うと,設定ファイルを条件付きで読み込めるため,さっそく検証することにした.

git-scm.com

検証環境

以下のように,ホームディレクトリ直下に github ディレクトリと codecommit ディレクトリを作成した.さらにサンプルリポジトリ g1 / g2 / c1/ c2 を作って git init をしておく.

~/github
    ├── g1
    └── g2
~/codecommit
    ├── c1
    └── c2

~/.gitconfig

今まで通り,ホームディレクトリに ~/.gitconfig を置き,GitHub 用に global 設定をしている.今回は useremail を抜粋した.さらに includeIfgitdir を組み合わせて,~/codecommit/ 直下にあるリポジトリの場合に ~/.gitconfig_codecommit を読み込む設定を追加した.Git Documentation を読むと,gitdir 以外に onbranch なども使える.

[user]
  name = kakakakakku
  email = y.yoshida22@gmail.com

[includeIf "gitdir:~/codecommit/"]
  path = ~/.gitconfig_codecommit

~/.gitconfig_codecommit

そして,条件付きで読み込む設定を ~/.gitconfig_codecommit に置く.今回は仮で bobbob@example.com にした.

[user]
  name = bob
  email = bob@example.com

検証結果

global 設定を反映する github/g1github/g2 は今まで通りだった.

$ cd ~/github/g1
$ git config user.name
kakakakakku
$ git config user.email
y.yoshida22@gmail.com

$ cd ~/github/g2
$ git config user.name
kakakakakku
$ git config user.email
y.yoshida22@gmail.com

そして codecommit/c1codecommit/c2 は,期待通りに bob になり,条件付きで読み込めていることを確認できた.便利だ!

$ cd ~/codecommit/c1
$ git config user.name
bob
$ git config user.email
bob@example.com

$ cd ~/codecommit/c2
$ git config user.name
bob
$ git config user.email
bob@example.com

まとめ

プロジェクトごとに git config を読み替える場合は includeIf を使うと便利!特に git clone した直後にすぐ使えるのは体験として大きく改善した.小規模なら git config --local コマンドも引き続き併用していく.

「Redash v8.0.0」で気になった新機能と機能改善

2019年10月末に Redash の最新バージョン「Redash v8.0.0」がリリースされた.Change Log を読むと機能改善が多くあり,今回は「個人的に気になった Redash v8 新機能と機能改善」「計10点」紹介しようと思う.Change Log は以下の CHANGELOG.md で確認できる.

目次

  1. ドロップダウンで複数値を選択できるようになった
  2. クエリ名を日本語で正しく検索できるようになった
  3. ダッシュボードがグリッド表示になった
  4. データソース追加/削除
  5. データソース設定画面の UI 改善
  6. クエリ画面にデータソースのアイコンが表示されるようになった
  7. カスタムアラート機能
  8. Query API Key を作り直せるようになった
  9. アラート送信先から Hipchat が削除された
  10. 匿名利用データ共有

1. ドロップダウンで複数値を選択できるようになった

今までも {{}} を使って「パラメータ付きクエリ」を作り,さらに「ドロップダウン」と組み合わせて「候補を選択する」ことはできたけど,あくまで「1個」しか選択できなかった.例えば,以下のクエリだと {{CountryCode}} として JPN などを選択できるようになる.

SELECT *
FROM city
WHERE CountryCode = '{{CountryCode}}'
ORDER BY Population DESC;

なんと Redash v8 では「ドロップダウンから複数値を選択できる」ようになった.例えば,以下のように IN で複数値を検索する「パラメータ付きクエリ」を作れるようになる.

SELECT *
FROM city
WHERE CountryCode IN ({{CountryCode}})
ORDER BY Population DESC;

ドロップダウンを設定するときに,以下のように「Allow multiple values」という項目があり,3種類ある Quotation から選択できる.今回は IN に合わせるため Single Quotation Mark にした.

  • None (default)
    • value1,value2,value3
  • Single Quotation Mark
    • 'value1','value2','value3'
  • Double Quotation Mark
    • "value1","value2","value3"

f:id:kakku22:20191104002553p:plain

実際にクエリ画面を見ると JPNAUS など,複数値を選択し,クエリを実行できる.これは便利!間違いなく「パラメータ付きクエリ」の用途の幅が広がると思う.

f:id:kakku22:20191104002610p:plain

2. クエリ名を日本語で正しく検索できるようになった

今までは,メニューバーにある検索フォーム(Search queries...)でクエリ名を検索しても,マルチバイト文字に対応してなく,日本語の場合は期待した結果にならず,困っていたと思う.Redash v8 でマルチバイト文字に対応し,クエリ名を日本語で正しく検索できるようになった.ただし,デフォルトでは無効化されていて,Settings 画面で Enable multi-byte を有効化する必要がある.

f:id:kakku22:20191104002632p:plain

3. ダッシュボードがグリッド表示になった

ダッシュボードがグリッド表示になり,罫線を見ながらウィジェットを配置できるようになった.地味な改善ではあるけど,神は細部に宿る!

f:id:kakku22:20191104002650p:plain

4. データソース追加/削除

Redash はバージョンアップごとにデータソースを増やしている.Redash v8 では「計7種類」が追加されて,一部は削除となり「計49種類」になった.データソースの選択肢の多さは Redash を使うメリットになる.

  • 追加
    • Azure Data Explorer (Kusto)
    • Cassandra
    • Couchbase
    • Dgraph
    • JSON
    • Phoenix
    • ScyllaDB
  • 名称変更
    • GoogleSpreadsheet → Google Sheets
  • 削除
    • MemSQL
    • Url

5. データソース設定画面の UI 改善

データソース設定画面で「インクリメンタルサーチ」が使えるようになった.今までは全てのデータソースが並んでいた.バージョンアップごとにデータソースが増えているため,今後さらに増えることを考えると,価値のある改善だと思う.

f:id:kakku22:20191104002806p:plain

6. クエリ画面にデータソースのアイコンが表示されるようになった

クエリ画面で,データソースの左にアイコンが表示されるようになった.地味に良いと思う!

f:id:kakku22:20191104002821p:plain

7. カスタムアラート機能

Redash v8 を起動するときに,環境変数 REDASH_FEATURE_EXTENDED_ALERT_OPTIONStrue を設定し,Feature Toggle を有効化すると「カスタムアラート機能」が使えるようになる.今までも「アラート機能」はあったけど,例えば Slack にアラートを通知しても「アラート名」以外に情報がなく,迅速な状況判断には使えなかった.

そこで「カスタムアラート機能」を使うと,以下のように自由にテンプレートを定義することができ,カスタマイズしたアラートを通知できるようになる.ちなみに Description templateMustache フォーマットを使う.さらに「プレビュー機能」もあり,これは便利すぎる新機能!今回はサンプルとして「閾値」「実測値」をテンプレートに埋め込んでみた.

f:id:kakku22:20191104002838p:plain

実際に Slack に通知をすると,以下のように Description が追加されていた.定義するテンプレート次第では,今までよりも格段に情報量が上がるため,障害時の迅速な状況判断に活用できそう.

f:id:kakku22:20191104002852p:plain

8. Query API Key を作り直せるようになった

Redash v8 から Query API Key を作り直せるようになった.実際に API Key のダイアログを確認すると Regenerate ボタンがあった.

f:id:kakku22:20191104015451p:plain

9. アラート送信先から Hipchat が削除された

2018年の Hipchat 廃止に伴って,アラート送信先から今まであった Hipchat が削除された.

f:id:kakku22:20191104002904p:plain

10. 匿名利用データ共有

Redash v8 から「Anonymous Usage Data Sharing(匿名利用データ共有)」の仕組みが追加されていて,オプトインをすると,クエリ数など一部の利用データが Redash 運営側に送信される.今回 Redash トップページ下部にオプトインをするメニューが追加されていた.

f:id:kakku22:20191104002922p:plain

オプトインは Settings 画面から変更できるようになっている.

f:id:kakku22:20191104002932p:plain

まとめ

  • 2019年10月末にリリースされた「Redash v8.0.0」を試した 🎉
  • 個人的に気になった新機能と機能改善を「計10点」紹介した
  • 特に以下は目玉機能だと思う 👀
    • ドロップダウンで複数値を選択できるようになった
    • クエリ名を日本語で正しく検索できるようになった
    • カスタムアラート機能

Redash v7 紹介記事

kakakakakku.hatenablog.com

変更可能なコードを書こう /「レガシーコードからの脱却」を読んだ

9月に発売された「レガシーコードからの脱却」を読んだ.本書はサブタイトルに「ソフトウェアの寿命を延ばし価値を高める9つのプラクティス」と書いてある通り,変更可能なコードを書くための「原則とプラクティス」に対する理解を深めることを目的にして書かれている.よって,意図的に抽象度は高くなっていると思う.実際に読んで,そう感じた.

原著の著者 David Scott Bernstein は IBM などでソフトウェアエンジニアのトレーニングを担当されてきた方で,そのエピソードも本書に多く出てくる.そして「認定スクラムデベロッパー研修」の講師で来日されることもあるらしく,気になる!来年研修を受講する予定なので,開催予定を調べてみようと思う.

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

  • 作者: David Scott Bernstein,吉羽龍太郎,永瀬美穂,原田騎郎,有野雅士
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2019/09/19
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る

目次

  • 第I部 : レガシーコード危機
    • 1章 : 何かが間違っている
    • 2章 : CHAOSレポート再考
    • 3章 : 賢人による新しいアイデア
  • 第II部 : ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
    • 4章 : 9つのプラクティス
    • 5章 : プラクティス 1 : やり方より先に目的、理由、誰のためかを伝える
    • 6章 : プラクティス 2 : 小さなバッチで作る
    • 7章 : プラクティス 3 : 継続的に統合する
    • 8章 : プラクティス 4 : 協力しあう
    • 9章 : プラクティス 5 : 「CLEAN」コードを作る
    • 10章 : プラクティス 6 : まずテストを書く
    • 11章 : プラクティス 7 : テストでふるまいを明示する
    • 12章 : プラクティス 8 : 設計は最後に行う
    • 13章 : プラクティス 9 : レガシーコードをリファクタリングする
    • 14章 : レガシーコードからの学び

既に正誤表も公開されている.読んでいて気付いた誤植はほとんど載っていた.あと1箇所気付いたので,記事の最後にメモ程度に残しておく.

www.oreilly.co.jp

9つのプラクティス

本書の軸は,当然ながら「9つのプラクティス」だけど,Extreme Programming (XP) を中心に以下のように構成されている.

  • プラクティス 1 : やり方より先に目的、理由、誰のためかを伝える
  • プラクティス 2 : 小さなバッチで作る
  • プラクティス 3 : 継続的に統合する
  • プラクティス 4 : 協力しあう
  • プラクティス 5 : 「CLEAN」コードを作る
  • プラクティス 6 : まずテストを書く
  • プラクティス 7 : テストでふるまいを明示する
  • プラクティス 8 : 設計は最後に行う
  • プラクティス 9 : レガシーコードをリファクタリングする

そして本書に載っている読者層は以下の5種類で,僕自身は当てはまる.ただし,過去の開発経験と今まで読んだ関連書籍の知識もあり,本書の内容で既知に感じる箇所も多かったので,新しく得られた知識は少なかったように思う.ただし,改めて理解を整理できたという側面でメリットを感じた.

  • ソフトウェア開発者
  • ソフトウェア開発と IT のマネージャー
  • ソフトウェアの利害関係者
  • さまざまな業界のプロダクトマネージャー,プロジェクトマネージャー
  • この欠くことのできない技術に興味を持つ人すべて

今回の書評記事では,個人的に本書を読んで印象に残った「プラクティス」を紹介しようと思う.

完了の完了の完了

「プラクティス 3 : 継続的に統合する」では,コードを書くたびに統合することの大切さを学べる.例えば「継続的インテグレーション」「継続的デリバリー」など,よく知られたプラクティスの軸になる考え方となる.この「統合された状態」を表現する言葉として「完了の完了の完了」と書かれていて,センスの良さに驚いた.確かに「ローカル環境でビルドができた状態」「完了」と表現する人も過去にいたし,今後も積極的に「完了の完了の完了」という表現を使おうと思う.

ブランチを避ける

「プラクティス 3 : 継続的に統合する」に載っている「リスクを減らす7つの戦略」の中に「ブランチを避ける」という内容もある.統合されるまでリスクに気付けないので,ブランチを使わずにフィーチャーフラグを使うと書いてあり,まさに先週あたりから議論が巻き起こっていた話題に関連している.

irof.hateblo.jp

スパイク

「プラクティス 4 : 協力しあう」では,質の高いコミュニケーションを作り上げるために協力し合う(協働する)ことの大切さを学べる.ペアプログラミングをしたり,モブプログラミング(モブワーク)をしたり,個人的にも強く意識して実践と推進をしているスタイルなので,共感できる点ばかりだった.

そして「スパイク」という用語は今まで使ったことがなく,新鮮だった.簡単に表現すると「未知の課題に対して技術的な調査などを行うこと」と表現できる.実は書籍「アジャイルコーチング」にも「スパイク」が出てくるので,界隈ではよく知られた用語なのかもしれない.

アジャイルコーチング

アジャイルコーチング

カンファレンスをすっ飛ばす

さらに「プラクティス 4 : 協力しあう」の中に「知識を広げる」というテーマもあり,そこに「カンファレンスに行ったら,カンファレンスをすっ飛ばし,友達を探してペアリングするべし」という面白いテクニックが紹介されている.確かに「カンファレンスに行ったら廊下で話すべし」という話もあるし,著者の素晴らしい体験談から学べるのも本書の魅力かなと思う.今年はほとんどカンファレンスに行ってなく,久し振りに行ってペアリングしたいぞ!

誤植

10.6「テスト可能なコードを書く」の最後に以下の文章があり,文脈的には「トレーニング "で" 教えたり」だと思う.

ブログを書いたりトレーニングを教えたりするには、十分な休憩と大量のカフェインが必要だ。

まとめ

タイトルに惹かれて「レガシーコードからの脱却」を読んだ.最初からレガシーコードを作り出さないように「どんなマインドセットを持っておくべきなのか」という原則とプラクティスを学ぶことができる.黙々と読むよりも,チームで輪読をして,ディスカッションを組み合わせるとより効果が高そうな書籍だと思う.個人的には今まで読んだ関連書籍の知識もあり,書評にまとめたプラクティスに偏りはあるけど,それでも理解を整理できたという側面でメリットを感じた.

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

  • 作者: David Scott Bernstein,吉羽龍太郎,永瀬美穂,原田騎郎,有野雅士
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2019/09/19
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る