使用しているコードが古いコーディングスタイルを使用しているため、プログラミングできません。これはプログラマにとって普通ですか？

プログラマーとしての最初の本当の仕事はありますが、コーディングスタイルが使用されているため、問題を解決できません。ここのコード：

• コメントはありません
• 機能がない（50、100、200、300以上の行が順番に実行される）
• if多数のパスを持つ多数のステートメントを使用します
• 意味をなさないの変数を持っている（例えば：cf_cfop、CF_Natop、lnom、r_procod）
• 古い言語（2002年のVisual FoxPro 8）を使用しますが、2007年から新しいリリースがあります。

1970年に戻ったような気がします。OOP、クリーンコード、デザインパターンなどに精通したプログラマーが、この昔ながらの方法でコーディングに問題を抱えることは普通ですか？

編集：すべての答えは非常に良いです。私の（未）希望として、この種のコードベースは世界中にたくさんあるように見えます。すべての答えに言及されているポイントは、コードのリファクタリングです。ええ、本当にやりたいです。私の個人的なプロジェクトでは、常にこれを行いますが、...コードをリファクタリングすることはできません。プログラマーは、設計されたタスク内のファイルのみを変更できます。

古いコードのすべての変更は、コードにコメントを付けておく必要があります（バージョン管理としてSubversionを使用する場合も含む）。さらに、その変更に関連するメタ情報（日付、プログラマー、タスク）古い行はコメントされました）。これはコードの問題だけでなく、ソフトウェア開発の管理の問題でもあると考えています。

わかりました、私は鈍くなります。それは仕事をするのに悪い場所です...私はそのような状況にありました、そして、通常、それはあなたがこのコードに飲み込まれることで終わります。1年かそこら後、それに慣れるでしょうし、最新の代替手段を使用して同じタスクをより簡単に、より保守可能な方法で、また実行時に高速で実行する方法についての理解を失います。ほとんどの場合。

私はそのような職場を去りました。たった1か月後に、私は古いskoolコードに引きずり込まれていると感じたからです。私はそれを試してみましたが、しないことにしました。毎日の練習が不足しているため、きれいなコードを使用できず、スキルを失い始めました。モダンアプローチは、3層の開発者によって承認されなければなりませんでした。また、最新のアプローチを使用しない場合に生じるコードの脆弱な性質は非常に恐ろしいものです。

誤解しないでください、人々がソリューションを過剰に設計する場合がありますが、私はすべて反対しています。しかし、'80年のコーディング規約とスタイルに長い時間引きずられると、あなたの進歩は止まり、また、キャリアの機会も減ると思います。

それから再び、あなたはお金を稼がなければならないので、時々あなたは正確に好きではないことをしなければなりません。ただし、燃え尽き症候群に注意し、そのような場合にはコーディングを日常的な作業に変えてください。

このコーディングスタイル（任意の種類のスタイルと呼びたい場合でも）は悪いコーディングスタイルです。

ほとんどの近代的な言語で、記述的な変数名と健全なフロー制御を備えた短い関数を書くことができます（Visual FoxProは近代的です、はい）。

あなたが抱えている問題は悪いコードベースにあり、それ以上でもそれ以下でもありません。

そのようなコードベースは存在し、多くあります-あなたがそれらに問題を抱えているという事実は、それらがどれほどひどいものであるかを証明します（そして、あなたは良い訓練を受けています）。

あなたは試してみて、できることは、あなたができるものに改善している-小さなものなどにリネーム変数、エキスの共通点と除算大きな関数...のコピーを取得するレガシーコードと効果的に作業を ...

私は、あなたが説明するものから何マイルも離れていない、非常に悪い構造を持つC＃プロジェクトにいます。12個の個別の関数（明らかなコピーと貼り付け）を組み合わせて、単一のパラメーターを取る関数にしただけです。

（現在の）優れた設計手法が常に人気があるとは限らないことを除いて、それは実際には「旧式」ではありません。それはただの悪いコードです。悪いコードはだれでも遅くなります。あなたは最終的にそれに慣れますが、それはあなたがあなたの特定のシステムの特定の癖に慣れるからです。新しいプロジェクトを考えると、悪いコードを書くまったく新しい方法を見つけるかもしれません。良いことは、これらのコードの匂いを特定する方法をすでに知っていることです。

