コードレビューを段階的に行ってもらう話 - $shibayu36->blog;
最近コードレビューをどのように回していくかについて考えたことがあったのでブログに書いておく。 コードレビューの目的 コードレビューには誤りの発見以外にいろいろな目的がある。自分の中ではid:hisaichi5518が昔プレゼンでまとめていた目的が結構しっくり来ている。 https://speakerdeck.com/hisaichi5518/kodorebiyufalsehua?slide=8 http://hisaichi5518.hatenablog.jp/entry/2014/10/29/165721 機械的に発見できない誤りの発見 技術力の向上 属人性の排除 コードレビューの目的としては誤りの発見と同様に、技術力の向上や属人性の排除といった教育的側面も重要である。 コードレビューで課題に思っていたこと 自分のチームでは基本的に一人がコードレビューをして、OKだったらmergeをして
気軽にコードレビューするならGitHubではなくRefactor.ioでも良いと思った - Qiita
2016年に流行りそうだけどまだ殆ど知られていないエンジニア向けサービス10選を見ていたら、Refactor.ioというサービスがあって気になったので軽く使ってみた。 https://www.refactor.io/ Refactor.ioとは コードレビューやリファクタリングを気軽に依頼できるサービス。依頼したいコードを投稿するとレビュー用のページが作成され、そのページのURLを依頼者に共有、もしくはそのページを訪れた人にコードレビューやリファクタリングをしてもらう事ができる。 何ともシンプルなUI。画面右上に「GitHub Login」というリンクがある通り、GitHubとも連携出来る。連携の設定をしておくことで依頼したコードにコメントが入るとその旨をメールで受け取ることが出来る。対応言語は以下の通り。 ・JavaScript ・JSX ・CoffeeScript ・LiveScrip
テスト(コード)レビューの方針 書きなぐり版 - うさぎ組
牛尾さんのブログをはてブったら、「じゃぁ、その手本を見せろやゴルァ」と言われたので書きました。雑です。すみません。 元記事 「自動化対象のユニットテスト（単体テスト）の仕様書を書くことは完全なる無駄である」 Blogs - Live DevOps in Japan! - Site Home - TechNet Blogs 僕のコメント 「だいたい同じ意見だけど、これで単体テスト仕様書がいらない理由にはならないかなぁと思った。テストレビューの成長方法について書かれていないしなぁ。出来る人いない現場は諦めろってことかな？」 はてなブックマーク - kyon_mm のブックマーク - 2016年1月25日 牛尾さんのコメント「どっかに書いてありますか？もしあったら記事にはります。」 僕のコメント「書いていません！」 僕のコメント「書きました！」 僕の主張 本記事は僕の実験結果（経過報告）であり、
レビュー依頼前のコミット整理方法 - 弥生開発者ブログ
Misoca開発チームのmzpです。 新しいMisocaステッカーが完成したので、いろいろな場所で配りはじめました。 今日は、Misoca内でレビュー依頼をする前にやっているコミットの整理について紹介しようと思います。 Misocaの開発の話ですので、GitHubのpull requestベースでのレビューが前提です。 要約 pull requestをレビューしやすくするために、コミットを整理しよう。 方針 最終的な結果だけを残し、途中の試行錯誤の跡を消す 無関係の内容は別のコミットにする 具体的な作戦 自動生成と非自動生成のものは分ける scaffoldで生成されたものや Gemfile.lock 等の自動で更新されるものは、特にレビューする必要はありません。 そのため、それ以外の手で書いた変更とは別のコミットとは別にしておくとよいです。 試行錯誤の跡を消す PR内で発生したバグの修正コ
アプリ評価が★２→★４に改善されると、ダウンロード率が5.4倍に。アプリのレビューが与える影響と、レビュー改善2つの成功事例。 | アプリマーケティング研究所
アプリ評価が★２→★４に改善されると、ダウンロード率が5.4倍に。アプリのレビューが与える影響と、レビュー改善2つの成功事例。 アプリストア（AppStore/GooglePlay）のレビュー関連のデータ、レビュー改善事例をまとめました。アプリのレビュー評価が上がると、どんなメリットがあるの？ １、どのくらいの人がアプリストアのレビューを読むのか？ アプリをダウンロードする前に「ひとつでもレビューを読んでいる人」は70％もいる。アプリストアのレビューは、ユーザーが「アプリをダウンロードするか」を決める要素のひとつである。 ２、中にはたくさんレビューを読む人もいる。 割合としては少ないけれど、「たくさんレビューを読んで検討する人」もいる。 具体的には「有料アプリ」は33％、「無料アプリ」は13％のユーザーが、アプリをダウンロードする前に、7つ以上のレビューを読んでいる。 言うまでもないが、有
コードレビューのベストプラクティス | POSTD
Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上
GitHub「完璧なプルリクの書き方を教えるぜ」 - Qiita
はじめに この記事は How to write the perfect pull request - GitHub を和訳というか、意訳した記事です。 ご指摘などありましたら大歓迎です！ 良いプルリクエストを書くには (原題 : How to write the perfect pull request) 会社が成長していくと、人もプロジェクトも様変わりしていきます。GitHubの中に私達が望む文化を育んでいくためには、我々が何を自覚してコミュニケーションするべきなのか分かってきました。私達のチームが最強であり続けるために、最近以下のようなプルリクエストのガイドラインを導入しました。 プルリクへのコメント (原題 : Approach to writing a Pull Request) プルリクエストには目的を明記しましょう。たとえば… これは〜を調べてみるためのプロトタイプです これは
クソレビューアだらけのレビュー会
体裁厨 「お♪ ここだけフォント違うくない? それからなんか間隔せまいし。」 用語統一厨 「"お問い合わせ"は"お問合せ"と表記することに決まってるので」 箇条書き過剰 「箇条書きにして。その方が分かりやすいよ。」 物忘れ激しい系 「こここんな仕様だっけ? え、設計書に書いてる? 作成者だれ? オレ? 決めた覚え無いけどなぁ…」 レアケース厨 「UUID? 100%衝突しないと言えない? じゃあダメじゃん。」 ショートカット厨 「Ctrl + Shift + T、Ctrl + Shift + T。あぁそれやるならCtrl + Shift + Rだ。」 遅れてくる系 「なんかここおかしくない? えっもう指摘された? ごめん、もう一回ちょっと説明して」 指摘曖昧系 「なんか分かりにくいなぁ。色付けたりするとかあんじゃん?」 寂しがり 「ちょっとなんか寂しいな。ここ説明書き足したら。いやこれだけ
レベル１の勇者がハーレムなメンバーと一緒に戦う『Hero and Daughters』をプレイしてハクスラについて考える – もぐらゲームス
パーティは自分以外かわいい女の子。 それなんてギャルゲ？と言いたくなるのだが、ダンジョンに繰り返し潜ってレアアイテムを探したり、レベルを上げて、魔王に挑む……と、ゲーム自体はかなり本格的なフリゲRPGが登場した。 ７月２５日にtachi氏が公開した『Hero and Daughter』を紹介しよう。 なお、制作者のtachi氏は、前作『月光妖怪』の制作でも知られている。もぐらゲームスでもレビューしている。 びっくりさせる快感――フリーゲーム「月光妖怪」レビュー 国王に呼び出され通算何度目かの魔王討伐を依頼される主人公。いつものようにサクッと終わらせようとしたのだが・・・。今回は、国王の策略でレベル１に戻されてしまいスライムすら満足に倒せない身体になってしまった主人公。 そこで登場するのが、本作の肝である「女の子召喚システム」だ。ダンジョンで拾える召喚石から女の子を召喚し、彼女たちの助けを借
「強いチームはオフィスを捨てる」を読んだ - $shibayu36->blog;
強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」 作者:ジェイソン・フリード,デイヴィッド・ハイネマイヤー・ハンソン早川書房Amazon 最近リモートワークへの知識に興味が湧いてきたので、ひとまず強いチームはオフィスを捨てるを読んだ。元々はリモートワークについての思い込みがあり、そのためリモートワークの難しさのほうに目が行き過ぎていたのだけれど、この本を読んでみて少し中立よりになれたように思う。そういう面で今の時期に読むには非常に良かった。リモートワークの知識だけというより、普通に働いていても参考になる知識も得られた。 リモートワークを始めたいけど何から始めたらいいかについて分からない人には最適な本。ただし良い本であるという一方で、少しリモートワーク礼賛の傾向があるので、そこは一歩引いて読むと良いのかなと思う。とはいえ、ただ褒めているというだけでなくて、きちんとメリット
Clang-FormatでObjective-Cのコードを整えたらレビュー捗る - ainameの日記
最近Objective-C書いてるのでClang-Formatというツールを試してみた。 些末なコードレビュー - naoyaのはてなダイアリー にもある通り、コードレビューするときにいちいちソースコードのフォーマットを指摘し続けるのはアンチパターンで、人間以外がやるべき仕事。 PerlならPerltidyというツールがあるけど、Objetive-C（C, C++）にはclang-formatというコマンドがある。暇なので社内で導入出来るように調べた。 ClangFormat — Clang 3.5 documentation 使い方 CLIの場合は以下のように実行する。-iで指定したファイルを上書き、-styleでフォーマットを指定する。 $ clang-format -i -style=Google Hoge.m これだけで既存のコードがフォマッターの設定通りに整えられる。 2014年
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://post.simplie.jp/posts/34