コードを書く仕事をしてると、読むことも多い。読んでる時間のほうが多いかもしれない。いま書かれてるコードを読むことも、もちろん多いし、何年も前に書かれたコードを読む機会も割とよくある。
コードを読むと、そのコードを書いた人の考えや、そのときの状況が感じられて、おもしろい。特に、何年も前に書かれたコードを読むときは、コーヒーを片手に（そのときはこんな感じだったんだろうなぁ）って想像しながら読んで楽しい。
ふと、どういうコードから、自分がどういうことを想像するのかを書いてみようと思った。
前提
今、目の前で書かれているコードを読んでレビューしてるときの話じゃなくて、何年も前に書かれたコードを読むときの話をしようと思う。だから、そのコードが良いとか良くないとか、こうするべき「だった」とかは考えない。今後の自分がどう書きたいかなぁ？くらい。
また、そのコードを書いた人が良いとか良くないとかでもない。そのときのベストを尽くしているのが前提にあるし、そのコードのおかげで自分がここにいられてたりする。それよりも、自分が過去に書いたコードを思い出して・・・すまない、という気持ちになったりする。
あ、そうそう、僕がこれまで見てきたのは、自社ウェブサービスのコードが多いので、その視点での話になるし、個人の経験からくるひとつの視点の話になる。おやつでも食べながら、気楽に読んでほしい。
コピペ
まず、よく見るのはコピペコードかな。少量のときもあれば、いろんなところに散らばってる場合もある。読むときに気をつけるのは、同じように見えて、ちょこっとだけ書き換えてある場合が多いということ。それと、全体をコピペしていて、あんまり必要ない部分まで混ざってたりすること。
コードを読んでて「あれ？このロジック必要かなぁ？」って感じたときには、コピペを疑って探してみると、コピー元のコードが見つかって、「あぁ、コピー元では意味が分かるな」ってなったりして、納得する。
コピペコードを見たときに想像するのは「動いているコードを触るのが難しい環境だったんだろうな」ということ。時間がない中での改修だったり、コピー元のコードがプロダクトのすごく重要な部分で、そこに手を加えてトラブルになったら大変だからさわれない、みたいなの。コピーすることで変更の影響範囲が限定的になるから。
とはいえ、コピペをすると、ロジックが分散してコードを読むのも改修するのも難しくなるから、できれば避けたいなとは思うんだけど、避けるには「動いているコードを触るのが難しくない環境」が必要なんだろうな。影響する範囲を小さくとどめるアーキテクチャや、自動テストが充実している、とか。
「動いているコードを触るな」は、理解できることではあるけど、自社ウェブサービスの範囲だと、個人的には、触り続けたいなって思う。触り続けてもトラブルになりにくい・大きなトラブルにはならない仕組みにしておきたい。じゃないと、手に負えないものが、さらに手に負えなくなってからの、ライブラリの EOL などで、大変つらいことになる。
あれ、このペースだと3つくらいしか書けないな・・・。もっと軽く書こう。
後から発見された仕様
読んでて「あれ？この部分、名前と実際に格納している情報が違う？」って場合や、データの構造が不自然な場合がある。それは、あとから発見された仕様の場合が多い。
たとえば、最初は1対多のリレーションだったつもりが、ローンチしてしばらくして「これ多対多だ・・・」って気づいたときなど。忙しい中で、サービスへの影響を最小限にして、手を入れないといけないので、無理矢理なコードになっていることが多い。
だから、「なんかいびつな構造だなぁ」とか「なんでこれだけ別のテーブルになってるんだろう？」ってときは、後から発見された仕様かも！ってわくわくしてドキュメントをあさりにいく。
特別対応 if
特定の顧客の場合だけ、分岐が入っている場合がある。特に BtoBtoC みたいなサービスの場合、影響力の大きな重要な顧客からの要望を特別対応として入れたりする。
なんでもかんでも受け入れちゃうとそれはそれで大変だと分かったうえで追加された「特別対応 if」には、エンジニアとしての迷いと、サービスの生き残りをかけた匂いを感じられて、好き。
「特別対応 if」は、いちど入ると色んなところに混ざり込む性質を持っているので、後になってコードに改修を入れるときに、この分岐を意識するのがとても大変になっていく。バグが入り込むときには、影響力の大きな重要な顧客に対するバグになってしまうので、大変。
仕様変更
しばらくして「こっちじゃなくてこっちだったわ！」ってサービスがピボットしたり、仕様変更によって、ぐちゃってなってる場合もある。ぐちゃっとしてるときは「もしかして元の仕様はこうだったけど、それをこういう仕様に変更したのかな？」って考えながら読むと試行錯誤が見えてきて楽しい。なるほど、そういう対応にしたのかー！みたいなの。
あぁ。「後から発見された仕様」や「特別対応 if」も、仕様変更のひとつだね。
こういうコードを読むと、最初にある程度さきを見越して、どう転んでも対応しやすい設計にしておきたいな、という気持ちと、そんなこと考えるよりはやくリリースしたい、という気持ちのせめぎあいが始まって、最終的には「ある程度さきを見越して素早く設計できるスキルを身に着けよう」って自分の中で落ち着くのだった。パワー！💪
オブジェクトの過剰な継承
オブジェクトの継承を使いまくっているコードを読む機会は多い。継承元のベースオブジェクトに共通の処理が色々書かれていて、テンプレートメソッドパターンになってたりする。最近は、自分の周りではそういうコードを書くことは減ってきたけど。
継承を使うと、書くときは便利。スキルの高いメンバーが継承元のロジックを担当して、他のメンバーはそれを使うコードを書く、としておくと開発しやすい。
でも、読むときは割と大変。継承が深いと簡単に頭の中のスタックを持っていかれる ＆ 共通化されたロジックには目の前のコードには必要のない部分も含まれている、で頭から煙がでてしまう。ので、実際にどうなるか、別のファイルにつなげて書いてみて読んだりもする。
僕も以前は、そういうコードをよく書いてたけど、いま書くならできるだけ委譲にするだろうな。
道半ばの残がい
これはここ数年でちょこちょこ見るかなぁ。モノリスは嫌だ！開発が大変だ！ってマイクロサービス化しようとしたり、こんなフレームワークは古い！ってモダンなフレームワークにリプレイスしようとして、結局やりきれずに、複数のサービスにまたがって重複したコードが散らばったり、複数のフレームワークや開発言語の運用が必要になってるケース。
大変だとは思うものの、そういう挑戦ができる環境ってのはいいよなぁと思うのであった。それを怖がって挑戦できなかったら、改善もできないからなぁ。今後やるなら、途中で終わることになってもなんとかなるように、ちょっとずつ移行していく計画にしたらいいのかなぁ。
DIや命名規約
DI や AOP、命名規約による動作、などがある場合は、IDE でコードを読むだけで追いかけるのは難しいので、フレームワークの仕様を細かく確認する。あとアノテーションやデコレーターもか。
以前はそういうの便利だなーって思ってたけど、最近は、そういうのは少なめにして、コードに全部書いていくほうが好きだな。
おしまい
こんなところかな。だいたいが、コードを書いている人も「これ、あんまり良くないからあとでなんとかできたらいいなぁ」って書いてたりするよね。だけど、そうせざるを得なかった、という状況を想像すると、興味深いなぁって思うのだった。
コードを読んで、状況を想像して、自分だったらどうするかなぁ、こんな風にうまく乗り切れるかなぁ、とか考えると、そういう経験の一部を得られて、楽しい。
あと、コードを読んでて、よく分からない部分に「こういう理由でこうなってる」ってコメントが書いてあると「好き！」ってなる。
おしまい。
宣伝
スクラムフェス大阪2023 6/30-7/1
今週末の、6月30日と7月1日に開催される「スクラムフェス大阪2023」で、アジャイルラジオのゲストに呼んでもらって公開収録します！スクラムフェス大阪2021でキーノートセッションをやってからの2年間で、転職やレイオフやツイッター転職など色々あったので、そのあたりの話や、今はカケハシという会社で、ゆのんさんと一緒のチームで仕事をしてるんだけど、そのあたりの話ができたらいいかなって思ってます！スクラムフェス参加される方は、オンライン・オフラインどちらでもぜひ遊びに来てください！
【オンライン】医療スタートアップ開発裏側 7/3
もうひとつ宣伝。7月3日の月曜日に、カケハシのエンジニアとして、ヘンリーさんとファストドクターさんと一緒に、医療スタートアップの現場のお話をします。まだ入社して3ヶ月なので、会社の踏み込んだ話というよりは、入って今具体的にどんなことをやってるか、どんな風に過ごしてるか、フルリモートでコミュニケーションがどうなってるか、みたいなことを紹介できたらいいかなって思ってます。会社に少し興味あるなぁって方はもちろん、単純にどんなことしてるのか興味がある方も、無料のイベントなのでぜひにぎやかしに来てくださいー！
ではではー、週末にお会いしましょう！
