アカウント名:
パスワード:
前任者の汚いけど良くテストされたコード
というストーリーを妄想してしまいました。
変更点についてコードレビューを経ないとコミットできないというルールでどうでしょう?単位が違うくらいならコードレビューで落とせそうな気がします。
#そうすると今度は、レビューしたのと違うコードをコミットしてしまうミスとかが発生するんですけどね。
問題は委託側がコードレビューできるか、によると思います。開発側に任せては意味がないです。
たしかに"単位が違うくらい"なら分かる可能性もありますが、大概無理ではないでしょうか。単位だけを直したわけじゃないでしょうし。
それは、プロモーション管理のやり方が間違っているよ。
コミットしたものにタグを打ち、タグで取得してからレビュー&テスト。合格したものに対してやはりタグを打ち、タグで取得してリリース。
そういう時のための多数決方式だと思う.
> そういうことを(する/できる)体制ってどうなのよ
否定でも反論でもなく賛成なんですけど、今回のような事例を防げるようなしっかりした体制を実際に作るって難しいだろうと思うのですが。みなさんの会社では実現できていますか?
もしくは取引先の企業はしっかり体制が組まれて、今回のようについでにコッソリ他の修正すらできない企業は結構多いものですか?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
セキュリティ上の重大な脅威? (スコア:0)
改修対象外機能のモジュールがリリースされてることに気がつけないあたりは、受け入れ担当のボーンヘッドもあるかもしれませんが。
検証以前 (スコア:1, すばらしい洞察)
そういうことを(する/できる)体制ってどうなのよ
Re:検証以前 (スコア:1)
Re:検証以前 (スコア:1)
というストーリーを妄想してしまいました。
巧妙に潜伏したバグは心霊現象と区別が付かない。
Re: (スコア:0)
これ、結構難しいと思うなぁ。今回のは修正後のテストに含まれない筈の話だから。
どんな修正でも全部テストするというのは非現実的だろうしさ。(コスト度外視はもってのほか)
Re:検証以前 (スコア:2)
変更点についてコードレビューを経ないとコミットできないというルールでどうでしょう?
単位が違うくらいならコードレビューで落とせそうな気がします。
#そうすると今度は、レビューしたのと違うコードをコミットしてしまうミスとかが発生するんですけどね。
Re: (スコア:0)
そうすれば差分の情報がちゃんと残るから、こっそり改変は無理でしょう
Re: (スコア:0)
問題は委託側がコードレビューできるか、によると思います。
開発側に任せては意味がないです。
たしかに"単位が違うくらい"なら分かる可能性もありますが、大概無理ではないでしょうか。
単位だけを直したわけじゃないでしょうし。
Re: (スコア:0)
それは、プロモーション管理のやり方が間違っているよ。
コミットしたものにタグを打ち、タグで取得してからレビュー&テスト。
合格したものに対してやはりタグを打ち、タグで取得してリリース。
Re:検証以前 (スコア:1)
そういう時のための多数決方式だと思う.
Re: (スコア:0)
> そういうことを(する/できる)体制ってどうなのよ
否定でも反論でもなく賛成なんですけど、
今回のような事例を防げるようなしっかりした体制を
実際に作るって難しいだろうと思うのですが。
みなさんの会社では実現できていますか?
もしくは取引先の企業はしっかり体制が組まれて、
今回のようについでにコッソリ他の修正すらできない企業は
結構多いものですか?