綺麗なコードを書くためのコードレビューチェックリスト - Qiita
綺麗なコードを書くためのコードレビューチェックリスト PR出す前にこの観点は必要だよねリストまとめ 1. 設計と仕様の整合性 コードが既存のシステム設計に一致しているか確認します。 例えば、MVCアーキテクチャを採用している場合、モデル、ビュー、コントローラーが適切に分離されているかをチェックします。 機能要件 コードが仕様書に記載された機能を正しく実装しているか確認 テストケースを使って期待される動作を検証すると効果的 非機能要件 パフォーマンス、セキュリティ、拡張性などの非機能要件も満たしているかをチェックし YAGNI（You Aren't Gonna Need It）の原則 必要な機能だけを実装し、将来の要求に備えて無駄な機能を追加しない。これはコードの複雑さを減らし、保守性を高めます。 オブジェクト指向設計の原則 単一責任の原則 (Single Responsibility Pr
テストコードを書く上で個人的に気をつけている5つのこと - Qiita
はじめに エンジニアの皆様、テストコードはちゃんと書けておりますでしょうか？（挨拶） どんな開発言語や開発手法を導入していたとしても、アプリケーションの機能実装とテストは表裏一体であると言えます。場合によっては機能の作り込みよりも時間をかけるべきケースが多いくらい重要である（・・・と信じたい）反面、デッドラインが近づくにつれて真っ先に工数が削られやすく軽視されがちな工程でもあります。 時間に追われてテストコードを書いた結果、テストの体をなしていないコードになっていたり後で見返したときに記述が煩雑すぎてメンテ不能になっていたり・・・といった苦い経験は誰しもがあるかと思います。かくいう自分もそんなことは多々ありました。 そんな今までの経験則を基に「自分がテストコードを書くにあたってどんなことを意識しているのか？」をいくつかピックアップして備忘録も兼ねて紹介したいと思います。 一応注意なのですが
組織のコード品質を向上させる “レビューシステム”の取り組み
dmm.go #6 の登壇資料です。 https://dmm.connpass.com/event/295065/
フリーランス歴20年の強強エンジニアからのガチコードレビュー集 - Qiita
はじめに こんにちは、まつけんです。 早いもので、Webエンジニアになって、10ヶ月経とうとしています。 先月末、僕の職場に参画していたフリーランス歴20年の強強エンジニアCさんが卒業されました。（以降Cさんと称します） Cさんには、いつも迅速かつ丁寧なレビューをしていただいてました。 たまに補助で僕のプルリクにコミットを積んでもらうことなどもあり、お世話になった記憶が大半です。 今回はそんなCさんから受けたコードレビューから、今後どう改善していくのかアウトプットして学びを深めたいため、こちらの記事を書きました。 ペアプロしている時の参考になったこともおまけで書いてます。 ※こちらの記事に出てくるコードに関しては全てRubyです。実務で学んだことなので、出てくるコードは全てフィクションです。(実際のサービスのコードではないです) レビュー1: migrationファイルを追加する時「db:
コードレビューにラベルを付けるだけでチームの心理的安全性を高めた話
ハコベルシステム開発部のおおいし (@bicstone) です。普段はフロントエンドエンジニアとして物流DX SaaSプロダクトの開発を行なっています。 この記事ではハコベルの開発チームが心理的安全性の向上を目的に採用した、プルリクエスト (マージリクエスト) コメントにラベルを付ける手法についてご紹介します。 背景 プルリクエストをレビューする時、レビュアーとして上から目線になってしまい相手を傷つけないか緊張したり、ちょっとした確認のつもりで書いたコメントが修正必須と捉えられてしまったりした経験はないでしょうか。 本来、ピアレビューは対等な関係であるはずなのに、レビューする側の方が上になってしまいお互いに恐縮してしまいがちです。「勘だと怪しいけど間違っていたら怖いから言えないな」や、「将来的に辛くなりそうな実装だけどわざわざ指摘するほどでもないな」など荒波を立てずにApproveしてしま
知らないと恥ずかしいコードレビューで指摘されがちなポイント14選 - Qiita
この記事はNuco Advent Calendar 2022の13日目の記事です はじめに 私は情報系の学部に通う大学４年生です。大学でプログラミングを学んだことをきっかけに、プログラミングを使用した実際の業務に取り組んでみたいと思いました。そして、株式会社Nucoさんで機会をいただき、現在インターン生として実務に参加させていただいています。 自分のように、プログラミングを学び、「実務の経験が積みたい」「インターンに参加してみたい」という方はたくさんいらっしゃるかと思います。この記事では自分が実際にインターン生として実務に参加し、コードレビューで指摘されたポイントを紹介します。 難易度、頻出度の目安を★の数で示しています。 ・難易度・・・それぞれの項目で指摘されないようなコードを書く難しさ。 ・頻出度・・・それぞれの項目のミスの起きやすさ。 難易度(低→高)、頻出度(高→低)の順番で紹介し
コードレビューで嫌われる人の特徴7選 - Qiita
「コードレビュー・・・うっ頭が」となっているそこのアナタへ。 先週弊社キカガクで人生初の実務コードレビュー体験をしました。 控えめに言って最高すぎました。 お互いが「気持ちよく・効率的に」学びを深められるように組まれた一級品のレビュー構成。 細部に渡る心遣いとテクニックの為せる技だと思いました。 そこで私は考えた ー。 真逆のことをしたらどうなるんだろう？ 想像してみたらなかなかブラックな開発環境が脳内で出来上がりました （大学時代のコードレビュー現場そっくりだなと思ったのは内緒）。 自分がコードレビューに参加する時こうはなるまいぞいう戒めを込めて紹介していこうと思います。 具体的な改善案も5選紹介しています。 共に愛され系コードレビュアー ＆ レビューイを目指しましょう！ 想定している対象読者 「もうすぐ初めてコードレビューを受ける予定で不安・・・」 「コードレビューを行うことになったけ
WEBサービス開発歴約6ヶ月の私が受けたコードレビューをまとめてみた - Qiita
はじめに WEBサービス開発に関わって約6ヶ月のにこと申します！ さて、ここで質問です。 あなたは初めてコードレビューを受けたときのことを覚えていますか？ 覚えていますよね？ ・・・え、覚えていない？ そしたらこの記事はもしかしたらあなたが駆け出しエンジニアのあの時の頃を思い出させてくれるかもしれません・・・。 私はコードレビューを受けた時に衝撃を受けました。 こんな書き方が出来るとは・・・。私はなんとおブスなコードをかいていたんだろうと・・・。 レビューを受けてから良いコードを書けるようにより意識をするようになりました。（実際にきちんと出来ているかどうかはまた別のお話） そしてこのコードレビューを自分の中だけで留めておくのはもったいない！！という気持ちと振り返りのためにまとめました。 これからエンジニアになろうとしている方、私と同じくまだ実務経験が浅い方、そして初心の気持ちを思い出したい
レビューする人も、される人も知っておきたい！開発プロセスごとのレビュー観点チェックリスト - Qiita
この記事はモチベーションクラウドシリーズのアドベントカレンダー7日目の記事です。 こんにちは。リンクアンドモチベーション、モチベーションクラウド開発チームの江上です。 モチベーションクラウドの開発チームは、新卒メンバーも多数参加していることもあり、開発プロセスを細かめに定義しています。その開発プロセスにおいてそれぞれに、「レビュー観点チェックリスト」を作成しているので、それを公開していきたいと思います。 全てのチームで有効とはいかないものの、何かの気付きになればいいなと思います。また、「こういう観点もあるよね」というFBは大歓迎ですのでぜひよろしくお願いします。 開発プロセスの定義 現状の開発プロセス 現在モチベーションクラウドの開発チームは以下のようなプロセスを前提にして動いています。 関係者レビューは実際には実装のレビューに近しいですが、実装レビューはコードレビューと紐付けたいので、あ
レビュワーとしての心得 - Qiita
はじめに みなさんコードレビューしてますか？ 初めてレビュワーとして挑戦するコードレビューはなかなかハードルが高いものです。 私が所属している開発チームは全員がレビュワーとしてコードレビューに参加するのですが、新しく参入してきた人はやはり戸惑ってしまいます。 ここでは弊チームのレビュワーとしてのお気持ち的な心得を大公開しちゃいます！ マサカリなどなどあると思いますが、誰かの参考になれば幸いです。 1. レビュイーをリスペクトしよう！ まずはコードを修正してくれた人に感謝しリスペクトしましょう！ 相手も人間なので、不必要に貶めたりしないようにしましょう！ 2. プルリクが大きすぎても頑張る！ たまにトンデモなく大きなプルリクが飛んできます...。 来ちゃったものはしょうがないので、一生懸命にレビューしましょう！ 作った側もやっちゃったなーとか思ってるはずです！ いつまでもプルリクを見られない
【コードレビュー】レビュアーの心構え - Qiita
はじめに 業務中、ふと「雰囲気でコードレビューしてしまっている」ということを自覚しました。 そこで、コードレビューにおいて気をつけていること、こうすればさらに良くなりそう！を言語化してみました。 「雰囲気レビューを卒業したい」、「コードレビューの質を向上・体系化したい」といった方はぜひ読んでみてください。 ✊ レビュアーの役割 レビュアーが果たすべき重要な役割として、システムの品質を保証することが挙げられます。 要件不十分 不具合 コード品質低下 などの発生責任は、レビュアーにも共有されます。 それらの発生を防ぐために、レビュアーが心がけるべきことをについて書いていきます。 👀 コードレビューの視点 コードレビューのときに特に見るべき観点は、大きく分けると以下の３つです。 仕様を満たしているか バグが含まれていないか コードの品質が低くないか 1と2は言わずもがな重要です。死ぬ気で見まし
メンバーに恨まれそうな3つのコードレビュー施策を徹底したら、逆にメンバーが爆速で成長した話 - Qiita
ある程度経験を積んだレビュワーがやりがちな失敗は、 指摘しやすいコーディング規約違反だけ指摘している というもの。 コードレビューで指摘するべき欠陥とは、必ずしも規約違反だけではなく、 仕様考慮もれや機能的なバグ、非機能的なセキュリティやパフォーマンス上の問題点も含まれる。 一つ関数に対して複数の視点でソースチェックをしないといけないが、 人間は同時に複数のことは考えられない。 そこでどうすればいいかと情報をあさっていたところ、 われらがIPAがセキュアプログラミング講座というWEBページで、 四回に分けてレビューすることを提唱していた。 １回目はどこに何があるか、 ２回目は可読性が確保されているか、規約にのっとっているか ３回目は機能性 ４回目はセキュリティ といった具合である。 IPAの講座では４回目はセキュリティに限定しているが、 担当していたプロダクトは、非機能面はセキュリティはも
コードレビュー虎の巻 - Qiita
レビューガイドライン(Review GuideLine) ここで述べているレビューはピアレビューについての方法です。 （作業成果物の欠陥と改善の機会を探すレビュー） 「最悪を最初に」を基本としてレビューすべき、 たとえば、仕様やアルゴリズムに欠陥があるのに、typoにこだわってもしょうがないので、なにが最悪かを考え、それを防ぐための物からレビューをします。 誤りがプロダクト全体に影響し、手戻りのコストが高くつく、あるいは失敗するようなリスクがないかを考慮にいれてレビューの対象を選択します。 たとえば、基本的な初期フェーズの要求仕様や、クリティカルな決定の基礎になる仕様、使用頻度が高いモジュールなどを重点的にレビューします。 以下に書く項目はレビュアーに負担をかけないようにするのが前提なのでレビュアーに出す前にそもそもテストしたい項目です。 参考： あなたのおっしゃるレビューってどのことかし
たのしくなるコードレビュー - クックパッド開発者ブログ
こんにちは！サービス開発部でAndroidアプリの開発をしているこまたつ（@k0matatsu）です。 みなさんコードレビューしていますか？ 最近ではとりいれているチームも多いと思いますが、良い効果をもたらしてくれる一方で、負荷の高い作業でもあります。 また、コードレビュー自体に馴染みの薄かった人はなにをどうしたらいいのか難しいですよね。 同僚から得たアドバイスと自分なりのノウハウをあわせて、コードレビューの指針を考えていたので公開してみようと思います。 前提として、クックパッドではGitHub Enterpriseとプルリクエストを使った開発プロセスを採用しています。 また、コードレビューの前には自動テストと静的解析ツールによる単純なフォーマット、コードスタイル、頻出バグのチェックは行われているものとします。 静的解析による機械的なチェックはコードレビューよりも低コストで有効な方法ですの
コードレビューの極意。それは「自分のことは棚に上げる」こと！！ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに：コードを良くするためなら遠慮は不要 昨日Twitterに投稿した内容が思った以上に拡散されていたので、タイムラインに流れてしまわないようにQiitaにも書いておきます。 内容は上に書いてあるとおりです。 コードレビューはコードの問題点を指摘し、そのコードを良くすることが第一の目的です。 そのため、少しでもおかしいと思った部分は遠慮せずにどんどんツッコむ必要があります。 しかし、レビューする側が「これ、自分もあまりできてないんだよなあ」「お前もできてないじゃん！って言われたら返す言葉もないし・・・」などと思って遠慮してしまうと、
Android開発のコードレビューbotを乗り換えた話 - クックパッド開発者ブログ
モバイル開発で利用しているコードレビューbotを最近乗り換えた話をします。 コードレビューbotとは コードレビューbotはPull Request(以下PR)に対して、静的解析した結果などをコメントする機能を持つプログラムの事を指します。 コードレビューbotを導入すると、些末な内容はbotが勝手に指摘してくれるため、レビューワーがより重要な内容のレビューに時間を使うことが期待できます。 有名なサービスにHoundやSideCIなどがあります。 Android開発でのレビューbotの役割 CookpadのAndroid開発では、下記の項目をPR毎に実行しています。 PRのマイルストーンチェック FindBugsを利用した静的解析 AndroidLintを利用した静的解析 license-tools-pluginを利用したOSSライセンス情報のチェック アプリのビルド deploygate
コードレビューを会話しながら行う取り組み - Hatena Developer Blog
こんにちは。アプリケーションエンジニアの id:itchynyです。 今回は、コードレビューを会話しながら行う取り組みについて紹介します。 コードレビューは大事なコミュニケーションの場です。 コードレビューの効用としては、単純なミスがあるコードをリリースしない・プロダクトのコードの品質をよりよくしていく、あるいはその方策を模索するといったことが挙げられます。 こういったことは当然のことですが、なによりもまず、レビューというのは一緒にプロダクトを作っている仲間とのコミュニケーションの場だと思います。 多くの人は、プロダクトのコードをよくしていきたい、読みやすいコードを書きたい、分かりやすいコードで目的の機能を作りたいといった共通の思いを持っていることでしょう。 コードを書いた人の思いを汲み取りながら、共感したり、譲歩したりしながら、よりよい方法を提示していきます。 それでも時には、どういうコ
[翻訳] コードレビューについて
この記事は::..: glen.nu :.: ramblings :.: on code review :.::の意訳記事です。@9len氏の許可を受けて投稿しています。誤り・修正などがありましたら、@iwashi86までご連絡いただけますと幸いです。 This article originally appeared in English at :..:: GLEN D SANFORD :.: RAMBLINGS :.: ON CODE REVIEW ::..: and has been translated with @9len’s permission for posting to this blog in Japanese. この記事は2014年3月に書いている。Twitterでユーザ検索チームを私が率いていたころの話だ。この記事は、コードレビューに関するセオリー・アプローチを体系化
![[翻訳] コードレビューについて](https://cdn-ak-scissors.b.st-hatena.com/image/square/4b2b513cd4b9941cd623836a282bad7afa76c330/height=288;version=1;width=512/https%3A%2F%2Fiwashi.co%2Fassets%2Fimages%2Fogp-min.png)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
良いソフトウェアとコードレビュー / Good software and code review
新卒2年目が鍛えられたコードレビュー道場 #jjug_ccc #ccc_l3
