未経験から4年目に至るまでに読んだ本・やったことをまとめてみた
自分が未経験の頃から今までの間に読んだ本を列挙してみました。
いわば、自分がエンジニアになるまでにやってきたことの足跡の様な感じです。
「これからエンジニアやっていくぜ！」って方と出会って「やっていこうぜ！！」って話すことが多いのですが、そういった人向けの参考になればなと。 ここに載せた本は全部、自分がコードを書ける様になったり、作業の質が上がったりしたキッカケの本です。
バックボーン
文系卒で心理学・社会学系を触っていました（学んだとは口が裂けても言えない。）
比較的、数学が好きだったので元々の適正や素養自体はあったかもしれませんが、プログラミング経験は皆無です。
ただ、エンジニアになるとは微塵の「み」も思ってませんでした。
未経験期
progate でコードを書くのに慣れつつ、ITパスポートを勉強して良い感じにIT系の言葉を知るっていう感じでしたね。
仕事でお供したことがある方が「新人はまず言葉に慣れることが大事」と教えてくださっていて、今振り返ると丁度それを独学でやっていたのかなと思いました。 たまたまですが、今振り返るとわりとスジの良い入り方でしたね。
progate も IT パスポートも「これで〇〇が出来るようになりました！！」ということは無いけど、最初に取り組んでいたからこそ色々なことに抵抗無く取り組むことが出来たので、もしもこれからエンジニア興味あるかもって人は触れてみると良いかもしれません。
1年目
懐かしの研修期間。
しこたまインプレス社にお世話になりましたね。 研修受けて、ガガガッと Java について勉強して、java silver 取って〜みたいな感じでした。
とにもかくにもプログラミング言語が書けるように〜〜！！って感じ。
「常識として知っておきたいプログラムのしくみ」は当時お金がなかったので図書館で勉強できる本を探そうと思って手に取った本でした。
僕はどうにも配列や文字列の振る舞いが理解できなくて詰まっていたのですが、この本を通してメモリレベルの話の概要を知ることでようやく理解する事が出来たので読んで良かったと思っています。
本にコーヒーこぼして、図書館に新品買って返したところまで良い思い出。
後は Angular と出会ったのもこの時期ですね。 大事なことは全て Angular から学びました。バイブルですね。
2~3年目
2年目はあんまり本呼んでなくて、ひたすら Angular 周りの記事やフロントエンドのアーキテクチャについて調べてました。 しこたま lacolaco さんや 奥野さんのスライドを読み漁ったりなんだり。
ただ、その少ない読んだ本の中でもかなり重要なのはプリンシプルオブプログラミングとTDDの本ですね。
特にTDDを知ってから本当にコードの書き方・考え方・仕事の仕方が変わりました。
個人的なおすすめ度で言うと、ナンバーワンかもしれない。
TDD は一つのスキル・コーディングスタイルだと思うので、コーディングに悩む人は一度手にとって見ると良いと思っています。 TDDに限らず xxxx駆動開発系のワードは開発プロセス全体の事の様に思われがちかもしれないけど、実際はシステム開発する上での一つの方法論・スキルだと思っていて、日頃の仕事に活かせる考え方や技術がいくつもあるのでハマってみるとおすすめです。
4 年目
これは直近読んだ本の羅列ですね。。。笑
DDD 関係の本ばっかりですね。
DDD をやってみたい！！というよりは自分にとって一番興味が持てて且つ有用な知識のありそうな分野だったので、ガッツリ読みまくっていこうかなとスタイル。
（僕もわかっていないので観測範囲の認識ですが）DDD 界隈をウォッチしていると色々ありますが、そもそも根幹にある「ドメインに目を向けてよう」っていうことはソフトウェア開発における一番普遍的なことなので触ってみると良いかなぁと思っています。 なので、値オブジェクトやエンティティは開発の How の部分で、実際に適用するかどうかはケースバイケースだと思います。
とにもかくにも、興味駆動でガンガン読んで、その中で普遍的なことや応用の効く考え方をたくさん読んでいけたら良いなと。
その他
話の流れ的にここに持ってきたのですが、フロントエンドエンジニアとして、もちろんこの辺も読んでました。 デザインの4原則あたりの知識は、最低限の教養として押さえると良いことだと思っています。
後、この辺の本とかも。 意味がわかって実践できるようになりつつあるのが最近なので大変恥ずかしいですが、それでも当時読んで自分の行動改善が進んだので一応ご紹介。
まとめ：振り返りとこれから
改めて振り返ると今の自分がどう出来上がってきたのかが俯瞰出来て良いですね。 まだまだ道半ばなのですが、こうやって振り返ると色々勉強したし、スタート地点からはだいぶ遠いところに来たな〜〜〜
ネットワーク・サーバー・インフラ周りは知識薄いし、アルゴリズムも激弱で課題だらけっすけど、興味持てるところで強み持っていきたいかなぁ。
この記事が何らか道標や参考になればな〜とか、話のネタになればな〜と思いつつ、今後も頑張っていきたいですね。
『事業分析・データ設計のためのモデル作成技術入門』を読んだ感想
『事業分析・データ設計のためのモデル作成技術入門』を読み終わった。
元々、フロントエンド・小規模のアプリ開発からエンジニアキャリアをスタートして今日に至るので、どうにも「モデリング」の様なレイヤーの話に疎く、衝動買い基礎的な知識を学ぶ為に購入。
結論から言うと、自分から読みたいと思うぐらいに面白い内容で、非常に読んで良かったと感じている。
（デファクトスタンダードなやり方ではないのは承知だが）
数学の理論や手続きに則って「誰がやっても同じモデル図が出来る方法論・技術」がまとまっていた。
以下、簡単な感想をつらつらと。
徹頭徹尾、数学の話だった。
本の中ではいわゆる Entity という言葉が出てこなく、全て集合や元など数学に基づいた考えに基づいてモデル分析をしていく手法がまとめられていた。
大まかには以下の通りの様な話が展開されている。
- 事業上登場する事柄は全てモノ（事態・事物）として扱う
- 事業活動は５種類に分類され、それに対応する5種類の管理業務がある
- 管理業務上、管理したい事柄には必ず識別子が存在する
- その識別子ごとに正規化したモノを作り、Event（日付を基に並べることができるもの）Resource（辞書的な規則に則って並べられるモノ）に分類する
- それぞれのモノの関係を基に文法・論理規則に当てはめて成り立つかどうかを関係論理に基づいて図式化していく（合わせて、実務に合わせた知識・補足がされている）
完全に定義・概念・計算方式が確立されていてモデルの作成にエンジニアの解釈が必要無く、誰がやっても同じモデル図になるとのことだった。
また、曰く出来上がったモデル図はそのまま DB 設計に置き換えても動くとのこと
（INDEX ONLY, ADD ONLY で DB 作成する。著者の経験＋観測範囲ではパフォーマンス問題に出会ったことがないらしい。）
これだけ聞くと魔法の様な話だが、実際にその関係式が充足されるのか否かを判断・判定する必要があるから完全に属人性が排除される訳ではない。実際の業務知識が無いと正しい図は作れない。 それに補助資料も多いので相応のコストもかかる印象だった。
ただ、この本に書いてある知識・考え方は普遍的なものだと思うし、直接この方法で分析・設計を行わずとも役に立つ知識だったなぁと思う。 （迷惑かからない小規模アプリを作ることがあれば、試してみたいなと思う。）
「構文論が先で意味論が後」
上記の数学の話と被るが、書籍の中で繰り返される「構文論が先で意味論が後」という話が凄く印象的だった。
まず「文法・論理規則・関係（関数）として正しいか否か 」が常にあり、「真とされる値が本当に充足されるかどうか。」は後から判断する、という話。
例えば、R(受注, 発注) の関係は支払い請求、R（発注、受注）は先払い、R(受注, 発注) も R（発注、受注）も論理的には成り立つけど事業上存在するかは別な話だよね、という感じ。
本当に知識ゼロと言っていいぐらいの身としては、これぐらい形式だった手法を学べるのはありがたいなぁと思った。
事実：情報は1:N、情報:モデルはN:1
数学の写像の話に基づいた説明をされて「なるほど」となった。
1:N 関係は関数（写像）にできないけど、N:1関係は関数に直せる、という話。
今よりももっと何も知らなかった頃は「Entityって実体だよな、実体を1:1に表す、、、訳ではないけど、どう解釈すれば良いんだ？」という疑問が絶えなかったので、ようやく一番論理的な理解が得られた。
そもそも「Entity は ID を基に同一性を判断できるオブジェクト」って定義でもあると思うので、改めて全然とんちんかんな疑問を抱いていたなぁとも気づいたり。
総じて自分は相性が良かったし、相性が良さそうな人にはオススメ
繰り返しになるが、DB の設計手法として使うかは別として、モデリングや事業分析の為の普遍的な考え方・基礎知識を学べる書籍として本当に良かった。
色々とモデリングに対する誤解が解けたり、正しい知識が得られたと思う。
もう一週ぐらい読み直して、自分に定着させたい。
また、相性が良くない人は全然受け付けないと思うが、相性の良さそうな人は凄くしっくりくると思うので是非オススメしたい。
ところどころ、数学や哲学、ないしはコッド先生の話など歴史の話題が多かったり、今の手法にたどり着くまでの悩みなどもあるが、その辺りの癖を掴むと非常に読みやすいと思うのでご興味ある方はご参考までにどうぞ。
Container / Presentational Pattern について
Container / Presentational パターンはコンポーネント設計や責務分担を考える時に役立つデザインパターンだと思います。
フロントエンド始めたての方なんかは是非学んで欲しいパターンだなぁと。
なので、最初に自分が理解する為に呼んだ記事や勘所等をまとめたいと思います。
Container / Presentational パターンとは
概要
コンポーネントを以下の2種類に分類して実装するパターンのこと
...と言われても、こういう概念はサンプルコードが無いと意味がわからないと思います。
なので、イメージを掴みやすいように参考例を作成してみました。
サンプルコード
個人的に一番わかり易い事例はモーダルダイアログだと思います。
仮に「外部APIから取得したデータを表示する」「送信ボタンを押した際にAPIへ何らかの値を送信する」 という処理を持ったモーダルダイアログがあるとします。
その時、もしもモーダルダイアログに全ての処理を実装すると以下の様になってしまいます。
const ModalDIalogComponent = () => { const [content, setContent] = useState(); useEffect(() => { /* 外部APIから表示する値を取得する const val: any = "何らかの値"; setContent(val) */ },[]) const onSubmit = useCallback(() => { /* * APIの送信処理など */ },[]) return ( <div className={"モーダルダイアログに関するCSSクラス"}> <span> {props.content} </span> <button onClick={onSubmit}>送信</button> </div> ) }
かなりツッコミどころのある事例ですが、これが「見た目に関するロジックと振る舞いに関するロジックが混在している状態」です。
今、このコンポーネントには「モーダルダイアログのスタイリング」「データを取得する処理」「APIを送信する処理」などが記述されています。
API を送信する処理は見た目に関係ありませんし、データを取得する処理自体は直接見た目に関係しているわけではありません。
なので、このコンポーネントから見た目に関するロジック以外を取り出し、親コンポーネントに処理を委譲してみます。
type Props = { content: string; onSubmit: () => void; } const ModalDIalogComponent = (props:Props) => { return ( <div className={"モーダルダイアログに関するCSSクラス"}> <span> {props.content} </span> <button onClick={props.onSubmit}>送信</button> </div> ) } const PageComponent = () => { const [content, setContent] = useState(); useEffect(() => { /* APIやLocalStorageから表示する値を取得する const val: any = "何らかの値"; setContent(val) */ },[]) const onSubmit = useCallback(() => { /* * APIの送信処理など */ },[]) return ( < ModalDIalogComponent content={content} onSubmit={onSubmit}></ModalDIalogComponent> ) }
モーダルダイアログ側のコンポーネントは親コンポーネントから受け取った値を表示し、受け取ったコールバック関数を実行するだけのコンポーネントになりました。
元の状態の場合、別な API から値を取得したくなった時、類似のコンポーネントを作るか、モーダルダイアログを拡張する必要があります。
しかし、親コンポーネントから受け取る props に応じて振る舞いを変更できる様にすることで、そのまま再利用することが出来るようになりました。
こうして「見た目に関するロジック」「振る舞いに関するロジック」の観点でコンポーネントを分割するパターンをContainer / Presentational パターンと言います。
理解する為の勘所
僕がこのパターンを理解する為に必要だった勘所が２個ありまして、それぞれまとめていきます。
Pure Container よりも Pure Presentational を意識する
完全にロジックしか持たないピュアな Container Component よりも 完全に見た目に関するロジックしか持たないピュアな Presentational Component を目指してみると理解が捗ると思います。
二分割する一方のみに注視した方がわかりやすいですし、ロジックの複雑さ的にも Presentational 側の方がわかりやすいです。
なので、最初は大きい粒度でコンポーネントを作り「ここ共通化出来るかもな〜」「流石にコンポーネントが大きくなってきたな〜」と感じ始めた時にコンポーネントを切り分けていく内に、自然と Container / Presentational な関係になります。
また、最初からキレイに分割することは難度が高い上に、早過ぎる最適化になりやすく、無駄にもなりかねません。
デザインや仕様が固まりきっていない内は無理にチャレンジしないほうが得策かなぁと思います。
とどのつまり「責務分担」
そもそも「見た目と振る舞いに関する関心をわけること」とはすなわち「責務分担を考えること」ということです。
このパターンの名付け親の Dun 氏も「Reactを長くやっているのであればおそらく既に発見していることでしょう」と述べています。
なので、恐らく多くの開発者がコンポーネントを分割するにあたって責務を考えた時に自然に辿り着く様なことだと思います。
というわけで、そもそもそのコンポーネントが行うべき処理や責任範囲を考えて分類してみよう、という観点でもう一度見つめ直してみるとしっくり来ると思います。
で、何が嬉しいの？
ざっくり箇条書きにすると、
- 可読性の向上
- テスト容易性の向上
- Storybook の導入のしやすさ
- etc...
といった感じかなぁと思います。
とどのつまり「責務を考えよう」というお話なので、コーディングスキルの向上やテスト容易性の向上に繋がるのかなぁと。 後は、特に Storybook なんかを使いたい時は、チームの共通認識として持っておかないと破綻しかねないかなぁと思います。
あとがき
というわけで、Container / Presentational Pattern についてまとめました。
少し古いかもしれませんが、自分の理解の言語化＋ちょこちょこReact教えて！みたいな話されるので説明用の資料になれば良いなぁという感じですね。
後、書いていて思ったことですが、フロントエンドに入門して一番興味が湧くことの一つがコンポーネントの分け方だと思うので、そこに責務分担を絡めて学べたらゆくゆくの成長に繋がったりするのかなぁと。
なので、やっぱり基本的な考え方として抑えておくことは今からでも結構、有用なのかなぁと思います。
余談：初出
Redux 作者の Dan Abramov 氏の記事が初出です。（調べる限りは間違いないはず。）
著者本人は「Hooks の登場によって必ずしもこのパターンが最適ではなくなった。コードベースで自然だとわかった時は便利なパターンではある。」(意訳)としています。
また、記事の締めで「このパターンを dogma (教義) としないで」とも述べていて、この２つのコンポーネントは必ずキレイに分かれるものではなく、分割が難しい場合もあるとつけくわえています。
参考リンク
【覚書】お試しでスクショ自動化＋ diff 比較（簡易VRT）をやってみた
目的
- ビジュアルリグレッションテストに興味があった。
- お試しでスクショ自動化と diff 比較をやってみたので振り返りと覚書をまとめる。
やったこと
- pupetter でローカルホストにアクセスしてスクショを撮る。
- lookSame で取ったスクショを比較する。
- 出来栄えを見て喜ぶ。
使用したライブラリ
puppeteer
Google 製のヘッドレス Chrome を操作するライブラリ。
類似ツールの Cypress 等との違いは、Google 製且つCDP (Chrome DevTools Protocol) 準拠の為、Chromeとの親和性が高いことが特徴。
looks-same
パット見使いやすそうだった為、採用。
github.com
わかったこと
- 一度経験すればサクッと作れる様になりそう。
- 実装量は少ない。かけた時間のほとんどが記法の調査だった。
- もしも知識ゼロで作る場合、ハマりどころは「スクショしたい画面の描画を待つためにスリープ処理が必要」ぐらい。
- 何か簡単なツールを作りたい時の心理的な抵抗感って数時間で済むような学習コストで減るんだなぁと体感。素振り大事。
- もしも実運用する時に考慮することは以下の事が懸念事項かも。
- スクショデータの管理と正解データの更新方法。
- 差分検知をどれだけ厳密にするか。何故か puppettier のスクショにピクセル単位のズレが出る時があり、厳密にしすぎると落ち易すぎる印象。
- どこまで画面を操作するか。操作数が増える = テストが壊れるリスクの増加 or メンテコストの増加。
ハマったこと
- スクショ結果が不安定 同じ画面を同じ状態でスクショしていたにも関わらず、若干の差分やズレが発生した。 おそらく自身の端末の性能（最近、メモリの圧迫によって動作不安定。。）に起因していると思われる。
さじ加減が難しいが、looks-same が許容する差分の閾値を調整してOKということにして対応した。
次にやりたいこと
- 他の diff を取るライブラリを試したい。ぱっと見つかるのはこんな感じ。
スター数は他のライブラリに劣るが、機能の豊富な reg-suit を試してみたい。
GitHub - reg-viz/reg-suit: Visual Regression Testing tool
GitHub - mapbox/pixelmatch: The smallest, simplest and fastest JavaScript pixel-level image comparison library
GitHub - uber-archive/image-diff: Create image differential between two images
実装メモ・サンプルコード
コードのイメージを記載しました。 思ったよりも実装量が少ないことが伝われば良いなと。
トグルにまとめました。
スクショ自動化
実装したコードの一部。
puppeteer を起動して、ログインして、画面遷移してスクショするだけ。
全体で約100行ぐらいで、そんなに時間がかからなかった。
const main = async () => { const { page, browser } = await initPuppeteer(); await login(page, { loginUrl: LOGIN_URL, username: USER_NAME, password: PASSWORD, }); await screenShotPages(page); await browser.close(); }; const screenShotPages: (page: puppeteer.Page) => Promise<void> = async ( page: puppeteer.Page ) => { for (const path of PATHS) { const url = `http://localhost:4200/${path.path}`; await page.goto(url); await sleep(12_000); await screenShot(page); } };
diff 作成
実装したコードの一部。全体では大体120~150行ぐらい。
ファイルパスを渡すだけで比較・比較結果の画像を作成してくれる。
ファイル移動やディレクトリの存在チェックの方がよっぽど面倒だった。
// reference と current にファイルパスを渡すだけで比較してくれる。 function checkDiff( reference: string, current: string ): Promise<LooksSameResult> { return new Promise((resolve, reject) => { looksSame( reference, current, { tolerance, }, (error, result) => { resolve(result); } ); }); }
【はじめてのIT勉強会】「テストがキッカケで成長した」というLTをしてみた。
先日のはじめてのIT勉強会のLTで発表した内容をブログにしたものです。
この記事で書くこと
- はじめてのIT勉強会でLTしてきた感想
- 久しぶりのオフライン勉強会の感想
発表スライド
発表用のイラストなどを少し減らしています。
LT の意図
- プログラマーとしてのコードの悩みが減った自分の体験をシェアしたい。
- 文卒・未経験の人が成長する一つのケースとしてシェアしたい。
自分の実体験
コードが書ける様になると「どう書けばよいか」「何を正しいのか」に悩むことになるものだと思います。
特に自分の場合「何が正しいコードであるか判断する基準」を作れなくて、実装の手が止まることが多かったですね。
色々試してみていてRealworld Example (様々なフレームワークで実装されているサンプルアプリ) や AWS Amplify の npm ライブラリの実装をかいつまんで読んでは自分なりの実装パターンを身に着けたりしていったのですが、
グッとレベル感が上がったのはテストコードを学んで実践した時でした。
（逆にあんまり考えてない時は成長していなかったですね。その分は伸びしろということにしましょう。）
「テストしやすさ」にはベストプラクティスが詰まっていて、テストしやすいコードには一定の正しさが存在しています。
なので、テストコードと向き合ったことが一つ壁を破れたキッカケだったと思いますし、それを今回は一つの体験談としてシェア出来ればなぁという次第でした。
テストコードを書ける職場で無くとも是非、調べてみてください。
若手・中堅の人のモチベや成長の一助になれば幸いだなぁと思います。
質とスピードは比例しますし、良いコードを書けることには価値があると思うので、やっていきましょう。
余談
「好きな話させてもらうし1000円払ったろ！！」と思って有料枠で申し込みました。
元のスライドの大枠を作りリハをした所、序盤の序の部分で5分をオーバーし、30分くらいかかりそうだと判明しました。
宇宙猫になりましたね。
という訳で、その分のネタはこれからブログで書いていこうと思っています。
もし良かったら読んでください。
ソフトウェアデザイン 2022年3月号の「そろそろはじめるテスト駆動開発」を読んでみた。
ポッドキャストを聴き、そのままの勢いで Software Design 2022年3月号 を購入し、読んでみました。
第１章はポッドキャストや t_wada さんのブログにもある通り、
「自動テスト・テストファースト・テスト駆動開発」x「利点・注意点」
の６象限についてまとめてある非常に内容のギュッと詰まった記事でした。
第２，３章にはJest を用いた環境構築・TDDの手法などがまとめられておりました。 テストの種類・考え方・現場で実践する為のコツについても触れられていて、こちらも濃密。 (Jest 書きたい。。)
今、自分にとって「やりたいこと、興味あること、必要なこと」が自動テストの領域だったので、より詳しく言語化出来て良かったなぁと思いました。
総じて、非常に学びが多かったので、買って良かったなぁと思いました。
感想・気づき・学んだこと
雑誌本編の話や具体的な知識には触れないので、雑誌やポッドキャストを是非聴いてみてください。
無料公開のポッドキャストの内容の範囲での個人的な気づきの一部だけ。
自動テスト・テストファースト・TDD にまつわる認識のズレ
t_wada さんが執筆動機にもあげているそれぞれの言葉の定義について。
実際に僕も人と話す時に認識がズレてたことがあったので、しっかり言葉の意味を揃えられた方が良いなぁ。
ちなみに、個人的にTDDは「コード書く前にはちゃんと設計や仕様を考えた方が良いよね」ということを体感できるから凄く良いと思ってます。
テストを書くに限らず、それがしっかり出来ている時はPRが通るし、それがしっかり出来ていない時はPRが通らない。
テストとソフトウェアの変更容易性について
ポッドキャストで登場する「Testing」「Cheking」っていう概念は、ソフトウェア開発に自動テストが必須な理由を言語化する為に必要な言葉だなぁと思いましたね。
後、これはどちらかというとDDDの文脈からの気付きなのですが、
理想的に言えば最初から「変わらない重要な処理」を見つけモジュール化して、「常に検証可能な状態」に置くことが出来れば良いのかなぁと。
ドメインモデリングはそういった状態を目指す為の設計手法という解釈ですね。
自動テストの質について
より質の高い自動テストを回そうとするとチームの問題に発展する、と思い至りましたね。
知り合いが、設計の話がチームビルディングの話になり、チームビルディングの話が組織論の話になる、言っていたけど、ここが入り口なのかと。。笑
他にも様々学びや知識・気づきがありましたね。
知らなかった語彙
- テスティングトロフィー
- 原著はここみたいなのでまた今度読む。
https://kentcdodds.com/blog/the-testing-trophy-and-testing-classifications - E2E, インテグレーションテスト、ユニットテストに加えて、コードの静的解析もテストに含んでいる。
- 原著はここみたいなのでまた今度読む。
まとめ
ラーメン食べながらポッドキャスト聴いたのが購入のキッカケだったので、ラーメンを食べて良かったなぁと思いました。
これからもこまめにラーメンを食べたいと思います。
それはそれとして、
以前参加した TDDBC に参加して TDD に触れたことが自分のコードが良くなるキッカケ、コードへの悩みを解決するヒントが得られた機会でした。
なので、同じ様に悩んでいる人は是非、TDD に触れてみてくれたら良いなぁと思います。
【AWS Amplify】AWS Amplify を推したい。(2021年以降の気になるアップデートのまとめ)
先日のはじめてのIT勉強会のLTで発表した内容をブログにしたものです。
この記事で書きたいこと
- AWS Amplify は小規模・プロトタイプ開発向けではなくなってきている。
- かなり強力なアップデートがされており、今後も要チェックのサービス。
- AWS Amplify の様なサービスが普及した時、一人のエンジニアが持てる役割はより大きくなりそう。
以前の AWS Amplify
僕が最初に触れた 2018年頃はプロトタイプ・小規模開発向けという位置づけだったと記憶しています。
(トップページも更新されてしまい、当時のソースは見つけられませんでした。。)
ただ、実際に当時は Amplify の管理するリソースをカスタマイズ出来ない、データベースは DynamoDB しか選べない、などの制限が多くプロダクトとして利用するの際の拡張性・柔軟性に欠けるという印象でした。
最近のアップデートが激アツ
そんな Amplify ですが、2021年あたりのアップデートから非常に機能が強化されていました。
細かいことも含めつつ、いくつかのアップデートをピックアップしてご紹介していきます。
CI/CD のサポート
GitHub と連携したCI/CDをサポートがされました。
元々CLI ベースのデプロイ機能はありましたが、GitHub Acitons などを自身で設定せずに CI / CD 環境を構築出来る様になっています。
AWS Amplify がフルスタック CI/CD 機能を新たにローンチ
AWS CDK によるカスタマイズに対応
Amplify のネックだった Amplify CLI 未対応のリソースを管理することが出来ます。これは激アツ。
Extend Amplify backend with custom AWS resources using AWS CDK or CloudFormation | Front-End Web & Mobile
AWS CDK によるオーバーライドに一部対応
Amplify CLI で作成したCognitoなどをカスタマイズすることが出来るようになりました。
AWS Amplify が CDK を使用して Amplify で生成されたリソースをオーバーライドする機能を発表
Amplify Studio + Figma によるコンポーネント生成
個人的に可能性を感じるアップデートだと思っています。後述します。
AWS Amplify Studio – 最小限のプログラミングでFigmaからフルスタックのReactアプリを実現 | Amazon Web Services ブログ
拡張性を得た AWS Amplify
以前の Amplify は DB が DynamoDB 以外選べないことや他のサービスと併用する時に結局 CloudFormation を二重管理する必要があるなど拡張性の面で限界が存在していました。
AWS CDK 対応のアップデートでこれを打ち破ることができる様になり、ある程度の小・中規模のプロダクトなら十分使えるレベルになったと思います。
また、FIgma から React Component を生成する機能も超強力になる可能性があると思います。
自動生成したコードは融通が効かない・使えない・読めないという事は往々にしてよくあることですが、「ロジックとビューの分離」は昨今のフロントエンドのトレンドです。
Container / Presentational にコンポーネントを設計し、自動生成したコードをUIコンポーネントとして Presentational 側で使用する事は決して難しくはありません。
まだ public preview 版ですし、props の型が無いなどのツラミもあると思いますが、今後の動向をチェックして損のない機能だと思います。
まとめ
最近のアップデートにより AWS Amplify は実践的にかなり使えるサービスになってきています。
少なくとも以前のプロトタイプ開発や学生向けといった様な範疇には収まらない水準まで来ており、新規開発の際の選択肢の一つに入れても良いのではないでしょうか。
興味持って頂けた方は上記で列挙した以上のアップデートもあるので是非チェックしてみてください。
僕自身も今後もチェックして触っていきたいと思います。
余談: AWS Amplify を通して個人的に思ったこと
一連のアップデートは単純に便利サービスに進化しただけではなく
「フロントエンド・バックエンド・デザイナーの垣根を薄くしている」
「一人のエンジニアがカバーできる領域が広がりつつある」
ということでもあると解釈しています。
(もしくは元々は一つだったはずなので、昔に戻っているのかもしれませんね。)
Amplify に限らずとも XD で Android の UI を自動生成するなどもありますし、デザインツールで実際の UI をそのまま作る将来は近いのかなぁと。
この先もプログラマー・デベロッパーを続けていくには、
デザインやネットワークなどより上もしくは下のレイヤーの知識を身に着けていかないといけないのかもしれませんね。
この先はそのつもりで色々とキャッチアップしていこうと思います。
