巨大 Pull Requestを避けるための9つのポイント - Qiita
巨大 Pull Requestの問題 レビューに時間がかかる、疎かになる テストとコードを照らし合わせが大変 本番で問題が起きたときに、問題の切り分けがしにくい masterとの差分を反映する際のレビューが難しくなる 一つのミスが大きなfeatureブランチになるきっかけになることも 大きくなるとmergeに時間がかかり、ますます大きくなる どのようにして大きなPRを避けるか PRが大きくなりそうな時は事前に相談する 作業しているときに、変更点がたくさん必要になったときは早めにレビューアーに相談する 複数人で開発しているときは、しっかり話す時間をとる PRが大きくなる問題は後で変更するのが難しいので、最優先で相談するとよい。近くにいるなら直接相談する。いないときはチャットで相談する。 モデルだけの変更とテストを書く なにか機能の変更がある時に、まずモデルからレビューする 実際にどういう変化
読みやすいREADMEを書く | Yakst
いくつかのオープンソースプロジェクトを公開している筆者からの、読みやすくユーザーにやさしいREADMEを書くためのアドバイス。 この記事は、Rowan Manning氏による「Writing a Friendly README」(2016/3/14)を翻訳したものです。 あなたのプロジェクトのREADMEは、かなり重要です。そこはプロジェクトに初めて来た人が大抵最初に見るであろう場所であり、唯一のドキュメントであることもよくあります。あなたのオープンソースプロジェクトにとってのREADMEは、企業にとってのウェブサイトのようなものです。ウェブサイトはユーザーエクスペリエンスの注目を集めるところですが、READMEがユーザー観点で考えられることはほとんどありません。 この記事では、分かりやすいREADMEを書くために役立ち、開発者(ユーザー)の要求に見合い、開発者がプロジェクトを初めて見たの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
