良いソフトウェアとコードレビュー / Good software and code reviewScala + Caliban で作るGraphQL バックエンド / Making GraphQL Backend with Scala + Caliban
「妥協しないコードレビュー」をテーマとした勉強会を開催しました - ブログ
ソニックガーデンでは、数年前から「SGTech」と称した社内LT会を継続的に行っています。今回、社内の若手プログラマに社外で登壇する経験を増やしてもらうという目的で、これまでの勉強会を社外に開いたオンライン勉強会である「エンジニアのためのスキルアップ勉強会」を開催する運びとなりました。 2023年12月14日に開催した第1回目の勉強会には、317名の方の応募が集まりました。こちらの記事では、実際のイベントの様子と、登壇したメンバーについて紹介していきます。 LT#1 「レビュアーとして成長するには」 1人目の発表者は、2022年4月に弊社に入社し、現在は岡山のオフィスでプログラマとして働いている橋本です。レビュアーとして成長するための技術書の選び方やレビューの受け方、レビュアー初心者がレビューをするためのコツなどについて発表しました。 発表中、読んでいて苦しい技術書と楽しい技術書の違いにつ
そのコードレビュー、使い捨てになっていませんか？
こんにちは。株式会社プラハCEOの松原です。 どんな人にこの記事を読んで欲しいか コードレビューの効率化に悩んでいる コードレビューのやり方に自信が持てず、何か参考になる事例を知りたい 使い捨てコードレビューに翻弄される日々 1~2年ほど前に自社サービスを開発していた頃、弊社では全てのプルリクエスト（以降PR）に対してランダムに割り当てられたレビュワー2名、もしくはテックリード1名にapproveされない限りマージしない運用で開発していました。開発者が5名ぐらいだったと記憶しているので、規模の割にはリッチなレビュー体制だったのではないでしょうか。 修正点があれば指摘して、直して、再確認して、merge。 来る日も来る日も、確認、指摘、修正、再確認、merge。 次第に「僕ら業務時間の大半をコードレビューに使ってね？」と、レビューに費やす時間が気になるようになってきたあたりで、一度自分たちの
コードレビュー ありがちな問題への対処例 - Crieit
コードレビュー、これまでいろんなプロジェクトで経験して、意外と使われていないノウハウがあったり、風習が違ってつらみがあったりしたので、いろいろまとめてみる。 指摘事項について よくある話 - 駄目コードを憎んで人を憎まず。駄目なのはコードであって人格じゃない - 指摘する人は人格攻撃せずにコードのどこが悪いのかを指摘しましょう - 指摘される人も、言われているのはコードの問題であって人間の問題じゃないので、素直な心で受け止めよう この辺はみんな知ってると思うので略。ぼくが思う大事なルール コードレビューで指摘された内容は、対応必須ではない 理由： 対応必須にすると、「これ言ったらリリースできなくなるよね」みたいな忖度が発生してコメントできない人が出現するから。 絶対ダメとは言わないけど、あまりよくはない、みたいな指摘については、そのときは急ぐからリリースするけど、次回から気をつけるとかがあ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Tama Ruby Kaigi 01
コードレビュー自動化の最前線から
