コードレビューのベストプラクティス | POSTD
Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上
「人間はどんな悪者にもなれる」脳科学者・中野信子が説く、“わかりやすさ”だけで判断する恐ろしさ
役割さえ与えられれば、人間はどんな悪者にもなれる 中野信子氏（以下、中野）：大衆に判断をゆだねることの恐ろしさについてもう少しお話していきましょう。 人は、自分のことを「正しい判断をするものだ」と無自覚に信じている。これは多くの実験が示唆しているところです。 例えば、ミルグラム実験と呼ばれる有名な実験があります。これは、閉鎖的な状況で、権威者の指示にどれだけ人間が従ってしまうものか、その心理状況を調べるために行われた実験です。 実験者、つまり権威者から「あなたは生徒役の被験者が課題を間違ったら、罰として電気ショックを加えてください」と依頼される。あらかじめ、自分でもその電気ショックがどんなものか、体験もしてもらいます。 生徒が一問間違えるごとに15ボルトずつ電圧を上げるように指示されるのですが、それぞれの電気ショックボタンには「ストロング・ショック」やそれを超えた「エクストリーム・インテン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
