2024/10/3

/icons/hr.icon

広告単価設定の基礎

開発者視点では広告 = 悪一辺倒の人が多いけど、リファラル・収益分析を始めると広告の基礎を知りたくなってきた。

CPC/CPVの概念を調べてる最中。

SwiftUI Previewの代わりにXcode Playgroundを使う

SwiftUI Previewがたまに壊れることがある（ビルド時のTimeoutやそれ以外の不思議な（確認できない）理由で）ので、Xcode Playgroundを使うという案。

code:Preview.swift

import PlaygroundSupport

import SwiftUI

struct MyView: View {

// your view here

}

let view = MyView()

PlaygroundPage.current.setLiveView(view)

効果的なコードレビュー

よいtipsと哲学がまとまってた。読み返す。

コードレビューの良し悪しを決めるものは何でしょうか?

適切なコードレビューにより、明確さが増し、コードが開始時よりも良い状態になります。

レビュー担当者にとって、コミュニケーションの明確さは重要です。コメントのどれが個人的な好みで、どれが承認の妨げになるのかを明確にする必要があります。コードレビューのレベルを高め、提案の意図をさらに明確にするために、提案するアプローチの例を示します。プルリクエストと同じリポジトリからの例を提供できるとさらに良いでしょう。これにより、一貫した実装が促進され、提案がさらに裏付けられます。

対照的に、質の低いコードレビューは明確さに欠けます。たとえば、コメントなしで全面的に承認または拒否すると、プルリクエストの作成者はレビューが徹底したものかどうか疑問に思う可能性があります。承認時にプルリクエストの作成者の意図を理解していることを再度伝えるだけでも、作成者と自分が同じ理解を持っているかどうかが明らかになります。

提案をいつ実装すべきかが明確でないコードレビューは、作成者にとって悪い経験になることもあります。既存の変更されていないコードをリファクタリングする必要がある、または追加のケースを処理する必要があることを指摘するのは問題ありませんが、それらが承認の前兆であるかどうかを明確にすることが重要です。プル リクエストを提案なしで送信しても問題ない場合は、必ずその旨を伝えてください。小さな差分を保持し、それらの変更を別のプル リクエストとして個別に送信した方が安全かもしれません。

良いコードレビューを行う方法

質問する

プル リクエストの作成者は、そのプル リクエストが行う変更について最も詳しいコンテキストを持っている人物だと私は考えています。私は自分の経歴 (Ruby on Rails モノリス、TypeScript、または大量のトラフィックが流入するデータベースでの作業経験) に基づいて、見つけた問題を指摘できますが、質問に対する作成者の回答を信頼しています。詳細に関する理解は私よりも優れていると考えています。

また、コード内での仮定に関する質問をすることも好きです。扱っているデータの形状はどのようなものですか? その形状と一致しないデータは存在しますか? コードはそれにうまく対応していますか? コードはリソースを大量に消費しますか? パフォーマンスは良好ですか? レビュー担当者として私が最も好む回答は、作成者がそれらのシナリオでの動作を検証する自動テストを提供することです。2 番目に好む回答は、データ ウェアハウスからのクエリや、それらのシナリオが問題ではない理由を示す Datadog グラフなどの経験的データです。

プル リクエストの作成者として、質問を受けるのはありがたいことです。誰かが質問すると、必要に応じて問題、クエリ、グラフを引用しながら、自分の変更に自信がある理由を説明する余地が生まれます。また、自分の知識や経験を他の人と共有することもできます。作成者は私の回答を見るだけでなく、過去の決定のコンテキストを追跡している可能性のある他のレビュー担当者や将来の読者も見ることが出来ます。

> Hint: コード ベースやチームに不慣れな場合は、コード レビューで質問して、テクノロジ スタックや、利用可能な内部ツールとライブラリについて学習してください。レビューするすべてのプル リクエストは、作成者が別のアプローチよりも特定のアプローチを好んだ理由を知るチャンスです。

肯定的な言葉を提供する

質問するだけでなく、プル リクエストで同意する部分にコメントするのも良い習慣です。これらのコメントにより、変更内容を読んで理解したことや、コード内の仮定を検証したことを強調できます。次に例をいくつか示します。

「このモジュールの他のクラスで使用されているパターンと一致しているようです。」

「これにテストを追加していただきありがとうございます！」

「以前よりもずっと読みやすくなりました。」

私の経験では、このようなコメントを受け取るのも、単純にうれしいことです。コード レビューを受けると、疲れを感じることがあります。複数の関係者から質問や提案を受けているときに、私に何も要求せず、私がこれまでに行った作業をサポートし、認めてくれるコメントをいくつか受け取ると、励みになります。

偏見や思い込みに注意する

レビュー担当者や、担当者が変更するコード領域に対する偏見が、レビューに影響を及ぼしがちです。特定の領域で作業している人や、ある程度の年功序列のある人に慣れて、その人は自分が何をしているかわかっていると思い込んでしまいますが、誰でも間違いを犯します。担当者の変更に目を配り、担当者の想定を確認したり、自分の想定を検証したりするために質問することで、問題が展開される前にそれを発見できます。

