2020/07/21 に弊社新卒向けに実施したコードレビュー研修の資料です。
When people talk about code reviews, they focus on the reviewer. But the developer who writes the code is just as important to the review as the person who reads it. There’s scarcely any guidance on preparing your code for review, so authors often screw up this process out of sheer ignorance. This article describes best practices for participating in a code review when you’re the author. In fact,
まえがき コードレビューの目的 大目的 小目的 チェックリスト 優先度高（大きな損失を生む問題・後からの修正が困難な問題） 優先度中 優先度低（システムに大きな影響を与えない問題・後からの修正が容易な問題） レビューを負担にしないために レビューサイズのコントロール 誰がレビューをするか 議論をどうまとめるか 批判と個人攻撃 レビュワー向けアドバイス Code author向けアドバイス 参考文献 まえがき コードレビューの有効性が説かれるようになって久しい。しかし、コードレビューをするべきという観念ばかりが先立ってしまい、何のためにコードレビューをするのか、どのような点をレビューするべきなのかといった、目的や進め方に対する意識が曖昧なケースも数多くあるように思われる[6]。コードレビューの目的を理解せずに惰性でレビューしているだけでは、いずれレビューそのものが形骸化し、単に承認のハンコを
Interesting. I would caution that some of the tips are very culture-dependent. For instance, the example of not criticizing the person - I would rather have someone tell me straight in my face "Your approach is adding unnecessary complexity" than go around in circles and word-dancing around it, I would appreciate the honesty and the respect for my time (the 2nd way of phrasing is longer. but more
チーム開発実践入門──共同作業を円滑に行うツール・メソッド WEB+DB PRESS plus 目次 目次 はじめに コードレビューツール GitHub Redmine Code Review プラグイン Review board Upsource Crucible コードレビューで注意すべきこと レビュワーは完璧主義にならない 可能であれば、コードレビューを開始する前にレビュワーを選び、大まかな設計方針を決めておく できるだけ良い部分は褒める コードレビューのサイズはできるだけ小さくする コードレビューの反応はできるだけ早くする コードスタイルはスタイルガイドに従う レビュワーがレビューで、確認すべきこと コメントは論理的に、そして礼儀をもって 良いコードレビューの作り方 コードレビューでよく使われる言葉 PR LGTM IMO Nit TL;DR. 参考資料 MyEnigma Supp
People & Culture 40 Favorite Interview Questions from Some of the Sharpest Folks We Know Given the high-stakes nature of every hire, interviewing chops are always in need of sharpening. We’ve spent the past few months reaching out to some of the most thoughtful company builders in our network to pose a simple question: What’s your favorite interview question to ask and why? Here are the Here at Fi
Google Engineering Practices Documentation Google has many generalized engineering practices that cover all languages and all projects. These documents represent our collective experience of various best practices that we have developed over time. It is possible that open source projects or other organizations would benefit from this knowledge, so we work to make it available publicly when possibl
2021-10-17 追加 弊社の Android 採用課題も公開されましたので、そのリンクを追加しました。 2020-05-18 追加 本日から弊社の採用課題がこちらに変更されました。これまではアプリをゼロから作成していただく課題でしたが、今後は既存のコードをリファクタリングしてもらう課題となりました。ただし我々が確認する項目はそれほど大きく変更するわけではありませんので、本記事の内容の多くは引き続き有効です。 ここ数ヶ月は、iOS のエンジニア採用のコードチェックにもよく参加していますので、そろそろ良さそうと思って、ここで私がコードチェックする時に一体何をチェックしているのかを共有し、皆さんの転職活動やキャリア設計に役に立てればと思います。 Disclaimer この記事の内容はあくまで株式会社ゆめみの iOS エンジニア採用のものです。弊社以外の iOS エンジニア採用や、弊社でも
As a frequent contributor to open source projects (both within and beyond Red Hat), I find one of the most common time-wasters is dealing with code reviews of my submitted code that are negative or obstructive and yet essentially subjective or argumentative in nature. I see this most often when submitting to projects where the maintainer doesn't like the change, for whatever reason. In the best ca
最近、Markdownからpdfを作る機会がありました。 pdf化を都度行うのは手間だったため、何か良い方法がないかを探したところ、 Markdown > Re:VIEW > pdf という経路でpdfを作成できそうでした。 ただ、手動でpdfを生成するのが手間だったため、GitLab CIを使って、push後にMarkdownをtextlintしてからpdf化するCI環境を作ってみました。 目次 環境 GitLab CIの設定ファイル .gitlab-ci.yml の作成 ステージを定義 ジョブを定義 ジョブ「対象のMarkdownにtextlintを実行」の詳細を定義 ジョブ「Markdownをpdf化する」の詳細を定義 textlint向けの定義 prh.yml .textlintrc review-pdfmaker向けの設定 config.ymlの設定 pdf化するコンテンツの設定
はじめに 最初に言っておきますが、とくにスカっと結論が出るような話ではないです。 昨日ふと「行為の否定」を「人格の否定」と捉える人がどれだけの割合でいるのか、人格の否定ととらえた場合はどういう感情が湧くのだろうか、ということに興味があってtwitterでアンケートを取ってみました。 わたしはソフトウェア開発に携わっていて、かつ、フォロワーも同業が多いだろうということで、コードレビュー*1を題材にしました。 コードレビューで「このコードはこういう理由で駄目です」と言われたらどう思うか。ここで理由は妥当なもの(仕様を守っていないなど)であり、かつ、口調や優しくも厳しくもないニュートラルなものとする。わたしは「感情に変化は無い」かな— sat (@satoru_takeuchi) 2019年3月20日 「50-60人くらい答えてくれたら面白いな～」と思っていたのですが、最終的には3705人もの人
役立つコードレビュー（CR）のコツは、学校では習いません。アルゴリズム、データ構造、プログラム言語の基礎は習っても、確実に役に立つフィードバックを返す方法をじっくりと教えてくれる人はいないでしょう。 コードレビューは優れたソフトウェアを作り出すには欠かせないプロセスです。レビューを通したコードは、そうでないコードよりも 質が高く、バグが少ない 傾向があります。健全なコードレビュー文化には、副次的な利点もあります。たとえば、 バス因子 を押しとどめる、新メンバーのトレーニングに最適なツールになる、など。また、コードレビューは優れた知識共有の手段でもあります。 前提 まずは、この記事のポイントの前提を提示する必要があるでしょう。それは以下のとおりです。 信頼のおける環境で作業をしている。あるいは、あなたとチームは、あなたの信頼性を高めることを目指して作業している。 コードではないシナリオでフィ
ある程度アプリケーションの規模が大きくなってくると、ある変更がどこまでの影響範囲だと思っているのかがコミュニケーションにおいて重要
In the classic management book High Output Management Andy Grove argues that “training is the manager’s job” because it’s the highest leverage activity a manager can do to increase the output of their organisation. It’s still great advice for managers applicable across most teams, but for the manager of the modern software development team the fulcrum point has shifted. The code review, usually pe
技術ブログの方に書くか迷ったのですが、かなりポエムの類な文章になりそうなのでこちらに書きます。 ちょっと前にバズったこちらの記事 medium.com に触発されました。 ちなみにコードレビューに関する話としてはまだ僕が色々と手探りだった3年前にもこんなことを書いていたようです。3年前の自分の考えに触れられるブログって面白いなという気持ちとこいつどんだけ軽率な文章書いてんだよという気持ちが合わさり甘酸っぱい気持ちが生み出されました。 hachibeechan.hateblo.jp 当時と今では日本全体の技術的トレンドも変わっていますし、そもそも僕の所属している会社も違います。今の会社ではGitHubを使っており、コードレビューが当然のフローとして組み込まれています。 そしていま改めて当時のブログを読み返したのですが、びっくりするほどコードレビューに対する僕の考えが変わっていないので、改めて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
