レビューフレンドリーな開発のしかた - tomykaira makes love with codes
2013-09-02 レビューフレンドリーな開発のしかた git dev 最近は多くのチームでレビューの習慣が定着してきました。おもにレビュアーとしての仕事を依頼されることもあります。 コミット・ブランチの作りかた一つでこのレビューのしやすさが格段に違ってきます。 自分が普段の開発でこころがけていることをまとめてみます。 前提 レビュイーとレビュアーの間に上下関係があるわけではないですが、レビュイーは多少手数が増えても、レビュアーのことを最大限配慮すべきです。 なぜなら、レビュイーはその機能の開発に集中して取り組んでいますが、レビュアーはすこし見るだけです。 なにかするとしたら、レビュイーがやったほうが時間も手間も少なくなります。 レビュアーはレビュイーよりも、変更について詳しくありません。 レビュイーは開発にいろんな部分を見てまわり、他のモジュールとの関連性や実装のこまかな意図を把握して
開発時に出会いたくないパターン - Perl日記
悩んだりうまくいかなかったり解決したり。だらだら書いた。 手作業症候群 とにかくなんでもかんでも手で確認・作業する必要があると思い込んでしまう病。 そりゃiOSアプリとかAndroidアプリとか最終的には実機確認は必須だけれども。 その前にやれることは多々あるはず。リグレとか。 あと「デプロイ職人」も不要にするべき。わかってる。 自動化できない要素を突っ込んでる方が悪いのだ。なんとかする。 masterブランチぶっこみ志向 masterブランチに直接コミットを重ねていくことにより開発速度をアップさせることができる。 ただし孤独な背水の陣を構えることになる諸刃の剣。 おとなしくtopic branchを切って作業するのが安心への近道であり王道である、 とか言ってたらみんなちゃんと切ってくれるようになった。めでたし。 チケットそっ閉じ症候群 本来はリリースしたりデータを修正したりしてチケットと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
