【ソースコードの品質向上】デザイナーもコードレビューしよう

【ソースコードの品質向上】デザイナーもコードレビューしよう

2016.01.15
Code Review01
ノウハウ

ドワンゴデザイナーのマカロフです。

私がドワンゴに入社したのはニコニコ動画のバージョンが原宿の時でした。それからPS4生放送対応等を行ったり、ニコニコ生放送のサービスに携わって来ました。仕事の領域的にグラフィックデザインをするより、エンジニアさんと連携を取りながらコードを書くことが多いです。

そんな背景もありコードレビューの大切さを日々痛感しておりますので、今回はデザイナーの開発環境の紹介としてコードレビューを取り上げたいと思います。

デザイナーもコードレビューをする時代

ドワンゴのデザイナーも世間のデザイナーと同じくimage、HTML、CSS、JavaScript等を日々、編集してコミットしています。
新しいテンプレートエンジンの採用によりHTMLの記述方法が変わったり、自動化したり、コンポーネントなcss設計を考えたり、JavaScriptも日々進化していき新しく採用したフレームワークへの対応を求められます。

そういった背景もあり、デザイナー個人での対応は最早限界を迎えているといっても過言ではありません。特に何かを作業する時にデザイナー1人で悩むのもよくないと考えています。

  • この書き方でいいのか?
  • こういう記述そろそろいける?
  • プレフィックスつけておくべきか?
  • もっとイケてる命名ないかな?
  • react化したテンプレートがエラー吐いてる!

こういった悩みや疑問、事故が日々おこります。

そんな時にはコードレビューを行いましょう!
1人で悩むことがなくなりますし、コードレビューを行うことによって様々な効果があります。

コードレビューを行うメリット

  • 記述ミスによる表示の崩れやバグを減らすことが出来る!
  • 他人にコードを見せることにより可読性が上がる!
  • コーディング規約等の認識のズレを修正して共通の書き方に統一することができる!
  • コード上のコメントでエンジニアや他のデザイナーに指導を請う事ができる!

コード品質の向上や知識の共有という点を目的としてコードレビューしていく事でみんな幸せになります。

コードレビューする環境

ドワンゴのエンジニア、デザイナーはGitHub Enterpriseのアカウントが入社時に付与され、業務作業のコードレビューは会社のGithubアカウントを使って行っています。
Code Review02
Githubの導入前はsvnでのコミットを行っていましたが、もはやGithub無しではいられない体になっています。

エンタープライズ版でないGithubアカウントは無料で使えるFreeプランもあります。
Code Review03

※Github無料ユーザはプライベートリポジトリが作れません。無料での利用はリポジトリが公開されますのでご注意ください。

他にもweb公開型のGitホスティングサービスはAssemblaBitBucketといった物もあるので、それらを試してみるのも良いかもしれません。
今回はGithubのスクリーンショットでコードレビューをご紹介します。Githubの取り扱いに関してはまたの機会に詳しくご紹介したいと思います。

コードレビューのポイント

コードレビューする際に気をつけているポイントをご紹介します。

レビュワーを決める/お願いする

チームミーティングや簡単な相談を事前に行い、
「hogehogeの案件でfugafugaなclassを修正したんでレビューお願いします!」
そんなやり取りをしましょう。コードを見る側にも予定や都合はあるのです。

JavaScriptやReactテンプレートを修正した場合はフロントエンドなエンジニアさんにレビュワーをお願いする事も多いです。(いつもお世話になっております)

必ず手元のブラウザでの表示確認(or動作確認)、査読を行う

これからコードを見てもらうというのに出す側が表示確認とコードの査読を行っていないという状況はあり得ません。プルリクエストのコメント欄に確認環境のURLを記述して実際にブラウザで表示できる環境を見てもらう努力も行いましょう。

セルフチェックを必ず行いケアレスミスがないかの確認することが鉄則です。

記述した箇所の簡単な説明をレビュー前に行う

Code Review05
書いた側がわかっていてもレビュワーは初めて見るコードかもしれませんので、レビュワーが見やすいようにコードの変更箇所に簡単な説明を記述しましょう。

事前にコーディングスタイルについて決めておく

事前にある程度のコーディングスタイルを統一する為の資料があるとコードレビュー時の認識をあわせる事ができます。
できればHTML、CSS、JavaScriptといった物を扱うデザイナー、フロントエンドエンジニア間で共通の認識をあわせる会を開いて資料を策定するといいと思います。

現在のチームでは、

HTMLガイドライン基本方針 CSSガイドライン基本方針
  • 文書形式
  • HTML5からの新要素で利用を推奨する機能
  • HTML5未対応ブラウザ向けへの対応
  • 正当なHTMLで記述する
  • セマンティックなマークアップ
  • 情報の並び
  • マルチメディアの代替コンテンツ
  • 文書形式
  • 正当なCSSで記述する
  • プロパティ記述順序
  • タイプセレクタ
  • IDとクラスの命名
  • 単位
  • 接頭辞付きプロパティ

等を資料として作成し共有を行っています。(この辺りもコードレビューから外れるので割愛します。)

レビュワーからの指摘に対応しつつ修正コードをコミット

Code Review06
コードにコメントが貰えるとGithubに登録したメールに通知が届きます。
それに返答をコメントしつつ、修正をコミットしていきましょう。

セルフマージはしない

コードを見て貰った人に必ずマージボタンを押してもらいましょう。
Code Review07
これは見る側にも責任を持ってもらう為であり、コードの記述ミスを個人が背負わない為の措置であります。(緊急時は別かもしれません)
レビューしてコードを入れたことよって起こる不具合はチーム全体の責任として皆で背負い、再発を防止するという形が理想だと考えてます。

私たちのチームでは現在このような形でデザイナー間だけでなくエンジニアともコードレビューをする環境で作業を行っています。

最後に

今回はドワンゴデザイナーの環境の紹介としてコードレビュー取り上げてみました。

コードレビューはチームによって流れややり方が違うところもあると思います。一例としてご紹介しましたので、チームの形にあったコードレビューを見つけてみるといいと思います。開発チームの中で作業しているデザイナーだからこそ、一部の人間だけがわかる記述ではなく周囲のエンジニア・デザイナーに共有していく方法を模索していきたいものですね。

文中で触れた、

  • デザイナーのgithubの取り扱い方
  • コーディングスタイルについて
  • react難しい

この辺りはまた触れる機会があるかなと思います。

デザイナー個人のgithubアカウントqiitaアカウントをお持ちの方はそのURLを添えてドワンゴのデザイナーに応募してみてください。

弊社クリエイティブセクションでは常に救世主を求めています!
一緒にコードレビューしていきましょう!

 

編集部オススメ

  • このエントリーをはてなブックマークに追加

あわせて読みたい記事

この記事を書いたメンバー

マカロフ

マカロフ

Designer

雪国生まれゲーム好きのデザイナー。

ドワンゴデザイナー メンバー募集 ! !