あなたができる最大のことは、問題を広めないことです。あなたのチームがそうでない限り、これらの悪い習慣を慣習として受け取らないでください。リファクタリングを強制しない方法で、新しいコードをクリーンに保ちます。それがひどくて時間があるなら、大きなリファクタリングを考えてみてください...しかし、実際にはそんな贅沢はめったにありません。

物事を理解する際にコメントを追加することを検討し、実用的には少しずつ変更してください。単独でコーディングしている場合を除き、チームでこれを解決する必要があります。慣例がなければ、時間をかけてそれらを考え出す必要があります。とにかく定期的に保守している場合は、コードベースを徐々に改善することをお勧めします。

間違った変数名を持つ完全に分離された関数を見つけて、それを修正している場合、変数名を何か有用なものにし、ifをリファクタリングすることもできます。その大部分をリファクタリングする場合を除き、一般的な機能に変更を加えないでください。

• コメントはありません- 学習しながら修正してください
• 機能を持たない（50、100、200、300以上の行が順番に実行される）

これはおそらく、コードの前回の反復からのものです。この時点で、「機能」になった似たようなコードブロック間の微妙な違いに注意します。しかし、このタイプの構造がいかに悪いアイデアであるかに関係なく、理解するのは非常に簡単です...ですから、どこで問題が発生するのかわかりません。

• 多数のパスを持つifステートメントを多数使用します- 実際の意味はわかりません
• 意味をなさない変数がある（例：cf_cfop、CF_Natop、lnom、r_procod）-

「変数の名前を変更する」ビットには注意が必要です。まだ専門用語をまだ理解していない可能性がかなりあります。変数名は、しばらくそこにいればもっと意味があります。問題のある変数名もありえないというわけではありませんが、サイトの一般的な頭字語を知っていれば、例はそれらに論理があるように見えます。1のチームである場合、これは明らかにそれほど重要ではありません。

• 私が不慣れな言語を使用します（2002年のVisual FoxPro 8）- これはコードの問題ではなく、あなたの問題です

これは私にとっては機会のように聞こえます。

物事がどのように行われ、管理されるかに多くの問題を既に見ていることは明らかです。あなたはそれがすべてゴミであり、あなたが何もできないと文句を言うか、またはあなたの雇用主にあなたの価値を本当に示す絶好の機会としてこれを使うことができます。

今、あなたがあなたの雇用主に行進し、すべてを変える必要があることを彼に伝えるならば、それはあなたを助けようとしていません。だから、コツはしばらく一緒に遊び、たくさんの質問をすることであり、コードを書く必要があるときは、他の開発者を維持する必要があるので、すべてのコメントなどのルールで遊ぶ必要があります現在好むシステムを使用して情報を提供すると同時に、何のリスクももたらさない賢明なリファクタリングを導入できます。いくつかのメソッドを抽出できます。言語がサポートしている場合は、いくつかの単体テストを導入してください。このようにした理由を尋ねられた場合、または「間違った」ことを言われた場合は、好みのコーディングスタイルの位置を適切に提示しながら、防御的または論証的にならないようにしてください。例えば、Bob MartinのClean Codeなどの本を参照するか、Programmers.SEで出会った他の本、記事、または質問と回答を参照することもできます。あなたが働いている人々の目にはあなたの経験を超えているかもしれない事実であなたの立場をサポートするのに役立つと思うことができるもの。

過度のコメントに関しては、変数とメソッドにいくつかの説明的な名前を追加する場合、これの一部を解決できますが、適切なバージョン管理システムを主張し、それを使用することもできます変更や日付などの記録を保持し、選択したVCSにまだ付属していないソースファイルのさまざまなバージョンを比較するツールを使用します。

私が言ったように、これは開発チームの改善に貢献する機会であり、いわば道を失ったように思えます。あなたには、スキルと知識があり、模範によって導くことができる人として目立つ機会があります。これらはすべて、後であなたのキャリアが進むにつれてあなたを助ける良いものです。

ジャングルにようこそ ！

