【ソースコードの品質向上】デザイナーもコードレビューしよう
ドワンゴデザイナーのマカロフです。
私がドワンゴに入社したのはニコニコ動画のバージョンが原宿の時でした。それからPS4生放送対応等を行ったり、ニコニコ生放送のサービスに携わって来ました。仕事の領域的にグラフィックデザインをするより、エンジニアさんと連携を取りながらコードを書くことが多いです。
そんな背景もありコードレビューの大切さを日々痛感しておりますので、今回はデザイナーの開発環境の紹介としてコードレビューを取り上げたいと思います。
デザイナーもコードレビューをする時代
ドワンゴのデザイナーも世間のデザイナーと同じくimage、HTML、CSS、JavaScript等を日々、編集してコミットしています。
新しいテンプレートエンジンの採用によりHTMLの記述方法が変わったり、自動化したり、コンポーネントなcss設計を考えたり、JavaScriptも日々進化していき新しく採用したフレームワークへの対応を求められます。
そういった背景もあり、デザイナー個人での対応は最早限界を迎えているといっても過言ではありません。特に何かを作業する時にデザイナー1人で悩むのもよくないと考えています。
|
|---|
こういった悩みや疑問、事故が日々おこります。
そんな時にはコードレビューを行いましょう！
1人で悩むことがなくなりますし、コードレビューを行うことによって様々な効果があります。
コードレビューを行うメリット
|
|---|
コード品質の向上や知識の共有という点を目的としてコードレビューしていく事でみんな幸せになります。
コードレビューする環境
ドワンゴのエンジニア、デザイナーはGitHub Enterpriseのアカウントが入社時に付与され、業務作業のコードレビューは会社のGithubアカウントを使って行っています。
Githubの導入前はsvnでのコミットを行っていましたが、もはやGithub無しではいられない体になっています。
エンタープライズ版でないGithubアカウントは無料で使えるFreeプランもあります。
他にもweb公開型のGitホスティングサービスはAssemblaやBitBucketといった物もあるので、それらを試してみるのも良いかもしれません。
今回はGithubのスクリーンショットでコードレビューをご紹介します。Githubの取り扱いに関してはまたの機会に詳しくご紹介したいと思います。
コードレビューのポイント
コードレビューする際に気をつけているポイントをご紹介します。
レビュワーを決める/お願いする
チームミーティングや簡単な相談を事前に行い、
「hogehogeの案件でfugafugaなclassを修正したんでレビューお願いします！」
そんなやり取りをしましょう。コードを見る側にも予定や都合はあるのです。
JavaScriptやReactテンプレートを修正した場合はフロントエンドなエンジニアさんにレビュワーをお願いする事も多いです。（いつもお世話になっております）
必ず手元のブラウザでの表示確認（or動作確認）、査読を行う
これからコードを見てもらうというのに出す側が表示確認とコードの査読を行っていないという状況はあり得ません。プルリクエストのコメント欄に確認環境のURLを記述して実際にブラウザで表示できる環境を見てもらう努力も行いましょう。
セルフチェックを必ず行いケアレスミスがないかの確認することが鉄則です。
記述した箇所の簡単な説明をレビュー前に行う
書いた側がわかっていてもレビュワーは初めて見るコードかもしれませんので、レビュワーが見やすいようにコードの変更箇所に簡単な説明を記述しましょう。
事前にコーディングスタイルについて決めておく
事前にある程度のコーディングスタイルを統一する為の資料があるとコードレビュー時の認識をあわせる事ができます。
できればHTML、CSS、JavaScriptといった物を扱うデザイナー、フロントエンドエンジニア間で共通の認識をあわせる会を開いて資料を策定するといいと思います。
現在のチームでは、
| HTMLガイドライン基本方針 | CSSガイドライン基本方針 |
|---|---|
|
|
等を資料として作成し共有を行っています。（この辺りもコードレビューから外れるので割愛します。）
レビュワーからの指摘に対応しつつ修正コードをコミット
コードにコメントが貰えるとGithubに登録したメールに通知が届きます。
それに返答をコメントしつつ、修正をコミットしていきましょう。
セルフマージはしない
コードを見て貰った人に必ずマージボタンを押してもらいましょう。
これは見る側にも責任を持ってもらう為であり、コードの記述ミスを個人が背負わない為の措置であります。（緊急時は別かもしれません）
レビューしてコードを入れたことよって起こる不具合はチーム全体の責任として皆で背負い、再発を防止するという形が理想だと考えてます。
私たちのチームでは現在このような形でデザイナー間だけでなくエンジニアともコードレビューをする環境で作業を行っています。
最後に
今回はドワンゴデザイナーの環境の紹介としてコードレビュー取り上げてみました。
コードレビューはチームによって流れややり方が違うところもあると思います。一例としてご紹介しましたので、チームの形にあったコードレビューを見つけてみるといいと思います。開発チームの中で作業しているデザイナーだからこそ、一部の人間だけがわかる記述ではなく周囲のエンジニア・デザイナーに共有していく方法を模索していきたいものですね。
文中で触れた、
- デザイナーのgithubの取り扱い方
- コーディングスタイルについて
- react難しい
この辺りはまた触れる機会があるかなと思います。
デザイナー個人のgithubアカウントやqiitaアカウントをお持ちの方はそのURLを添えてドワンゴのデザイナーに応募してみてください。
弊社クリエイティブセクションでは常に救世主を求めています！
一緒にコードレビューしていきましょう！
