- - PR -
スペースがバグになるとき
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2008-08-24 04:02
こんにちは。
先日の話なのですが、私の上司から、こんな指示を受けました。 「開発用のフォルダにある君がコーディングしたプログラムのソースなんだけど、本番環境アップロード用にコピーしてあったプログラムのソース(アップロード済み)と異なっているんじゃないか？ 不安なので確かめるように」とのこと。 別に修正をしたような記憶はなかったので、変だなと思いつつ差異をチェックしてみると、アップロードしたプログラムの関数の引数宣言部には、無駄な半角スペースが入っていて、それを削除したものが開発用のフォルダに置かれていると言う事が分かりました。 ここでいう無駄な半角スペースというのは、たとえば x = x + 1 ; /*←コロンの後*/ y = y + 1 ;/* こちらはない */ とか、 public int test(int x, /*←こういう所にあるスペースとか*/ int y){ …… } とか、言わば通常は無視されるであろう半角スペースの事を意味します。 どうやら、無意味な半角の存在が気になって削除したけれど、別に今のままで動いているし、これくらいでいちいちアップするのも面倒だと考えて、直したきり放っておいたらしいと分かりました。 そこでそれを上司に報告すると、 「君、それはダメだ。事故の元だ。たとえ半角スペースやタブと言っても、今動いているものを変えるということはデグレの元になる恐れがある。金融とか鉄道関係なんかだと、一行変更するだけでも大変なんだぞ。そういうつもりでやれ」 と言われました。 確かに、更新したものがほったらかしにしてあったというのは、事故の元になりえる自分のミスだと思いますし、あるシステムでは、たった数行の変更でも提出してからコードの監査に一ヶ月以上掛かったなんていう話も聞いたりはしていましたので、一行の変更が大した事ではないとも思っていません。 最近では、実際にうちの会社で、要求のそうとう厳しいお客さんのミッションクリティカルなシステムを開発して、何やら仕様書の記述が1文字違うとか設定が違うとかなんとか揉めまくった挙句2億(!)も損失を出した(もちろんそれだけが原因ではありませんが)なんて話もあり、皆そういう事には極めて敏感な状態になっています。 そうなると気になるのは、無視されるはずの半角スペースやタブが有ったり無かったりする事によって、何らかのトラブルの元に繋がることがあるかどうか、ということです。 私が今まで知っている範囲では、無視されるだけで済むはずだという認識しかありませんでしたので、もしそういうことが起こりうるとしたら、予め注意したいと考えています。それとも、私の受けた注意は、私の不注意に対するものだったのでしょうか？ どうぞ、このようなシチュエーションが考えられうる、という事をご存知であれば、ご教示下さい。お願いいたします。 （なお、ここで言うスペースとは半角スペースで、本来言語の仕様上無視されるはずの位置にあるもの、として下さい。全角スペースだったとか、アンダーバーがフォントのせいで見えなかったとか、引数の名前に半角スペースが入ってたとか、そういう単純ミスの類は、除外します。） | ||||||||
|
投稿日時: 2008-08-24 08:35
ご質問内容の前提が、
とあるので直接的なものはあり得ないでしょう。 では間接的にあり得るかと言えば元のソースに問題がない以上、アップしなかったことで問題になるものも存在しないと思います (間違える人はスペースがどうであれ間違えます)。 上司はソースの意味が変わるどうこうというよりアップしていなかったその心構えが 'デグレの温床' に繋がるという意味で言ったのではないかと思います。 そうでなくとも上司ももともと理解が少ないでしょうから、それくらいに留めておき注意されたこと自体はあまり気にしないことですね。 ピリピリしていただけかもしれません。 _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||||||
|
投稿日時: 2008-08-24 08:37
腹が立ったのはわかりますけど、自分が同じミスをとがめられたら正当化するのはあきらめる内容です。上司が言っていることが正しい！
「半角スペースやタブ」のことを気にするより、業務の手順化を考えてみたらどうだろう？ ＃どうもバージョン管理システムを導入していないようなのでその導入も含めてね。 リリースの手順書（業務フロー）を自分で書こうとしたときに、 『変更内容が「半角スペースやタブ」だけならそのままスルー』という例外ルールを わざわざ作りますか？ Lyijykyyneleetさんの受けた注意は不注意に対するものです。 インタープリタ系の言語だとダイナミックステップが違うものがあるのかもしれないけど、そんなことを調べるパワーは別なところに振り向けたほうが幸せになれると思う。 | ||||||||
|
投稿日時: 2008-08-24 08:43
意地悪な質問をしますが、「無視されるはず」ということをどうやって証明できますか？ 自分が今まで知っている範囲では、無視されるはずなのかもしれませんが、今までに知らないことが原因となって無視されないということがありうるかもしれません。 これを完全に否定するたまには、いわゆる「悪魔の証明」が必要になります。 私だったら、別にそんな証明をしなくても、本番とバックアップのファイルが同一になるように保守しておくほうを選択します。 | ||||||||
|
投稿日時: 2008-08-24 09:49
ノリノリでスペースやTab消してたら、必要な行をまるっと消してたとかってミスがあるかも？
| ||||||||
|
投稿日時: 2008-08-24 10:22
この技術的な点のみについて書きますと、たとえば、コンパイラーなのかインタープリターなのかで大きく分かれると思います。コンパイルしてしまえば、スペースの有無はコンパイル結果には残らないので、動作に違いはないでしょう。一方、インタープリターならば、スペースが存在することで処理時間が微妙に変化して、それによって、時間に依存したバグが顕在化して動作に違いが出るということはあるかもしれません。(もっともコンパイラーであっても、そのバグで空白の有無でコンパイル結果が違う、ということはあるかもしれません。) 特に、もともとバグが潜んでいるという前提があって、それが顕在化するか、まで考慮すると、やはり同一のソースコードでないというのはなにかとトラブルの元になると思います。 あと、良くは知りませんが、.NET のソースコードデバッガーって、行単位ではなく列単位までの細かさではなかったですか？(たとえ .NET がそうでなくても、そういうことが一般に皆無ではないかもしれないという話で進めます。) だとしたら、本番で障害がおこり、デバッグしている最中に、列がずれると、バグの発見が遅れる、などの弊害はあるかもしれません。 | ||||||||
|
投稿日時: 2008-08-24 10:43
今度は反対に擁護する意見を書きますと、この削除をしても CVS などのツールでは、設定にもよりますが、同一のものとみなす設定ができたと思います。(列は知りませんが少なくとも行は。) 目で見て「同一」というのはイマイチ客観性に欠けますが、ツールが「同一」というのでしたら、同一とみなしてもよいという考えもできると思います。 アップロードのし直しが非常に困難な環境だったりすると、そういう運用があってもそれなりに納得できると思います。しかし、いまどき、スペースを削除してアップロードすることに、手間がかかるとは思えません。アップロードしていないのは、ただのし忘れではないか、と考えるほうが妥当でしょう。 ただ、今回のご質問はスペースの削除ですが、私の経験としては、最終バージョンをアップロードした後、「ああ終わった」と思ってソースコードを眺めていたら、「ここの処理にはコメントをもっと書いておいたほうが良いかな？」と思うことはあります。こういうときに困ります。 コメントを追記することは許されるか？もしこれが許されるのならば、スペースの削除も許されるべきでしょう。 | ||||||||
|
投稿日時: 2008-08-24 13:26
＃言語仕様上的な話は他の方のコメントの通りなので割愛します
Lyijykyyneleetさんの質問内容を見ると、 プログラミング上でのトラブルについての観点しかないようですが、 開発プロセス上の観点で見れば、問題ありありです。 本番アップロード後に開発フォルダのソースを変更をしたとのことですが、 アップロードを忘れていたことと同じくらい問題なことは、 おそらくソースコードを変更したのにテストしていない、というところです。 テストしていないとは質問文に書かれていませんが、 半角スペースを除去しただけであれば、せいぜいコンパイルを通したくらいしか していないのでは？テストを実施していたとして、この場合、 どんなテストをすれば必要十分といえるでしょうか？ また、ある程度の規模のチーム体制で開発をしている場合は、 開発チームとリリースチームとを分かれている場合もあり、 そういうった半角スペースくらいいいだろう的な発想が、 他のチームに迷惑をかけることになるので、実工数上も影響を与えることがあります。 上司の方は単に不注意に対して注意されているだけでしょうけれど、 私が私の部下に対して注意するなら開発プロセスに対する認識不足として注意します。 | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。