静的解析と人の歩み寄りがコードの治安を守る

お弁当が配布されたランチスポンサーセッションの終了後、Room 1へ移りmacopyさんの「Perl5の静的解析入門」を聞きに行きました。Perl5のソースコードの静的解析には興味があり、個人的に楽しみにしていたトークの1つです。

macopyさんは、そもそも静的解析とはどういうものなのかというところから話し始めました。静的解析とは、本質的にはコードをただの文字列として扱うことです。通常、Perlで書かれたプログラムはperlコマンドによって実行されるものですが、静的解析では文字列を読むだけで実行をしません。静的解析の利点として挙げられていたのは、コードの「見たままを扱える」こと。プログラムは実行できる形式に変換される過程で最適化され、不要な情報がどんどん落とされていきます。文字列の状態のプログラムを読めば、コメントを含めたすべての情報にアクセスすることができるわけです。また、静的解析では実行する必要がないため、悪意のあるコードを解析しても安全だという点にも触れられました。

次に、具体的にPerlの静的解析を行うモジュールがいくつか紹介されました。 PPIはPure Perlで書かれたPerlコードの解析機で、Perlのソースコードをドキュメントとしてパースすることができるものです。昔からあるモジュールで広く使われていますが、動作が遅いことが問題であり、IDEにおいてリアルタイムでフィードバックをするような用途では使うのが難しいようです。高速なものとしてはCompiler::Lexerや Perl::Lexerがありますが、古かったり利用が推奨されていなかったりしてプロダクションで使うのは難しいそう。

そこで今回のトークで取り上げられたのはPPRというモジュールです。PPRとはPattern-based Perl Recognizerの略であり、Perlコードのトークンにマッチする正規表現が集められたものです。PPRを使うと正規表現を利用してPerlのプログラムの一部を文字列の状態で取り出すことができます。例として、サブルーチンのコードの一覧をプログラムから取得し、その中できちんと引数のバリデータを利用しているかを検知する手順が説明されました。

トークの後半は、「⁠人間側の歩み寄りが必要」という話でした。Perlには人間にも機械にも意味を誤解しやすいコードというのがあり、人間もそれを避けるべきということです。

たとえば、Perlでは$method = $_ . "_factor"と動的に構築した文字列を$person->$methodのように呼び出すことができますが、このように生成されたメソッド名は人間はgrepで検索することはできず、また、静的解析を行う機械からも実行するまでメソッド名がわからないため利用できません。macopyさんは、そのようなコードをなくすことで、「⁠治安の良い」コードに保つことが可能になると説明しました。

会場からは、Javaでは可能な静的解析がPerlでは難しいのはなぜかという質問が出ましたが、Perlの実行時にしか型がわからないという特徴が静的解析を難しくしているということでした。

「エンジニアリング組織論への招待」著者によるゲストトーク

再びホールに戻り、今回のゲストスピーカの1人である、広木大地さんによる講演を聞きました。「⁠エンジニアリング組織論への招待―2つのDXと技術的負債論」と題されたこの講演では「2つのDX」をテーマに、エンジニアリング組織論、これからのエンジニアにとって必要なことが話されました。

2つのDXとは、開発者体験（Developer eXperience）と企業のデジタル化（Digital transformation）のことです。ソフトウェアエンジニアリングも組織設計も、どちらもビジネスを成功させるために必要不可欠なものです。

両者は一見異なるものに見えますが、どちらも不確実性を減らす試みであるという点で共通しています。さらに、「⁠システムを設計する組織は、その情報伝達の構造をまねた設計を生み出してしまう」というコンウェイの法則を紹介し、この2つを分けて考えることはできないとしました。

そして、コンウェイの法則に従えば、良い組織からは優れたソフトウェアアーキテクチャが生まれ、逆に悪い組織からは技術的負債が生まれると述べました。そこで、よい組織を作ることで優れたアーキテクチャを生み出すという、「⁠逆コンウェイ作戦」という考え方に至ります。それを支える技術として、マイクロサービス化も同時に押し進めることが多いそうです。

また、技術的負債という言葉がエンジニアによって使われ始めた背景には、エンジニアとそうではない人との間の情報の非対称性がある、と広木さんは指摘します。エンジニアはプロダクトの細部まで知り尽くしているので、プロダクトに問題があることに初めから気がつきます。しかし、非エンジニアの目からはシステムに問題があることはわかりません。エンジニアは適切な可視化によってプロダクトの問題を伝え、また、非エンジニアはコミュニケーションのやり方を工夫してエンジニアからプロダクトの問題を聞き出す必要があります。こうして情報の非対称性をなくしていくことを、DXというのだろうとトークを締めくくりました。

参加者からも非常にわかりやすいという感想が多数出ており、PerlにこだわらないYAPCならではの講演だったと言えるでしょう。