ソース解析で困ったら試してること

みなさん、こんにちは！
エンジニア歴、えーっと何年だろう？約18年くらい？かも？
初めての投稿なのですが、これまでの経験を踏まえて、今でも続けている事を書いてみたいなぁと思います。

エンジニアを目指している方も、現在エンジニアしている方も、大した内容ではないかも知れませんが、興味があったら読んでみて下さい。

設計書がないプロジェクト

この世には色んなプロジェクトがあり、色んな人たちが関わって作り上げたサービスがあったりします。
もちろん、スクラッチもあればこれまで作ってきたサービスを保守していくことも大事で、もちろん人の手が必要になることもよくあると思います。

あるビジネスをするために必要な便利ツールとして何かのAppを実装するために、要件はもちろん設計という工程があり、その設計に基づいてコード化する事がほとんどだと思います。
プロジェクトだったり予算だったりもあるかも知れないけど、設計書がないプロジェクトも多くあったりします。

10年前とかは「設計書がないと何も出来ません！！」というエンジニアの人は普通にいました。
今はどうなんだろう？そういうエンジアさんってまだいるのかなぁ？

ソース解析って？

設計書がないプロジェクトに参画すると、設計書がないので必然的に成果物として存在しているプログラムコード、つまりソースが全ての正（せい/正しいもの）となります。

例えば「このボタンをクリックしたら、どのような挙動になるか」と問われれば、FrontとBackendの両方のソースを追っかけて読んで回答するしかないですね。
設計書があれば、ソースを見なくても機能設計書などに書かれている事をそのまま回答出来ますし、なんなら「設計書に書いてありますよ〜」と言えば済む話ではあります。
ただし、その設計書がきちんとメンテされている前提の話になりますが…

ある機能として、どのような振る舞いとなっているかをソース読んで理解し、もし変更したい！となった場合は、どのように変更するのか、変更すると他の機能にどのような影響を与えるのか、などを検討したり立案したりするのに必要な作業だったりします。

複雑なロジックを追いかけるのつら…ってなったら

例えば、予約機能だったり請求機能だったり、複雑なAPIロジックってあったりしますよね。
そのロジックが複雑になってて、ServiceがService呼んでたり、裏でJob呼び出してたり、ソースとしても行ったり来たりしてて、どのソース読んでたのか迷子になったり、訳分からん〜！って経験ありませんか？

機能のイメージとしてはなんとなく分かってるけど、実際どういうコードでどういう処理をしてて、結局途中で「なんじゃこりゃぁ…」ってソースを追うのを諦めそうになったら、複雑なものは追わずに先に「I / O」を追うことに視点（気分も）を切り替えるのもいいかも知れません。

「I」は「Input」、「O」は「Output」を指します。
例えば「I」の場合だとRequestParameterの情報だったり、「O」の場合だとDatabase（何のテーブルなのか、Relationはあるのかも）や帳票、メールだったり、外部APIだったりします。

そうすると、「こういうパラメータを送ると、⚪︎⚪︎のテーブルに永続化され、メールが飛び、帳票が作られる。」「外部APIとかの通信はないから、外部システムとか気にしなくていい。」みたいなざっくり理解が出来るようになります。

先に「I / Oが何か！？」を抑えておくと、その後々の調査もちょっとずつ見えてくるようになり、必要があれば拡張調査（調査したDatabaseを参照しているAPIの洗い出しとかも）にも展開できると思います。

ちゃんとメモを取っておきましょう

• 追加機能のタスクをアサインされた時、ソース解析して自分が理解したらすぐ着手しちゃいます？

• 不具合の調査したら、すぐbugfixしちゃいます？

• 「現行の挙動ってどうなってるのか調べて欲しい！」と依頼されたら、口頭での報告ですか？

いえいえ！
ただでさえ設計書がない中、せめてチケットなどに検討した内容や不具合の原因、調査資料くらいのメモは残しておきましょう。
チケットがない場合は、起票すればいいですし、チームでもリーダにでも相談しましょう。

対応内容にも寄りますが、メモも取らず、実装方針大丈夫か？の確認もせずに実装してしまうと、レビューの際「この実装に至った検討資料ってあるか？実装方針とか誰かに確認したのか？」と問われた時に、後々困るかも知れません。

こういうチーム内でのコミュニケーションも大事ですね（おかしいなぁ、いつも話してる事なのに、我関せずで聞いてないって事なのかなぁ…。）

この投稿の最後に

ソース解析って大変ですよね。
コツコツやらないといけない事が多いですし（自分は性に合ってるけど）。

だけどその時に気づく新しい発見（単なるMVCにした事で、FatControllerの悪寒がしたり、Repository側でService呼んでたり、Request側でRepository呼んでたり）もあったりするので、調査資料は意外と貴重な資料になったりします。
そして、それは複雑であればあるほど、重宝されやすいです。

注意点としては、調査資料はあくまで「その時点」のものであり、「今後の改修・改善する参考資料」という位置付けにしておく所だと思います。

無理！見切れんてぇ〜！誰かたすけて〜！ってなったら、遠慮なく叫びましょう。
いいプロダクトを作るためにも、無理せず気分転換しながらソース解析を楽しみましょう。