タグ

reviewに関するusako1124のブックマーク (6)

  • 作業環境を快適に整えてくれる拡張機能のすすめ - Qiita

    はじめに こんにちは!アドカレの季節がやってきましたね🎄 筆者はフロントエンドエンジニアとして働いていますが、 作業効率を上げてくれる拡張機能やツールの存在って大きいな〜と感じております。 この記事では、開発時に役立つ便利な拡張機能やツールのご紹介をしていきたいと思います! Visual Studio Code拡張機能 indent-rainbow インデントに色付けをして視認性を高めてくれる機能です。 コードを書き進めていくとネストが深くなっていってインデントが分かりにくくなってしまうことがありますが、これを導入することでインデントのずれが気付きやすくなります。 Trailing Spaces 意図せぬスペースが入り込んでしまうとなかなか気付きにくいと思いますが、 Trailing Spacesを入れておけば末尾の不要なスペースを赤くハイライトして知らせてくれます。 Todo Tree

    作業環境を快適に整えてくれる拡張機能のすすめ - Qiita
  • プルリクエストへのコメントでは Text Blaze でラベルバッジをつけよう! - Qiita

    [imo] enumのswitch文ではdefaultは使用せずに全て網羅して記述した方が良いと思いますがいかがでしょうか。 将来的にcaseが追加され、そのcaseが網羅されていない際にコンパイラが検知してくれるためです。 defaultを使用した場合は、該当ケースが網羅されていなくてもそのケースはdefaultにながれてしまい、 バグが生まれる原因になりかねません。 ②ラベルを視認しやすくするためにバッジにする ①の方法をおこなうことで改善できるかと思いますが、より視認性をあげることができそうです。 たとえば、バッジ画像をつかう方法があります。 例えば、①のmustの場合は下記のようなものを使用します。 行なっていることは、Markdownの画像付与です。 ![review:must](https://img.shields.io/badge/review-must-red.svg)

    プルリクエストへのコメントでは Text Blaze でラベルバッジをつけよう! - Qiita
  • 心がけている PR の書き方とコードレビューについて

    私が普段心がけている PR の書き方やコードレビューの方法をご紹介しようと思います。 そもそもコードレビューってどうやるの、どういった観点でコードレビューをするのか、みたいなところは、わかりやすい記事がたくさんあるので、そちらを参照していだくと良いと思います。 この記事では、 PR の書き方やレビュアーにアサインされた際のコメントの仕方などをご紹介できればと思います。 1. PR を作成する Github に限定した PR の出し方を順を追って説明します。 下記の画像は PR を作成する際の例です。 ご参考までに。 (1) ブランチの設定をする 派生元のブランチと変更ブランチを正しく設定します。 (2) 説明を記入する フォーマットが決まっていればそれに従うようにします。 特に決まっていなければ、 Why , What を書くと良いと思います。 Why なぜこの PR が必要なのかを記載し

    心がけている PR の書き方とコードレビューについて
  • 僕がコードレビューの時に気をつけていること|su-

    いきなりがっつりとした記事を書くよりは慣れるために軽めの話を。 こんにちは、すーです。 今回は普段僕がコードレビュ(GitHubのPull Requestのレビュー)の時に気をつけていること、大切にしていることを書いてみます。 (※以降話は主にGitHubのPullRequest(PRと略します)上での話がメインだと捉えてもらえますと) 自分がレビューをするときまずは自分がレビュワーだった場合に、気をつけていることを。 ・ PRの概要、関連するIssueの内容をしっかり読む まずはじめにPRの概要や、関連するIssueの内容を確認します。 何も見ずにいきなりコードに目をやってしまうと的外れなレビューをしてしまう可能性もありますし、コードの善し悪しだけを追いがちになってしまいます。 どういう意図や背景があってこのPRが出されたのかを確認するのはとても大事になります。 ・ コメントに`[MUS

    僕がコードレビューの時に気をつけていること|su-
  • レビューは人に叩かれる場所ではない - Qiita

    元記事 自分のコードが批判される不安 一般にエンジニアは、自分の仕事の進行状況(コードの品質や生産性)を他人に見られ、評価されることを恐れます。 あるソースコード管理システムをGoogleが開発した際に、次のようなissueをもらっていました。 「特定のブランチを非表示にする機能を Google Code の Subversion に付与してもらえますか?」 「最初は世界に隠されていて、準備ができたときに公開されるオープンソース プロジェクトを作成できるようにすることはできますか?」 「こんにちは、コードをすべてゼロから書き直したいのですが、履歴をすべて消去してもらえますか?」 これらには「自分のコードや仕事の質を見極められる(誤解される)不安」が見て取れると思います。 自分のコードは完璧な部分だけ見て欲しい 完成されていないコードをみて自分を判断して欲しくない 昔の自分が書いたクソコード

    レビューは人に叩かれる場所ではない - Qiita
  • レビューの仕方

    Open8 勉強会で発表したレビューの仕方と心理的安全性の話しです。

    レビューの仕方
  • 1