cobol - COBOLプログラマーを現代のプログラマーに変える方法

Question

私は、COBOLIMSとCICSを使用してプログラミングを開始した人々が考え方を大きく支配している企業環境で働いています。今日、それらのほとんどはJavaのようなより現代的な言語でプログラムしています。しかし、彼らのコードと設計の決定を見ると、あまり変わっていません

• 多くの画面の長いメソッド
• 膨大な量のグローバル変数またはそれらの現代の化身シングルトンパターン
• メソッドの開始時に約30の変数定義
• パラメータの代わりにグローバル
• ファクトリメソッドを使用する代わりに、巨大なswitchステートメント
• 「十分なスペースが残っている」ためのデータベーステーブル列の誤用
• ..。

これらの人々は愚かではありません彼らのほとんどは非常に賢いです。しかし、彼らに現代のコーディング慣行を説明することは、盲人に色を説明するようなものです。彼らに立ち向かわずに、より現代的なアプローチを教えるための経験やヒントはありますか？

Answer 1

コードがどのように見えるかを学ぶ最良の方法は、良いコードを読むことです。独自のコーディングスタイルで例を示し、コードレビュー中に間違いを丁寧に指摘してください。それは本質的には単なる視点の問題です。言われているように、あなたが持っている唯一の道具がハンマーであるならば、すべての問題は釘のように見えます。これらのプログラマーは、経験した言語の観点からすべてを表示するため、Javaを作成する場合でも、思考プロセスはCOBOLで行われます。彼らのコーディングスタイルは、単に彼らの思考プロセスを反映したものです。

それを除いて、全員にCodeCompleteを読んでもらいます。

Answer 2

「CodeComplete」のコピーを購入して、本のレポートを書いてもらいます。

Answer 3

反例を一度に1つずつ使用し、自分のやり方がより良く、痛みが少なく、時間どおりに家族の家に帰るのに役立つ理由などを説明します。ただし、実際に試している場合は、一度に1つずつ行くことが非常に重要です。有機的に文化を育てる。いくつかの例：

• 非常に長いメソッド：参照してください。長いメソッドを調べたところ、2か所で同じロジックを使用していることがわかりました。私はそれを打ち破りました、そして今あなたは同じコードを二度タイプする必要はありません。さらに、その部分を1回だけテストする必要があります。
• 各メソッドの開始時のグローバル変数と多くの定義：参照してください。変数を使用場所に近づけました。さて、私が書いたこのテストコードは、システムを強制終了するnullポインターを使用してコードに副作用を与えるため、私の副作用を引き起こすことはできません。
• ジャイアントスイッチ：時々、ジャイアントスイッチは避けるのが非常に難しいです（そして時々あなたはそうすべきではありません）。とは言うものの、オブジェクトを構築しようとしているのであれば、「ファクトリー」という言葉が意味します。ほら、私のファクトリメソッドはあなたのファクトリと効果的に同じことをしますが、私は（例えば）ポリモーフィズムにスイッチケース管理のいくつかを置き換えさせます。コードが少ない=バグが少ない=時間どおりに家に帰ります。

ところで、私はエンジニアに読書の割り当てを割り当てることに成功したことはありません（ただし、キャシーはリファクタリングを提起します。これはまさにこの種のものの優れた情報源です）。私にとってうまくいくのは、本を読み、提案されたテクニックを使用し、成功とそれが私の人生をどのように楽にしているかを示し、そして「これらすべてを修正する方法をどのように知っているのですか？！」始めて、ハウツーブックがあることを彼らに伝えてください。賢い人はあなたの手からそれをとても速く引き裂くでしょう、あなたはその過程で皮膚を失うでしょう。

Answer 4

何年も前に、私がCおよびC ++の商用トレーニングコースを教えていたときに、私とCOBOLプログラマーとの間に心の出会いがない可能性があることに気づきました。コースの1人のCOBOL担当者がやって来て、次のように尋ねたとき、ほとんどのパンターが一般的に満足するように、malloc（）とfree（）に関するコースのセクションを完了したところです。

「しかし、この「記憶」のものは何ですか？そして、なぜ私はそれを使いたいのですか？」

もう少し建設的ですが、COBOLプログラマーは、次の2つのことを考えるように訓練されています。

• 記録
• あなたが記録に対して行うこと

これは実際にはOOからそれほど遠くありません。基本的な考え方は、微妙に異なる種類のレコードがあり、それらに対して行う必要のあることが異なるということです。これに対処する最善の方法は次のとおりです。レコードと、オブジェクトを作成するために実行する必要のあることをまとめます。

Answer 5

Javaを書いてもらいます。強力なコードレビュー基準があります。彼らのマルチページメソッドが良いコードではないためにコードレビューに合格しない場合は、なぜそれが良いコードではないのかを説明してください。ある時点で、彼らはイライラするかもしれません。長い間「定着」してきた習慣を、煩わしさなく変えることは、本当に不可能だと思います。しかし、レビュー担当者が合理的で一貫性を保っている限り、時間の経過とともにそのポイントを確認し始めます。経験は本当にこの種のものの唯一の解決策であり、これは実際に経験を得てそれを指示する唯一の方法です（彼らの過ちから学ぶのではなく）。

Answer 6

コードコンプリート（おそらくその後）と同様に、リファクタリング：既存のコードの設計の改善（少なくとも導入部）を読んでもらいます。標準的なコードの臭いとその修正方法の両方について説明します。

しかし、彼らが必要としているのは、オブジェクト指向の方法で考える方法の概要であるように思われます。そのための最良の本が何であるかはわかりません。

Answer 7

彼らの考え方は「うまくいく」という考え方であり、「これを行うための最良の方法は何か」という考え方ではないのではないかと強く思います。彼らがしていることがうまくいくようであれば、おそらく彼らはあなたが思っているほど悪くはないでしょう。

私はCOBOLコードと.Netコードの両方を使用しています。私の個人的な経験では、完全にCOBOLの考え方を持っている上司よりも優れた方法で何かをしたいと思った多くの例に出くわしました。多くの場合、彼はエレガントではなかったかもしれないより単純なオプションを提唱しましたが、それは正しい決断でした。そして、正しい決断とは、会社にとってより良いことを意味します。チームとアプリケーションにとって何が良いかについて、覚えておく必要のあることがいくつかあります。

• それは機能しますか？彼らがしていることがあなたのコードよりも問題なく機能し、彼らがあなたができる限り簡単にそれを維持することができるなら、それはただの好みかもしれません。そうでない場合は、コードをポイントして、「これは保守が簡単でした。修正に30分しかかからず、問題がなかったことを確認してください」と言うことができます。その中で彼らの鼻をこすろうとしないでください、しかし例によって導きなさい。「これが私のためにどのように機能したかを見てください」と言う方が、「それがあなたのために何かを達成するので、あなたはこのようにそれをするべきです」と言う方がはるかに良いです。
• 誰もがそれを理解できますか？最新の最も優れた方法論を使用したプログラミングはクールに思えるかもしれませんが、チームの半分が2回のバグを導入せずにコードをデバッグできない場合、それは彼らがその方法がどのように機能するかを知らないためです。チームがそれらを吸収できるよりも早く新しいものを導入しないようにしてください。これは、LINQや新しいものを使用できない場合に悪化する可能性がありますが、会社にとっては正しい動きです。
• 必要ですか？接吻。または、アルバート・アインシュタインが言い換えたように、「すべてを可能な限り単純にする必要がありますが、単純にするべきではありません」。

Answer 8

どういうわけか彼らに良いコードの作業を始めさせることができますか？小さな変更をしますか？