開発速度と品質のトレードオフの判断基準の合意 - Hatena Developer Blog
Webサービスの開発は、ユーザ/顧客へ価値を早く届けるため、競合より早くリリースするため、人的リソースを無駄使いしないためなど、とにかく素早く進めたいものですね。一方で、開発を急ぐあまり品質を犠牲にすればかえって価値が失われたり、技術的負債が溜まって長期的なコストが大幅に増大する可能性もあります。開発速度とプロダクト品質は基本的にはトレードオフの関係にあるのでしょう。 開発速度と品質のどちらを優先するかはプロダクトの性質や、チームもしくは会社の状況によって異なるとおもいます。この状況の認識がチームメンバー間でずれていると、チームのパフォーマンスを最大限に発揮できないばかりか、チーム内の関係悪化も招きかねません。エンジニアたちとプロダクトオーナーの間の対立のようなありがちな問題の原因の一つかもしれません。 そこで、開発速度と品質のトレードオフをどう判断すべきかの基準を明確にして、原則それに従
git の運用指針 - Cube Lilac
ソフトウェア開発に関しては、これまでほぼ一人で完結していた*1ので git の運用方法もかなり適当だったのですが（ただのコミットマシーン状態）、今回、同一プロジェクトに対して複数人でコミットしていく形になっているので、その状態だとやはりまずいなと言う気がしてきました。ググっていると「なるほど」と思う記事もたくさんあったので、それらの記事を元に自分のプロジェクトの「git の運用指針」を情報共有のために記載しておこうと思います。 前提 まず始めに、現在のプロジェクトの状況は下記のようになっています。 開発は 1 人のメインコミッタ（私）と数人のサポートコミッタ（アルバイト等）で行われる メインコミッタはフルタイム、サポートコミッタは週に数時間〜10時間程度の勤務形態 サポートコミッタに対しては、基本的に 1 機能（1 チケット）を 1 人で完結するように作業を配分するが、時間的な兼ね合いもあ
仕事で使ってる巨大SVNレポジトリをGithubに移管するためにやったことまとめ · DQNEO日記
動機 Subversionで困ってない ぶっちゃけSubversionで全然困っていませんでした。 コードレビューはちゃんとやっていたし、マージ・ブランチングも自作シェルスクリプトのおかげてスムーズにやれていました。 よく「Gitはマージが賢い、ブランチ作成が一瞬でできる」とかいわれますが、Subversionだってちゃんと使えばコンフリクトなんかめったに起きないし、ブランチ管理・マージだって全然めんどくさくない。 特にver1.7からはサーバもクライアントも大幅に高速化されたし、.svnディレクトリが.gitみたいに１個になったし、rebaseみたいなことだってできる。(sync merge & reintegrate) ただ、世の中が一斉にGitにシフトしている中でいつまでもSubversionを使っててよいのかという不安がありました。 また、月から金までSubversionにどっぷり
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