私はテストを書くことに力を入れています。テストを書くことで偏見がいくらかなくなるからです。コードが正しく動作するかをチェックするテストを書くときは、作者の言葉を鵜呑みにする必要はありません。テストが合格したかどうかだけを見ればよいのです。もちろん、テストを正しく実行できればの話ですが。😅

また、私は、ジュニア デベロッパーがコード レビューでシニア デベロッパーに質問することを強く支持しています。たとえ、質問が馬鹿げている、あるいは答えが明白だと思ったとしてもです。それがあなたにとって明白でなければ、それは正当なことです。他の人にとっても明白ではないでしょう。質問をして、作成者が答えを書き留めるスペースを作り、後から来る人のためにそのちょっとした教育を残しておきましょう。

承認するかどうか

私は自分のレビューを、他の人が製品を改善するのを阻止する障壁と見なしているので、良心的に承認を保留しています。個人的な好みがあり、作成者に実行してほしいオプションの変更を提案することもよくありますが、それだけに基づいて承認を保留することはありません。誰かのプル リクエストに対して提案がある場合でも、そのプル リクエストがそのままでは運用に支障をきたしたり、ユーザーに悪影響を与えたり、その他の問題を引き起こしたりしない場合は、そのコメント付きで承認します。作成者は、プル リクエストをマージする前に私のフィードバックに対応するか、別のブランチでフォローアップするかを選択できます。

コードをレビューするときは、提案の重要性を念頭に置いてください。提案に対応するためにリリースを遅らせる価値はありますか? 作成者がフィードバックを確認し、提案された変更を行い、CI、再レビュー、デプロイメント、そして最後にマージを待つというサイクル全体に価値があるでしょうか? 提案がないことで誰かの一日が悪くなることがなければ、提案された変更を行うかどうか、いつ行うかは作成者に決めさせましょう。

「変更をリクエスト」オプションは、レビュー担当者が戻って承認するまでプル リクエストのマージを中止します。私はめったに使用しません。通常、強引すぎると感じるからです。私はチームがプル リクエストをいつ承認すべきかを知っていると信じているので、私の代わりにチームメイトの承認で問題ありません。同様に、プル リクエストの作成者が私のフィードバックを尊重して検討し、他の誰かが承認したのに私が承認しなかったからといって盲目的にマージすることはないと信じています。私が「変更をリクエスト」オプションを選択するのは、差し迫ったセキュリティ上の問題があると考え、マージ前に私の懸念が伝わらないのではないかと心配なときだけです。

コードレビューを最大限に活用する方法

自分のコードを確認する

ドラフトプルリクエストを使用する

新しいプル リクエストを作成するときに、プル リクエストを下書きとして設定するオプションがあります。私は、レビューが必要かどうかを示すために、下書き段階を重視しています。たとえば、必要な CI ビルドが失敗している場合や、まだ完了していない場合は、下書きのままにします。他の人のプル リクエストにも同じことを期待する傾向があります。下書きの場合、作成者はレビューの準備ができていないと考えます。レビューの準備が整っているとマークされている場合は、十分な承認が得られていないことが、プル リクエストのデプロイを妨げている唯一の原因であると想定します。

ドラフト ステータスはプル リクエストが未完成であることを意味するため、マージの競合を解決したり、レビュー担当者のフィードバックに対応したりするときには、プル リクエストをドラフトに戻します。コードを変更する必要がある場合は、すでにレビューした人に負担をかけないように、まずプル リクエストをドラフトとしてマークします。プル リクエストを「準備完了」に戻すと、レビュー担当者に GitHub 通知が送信され、再度確認できるようになります。

慈悲深くあれ

「酢よりも蜂蜜でハエを捕まえる方がよい」という表現が思い浮かびます。私はプルリクエストのレビューが欲しいので、プルリクエストのコメントに返信するのが好きです。特にレビュー担当者に同意できない場合はそうです。レビューコメントに返信を書かなくても、同意を示すために👍を付けたり、❤感謝の気持ちを伝えるために。

レビュー担当者には、提案が忘れ去られることはないと信頼してもらいたいので、コメントを通じて常に最新情報を伝えています。既存のコードをさらにリファクタリングするなど、提案に同意する場合は、その旨を伝えつつ、現在のプル リクエストでその変更を行うことに反対することもあります。その後のプル リクエストでフィードバックに対応するときは、リンクを提供して、フィードバックが無視されなかったことをレビュー担当者に知らせます。

また、提案された変更を実装した後のプル リクエストでもタグ付けし、「これは、<以前のプル リクエスト URL> からの @so-and-so のフィードバックに対応しています」というメモを含めます。これにより、他の読者にコンテキストが提供され、元のレビュー担当者への感謝の気持ちが表され、アイデアの功績が認められます。

後のブランチでフィードバックに対処するという約束を守れば、レビュー担当者との信頼関係を築くのに役立ちます。レビュー担当者は、あなたが何かを不完全なまま残さないことを知っているので、今後のプル リクエストを安心して承認できるようになります。