[2021年8月号] Software Design(技術評論社) サマリー+個人メモ

Software Design の2021年8月号について、

ざっくり内容紹介
個人的に気になった記事やポイント

をまとめている記事です。

サマリー記事の一覧はこちら。

特集①：もう怖くない React 3つの壁とその超え方
特集②：GraphQLでかなえる効率的なデータ通信
Extra Feature
Development
OS/Network
そのほか
Software Design 2021年8月号

特集①：もう怖くない React 3つの壁とその超え方

どうでもいいけどやっぱりReactって怖がられてるのか…ｗ
なぜReactが選ばれるのか
- 仮想DOMというDOMの設計図を元に宣言的にUIを記述できること、が良い
- HTMLの超宣言的な書き方と、JSおよびjQueryのような命令的な書き方のハイブリッドという説明がよさそう→これがJSX
- 差分描画：勝手に差分検知して必要なところだけ描画してくれる。Flutterと同じやね。
  - 差分検出アルゴリズムは「リコンサイラ」という
- これまでだとHTMLという文字列的なファイルをパースして解析する必要があったのでこのような高速な処理が無理だったが、JSXにはJavaScriptオブジェクトとして書かれているものをそのままJSとして実行できるから速い
  - 複雑な操作フローがあるページでは断然ラクに、そしてバグも減る
    - 例えば「ローディング中は多くのボタンが一時的に無効化される」みたいなシーンでとても恩恵がある。
- 実際のフロントエンドのイメージ
  - 純粋なReactアプリでは、ほぼ空のHTMLでindex.jsというのが読み込まれているだけ。下手するとCSSすらもここに入れることがある（CSS-in-JS）。
  - このindex.jsにはReact本体や関連ライブラリ、自分が書いたコードなど全部入っている。これを「バンドル」と呼ぶ。
  - 実際はこれだとスクリプトが読み込まれるまで真っ白になってしまったりするゆえ、ここで初めてSSRなどの話が登場する
- ここで気になるコラム「Vue.jsとのうんたら」みたいなのがあった
  - 「とても似ている」としている
  - Reactはシンプル、Vue.jsはイージー、だそう
    - これはイメージ通り（シンプルの表現がちょっと分かりにくいけど、まあ律儀な分応用が効きやすいということで合ってた）
- SPA
  - これのおかげで従来の「フロントは画面やUI、バックはデータ保存など」という棲み分けがWebにももたらされ、フルスタックなWebアプリケーションフレームワークではなくAPI特化型の軽量なフレームワークなどが流行ってきた
ちょっと色々あって以降の実装例系の章はメモを消し飛ばしたのでカット。

特集②：GraphQLでかなえる効率的なデータ通信

「モダンなWebアプリケーションのために設計ｓれた、Web API上で動くクエリ言語とエンジンの仕様」
APIに求められているものが変化してきた
- 遅延が特に課題→通信回数も減らしたい
- REST APIは単一のエンドポイントしか持たないので複雑なリクエストに答えづらい
- これらのおかげで最終的にはエンドポイント自体が無限に増えていくことになる
ここでGraphQLが登場する
- クエリ言語：クライアント側で作るもの。ユースケースという。
- 型システムとスキーマ：事前にデータモデリングがされており、それに則る形になる。
- 実行エンジン：クエリ言語とスキーマをもとに、実際のロジックの実行などを行う。スキーマ上の型やフィールドと一対一になるようなロジックを実装する
サーバー側のGraphQLの実装は大きく2通り
- ライブラリの利用
- GraphQLのプラットフォームを利用する
  - AWS AppSyncがGraphQL as a Serviceらしい。フルマネージド。
クライアント側は「Apollo Client」か「urql」というのがおすすめとのこと。

Extra Feature

今回からこのカテゴリを新設。でも内容は特になし。

Development

イラストで明解Gitコマンド「git rebase」
- 挙動をしっかり理解できておらずわりと腫れ物に触るように扱ってきたのでこの機会にちゃんと読んでおく（改めて思ったけど名前の印象による勘違いを招きやすい）
- mergeと同様、「コミットをまとめるもの」
  - mergeとの違いはマージ用のコミットが生成されるかどうか。rebaseだとマージ先のブランチにマージ元の最後のコミットがそのまま自然にくっつく感じ
- 注意点は「rebaseは基本的に既存ブランチの改ざんになる」ということ。正直やっぱりよく分かんなかったけど（爆）、普段はあまり使わないようにしようみたいなニュアンスで書いてあったのでこれまで通り使わない方針でいいのかもしれない。
Pythonモダン化計画「レガシーな大規模システムをどうリファクタリングするか」
- とても現実的な課題でありつつもなかなか実例を見ることができないが、この記事ではモノタロウのECサイトが色々ヤバいということで題材にしていた
  - ヤバいのは2002年から独自開発をし続けてしまったかららしく、フレームワークもオリジナル、業務ロジックと画面ロジックの混在、テストが自動化されていない、などかなり大変そう。ちなみにあるシステムは1400ファイルで25万行もあるとのこと。そんなになるか…？？？
- まずリファクタリング対象を決めるため、Gitコミット回数と複雑度で四象限に分けて抽出を行った
  - 複雑さの取得にはPythonのradonというツールを使ったらしい。これ自分の色んなものでやってみたくなるね
- 今回はユニットテストがフォーカスされた
  - unittestではなくpytestで進めることにした
    - 一番差を感じたのはassertの式が分かりづらいということ。たしかに！
    - これまでunittestで書いてしまった部分もpytestは普通に実行できる
  - モックの話
    - なんか思ってたのと違くて単体テスト論の話ばっかりになってる…笑
    - そして奇しくも最近自分も時間をかけたところだったのでまあいいかなという感じ

OS/Network

systemd詳解
- 気になる記事だったけど第3回目だったらしい、前回と前々回全く気付かなかった…。
- 読んではみたものの要点を書き起こすのが難しい、これは中身も難しいということなんだろうか（適当）

そのほか

ITエンジニア必須の最新用語解説「Terraform」
- IaC化のためのプロビジョニングツール
- HCL（HashiCorp Configuration Language）で書く
- AWSでしか使ったことないけど、GCPはもちろんAzureもサポートしている
- コアとプロバイダという大きく2つのコンポーネントで構成される
  - コアは現在のインフラの状態と今回書いたコードとの差分チェックなどをし、実際に作成・更新・削除のような一連のプロセスを行う。たぶんterraform planとかapplyのことと思われる
  - プロバイダはAWSなど各クラウドサービスごとに用意されているプラグイン形式のモジュール。コアから呼び出されてリソース管理などを行う。サードパーティ製のプロバイダも存在する。
- 実際のインフラ構築作業は次の4段階
  - init
  - plan
  - apply
  - destroy
  - 実際にこの4つくらいしかたぶんコマンド知らなかった気がするけど、本当にこれが核となる機能だったのね