はじめに
お久しぶり？です、筆者です。
最近筆者が勤める会社にて、HTMLとCSSのレビューを受ける機会がありました。
会社ではこれまでC#やJavaScriptのレビューしか受けた事がなく…。
また、レビュー者もこれまでのレビュー者とは異なる方であり。
HTMLやCSSの知識も付きましたが…。
異なる方々のレビューを受け、 レビュアーによるレビューの質の違い をまざまざと感じました。
結論から言うと、両者ともレビューの質は良かった様に思えます。
…が、両者とも「異なる方向性で」良いなぁと感じましたため。
今回の記事ではこれらの違い等を書いていければと思います。
((結構容赦なく比較してるので、この記事をレビュー当人が見ない様に…と思いつつ…。
それではいきましょう。
両者の違い
まずは、レビュアーのざっくりとした方向性から。
C#とJavaScriptを見てくれた方(Aさん)と、HTML&CSSを見てくれた方(Bさん)2人の違いを端的に言うとこうです:
- Aさん: レビュイーの「成果物に対して」レビューをする
- Bさん: レビュイーの「技術力に対して」レビューをする
それぞれについてもう少し深く言うと…。
Aさんは「提示されたソースコードの範囲内でしか」レビューをしません。
それに反し、Bさんは「提示されたソースコードから伺えるその人の技術力を推察して」レビューをなされます。
もう少し深掘りしていきましょう…の前に。
両者とも実は、レビュー環境が違いますのでそちらの話から。
((2人とも異なるプロジェクトに所属してるので、レビュー体系が違うんですよね…。
2人のレビュー環境の違いについて
まず、AさんからのレビューはBitbucketのプルリクエストを用いて行っております。
BitbucketやGithubなどのコード管理が得意なツールをご利用の方は分かると思いますが…。
プルリクを投げると、マージ先のブランチとの差分が見られ、またコード一行一行に対するコメントが可能です。
先に述べた様に、Aさんが細かなレビューをしてくれるのはこの体系だからと言うのもあるかもですね。
次にBさんですが…はい、みんな大好き(筆者は大嫌い) Excel シートを使ってレビューしてくれます。
「コードの何行目に」「どんな指摘点があるか」を事細かに書いてくれます…。
個人的な意見としては…。
レビューされる側が「何行目に提示された指摘点があるのか」探すところから始まるので、ぶっちゃけめちゃ大変です。
個人的には言わずもがな、Bitbucketでのコードレビューの方が嬉しいです…。
Aさん(成果物に対してレビューするタイプ)について
成果物に対してレビューするタイプと評した様に、Aさんは「提示されたソースコード以上の事を言及しません」。
ソースコードの悪い点のみを指摘し、それ以外については何も伝える事はありません。
ｵｼﾞｻﾏによくいる「個人の技術力や成長に関して説法を解いたり」…なんてことはしません。
((Aさん自身はちょいｵｼﾞｻﾏな年齢です.
また、強い口調で何かを指摘する事なく「このコードはこう治しましょう」と伝えてくれるタイプです。
個人的にはこの「強い口調での指摘がない」と言うのはとても凄い事だと思います…。
また、コードに関する相談、特に「このコードとこのコード、何方がいいか？」的な相談をすると…。
「どっちがいいと思う？」や「こっちのコードにはどんなメリットがあると思う？」と問いかけ、相談者自身に考えさせる機会を与えてくれます。
もし、相談者がそこで詰まったらAさん自身の意見も聞かせてくれます。
ただし、Aさんは意見をくれるだけで決定はしません(Aさんが決定した方が合理的な場合を除く)。
あくまで決定させるのは筆者側と言うスタンスです。
この対応は、筆者が「自分で考え物事を決定するのが好きだから」そう対応している…と思います。
自分で決め切れない性格の方や、状況であればAさんはきちんと決めてくれると思います(多分)。
なお、付加情報として「Aさんは筆者の上司」でもあります。
PL兼PMの方であり、筆者のタスク管理もしてくれてるので…。
Bさんよりも筆者の技術力やキャパシティへの理解、仲の良さは異なります。
そのためか「筆者が自分で判断できそうなレビュー指摘点」については、判断を促す様なレビューをしてくれます。
※もちろんその回答が合っているかのレビュー付き
成長に寄与できる素敵なレビューをしてくれるなぁといつも感心してます…。
((それに、考えさせた方がレビュアーとしても楽な時もあるでしょうしね
また、相談をした際に話が煮詰まってきたり、互いにズレた認識をしてる事が察せられると「一度仕切り直して」「自分がどう感じてその話をしてるのか」を伝えてくれます。
((「僕はこう思ってるんだけど、筆者さんはどう感じてる？」という風に話してくれます
相談事になる様な事は、明確な答えがない場合もあるため…。
無駄な話をして気を揉んでいくのが防止され、効率的に話ができるいい手段だなぁと感じます。
また、Bさんと比較して「口頭での指摘がほぼありません」。
レビューに関するやりとりは全てチャットで完結できるほどです。
この辺りは「Bitbucketのプルリクで行っている」レビュー環境に起因する部分も多いかもですがね…。
ただ、一つ気になる点としては「コードについて褒めたりすることがないこと」です。
「ここの書き方いいですね！」という様なコメントはしません。
筆者は「+の評価をしてくれると、それが自信に繋がり学習意欲にも繋がる」タイプなので…。 個人的な感想ですが、調子に乗らせない程度に評価してもらえたらもっと良いなと思います。
((こうして書くと、Aさんレビュアーとして優秀すぎますね….
Bさん(技術力に対してレビューするタイプ)について
技術力に対してレビューすると称した様に、Bさんは「提示されたソースコードから窺い知れる技術力」にレビューをする傾向が見られます。
レビュー対象分野がHTML&CSSという「ど素人が適当に書いても見た目的には整ってしまう」物であり…。
「デザインの意図や今後の改修性を考慮して書かれたコードであるかどうかを見ている」
= 「提示されたコードがどんな意味を持って書かれているコードなのかを推察してレビューする必要がある」
…からこそ、コードよりも「どういう意図を持ってこのコードを書いたか」に重きをおいたレビューをしているからしれません。
もちろん、見た目が整っているだけのコードがレビューを通るはずもなく…。
その様なコードを提示しレビューをされた時は:
- HTMLのdivタグはタグが示すdivisionと言う意味を考えて付けて欲しい、例えばこのタグは〜
- CSSのmax-width属性は「width属性で指定した値が相対値である時に」「この値以上は広がって欲しくない時に使うもの」であるので、max-widthに相対値を付けるのはよくない
…など、タグや属性が持つ考え方や意味をという指摘が多くありました。
個人的には、概念や考え方レベルで話してくれると理解が深まるので、ありがたい限りです。
((その分レビューに時間をかけちゃいますが…
また、先の様な深いレビューがあるからか…口頭でのレビューが多い印象もあります。
個人的には、口頭で伝えてくれる知識は非常に深イイ物ばかりなのであまり気に留めてはないです。
((こちら側が求めることなく深い知識を伝えてくれるのは、ありがたい事です….
それに、先に挙げた様な深い知識を文章に起こすのは大変でしょうしね。
なお、口頭レビューの内容はそこまで重要じゃないためか、「ソースコードの何行目にどんな指摘があるか」が記載されてるレビュー結果シートにはその内容が書かれる事はまれです。
「キチンと書いてくれよ！」と思わなくも無いですが、「口頭でのみ伝えられた指摘点が修正されてないからと言って再度ツッコミが来る」事は今のとこないので…。
「最低限これだけ修正すればOK」な事が書いてあるシートが別途あるのは個人的にはありがたいです。
ちなみに…。
Bさんはコードについて相談事をすると「相談事の範囲から少しズレた大きな話」までしてくれる事が多いです。
…まぁ、欠点としては言わずもがな、「業務時間を無駄に取られる」事ですかね。
レビューされる側の所感
※ここからは、筆者の率直な感想が記されています。
あくまで一個人の感想として、捉えていただければと思います。
総合的に見て、筆者はBさんのレビュー体系の方が好きです。
レビュー環境(プルリク方式)もそうですが、必要最低限のレビューしかしないBさんの方式の方が、レビューをする側もされる側も負担が少ないなぁと。
また、Aさんのレビューは基本「文書ベースで解決する」と言うのもいいなと。
口頭でのやりとりが少ないので、緊急事態に陥り遠隔地からしか仕事できなくなった！…と言うような状態でも、Bさんの様なレビューなら受けやすそうだなと感じます。
技術力的な成長に繋がるのは確実にBさんであると思います。
「こちらが聞かずとも、ためになる知識を勝手に供給してくれる」方というのはとても貴重だと感じます…。
ただ、あまり学習意欲のない方があのレビューを受けると苦痛だろうなとは思います。 筆者は日頃から学習意欲旺盛な様に周りから見られているっぽいので、その様にレビューしただけかもしれませんが。
Bさんが「学習意欲が無さそうな方には、相応のレビューをされる」様な方なら、レビュアーとして最高だろうなと感じます。
おわりに
今回は異なる性質を持つレビュー者の違いについて、自分の思いを書いてみました。
今後、もしまた何か感じる事あれば別途記事化して投下したいと思います。
それでは|дﾟ).
