コードレビューでコメントタグを使い、心理的安全性を担保しよう
こんにちは。リンクウェル対面診療システムチーム、テックリードの山本です。 今回はコードレビュー時に開発部で実施しているコメントタグのご紹介です。 多分イケてる開発チームではすでに取り組んでいる試みだとは思いつつも、今回はなぜ必要なのかを改めて考えてみたいと思います。 GitHubのプルリクレビューについて 弊社のコードレビューではまず第一に「要求を満たすよう動くこと」が重視されます。その上で次のような点に注視しながら指摘を行います。 外部サービスの特殊な挙動やセキュリティ機構などが考慮されているか。 不具合が発生した時に検知できるようになっているか。 将来的に修正しづらくなる構造になっていないか。 N+1問題などパフォーマンスに問題がないか。 その上でコメントを書く際に次のようにタグを付けて分類しています。 must: 絶対に直して欲しいとき。強い指摘になるので言葉遣いに気をつけるべき i
DB のスキーマ情報の差分と闘った話し (Rails)
みなさんこんにちは。 バックエンドエンジニアの豊永です。 今回は Rails を使ってるとよく遭遇すると思われる問題に対して、 Makefile を使って解決した話を共有しようと思います。 何が問題だったか？ Github の Pull Request 機能を利用して複数人でコードレビューを行いながら開発するシーンはよくあるかと思います。その際に、 rails db:migrate を実行し自分の開発用 DB にレビュー中のコードのスキーマ情報を適用してしまうことは無いでしょうか？ レビュー完了後、そのまま自分の開発に戻り Pull Request を出すと、身に覚えのないテーブル名が db/schema.rb に記述されていて驚くことがあります。 実は db/schema.rb は migration ファイルから直接生成されるものではなく、開発用 DB から生成される仕組みになっていま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
