2024/10/6
laprasdrum.icon 日曜まったり
/icons/hr.icon
生産的なコードレビュー文化を構築する
質の悪いコードレビューは人材とプロセスの妨げになる
優れたコード レビュー プロセスの主な目的は、コードの保守性と可読性を向上させながら、運用を中断することなくコードを出荷できるようにすることです。
コードレビュー文化を改善するための 9 つのアイデア
1. デフォルトで承認する
完璧だとわかるまでブロックするという考え方から始めるのではなく、「信頼しつつも検証する」アプローチを適用できます。作成者が問題に対処するために最善を尽くしたと信じているのであれば、承認する理由を見つけることから始めます。コードが安全で正しいことを確認するために調査を続けますが、この考え方の転換により、より協力的な雰囲気が生まれます。
2. 仕事よりもレビューの方が重要
コードレビューを優先するには、文化の転換が必要です。私たちは、大量のコードを書く「ロックスターエンジニア」を称賛する傾向がありますが、コードレビュー担当者は、実際には私たちが求めている 10 倍のエンジニアである可能性があります。
優れたコード レビュー担当者は、コードが安全であることを保証し、非常にコストのかかるインシデントを防ぐことができ、1 時間以内に複数のコード変更に対してそれを実行できます。
エンジニアとして、私はチーム内でコードの作成者とレビュー担当者の両方を務めていますが、作成よりもレビューを優先しています。誰かがコードを公開する準備ができたとき、私はそのコードが本番環境に到達する前の最後のステップを担当するため、自分のコードよりも彼らのコードの方が緊急になります。そのため、私は彼らの作業をレビューして迅速にリリースすることに重点を置いています。
私の会社では、コードレビューに 4 時間の サービス レベル目標 (SLO)を設定しています。これは、コードレビューを優先する当社の文化の証です。
3. やり取りを減らすために最適化する
コードレビューは非同期であるため、コストがかかります。数回のやり取りですぐに数日間の遅延が発生する可能性があります。コミュニケーションツールを変更し、明示的なコミュニケーションを使用すると、遅延のリスクを最小限に抑えることができます。
コミュニケーションツール: GitHub のようなツールを使用すると、提案や提案の適用が簡単になります 。ただし、コードレビューツールは会話するには遅すぎることがよくあります。レビューしているコードが理解できない場合や、複雑なアイデアを提案する必要がある場合は、Slackなどの同期通信に切り替えたり、運が良ければ実際のオフィスでのディスカッションに切り替えたりします。
明示的なコミュニケーション:私のフィードバックには、ブロック、オプション、および nit という3 つのキーで強調された明確な期待があります 。
ブロッキング: これは、コードが承認されていないことを意味します。たとえば、ユニット テストが欠落しているか、実際のバグがあります。
オプション: このコードはパフォーマンスを低下させる可能性がありますが、システムを壊すことはありません。たとえばcommit suggestionを実行するのは良い考えだと思いますが、私の提案を実行する予定がない場合でも、返信をいただければ幸いです。
Nit : これは、コードを改善するための影響の少ないアイデアがあるが、実行されなくても怒らないときです。これを引き起こす原因は、不適切な変数名である可能性があります。
4. 動作するコードの提案をする
間違いを指摘して自分の仕事は終わったと考えるのは簡単です。問題は、自分の考えを伝えた後、コードの作成者がそれを読んでコードの変更を考え、それを実行しなければならないことです。
代わりに、動作中のコードと一緒にフィードバックを提示すると、提案を理解して適用しやすくなります。変更を提案するときは、そのアイデアがコードを改善できる理由を説明します。これは、ジュニア エンジニアを指導する絶好の機会です。自分の考えについてできるだけ多くのコンテキストを提供し、自分の視点を裏付ける Web リソースへのリンクを貼ってください。
レビュー担当者の観点からすると、提案された変更の理由を示すことで、低品質のフィードバックのリスクが軽減されると思います。変更の説得力のある理由がない場合は、コメントを削除します。
誰もがこの考え方を採用すれば、コードから展開までの時間は大幅に短縮されるでしょう。
5. コードレビューの概要を述べる
一般的なレビューでは、コード全体にいくつかのコメントが付けられますが、全体的なトーンが読みにくい場合があります。いくつかの小さな変更を除いて、コードはほぼ準備ができていますか、それとも全体を徹底的に見直す必要がありますか?
要約を追加すると、作成者にレビュー担当者の意見をわかりやすく伝えるのに役立ちます。気に入った点、大幅な変更が必要と思われる点、コードレビューの妨げにならないための一般的なアドバイスなどを含める必要があります。
6. 質問として提案する
解決策を直接提案するのではなく、問題となっている点を質問として提示してみてください。質問をすると、協力的な会話が生まれることが多く、コード作成者が防御的になる可能性が減り、レビュー担当者が考え出した解決策よりも優れた解決策が見つかることがよくあります。
7. 楽しむ
コード レビューはストレスが多く、批判される可能性が非常に高い状況です。関係者全員が安心できるように最善を尽くしてください。これを実現するには、最も自然に感じる媒体を選択してください。私の場合、GIF や絵文字を使用する機会を逃すことはありません。
SwiftUI: 上下左右4方向無限ページング
いわゆる地図アプリとは違った。
なにかに使えるかもしれないので頭の片隅に入れておく。
UIImage(contentsOfFile:)はシステムキャッシュされない
UIImage(named:)の代用に。
画像を一度だけ表示し、システムのキャッシュに追加したくない場合は、代わりに imageWithContentsOfFile: メソッドを使用して画像を作成します。
一度だけ使用する画像をシステム イメージ キャッシュから除外すると、アプリのメモリ使用特性が改善される可能性があります。
Xcodeテスト設定
自分もよくやる設定書いてた
https://scrapbox.io/files/67047c60fffc6300224e956a.png
https://scrapbox.io/files/67047c6a0d82c3001dbc77fe.png
https://scrapbox.io/files/67047c7034c300001cc31f2c.png