残念ながら、多くの場合、会社で働き始めることは、このような状況に直面し始めることを意味します。構造化され、よく組織化された会社で働いていない限り、この状況は非常に普通です...

私のアドバイスは：

1. 学習を開始し、慣れる：使用するプログラミング言語（Clipper / dBase）と環境（Visual FoxPro）

2. コードベースを読んで分析し、コメントを開始します

3. コードの整理/リファクタリング（連続して実行される行が多すぎる問題に対処）

同様のコードベースに直面する問題は正常ですが、コード品質を改善し、プログラムに「タッチ」を与えてコードベースを改善し、より良いプログラムにするための大きな挑戦になる可能性があります...

あなたの質問に答えるために：はい、どこでも人々/会社は、くだらないコードの上に構築されるかもしれないインフラストラクチャを利用します。そのような状況に自分自身を統合するとき、対処するのは非常に困難です。

昨年の夏、私はインターンとして、特定の部門に所属するQAチームが使用するアプリケーションを開発しました。QAチームは、多くのスタンドアロンスクリプト（VBScript、Perl、Bash）を使用してデータベースなどでテストを実行し、それらを1つのアプリケーションにまとめたいと考えていました。ただし、これに関する問題は、これらのスクリプトが社内の他の場所で使用されたため（コア機能/変数名を変更できなかったため）、コードがほぼ10年間「追加」されたことです。たくさんのがらくたがたまっていた。

ただし、ここでできることは次のとおりです。

1. 助けを求めてください：このコードはおそらくその特異性に精通しているかもしれませんが、見なければならない仲間の同僚。あなたにとって鈍くて混乱していることは、彼らにとってはまったく問題ありません。だから助けを求める！
2. 可能な場合はいつでもリファクタリングします。このコードを長期間見たり維持したりする必要がある場合は、可能な限りリファクタリングします。変数名で検索と置換を実行している場合でも、少しずつ役立ちます。昨年の夏にインターンした会社には、くだらない変数名を使用するという同様の問題がありました。可能であれば、細かい歯の櫛、変数名の変更、ロジックの最適化（たとえば、さまざまな機能を1にグループ化するなど）などを通じてコードを実行できました。

どこでもそうであるように、コードの外部機能が適切に機能する限り、内部がどのように機能するかは問題ではありません。

ここで、多くのレスポンダーとは異なるコメントをします。私のコメントの多くはあなたには明らかかもしれませんが、とにかく言う必要があります。

• 理解しないコードは、理解するまで変更しないでください。
• チーム環境で作業している場合、チームメイトが作業するコードを使用して、変更を行う前に変更について話し合います。他の誰もが慣れ親しんでいるコードを変更して変更する「一人のガンマン」が好きな人はいません。これは、あなたの変更が保証されていない、または「正しい」ことをするということではありません。
• あなたのアイデアを取り入れましょう。全員をアイデアに乗せたら、ワークロード全体を負担する代わりに、チームのスキルを使用してリファクタリングできます。
• 経営陣の賛同を得ます。彼らはあなたがコードをリファクタリングするための資金を割り当てることができるかもしれません。
• コードベースをリファクタリングすることの利点について理解しているという意味で、経営陣に話してください。保守性の高いコードは、バグの解決、機能の追加などに費やす時間が少ないことを意味します。つまり、費用対効果の高い開発を意味します。より速いターンアラウンドタイムなど

環境の政治を理解することなく、純粋なコーディング、ベストプラクティスの提案を追加するのは簡単です。あなたが働く人々は、コードベースの変更に変更したり、時間を割り当てたりしたくないかもしれませんが、すべてに飛び込んで変更する前にアイデアをすべての人に売ろうとします（それ自体に本質的なリスクがあります）

お役に立てれば。

突出しているものの1つは、編集したコメントです

古いコードのすべての変更は、コードにコメントを付けたままにする必要があり、さらにその変更に関連するメタ情報（日付、プログラマー、タスク）が必要です（これは混乱になり、3行の使用行と50行のコメント付きのコードがあります）。これはコードの問題だけでなく、ソフトウェア開発の管理の問題でもあると考えています。

