アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
負の遺産ってねぇ、あーた (スコア:0)
価値があるのは(継承すべきは)データだけだよ。
つまりデータフォーマットさえ解れば大した問題じゃないってこと。
データフォーマットが解らないとしてもCOBOLのせいじゃないよね。
負の遺産って人間の不手際をCOBOLのせいにされているようで気の毒だな。
なんで毎度ネタになるんだか。
Re:負の遺産ってねぇ、あーた (スコア:1, すばらしい洞察)
プログラムを使うという事は入力に対して何らかの処理をした結果の出力も求められる。
正しい欠落のない仕様書がすべて残っていればそれが使えるだろう。
だが仕様書が正しいのかを確認するためにはプログラムが読めなければならない。
そして仕様書が失われていたり差異があった場合は真のロジックはプログラムの中に組み込まれている。
Re:負の遺産ってねぇ、あーた (スコア:2, すばらしい洞察)
データというか
データ構造および構造各要素(RDBならテーブルとかカラムとか)の命名から
「素直に」読み取れる範囲のことだけをしてるのならば、
データ構造だけ見せてくれれば判る、
という某御大の言葉どおりのシステムになる。
が、
実際の多数の現場では、DQNな連中が、
そういう判りやすいかたちをわざわざ捨ててしまい、
処理ロジックのほうで複雑怪奇なことをやってしまい、
それをデータ構造の素直さに反映するっていう工程を怠り、
結果、処理を読まないと何も判らないシステムを
作ってしまう。
それはあくまで人災なんですよ。
DOAとやらの肩を持つ気は無いけど、
少なくとも「データ構造で出来るだけ素直に、システムのかたちを表現しよう」
っていう姿勢は、重要だ。
なぜならそのほうが判りやすいからだ。
「うごき」で表現するより「かたち」で表現するほうが、
人間にとっては判り易いのだよ。
逆にいえば、そういう「判りやすくする化」の工程をサボるのが
得てして有り勝ちな(DQNな)現場だ。
Re:負の遺産ってねぇ、あーた (スコア:1)
Re: (スコア:0)
購入にしろリースにしろそれに見合うだけの額を払ってたから、それが当然だったよ。
Re:負の遺産ってねぇ、あーた (スコア:1)
:いや、過去形による言及なのが気にかかっただけな門外漢の戯れ言質問です。
:気が向かなければお気にせずスルーで
Re: (スコア:0)
開発と責任を丸投げしたいお客さんには良いんじゃないでしょうか?
Re:負の遺産ってねぇ、あーた (スコア:1)
「どうせハード的に老朽化した先から無くなっていっているんだろう」みたいにイメージしてました。
:我ながら浅い知識と想像力
Re:負の遺産ってねぇ、あーた (スコア:1)
そして、そのソースは存在しない。(失われている)
ソースの復元作業は、手間暇喰う割に、工賃が安い、美味しくない仕事。
# 実行ファイルにパッチして運用していると、逆コンパイルも上手くいかないケースが……
notice : I ignore an anonymous contribution.