アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
負の遺産ってねぇ、あーた (スコア:0)
価値があるのは(継承すべきは)データだけだよ。
つまりデータフォーマットさえ解れば大した問題じゃないってこと。
データフォーマットが解らないとしてもCOBOLのせいじゃないよね。
負の遺産って人間の不手際をCOBOLのせいにされているようで気の毒だな。
なんで毎度ネタになるんだか。
Re: (スコア:1, すばらしい洞察)
プログラムを使うという事は入力に対して何らかの処理をした結果の出力も求められる。
正しい欠落のない仕様書がすべて残っていればそれが使えるだろう。
だが仕様書が正しいのかを確認するためにはプログラムが読めなければならない。
そして仕様書が失われていたり差異があった場合は真のロジックはプログラムの中に組み込まれている。
Re:負の遺産ってねぇ、あーた (スコア:2, すばらしい洞察)
データというか
データ構造および構造各要素(RDBならテーブルとかカラムとか)の命名から
「素直に」読み取れる範囲のことだけをしてるのならば、
データ構造だけ見せてくれれば判る、
という某御大の言葉どおりのシステムになる。
が、
実際の多数の現場では、DQNな連中が、
そういう判りやすいかたちをわざわざ捨ててしまい、
処理ロジックのほうで複雑怪奇なことをやってしまい、
それをデータ構造の素直さに反映するっていう工程を怠り、
結果、処理を読まないと何も判らないシステムを
作ってしまう。
それはあくまで人災なんですよ。
DOAとやらの肩を持つ気は無いけど、
少なくとも「データ構造で出来るだけ素直に、システムのかたちを表現しよう」
っていう姿勢は、重要だ。
なぜならそのほうが判りやすいからだ。
「うごき」で表現するより「かたち」で表現するほうが、
人間にとっては判り易いのだよ。
逆にいえば、そういう「判りやすくする化」の工程をサボるのが
得てして有り勝ちな(DQNな)現場だ。