アカウント名:
パスワード:
COBOLそのものではなく、COBOLで動かし続けリプレースもされない古くてカビの生えたシステムが諸悪の根源なのでは?色々な事情はあるだろうけれど、ある程度の期間で更新し続けないと保守しづらくなるのは自明の理ではないかと。
COBOLが古くて使いづらい云々は、正直なところ必要な言語なり手続きを覚えずに「あっちはこれがあるのにこっちには無いから・・・」と文句垂れるだけの使いづらいエンジニアなのだと思ってしまう。
# 必要ならなんでも覚えてやるさ。相応の対価を出してもらえるなら
要は「COBOLの仕様上の問題で、構造化すらされておらず、ソースコードから仕様を紐解くのが非常に難しい」というのと、「そもそも仕様書が更新されていないか、あったとしても未記載や言外の仕様が多くて役に立たない」という2つの合わせ技だと思いますよ。
言語側で業務に合った抽象度の高いコードにしている(=そこから仕様書を起こせる)か、仕様書がきちんと作成され更新され続けていれば、言語を移動することもメンテナンスすることも容易だからです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
COBOLではなく古いシステムが (スコア:1)
COBOLそのものではなく、
COBOLで動かし続けリプレースもされない古くてカビの生えたシステムが諸悪の根源なのでは?
色々な事情はあるだろうけれど、ある程度の期間で更新し続けないと保守しづらくなるのは自明の理ではないかと。
COBOLが古くて使いづらい云々は、正直なところ必要な言語なり手続きを覚えずに
「あっちはこれがあるのにこっちには無いから・・・」
と文句垂れるだけの使いづらいエンジニアなのだと思ってしまう。
# 必要ならなんでも覚えてやるさ。相応の対価を出してもらえるなら
Re:COBOLではなく古いシステムが (スコア:2, すばらしい洞察)
要は「COBOLの仕様上の問題で、構造化すらされておらず、ソースコードから仕様を紐解くのが非常に難しい」
というのと、「そもそも仕様書が更新されていないか、あったとしても未記載や言外の仕様が多くて役に立たない」
という2つの合わせ技だと思いますよ。
言語側で業務に合った抽象度の高いコードにしている(=そこから仕様書を起こせる)か、
仕様書がきちんと作成され更新され続けていれば、
言語を移動することもメンテナンスすることも容易だからです。