タグ

2017年6月29日のブックマーク (6件)

  • コードレビューのポイント

    すこし古いけどこちらを読んだ。 pull request を利用した開発ワークフロー // Speaker Deck 非常にわかりやすく読ませてもらったが、筋とはちょっとずれるレビューの勘所の話がとても面白く参考になった。 レビューコメントにラベルをつける [MUST] 問題があり、必ず治す [IMO] 意見、緩やかな指摘。自分ならこう書くけどどう? [nits] ほんの小さな指摘。インデントやタイポ たしかに普段のコードレビューでも、特に意識せずこれらは使い分けていた。こうしてラベルとして明示することでレビュイーに意図が伝わりやすい。レビュアーもこうした観点からレビューを行える。なによりレビュアー・レビュイー双方にとって明確に、指摘事項に優先順位がつけられる。こうすることでレビューとその後のアクションをよりスムーズにすすめる手助けになっている。 いいレビューとだめなレビューというものは

    コードレビューのポイント
    poyo
    poyo 2017/06/29
  • コードレビューに費やす時間を短くする - クックパッド開発者ブログ

    はじめに こんにちは、広告事業部の芳賀(@func09)です。普段はクックパッドの広告配信周りや純広告・タイアップ広告などの商品開発を行っています。 私が広告事業領域の仕事をするようになって、そろそろ1年になるのですが、初めはエンジニア以外の人(営業、編集、広告入稿、レポート、メール配信、などなど様々な担当者がいます)と業務をすることが多くてコミュニケーションが上手くいかず業務がスムーズに進まないことがありました。 当たり前のことではありますが、エンジニアにしかわからない言葉は使わないとか、できるだけ相手の業務を理解し相手の考え方や視点に立って話すなど、ちょっと工夫することで、長引きがちなMTG相談がすんなり終わったり、お互い良い気分で終わることが多くなって、費用対効果が高いなと感じています。 一方でエンジニア同士のコミュニケーションでも時間がかかってコストが高いと感じることがあります。

    コードレビューに費やす時間を短くする - クックパッド開発者ブログ
    poyo
    poyo 2017/06/29
  • 開発速度を上げるための Pull-Request のつくり方 - クックパッド開発者ブログ

    こんにちは、投稿開発部の森川 (@morishin127) です。クックパッド、お料理アルバム、みんなのお弁当の iOS アプリの開発等に携わっています。 クックパッドでの開発は GitHub Enterprise 上で行われており、書いたコードをプロダクトに取り込む前には基的に第三者のコードレビューが必須です。コードレビューはプロダクトの品質向上に貢献していますが、往々にして結構な時間と労力がかかるものです。Pull-Request を出してレビューをしてもらい指摘の修正を繰り返していると、場合によってはマージに数日〜1週間ほどかかってしまうこともあります。自分の開発速度を速めるため、また周りのエンジニアの開発速度を下げないためにレビューしやすい Pull-Request を出すことは重要です。この記事ではレビューしやすい Pull-Request のために心がけていることを紹介したい

    開発速度を上げるための Pull-Request のつくり方 - クックパッド開発者ブログ
    poyo
    poyo 2017/06/29
  • 開発フロー研修 @ Wantedly - Qiita

    Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサービスを生み出すために、役割の程度の差はあれ全員がプロダクトについて考え責任を持ったほうが良いと考えている。 理想型 図:「青と黄色」のチーム構成が従来の縦割り+統括チーム、「緑(金)色」のところが目指すべきマイクロサービスチーム マイクロサービスチームは、

    開発フロー研修 @ Wantedly - Qiita
    poyo
    poyo 2017/06/29
  • 初めてコードレビューされる人のためのpull requestとcommitの作り方 - Qiita

    pull requestの作り方について 作業途中でもpull request作ったほうがいい。 作業途中だと分かるようにwantedlyだと、[WIP]とかタイトルの最初につけてる タイトルに書くこと 作業の内容が分かるタイトル descriptionに書くこと WHY WHATを必ず書く Viewに変更がある場合は、スクリーンショットを貼る 関連のissueやpull reqeustへのリンクがあれば書く コードだけで分かりにくい箇所の説明(できるだけコードだけで分かるほうがいいけど) イメージは、初めてpull requestを見る人がmergeする上で必要な判断ができる情報があること。 どの作業をしているか、残っているか分かるように、マークダウンでチェックリスト作る git commitの方法について 僕自身まだまだcommitの単位は汚いので、今の僕レベルで気をつけていることを書

    初めてコードレビューされる人のためのpull requestとcommitの作り方 - Qiita
    poyo
    poyo 2017/06/29
  • 【CSS3】@keyframes と animation 関連のまとめ - Qiita

    はじめに animation プロパティと @keyframes を使うと、CSSだけでアニメーションの設定ができます。 簡単にアニメーションの設定ができるので、覚えると楽しいです。 そもそもアニメーションって? アニメーションの意味をググると動画と書かれていますが、動画というよりは、動きまたは変化という意味で捉える方が理解しやすいかと思います。 この記事でも、アニメーションという単語を用いて説明しますが、動きまたは変化という意味で読んでください。 最初は @keyframes について見ていきましょう。 説明するときに英語の読み方も記載していますが、参考程度に見てください。 keyframes について @keyframes は、アニメーション開始から終了するまでどのようなアニメーションをするのか指定できるCSSの文法です。 @keyframes は、@規則のため、@から始まり、波括弧内

    【CSS3】@keyframes と animation 関連のまとめ - Qiita