IDEから離れず、コード起点でプルリクやレビューができるCodeStream
日々の業務を効率よく進めるには、作業しやすい開発環境が必要だ。New Relicのソフトウェアエンジニア、齊藤恒太氏も、大好きなもの作りのために生産性も効率も爆上がりする、イケてる開発環境を求めてアップデートを欠かさないと明かす。だが、これがなかなか難しい。GitやIDE、Slack、Microsoft Teamsなど、開発作業で使うツールは案外多く、何かあるたびにウィンドウを切り替えたり、複数あるコミュニケーションチャネルをまたぎながらやりとりしたりと、一つ一つは小さな手間でも積み重なれば時間も集中力も奪うコストに変わる。その影響は個人にとどまらず、チーム全体のパフォーマンス低下に及ぶ可能性もある。
開発環境や周辺ツール、プロセスが開発者の足を引っ張っていては、開発者自身やチームがクリエイティブな仕事をできなくなる。そんな課題を解消するツールとして、齊藤氏は「New Relic CodeStream」（以下、CodeStream）をお勧めする。CodeStreamは、アプリケーションのテレメトリデータを関連コードと紐付けてIDE内に表示するプラグインソリューションだ。対応するツールは、VS CodeやVisual Studio、GitHub、JIRA、Asana、GitHub、GitLab、Bitbucket、Slack、Microsoft Teamsなど。広く使われているツールはほぼ網羅しているといっていいだろう。
タスクやイシューは、IDE内のCodeStream画面上に表示される。イシューの作成や確認、タスク修正してコミットしてからのプルリクエスト（PR）でのマージ、（レビューアによる）レビューなど、すべてこの画面上で完結する。これまでは必要に応じてツールを切り替えたり、ツール分散する情報の整合性を確保したりと、本来は時間を割くべきではない作業に時間を取られてきたが、それもなくなる。
特筆すべきは、コード中心にコンテキストが維持された状態で管理されている点だ。たとえば、タスクで作業開始すると、ブランチが自動的に作成される。また、PRでタスクをマージするとき、CodeStream画面内のPR一覧から新規プルリクエスト作成ボタンをクリックすれば、どのブランチのどこにマージされるかが表示される。
「従来は、整合性をとるためにブランチ名を決めたり、PRとイシューの関連づけを意識したり、複数の修正をしているときに注意深くブランチを切り替えたりと、細々としたことに気を配る必要があった。それが、CodeStreamを導入することでブランチの関連づけなどが自動処理されるので、煩雑な作業がなくなり、手動ミスも減り、開発に没頭できるようになる」（齊藤氏）
合わせてもうひとつ、CodeStreamではコード起点でコミュニケーションがとれる。既存コードのバグを修正するとき、そのコードを誰が書いたか分からないことがある。このときよくやるのは、コードをチャットツールにコピペしてチームメイトに聞き回る、コメント欄に埋もれたイシューやPRを過去に遡って調べるといった作業で、これがとても時間がかかる。特に最近は在宅勤務で開発することが増え、同僚との距離が遠くなった。コードレビューもWeb会議をセットアップして実施するも、気軽に会話するという感じではない。
CodeStreamでは、IDE内でコミュニケーションがとれる。たとえばコード内に意図が分からないメソッドを発見したら、“Add a Comment”を選択してディスカッションを開始。メンバーにメンションが飛び、コメントを開くと同時に表示されるコードの該当箇所を見ながら“Add Comment Back”で返信できる。メンションされた人がそのときIDEを開いていなかったとしても、連携しているSlackやTeamsから直接やりとりすることも可能だ。また、過去のやりとりもコードに紐付けられているので、修正の背景がすぐに確認できる。
さらに、コミット前の軽いレビューといったニーズにも応える。たとえば修正した箇所に問題ないかどうか、チームメイトに軽く確認してもらいたいということもあるだろう。そういうときは、コミットしない状態でCodeStream画面から“Feedback Request”を選択。ローカルのワークツリー内の修正コード一覧を表示して、その中から該当する未コミットのコードを選び、レビュー対象に登録。レビューアにレビュー依頼を飛ばす。レビューアは通知を見てIDEなどでコードをチェック、承認や修正依頼、コメント追加などして返すという流れだ。
「通常はマージやPR後にコードレビューを行うが、それではどうしても開発工程の後半にレビューが集中してしまい、一気にチェックするレビューアの負担も手戻りの負担も大きくなる。上流工程で早めに修正をかけることができれば、レビューは軽量化されて、手戻りも減る。それに、コードを気軽にレビューするという文化が醸成されれば、品質にも良い影響が出るはずだ」（齊藤氏）
