TL;DR
- トレーシングはデバッグの際にも使える様に環境を整えるべき
- トレーシングはサービスを構成するプログラムの理解に効果的に使える
はじめに
以前自分が体験した話ではありますが、業務範囲が大幅に増えた結果、
まったく知らない業務のソースコードだけを渡され、
読むのに大変苦労した経験があります。
また、私は転職者であり、現職で既に実装済であるサービスについて、
その個々のプログラムの意味や繋がりを理解するのにも苦労しています。
細かい部分に関しては、未だに知らない部分もかなり多くある、と感じています。
まだ理解が足りない、と思う事で感じる焦燥感は、実際に感じる部分がありますし、
逆に受け入れる側としては、物足りなさを感じている部分もきっとあると思います。
自分は早くチームの一員になれる様にコードを読むし、
受け入れる側は早くそうなってもらいたいと期待するが、
そこに時間が掛かるとお互いに物足りなさを感じてしまいますよね。
まずは、そんな実体験の話をベースに、
この様な問題をどうやって解決出来るか、を提案させて頂きたいと思います。
まったく知らない業務が増えた
以前、社内SEを務めていた際に、
他のシニアエンジニアが異動となる事をきっかけとして、
その方が担当していた特定の業務範囲をまとめて担当する事になった事があります。
当然ながら、それまでほとんど担当していなかった業務範囲です。
しかしながら、任された業務範囲は非常に繊細な箇所であった上に、
プログラムの数は500を優に超える、密結合なプログラム群でした。
各プログラムは多くが数千行を超えるソースで構成され、多くがコピペとベタ書きであり、
ネストの深さはとびきり深く、変更容易性など考えられていない上に、
プログラム達は難解に絡み合っており、フローチャートなんて当然存在しない。
ソースコードを読んで理解しろ、と言わんばかりの一子相伝プログラムでした。
多分同じような経験をしたことがある方は無数にいると思いますが、
そうでなくても、ソースコードだけ渡されて「理解してね」というのは、
相当な困難である事は理解頂けると思います。
それから1年程の年月を掛け、
担当部署のプログラム的な問題を潰しつつ、時間があればソースを読み込み、
そして表面上の問題を対処出来る様にはなりましたが、
結局転職してその会社を離れる事になるまでに、
プログラム群の根本の問題である、密結合な部分を崩すに至る事は出来ませんでした。
テストコードもテストパターンも存在せず、
テスト環境は一歩間違えば本番環境を荒らしかねない状態。
ブラックボックスなプログラム群の個々が、正常に動くかの保証がまったくない。
納期が近過ぎて、関連するプログラムを全て読み込んだり、動作検証をする事が出来ず、
とにかく実際に動かしてみるしか出来ない。
そして実際に動かして失敗し、夜中に呼び出されたり、
酷い𠮟責を受けたりした事も数知れず。
アップデートをリリースするのが怖くて、
リリース後は自宅の風呂にまで携帯電話（非防水）を持ち込んでいた時期もあります。
そして実際に電話が鳴り、風呂の中で電話対応し、
髪も乾かさぬまま会社に向かった事もありました。
失敗出来ないのに失敗するかもしれないという不安は、
精神を病ませる原因になります。
この問題において、悪いのは何か？
当然ながら、まずは悪いコードを書かない事が大切です。
Qiitaの記事ではありませんが、Zennで良い記事がありましたので、転載します。
変更容易性が無いプログラムというのは大変読み辛く、直し辛いです。
悪いコードも書いた本人は読めるし、直せるでしょう。
ただ、他の人は読むのに苦労するし、直す事も困難です。
自分がいなくなった時に、誰がそのプログラムを保守するのでしょうか。
所属するチームに負債を与えない為にも、
可読性の高いコードというのは十分な価値があります。
あなたも、サービスを保守管理しているあの人も、
もしかしたら、明日には同じ企業にいないかもしれない。
そのサービスを繋ぐまだ見ぬ誰かの為に、まずは可読性の高いコードを。
コードが良ければ解決したのか？
しかしながら、この問題はコードが良ければ解決するのかという問題があります。
どんなに可読性が高いコードを記載していたとして、
自分の部署に配属された新人が、すぐにコードを読めるようになるでしょうか。
疎結合されたプログラム群のフローチャートを見て、使いこなせる様になるのでしょうか。
プログラムに内包された問題に対して、アプローチする事が出来るでしょうか。
答えはいずれもNoです。
実際に使って見て、色々な値を突っ込んでみて、
それらのプログラム群のそれぞれがどういう結果になるかを見て初めて、
「ああ、そういう結果になるのね、理解した」となる訳です。
試験などを受ける時に、
対策用の講義を動画で見ていたとしても身に付かず、
過去問を実際に解いてみないと学習効果が無いのと同じで、
実際に動かして、それぞれの結果がどうなるのか、体験出来る事が重要なのです。
その為にテストコードだったり、テストパターンだったり、
テスト環境等を用意して、開発者がデバッグをするのと同じように、
実際に体験して、それらがどのように作用していくのかを、
自らの手を動かして確認出来る事が必要なのです。
ソースコードだけ渡されても、システムに精通してなければ分かる訳が無い。
システムに精通していないからこそ、手を動かせる環境や、情報が必要。
トレースを利用したエンジニアリング
上記の様な問題が起きる事を想定した時に、非常に便利な物がトレースです。
トレースと言うのは、オブザーバビリティを構成する要素の一つであり、
テレメトリーを収集する事で各プログラム群がどの様に連結されていて、
障害点がどこにあるのかを特定する為の重要な要素であり、
監視に関連する項目の一つです。
オブザーバビリティとは、いわゆるモニタリングと近しい働きをするものですが、
現代のサービスで多く見かけるマイクロサービス化したシステムにおいて、
より効果的に利用出来るよう、構築された考え方です。
この違いについては、本記事では特に触れません。ご容赦下さい。
しかしながら、オブザーバビリティ自体には監視や原因の特定だけでなく、
探索可能性を提供するという観点があり、
それはプログラムやサービス自体の理解が疎い人にも、多大な情報を渡してくれるのです。
私はサービスを構成するシステムに疎い新人にこそ、
探索可能性が高いプログラムが必要だと思っています。
本当に必要なもの
サービスに対して初心者であるエンジニアが欲しいものは、
テストを行って、得られる最終結果だけでは必ずしもありません。
簡単な例として、以下の様なフローチャートが用意されているプログラムを仮定します。
前提条件として、各AWS lambdaがどういう動きをするものか、
まったく分からない状態であったとします。
システム自体を知らないエンジニアが、このプログラムに直面しているという状態です。
当然ソースコードは読むでしょう。
しかしながら、テストを行って最終的な結果であるvalueを得たとして、
その実行結果から得られるものは、
保守／管理や開発を行うエンジニアとしてはあまり意味がある物ではありません。
この場合に本当にエンジニアが欲しいのは、
- 各AWS lambdaがどの様なinput/outputを行っているか
- 分岐の場面でどちらに進んだか
- valueの値はどこで得られたか
の様な、各プログラム群がどの様な働きをして、後にどう作用したかが知りたいのです。
つまり、工程の途中の結果の全てを知りたいのです。
そしてこれらを実行した後に、それらの結果を高速に知ることが出来るほど、
さらには可視性が高いほど、システムを理解する速度が速まるのです。
それは、例えばstep functionで得られる実行結果のワークフローの様なものだったり、
AWS X-RAYで得られる様なトレースのサービスマップや、
コンテキストを自由に参照出来る事で、
どういう動きで最終的な実行結果を得る事が出来たか、
そしてそれらの各スパンがどの様に実行結果に関与したか、
簡単に誰でも知ることが出来る環境が用意されている事で、
サービスに関する知識の習得速度は、遥かに向上します。
だからこそ、デバッグの際にこそトレースが重要であり、開発の早い段階から
オブザーバビリティに関連する機能を導入するメリットでもあるのです。
なるべく少ない苦労で、なるべく早く戦線に参戦してもらう為にも、
トレースを開発段階から導入するのは非常に有効であると考えています。
おわりに
苦労してコードを読んだ時代が自分にはありましたが、
当時こういう機能が自分が担当したサービスに導入されていれば、
もう少し容易くプログラム群の相関関係を知ることが出来て、
もっと改修に寄与出来たのかなと、振り返って思う事があります。
しかしながら、自分が当時感じた苦しさと同じ様なものを、
今後新しく入って来る方々に対して、同じように感じてもらいたいとは到底思いません。
そこには人を迎える側の努力も一定必要です。
分かり易く、楽しく、サービスを理解出来る事を通じて、
サービスや各機能の理解度がより一層高まる事は、
また新しいインテグレーションが生まれる一因にもなると思います。
次の世代に優しいプログラムの構築を、自分でも心掛けたいと思っています。