アカウント名:
パスワード:
新規プロジェクト向けにポリシーを定義する際の変更ならともかく、既存プロジェクトのポリシーをそのプロジェクトの本質に関係ない部分で変更しなくてはならないんだろうか日本では「言葉狩り」と表現される作用だと思うが、ことプログラミングプロジェクトにおいては「正常なプログラムは修正するな」の法則のほうが優先されるべきだと思うんだけどなぁスポンサーの意向でありコストはスポンサーが負担するっていうのならぜんぜん別の話だが
機能的なところと関係ない変更は、外部から突然やってくる。会社が買収されたり法令が変わったりしてドキュメントが書き換わることはよくあるんだから、社会的な価値観の変遷ということで、同じと考えてもおかしくないかと。
そしてコメントミスって余計な文言が入ったり、機械的に置換したせいで意味の分からない箇所が生じたり、置換漏れて旧規則と新規則が併存したり、ドキュメントとソースコメントが食い違って煩雑になったり、ドキュメントにあわせてプログラム内のコメント修正する過程でバグが埋め込まれたり、膨大なコメント修正に重要なコミットが埋もれたり、プログラムコメントに手を加えた場合には書き換えた箇所に対するテスト工数が莫大なことになったりする(コメントなので変化ないはずだけど、確認要求してくるプロジェクトは多い)
少なくともエンジニア視点では、プログラムが第一で、ドキュメント類の付随物はあくまでプログラムに従属するものであるとして、プログラムに関係なく、誤り修正でもない作業は極力排除するというのは正しい判断だと思う。
もちろん政治的な外圧でどうにもならないこともあるけど、どうにかなるうちは拒絶する態度を見せるのは良い事。構成管理者はこのような事案はリスク軽減のためにも厳しくあたるべきだと思う。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
既存のドキュメントを書き直す手間 (スコア:3, すばらしい洞察)
新規プロジェクト向けにポリシーを定義する際の変更ならともかく、既存プロジェクトのポリシーをそのプロジェクトの本質に関係ない部分で変更しなくてはならないんだろうか
日本では「言葉狩り」と表現される作用だと思うが、ことプログラミングプロジェクトにおいては「正常なプログラムは修正するな」の法則のほうが優先されるべきだと思うんだけどなぁ
スポンサーの意向でありコストはスポンサーが負担するっていうのならぜんぜん別の話だが
Re: (スコア:0)
機能的なところと関係ない変更は、外部から突然やってくる。
会社が買収されたり法令が変わったりしてドキュメントが書き換わることはよくあるんだから、
社会的な価値観の変遷ということで、同じと考えてもおかしくないかと。
Re:既存のドキュメントを書き直す手間 (スコア:2, すばらしい洞察)
そしてコメントミスって余計な文言が入ったり、機械的に置換したせいで意味の分からない箇所が生じたり、置換漏れて旧規則と新規則が併存したり、ドキュメントとソースコメントが食い違って煩雑になったり、ドキュメントにあわせてプログラム内のコメント修正する過程でバグが埋め込まれたり、膨大なコメント修正に重要なコミットが埋もれたり、プログラムコメントに手を加えた場合には書き換えた箇所に対するテスト工数が莫大なことになったりする(コメントなので変化ないはずだけど、確認要求してくるプロジェクトは多い)
少なくともエンジニア視点では、プログラムが第一で、ドキュメント類の付随物はあくまでプログラムに従属するものであるとして、プログラムに関係なく、誤り修正でもない作業は極力排除するというのは正しい判断だと思う。
もちろん政治的な外圧でどうにもならないこともあるけど、どうにかなるうちは拒絶する態度を見せるのは良い事。
構成管理者はこのような事案はリスク軽減のためにも厳しくあたるべきだと思う。