また、あなたが説明する多くの問題を抱えたレガシーFoxProコードベースを継承したプロジェクトもあります。プロジェクトに最初に導入したものの1つは、優れたソースコードリポジトリでした。FoxProはSourceSafeと統合できますが、その製品は使いにくいです。

Paul McNettのscxツールhttp://paulmcnett.com/scX.phpのコピーを入手し、それを開発サイクルに統合しました。Subversion、Mercurial、またはgitのようなソースリポジトリに配置できるテキスト形式にバイナリFoxProコードを抽出するという非常に良い仕事をします。（http://vfpx.codeplex.comのSubFoxプロジェクトが役立つ場合があります。

これらのツールは履歴を提供し、プログラマーがコードを維持する仕事に取り組めるようにします。これらのツールの使用方法を習得するには間違いなく時間がかかりますが、これらはすべて無料であるため、それらに時間をかけないことはあまり意味がありません。（ジョブプロジェクトをそのように動かすことができない場合でも）。

funkymushroomの答えに強く同意するつもりです。あなたがチーム環境である場合、将来良い割り当てを得る予定があるなら、コードをリファクタリングまたは再編成していることを他の人に知らせてください。

あなたは他にも変更し、維持するコード、維持されている場合は、コーディングのないあなたのスタイルながら、個人的な経験から私は、知っている滞在既存のコードのスタイルでを。コメントや説明を追加しても構いませんが、基本的なレイアウトと規則はそのままにしておく必要があります。プロジェクトの古い達人/銃は、コードが彼らが何年も見てきたものに似ていることを期待しています。

顧客がバグについて叫んでいるとき、管理者は古い銃を使って問題をできるだけ早く修正します。これらの古い銃が圧力下で「コードをクリーンアップ」し、調整する必要があるとわかっている変数をどこに移動または名前変更したかを把握する必要がある場合、会社の名前は「泥"。

危機が終われば、最初に古い銃が重要なアップデートをゆっくりと非難します。次に、会社にいる限り、クリーンアップされたコードを維持し続けることができます。最後に、新しい興味深いプロジェクトが利用可能になると、マネージャーはプロジェクトの作業者を指導者に尋ねます。一度ねじ込んだ場合は、最後に飼料が投入されるまで、新しいプロジェクトにたどり着きません。締め切りに間に合うように。

大学でコーディングの「正しい」方法を学び、現在従業員がいる場合は、その「正しい」方法を忘れてください。これらは大学での割り当てではありません。これらのプロジェクトは1学期だけでなく、何年も生きることができ、最新のCSトレンドにさまざまなレベルの専門知識とさまざまなレベルの関心を持つ人々のグループによって維持される必要があります。あなたはチームプレイヤーでなければなりません。

あなたは学校で最大のホットショットプログラミングになることができますが、職場では、あなたの最初の仕事は、ストリートストリートゼロの初心者です。何年もプログラミングをしている人は、あなたの学校や学年について気にすることはありません。それは、あなたが他の人とどれだけうまくやり、あなたが彼らの生活にどれほどの混乱をもたらすかです。

私の20年の間に、私は複数のエースプログラマーが解雇されたようです。あなたが仕事に非常に、非常に、非常にユニークな何かを持って来ない限り、あなたは交換可能です。あなたはクラスのトップだったかもしれませんが、来年、他の誰かがクラスのトップになり、仕事を探します。

私はそれをあなたの主な仕事と考えています。あなたが仕事を変えることを決めるまであなたの仕事を続けることです。仕事を続けるには、他の人が作り、支払いをした遊び場で素敵な遊びをしなければなりません。

私は否定的に聞こえるかもしれませんが、常に希望があります。経験を積んで成功すると、影響力を獲得し、物事をより良い方法に変えることができます。新しいコードを書くとき、または新しいプロジェクトで、求める変更をプッシュします。それが新しいコードである場合、古い銃はそれが去った方法であると期待していません、そして彼らが利点を見るとき、彼らは新しい方法を学び、適応するかもしれません。

古いシステムは変更できますが、時間がかかります。何かを変えるとリスクが発生し、ビジネスがリスクを憎むため、時間と労力をかけて会社が変化に対応できるようにする必要があります。