一行ずつではなく「全体の流れ」でわかるやさしい解説
Lambdaのコードを見ると、最初はどうしても
- 英語が多い
- 記号が多い
- 何から読めばいいかわからない
と感じやすいと思います。
ただ、Lambdaのコードは、細かい書き方を全部読まなくても、
「どういう流れで仕事をしているのか」 をつかむだけで、かなり見やすくなります。
特にブログや業務の自動化で使うLambdaは、見た目は違っても、設計の考え方はだいたい似ています。
この記事では、一行ずつの細かな説明ではなく、
Lambdaのコードが全体としてどういう設計になっているのか を、やさしく整理していきます。
Lambdaのコードは「自動で動く小さな仕事係」
まずイメージとして、Lambdaは
何かをきっかけに動く小さな仕事係
のようなものです。
たとえば、
- 決まった時間になったら動く
- ファイルが保存されたら動く
- テスト実行されたら動く
- APIで呼ばれたら動く
といった形で、何かのきっかけを受けて仕事を始めます。
そして、その中で必要な処理をして、最後に結果を返したり、保存したり、通知したりします。
つまりLambdaの設計は、基本的に
きっかけを受ける → 判断する → 必要な作業をする → 結果を返す
という流れでできています。
Lambdaコードの設計は大きく5つに分けて考えるとわかりやすい
Lambdaのコード全体は、ざっくり見ると次の5つの役割に分かれています。
- 入口
- 準備
- 本体処理
- 結果整理
- 出口
この5つに分けて見ると、コードを全部読まなくても
「このLambdaは何をする設計なのか」が見えやすくなります。
1. 入口
まずは「何をきっかけに動くか」を受け取る
Lambdaの最初には、必ず
呼び出されたときの入口
があります。
ここは、外から来た情報を受け取る場所です。
たとえば、
- 今日は何時実行なのか
- どんなイベントで起動したのか
- テスト実行なのか本番実行なのか
- 渡された条件は何か
といった、スタート時点の情報を受け取ります。
人の仕事でいうと、これは
依頼を受ける窓口
です。
ここで受け取った内容によって、その後の動き方が変わることもあります。
たとえば、テスト用の入力なら簡単な処理だけにする、本番なら外部データを取りに行く、といった分け方をする設計もあります。
2. 準備
仕事を始める前に必要なものをそろえる
入口で情報を受け取ったら、次は
仕事の準備
に入ります。
ここでは、後の処理で使うための材料や設定をそろえます。
たとえば、
- APIの接続先
- 通知先
- 保存先
- 監視対象の通貨ペアや銘柄
- 判定に使う基準値
- 時刻や日付の情報
などを用意します。
これは料理でいえば、食材と調味料を並べるようなものです。
いきなり調理を始めるのではなく、まず必要なものを手元にそろえます。
Lambdaのコードでも、この準備がしっかりしていると、後ろの処理が整理しやすくなります。
3. 本体処理
このLambdaが本当にやりたい仕事をする部分
ここが、Lambdaの中心です。
設計としてはここが
メインの仕事
になります。
たとえば簡単なアービトラージ系のLambdaであれば、ここでやることは次のような内容です。
- 価格データを取得する
- 複数の値を比べる
- 差を計算する
- 条件に当てはまるか確認する
- シグナルを出すか判断する
つまり、準備した材料を使って、実際に判断や作業を進める部分です。
この本体処理は、さらに小さな仕事に分かれていることが多いです。
たとえば、
- データ取得担当
- 計算担当
- 判定担当
- 通知文作成担当
のように、役割ごとに分けて組まれていると、設計として見やすくなります。
4. 結果整理
処理した内容を、そのまま使える形にまとめる
本体処理が終わったら、その結果をそのまま終わりにするのではなく、
使いやすい形に整理する
段階があります。
ここではたとえば、
- 計算結果を文章にする
- 成功か失敗かをわかるようにする
- 通知用メッセージを作る
- 保存しやすい形に整える
- 画面やテスト結果で見やすくする
といったことをします。
これは、仕事の途中メモをそのまま出すのではなく、
報告書の形に整える作業
に近いです。
実際の業務でも、途中でいろいろ調べて計算していても、最後は「結論」として相手にわかる形にしないと使いにくいですよね。
Lambdaのコードも同じで、最後に扱いやすい形へ整理することが多いです。
5. 出口
最後に「どう終わるか」を決める
Lambdaには最後に
出口
があります。
ここでは、この処理をどう締めくくるかが決まります。
たとえば、
- 実行結果を返す
- 成功として終了する
- エラーとして終了する
- 通知を飛ばして終わる
- 保存して終わる
といった形です。
ここは人の仕事でいうと、
最後の報告や提出
にあたります。
Lambdaの設計では、この出口がはっきりしていると、とてもわかりやすくなります。
つまり、
- 何を受け取って
- 何をして
- 最後に何を返すのか
が見えやすいコードほど、設計として読みやすいのです。
実際のLambdaは「1本の流れ」ではなく「分担制」になっていることが多い
初心者向けのサンプルでは、Lambdaコードは短くて、全部が1つのまとまりに見えます。
でも実際には、少し長くなるLambdaは
役割を分担する設計
になっていることが多いです。
たとえば全体としては1つのLambdaでも、中では
- データを集める部分
- ルールを確認する部分
- 判定する部分
- 通知する部分
- エラー対応する部分
のように、いくつかの担当に分かれていることがあります。
これは、1人が全部を頭の中でやるより、
「受付」「集計」「判断」「報告」と分担したほうが整理しやすいのと同じです。
設計として見るときは、一行ずつではなく、
「このブロックは何担当か」
という見方をすると理解しやすくなります。
アービトラージ用Lambdaなら、どういう設計になりやすい？
アービトラージ系のLambdaは、特に次のような流れで設計されることが多いです。
1. 起動する
スケジュールや手動テストでLambdaが呼ばれる
2. 必要な設定を読む
監視する通貨ペア、しきい値、通知先などを確認する
3. データを取りに行く
価格やレートなど、判断材料になる情報を取得する
4. 比較する
2つ以上の価格差や乖離を見て、条件に合っているか判断する
5. 結論を作る
「通知する」「まだ様子見」「条件外」などを整理する
6. 必要なら通知する
SNSやメールなどで結果を送る
7. 実行結果を返して終わる
最後にログや返り値として結果を残して終了する
この流れで考えると、コードが読めなくても
「このLambdaは今どこの段階をやっているのか」
がつかみやすくなります。
Lambdaの良い設計は「途中で何をしているか想像しやすい」
読みやすいLambdaコードには共通点があります。
それは、細かい文法がわからなくても、
途中の流れが想像しやすいこと です。
たとえば、
- 最初に設定を読む
- 次にデータ取得をする
- そのあと判定する
- 最後に通知する
という順番が自然だと、設計としてとてもわかりやすいです。
逆に、
- 設定
- 通知
- 取得
- 判定
- また取得
- また設定
のように、流れが行ったり来たりしていると、コードが苦手な人にはかなり読みにくくなります。
つまり設計の見方として大事なのは、
「処理の順番が自然かどうか」
です。
コードが読めない人は「文章の見出しのように」見ると理解しやすい
Lambdaコードをそのまま読もうとすると難しく感じますが、
設計として見るときは、コードを文章の見出しのように考えるとわかりやすいです。
たとえば頭の中で、
- まず何を受け取る話なのか
- 次に何を準備する話なのか
- そのあと何を判断する話なのか
- 最後に何を返す話なのか
と、章立てのように追っていくイメージです。
この見方ができるようになると、細かい文法がわからなくても
「このコードは全体としてこういう設計なんだな」
とつかみやすくなります。
まとめ
Lambdaのコードは、一行ずつの細かな意味を追わなくても、
まずは 全体の設計の流れ をつかむことが大切です。
大きく見ると、Lambdaは次のような構成で動いています。
- 入口：きっかけや入力を受け取る
- 準備：必要な設定や材料をそろえる
- 本体処理：実際の仕事をする
- 結果整理：わかりやすい形にまとめる
- 出口：返す、保存する、通知して終わる
つまりLambdaは、
何かをきっかけに動いて、決められた流れで仕事をして、最後に結果を返す小さな自動処理の仕組み
として設計されています。
コードが読めないうちは、細かな文法よりも先に、
「このLambdaは何を受け取って、どう処理して、最後にどう終わるのか」
を見るだけで十分です。
それだけでも、コードの見え方はかなり変わってきます。