Merpay Advent Calendar 2019 の22日目は、メルペイスマート払いチーム/Backend Engineer の @oinume がお送りします。今日はコードレビューについて自分が普段から実践していることを書いてみたいと思います。 はじめに 世の中にはコードレビューをする時の観点については数多く共有されていますが、より良いコードレビューをするためにはどうするのが良いか、というHOWについてのノウハウはあまりシェアされていないような気がしています。そのため、今日は自分なりに心がけているコードレビューのやり方と、ついでに気をつけている観点について書きたいと思います。 Slackを閉じる (これが本当に一番大事だと思っているので最初に持ってきたのですが)私は極端に集中力がないため、SlackのDesktop通知が来るとついついそれが気になって見てしまいます。コードレビューの
こんにちは。ゲーム・エンターテインメント事業本部の鈴木です。 AndAppの開発をしています。 今回は私たちのチームで使っているreviewdogについて、CIの設定やlinterの組み合わせなど、どのようにしてコードレビューに活用しているか紹介します。 reviewdogとは 一言でいうとコードレビューを補助してくれるコマンドラインツールです。 各種linterの実行結果を渡してあげると、Pull Requestなどの差分に関して警告された行を教えてくれます。 私たちのチームではほとんどがGo言語による開発なため、golintなどの結果を表示するために使っています。 開発はGitHub Enterprise上で行なっており、CircleCI Enterpriseからreviewdogを実行すると以下のような警告がPull Requestのレビューコメントとして付きます。 似たようなツール
tl;drコードレビューが上手く回って無くてチームが疲弊して辛かったよレビュアーの言い方を変えるだけで大体解決するよ立場とかで例外を許さず、みんながレビューしてレビューされると良いよはじめにあるプロジェクトでGitHubのPRベースでのコードレビューを導入をしました。いかんせんチーム開発が初めてレベルの新人さんが多く、何かと苦労しました。特にレビュイーに対して不効率な指摘はそのまま指示の不明確さに繋がり、チーム全体の開発生産性を下げるので、レビュアーはレビュイー以上に気を使う必要があると感じました。下手をすると、レビュイーのメンタルが弱って闇堕ちするので、チームメンバーの最も大人な人がメンタルケアしたりします。大人な人は大体がリーダー格なので、その人の時間が奪われると何かと開発現場が疲弊しちゃいますね。コードレビューってそんなに難しいものだっけと思ったりもしますが、反省の意味も込めて実際に
はじめに 2017年8月24日にRails Developers Meetup #4という勉強会で「プロを目指すRailsエンジニアのための公開コードレビュー」という発表をしてきました。 このエントリではこの勉強会の発表内容を紹介します。 発表のテーマを決めるまでの経緯 以前、「WEB+DB PRESS Vol.99の「良いコード」を本気でコードレビューしてみた」というエントリを書いて結構な反響があったのですが、この記事を読まれた主催者の平野さん（@yoshi_hirano）から「良いコードとは何か、というテーマで体系的に語ってもらいたい」と声をかけてもらったのが登壇のきっかけでした。 ただ、「良いコードを体系的に語る」となると、僕の中ではおそらく「CODE COMPLETEやリーダブルコードを読め。以上！」になってしまうので、それよりも具体的なコード例を見ながら「ここはこう」「このコード
はじめに Twitterを見てたら、気になる雑誌の特集を見つけました。 WEB+DB PRESS Vol.99の「Rubyで学ぶ！良いコードって何だろう？」という特集記事です。 WEB+DB PRESS Vol.99 作者: ?橋健一,谷口禎英,井本大登,山崎勝平,大和田純,内村元樹,坂東昌哉,平田敏之,牧大輔,板敷康洋,大?浩崇,穴井宏幸,原口宗悟,久田真寛,ふしはらかん,のざきひろふみ,うらがみ,ひげぽん,池田拓司,はまちや2,竹原,片田雄樹,渋江一晃,WEB+DB PRESS編集部編出版社/メーカー: 技術評論社発売日: 2017/06/24メディア: 大型本この商品を含むブログを見るRuby大好き！きれいなコード大好き！！な僕にとっては、この特集は読まずにはいられません！ 早速買って読んでみました。 お～、なるほど、たしかにいいことが書いてある！ うんうん、そうそう・・・あれ？この
Forkwell Meetup #3 https://forkwell.connpass.com/event/48147/Read less
GitHub: haya14busa/reviewdog: A code review dog who keeps your codebase healthy 英語記事: reviewdog — A code review dog who keeps your codebase healthy – Medium reviewdog というlinter などのチェックツールの結果を自動で GitHub の Pull Request にコメントしたり， ローカルでも diff の結果から新たに導入されたエラーだけを表示するようにフィルタリングできるツールを作りました． 英語記事 を Medium に書いたし，README も書いたので 日本語記事はまぁいらないかなぁと思ったけど，柄にもなく Vim 関連以外で普通に便利ツールを書いてしまって，これは日本語でも簡単に共有しようかなぁと思いこの記事
ブログ間違った，普段こういう事はこっちに書いてます． http://moznion.hatenadiary.com 最近自分がコードレビューで使いがち，あるいは表立って使ってないんだけど内心評す時に使う言葉が色々とあり，まとめてみることとした．参考にしない方が良いと思う． 左は言葉，右は説明． 屈強 - コードが力強い時に使う．例えば長い一枚スクリプトとか，コメントが一切ないバッチ処理とか．やや批判的な意味合いで使うことが多い． マッチョ - 屈強と同じ文脈で使いがち 屈強だけどしなやか - 屈強だけどしなやかな時に使う．好意的な屈強さと言える． モノリス - 長大なトランザクションスクリプト見た時とかに使う．やや批判的． 言い訳ないですか - 後で直していくぞ！ というメンタルの時に書かれたコードのコメントが案外少ない時に使う言葉．言い訳は無いよりあった方が良い．実際には「もうちょっと言
この記事は::..: 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/1c84f3cacb94b9447ddb0d39706cb073a984ea87/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fproxy.goincop1.workers.dev%3A443%2Fhttps%2Fiwashi.co%2Fassets%2Fimages%2Fogp%2F2015-10-22-oncodereview-translated_ogp.png)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
