テックブログを分析して分かった始めるコツ・続けるコツDevRel/Japan CONFERENCE 2023の発表資料です https://devrel.tokyo/japan-2023/
レビュアーにやさしいリファクタリングPRを作る
リファクタリングの PR、見るのツラい内容になりがち PR(PullReqeust)を作成してレビューを受け、Approve を受けたらマージする..という開発スタイルはよくあるパターンで、新たな機能追加や修正では観点が明確で動作確認も実施しやすいのですが、これがリファクタリングがテーマになると、途端にレビューが大変になることがあります。 個人的な経験則もありますが、何も意識せずに PR を作ると、次のような問題が発生しやすいように感じます。 １テーマに関する修正が一気に詰め込まれていて物量が多い 何を確認したらよいのかわからない 複数 PR に分けている場合に、後続の PR だけを見ても理解できない など... リファクタリングの PR は内容も淡々としたものになることが多く、確認もリグレッションテストが中心で、レビュアーはそこそこ心を削られます。そのうえ上記のような問題を抱えていると、
レビューしやすいプルリクエスト | DevelopersIO
このコードを見た時に、レビュアーは「ユーザーを削除するコードが追加されたこと」「ユーザーを削除するコードとして、deleteUser が正しいかどうか」あたりは判断できます。 しかし、「そもそもこれ、いるの？」とか「物理削除でいいの？」といった観点でのレビューは、このコードだけだと難しいです。 どういったコンテキストでこのメソッドが追加されたのか、判断ができないからです。 コードを利用する側の差分があった場合どうでしょうか。 ユーザーが自主的に退会ボタンを押した時に deleteUser が呼ばれる、という情報が追加されます。 ここでレビュアーは、「退会って単純に物理削除でいいのか・・・？」など、もう少し広い観点でのレビューをしやすくなります。 resign の実装時にも気づくことはできるのですが、根本的なところから考え直したい場合、 deleteUser のレビューにかける労力も減らすこ
Engineering Managerとしての技術ブランディングへの取り組み方 - itohiro73’s blog
本記事はEngineering Manager Advent Calendar 2019の23日目の記事です。 自己紹介 2019年10月からREADYFORというクラウドファンディングの会社でVP of Engineeringを務めております、伊藤と申します。「いとひろ」と呼ばれることが多いです。2005年から12年ほど外資系金融の会社でソフトウェアエンジニアを務めたのち、FinTech系のスタートアップ2社を経て現職に就いております。 Engineering Managerと技術ブランディング Engineering Manager（以降EM）が取り組むひとつの課題として、エンジニア組織をいかに成長させていくかという課題があると思います。そのためにも採用数を伸ばしていかないといけなかったり、人材流出を防ぐためにリテンション施策をとらないといけないと思います。その中のひとつの施策として技
GitHub - ldez/prm: Pull Request Manager for Maintainers
If you are a maintainer of Open Source Software, you need to review a lot of PR, this tool is made for you. With the GitHub feature "repository maintainer permissions on existing pull requests", now we can edit real PR branch. This tool allows to easily manage PR branches and remotes. 💼 Features: Checkout a PR (interactively or by its number) Remove a PR (interactively or by its number) Remove al
GitHubのPull Panda連携を(さっそく)導入しました！ - Studyplus Engineering Blog
Androidチームの若宮(id:D_R_1009)です。 今朝方、Twitterを眺めていたら下記のツイートが目にとまりました。 ここ最近、超絶便利に感じていた Pull Reminders が GitHub に買収されて、誰でも自由に使えるようになったみたいだ。 GitHub + pull request でチーム開発をしていて、Slack も使っているところであれば、とりあえず試してみると良いと思う。https://t.co/xvHdkDu7YR— suzuki (@suzuki) June 17, 2019 「これは便利そうだ！」と感じたため社内Slackに投稿し、 利用を開始したところ 期待以上の便利さだったので、本ブログでも紹介したいと思います。 Pull Pandaとは https://pullpanda.com/ GitHubのリリースでは下記のように紹介されています。 W
プルリクエストが最速でマージされるための７つの技 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? わたしはOSSとして公開されているGitHubのリポジトリに貢献することがあるのですがいつも困っていることがあります。私がPRをオープンするとめっちゃコメントがついて、それを修正するのにすごく時間がかかることです。そういえば私の元同僚のピーターは生まれて初めて新しい言語で書いたPRですら一発でマージされていて驚いた覚えがあります。どうやったらプルリクエストが最速でマージされるのか？インターネットを調べても情報がなかったので、自分で調べてみることにしました。ちなみにこのポストは、私自身が書いたHow can you get your PR
地味に面倒なブランチ作成〜WIPプルリクエストまでをコマンド1つで行う - LCL Engineers' Blog
フロントエンドエンジニアの岡田です。 やる気がでない時の最良の方法は、「とりあえず始めてみる」ことだと聞いたことがあります。 今回は、やる気がでないときでもコマンドを1つ叩くだけで、ブランチ作成〜WIPプルリクエストまで作ってくれるように設定をしましたのでご紹介します。 WIPプルリクエストを作るまでにすること WIPプルリクエストを作るまでには、以下のことをしています。 masterをチェックアウト＆プル ブランチを作成 空のコミットを作成してプッシュ プルリクエストの作成 ラベルを付ける 手順が多い上に、私が普段使っているSourceTreeでは、3. の空のコミットが作れません。そのため、ターミナルで操作しなければならず、面倒でした。 そんな時に同じチームの人が教えてくれた以下の記事を試してみました。 qiita.com すごく便利です…！ これはぜひ使いたいと思い、さらに以下の機能
commit をどう分割すべきか 〜コードレビューの観点から〜
普段の開発の中で git の commit の単位に気を遣っている人もいると思うんですが、どういう単位で commit すべきかみたいな話をあまり見かけない気がします。自分自身 GitHub の Pull Request（以降 PR）ベースのチーム開発を何年か経験してみて、「こうすると良さそう」というものが見えてきた気がするのでまとめてみました。 なお、小さい単位で PR を出す方針にしている場合は、以降の内容に出てくる commit を適宜 PR で読み替えてもらうと良いかもしれません。 そもそも commit の単位に気を遣った方が良いのか？ コードレビューを行う場合など、他者がコードを読む場合はある程度気を遣った方が良いと思っています。理由は次のとおりです。 コードレビューにおいてレビュアーのレビュー時間が短縮できる コードレビューの精度が上がる 変更の経緯を追いやすい 自分にとって
prprでGithubのPullRequestレビュー依頼をSlack通知する - hitomedia Tech Blog
最近サーバサイドをやりつつiOSアプリ開発をやったり何でも屋になっている hilotter です。 GithubのPullRequestレビュー機能、便利ですね。 チーム開発においては相互レビューが非常に大事です。 今回は、レビュー依頼を行った際にSlackに自動通知するようにしたらより便利になったというお話を共有させていただきます。 SlackのGitHub連携の課題 Slack公式のGithub連携がありますが、こちらは以下の2点が課題となっていました。 1. メンション付きのコメントをしても、message-attachmentsの記法になっているため、うまく通知されずコメントを見落としてしまう このため、コメント後にSlackでも「コメントしました！」と2重で連絡をする必要がありました。 2. PullRequestのレビュー依頼を行ってもレビュアーへの通知が飛ばないため、レビュー
なぜあなたのPull Requestは読まれないのか - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Pull Requestを出してレビューしてもらってから反映。 どこにでもあるありふれた開発フローに付きまとう、どこにでもあるありふれた問題。 「Pull Requestがレビューされない」 もちろん開発フローにレビューが含まれている以上、レビューをしないメンバーにも非がないとは言えませんが、多くの場合はレビューされないPRには問題があるものです。 デカい 兎にも角にもデカいPRは読むのがつらいです。 もちろん要件が明記されていないなど、他にもPRが読みにくくなる原因はたくさんありますが、一番はこれです。 極端な話、1行変更のPRは他に
よりよい機能をより早く届けるためにGit/GitHubを使いこなす10の方法 - Qiita
この記事は freee Engineers Advent Calendarの6日目です。 こんにちは。freee株式会社でアプリエンジニアをしている @kompiroです。主に会計freeeの開発に携わっています。 僕には「よりよい機能を、より早くユーザーに届けたい」という信念があります。今日はよりよい機能を、より早くユーザーに届けるためのGit/GitHubを活用する10の方法と題してGitやGitHubの便利な使い方や日々のTipsをお届けします。1 PRのレビュー完了までの時間を最速にするための工夫 freeeではGitHub上でレビューをしながら開発を進めています。レビューをするのもされるのも、うまく進めないと結構時間がかかります。もちろんコードをより良くする作業に時間を割いているのであれば時間がかかるのも致し方ないです。しかし、進め方による問題でも数日〜数週間デプロイが延期されれ
The Art of a Pull Request — Pony Foo
Writing a great Pull Request takes time. It can be a scary proposition going in. Did I implement something relevant? Will they like my changes? Will the PR meet their expectations? How much scrutiny can I expect? Something that we’ve been discussing recently in Kibana – the open-source analytics dashboard for Elasticsearch I outrageously call my day job – is how to improve the process of contribut
【暫定版】新人エンジニアのプルリクエスト入門 - Qiita
0.はじめに 新人さん向けプルリクエスト（以下：PR)の送り方・受け方入門をざっと書きます。 仕事ではScalaをベースに使っているので、それベースにサンプルコードを書きます。 もし、こういうのもあったほうがいいんじゃね？というのがあったら、編集リクエストください。 吟味して、取り入れます。 また、あえて少し乱暴めに書きます。 なぜかというと、この初めてエンジニアになった人にあなたのそのミスはこれくらい上司が呆れたり、イラっとしたりしますよということを伝えるためです。 というわけで、新人さんは参考に、上司の方は教育の参考に使ってもらえると幸いです。 1.PRを出す前にチェックすること 1-1.環境編 まずは、最低限の話をする。 正直、この章の☑が全てとおらないモノを論外と思ってくれていい。 ☑1: ビルドはとおるか？ これはホントに最低限。 一部の新人エンジニアを除いてグループ作業とかした
HubotにGitHubのプルリクエストを自動でアサインさせる - Qiita
ここで、パラメータとしてchannel_nameとreview_team_idとrelease_team_idを渡しています。 これらのパラメータは、Hubotのスクリプト側で使います。 またSlackのChannel名ですが、#generalの#を%23のようにエンコードして渡す必要があることに注意してください。 また、Webhookを送るトリガーを選ぶことができますが、今回は「Pull Request」のみにチェックを入れます。 これで、プルリクエストを作ったり、クローズしたりすると「Payload URL」で設定したURLにWebhookが送られるはずです。 Hubotスクリプトの実装 Webhookの設定が完了したので、今度はそれを受信する側のHubotスクリプトを用意します。 実際の実装は以下のようにしました（汚くてすいません）。 module.exports = (robot)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - shibayu36/merged-pr-stat
GitHub
ログイン - はてな