63

レガシー (コア) システムで作業している開発者が、すでにスパゲッティ コードに感染している既存のコードに新しい機能を追加する際に、GOTO ステートメントを使用するよう圧力をかけられているという状況が職場で発生しています。

さて、より保守しやすいソリューションへのリファクタリングに時間を費やす代わりに、「たった 1 つの小さな GOTO」を使用することについての議論があるかもしれないことを理解しています。問題は、この孤立した「たった 1 つの小さな GOTO」がそれほど孤立していないことです。少なくとも 1 週間に 1 回程度、新しい 'one little GOTO' を追加します。このコードベースは、1984 年以前にさかのぼるコードが GOTO だらけで、多くのパスタファリアンがフライング スパゲッティ モンスター自体に触発されたと信じるようになるため、作業するのがすでに恐ろしいものです。

残念ながら、これが書かれている言語には既製のリファクタリング ツールがないため、「後で生産性を高めるためのリファクタリング」をプッシュするのが難しくなります。

新しい GOTO を追加して 2000 行をランダムなセクションにジャンプすることはできないということで誰もが同意しているこの問題を経験した人はいますか?

tldr;

開発者が継続的に GOTO ステートメントを追加するよう圧力 (強制) されているという問題に対処するにはどうすればよいでしょうか (追加とは、何行も離れたランダムなセクションにジャンプするために追加することを意味します)。

この件でラプターズに貴重な開発者を失うのではないかと心配し始めています...

クレジット:

説明:

後藤 here

alsoThere:いいえ、これは、while ループの途中で、1 つのサブルーチンから別のサブルーチンに 1000 行ジャンプするような goto のことです。後藤 somewhereClose

there:私は、プログラムが何をしていたのかを合理的に読み取って判断できる goto の種類についても話していませんでした。後藤 alsoThere

somewhereClose:これはミートボールを作るようなコードですmidpoint: 初めてここに行く場合 nextpoint detail:(それぞれほぼ完全に異なります) Goto pointlessReturn

here:この質問では、goto を時々使用しても問題ないことについて話しているのではありません。後藤there

tacoBell:そして、それは製図板に戻ったところです。後藤 Jail

elsewhere:アナリストがプログラムに触れるたびにその動作を解読するのに数週間かかる場合、コードベースに深刻な問題があります。実際、仕様goto gotoのhell:最新の goto 4レンディションではないにしても、私は実際に detail pointlessReturn: tacoBell

Jail:実際には、小さな勝利を収めた小さなアップデートです。この特定のプログラムの一部を一度に 1 つのラベルずつリファクタリングするのに 4 時間を費やし、各反復を svn に保存しました。各ステップ（約20個）は小さく、論理的で簡単で、食事から自然に飛び出し bypass nextpoint:、奇妙な種類のスパゲッティミートボールの磁力を介して画面に飛び出しました. Goto elseWhere bypass:は、ロジックの変更を導入しないことを合理的に検証します。この読みやすい新しいバージョンを使用して、私はアナリストと話し合い、この変更のほとんどすべてを完了しました。後藤 end

4:最初 *の場合は初めてここに移動hell、なし 2 番目の場合は初めてここ hellに移動、なし 3 番目の場合は初めてここ hellに移動4 番目は現在最新の移動 hell

end:

4

10 に答える 10

28

GOTOが正しく記述されていないために、いくつのバグが発生しましたか？彼らは会社にいくらのお金をかけましたか？問題を「これは気分が悪い」ではなく、具体的なものに変えてください。担当者に問題として認識されたら、「関数の終了ロジックを単純化する以外は新しいGOTOを使用しない」、「機能を実行しない関数には新しいGOTOを使用しない」などのポリシーに変換します。 100％のユニットテストカバレッジがあります。」時間の経過とともに、ポリシーを厳しくします。

于 2010-05-26T04:18:46.190 に答える
12

GOTOは優れたコードスパゲッティを作成しません。他にも多くの要因が関係しています。このLinuxメーリングリストの議論は、いくつかのことを展望するのに役立ちます（gotosの使用の全体像についてのLinus Torvaldsからのコメント）。

gotosがないという理由だけで「gotoなしのポリシー」を設定しようとしても、長期的には何も達成されず、コードの保守性が向上しません。変更はより微妙で、コードの全体的な品質の向上に焦点を当てる必要があります。プラットフォーム/言語、単体テストカバレッジ、静的分析などのベストプラクティスの使用に沿って考えてください。

于 2010-05-26T04:19:36.010 に答える
4

開発の現実は、それを正しい方法で行うことについてのすべての華やかな言葉にもかかわらず、ほとんどのクライアントはそれを速い方法で行うことにもっと興味を持っているということです。コードベースが急速に崩壊し、その結果としてビジネスに影響を与えるという概念は、今日を超えて考える必要があるため、理解できないものです。

あなたが持っているのはほんの一例です。これにどのように立つかによって、将来の開発方法が決まります。私はあなたが4つのオプションを持っていると思います：

  1. リクエストを受け入れ、常にこれを行うことを受け入れます。

  2. リクエストを受け入れて、すぐに新しい仕事を探し始めます。

  3. やることを拒否し、混乱を修正するために戦う準備をしてください。

  4. 辞任。

どのオプションを選択するかは、自分の仕事と自尊心をどれだけ大切にするかによって異なります。

于 2010-05-26T04:22:12.853 に答える
4

ボーイスカウトのパターンを使用できるかもしれません。したがって、すべての機能要求に対して: 新しい goto を導入するのではなく、1 つ削除します。

これにより、改善に多くの時間を費やさず、新たに導入されたバグを見つけるためにより多くの時間を割くことができます。部分から goto を削除すれば、追加の時間はそれほどかからないかもしれませんが、理解と新機能の導入に時間を費やす必要がありました。

2 時間のリファクタリングにより、将来的には 15 分の 20 倍が節約され、より迅速かつ深い改善が可能になると主張します。

于 2010-06-03T11:50:27.833 に答える
3

これは、古典的な「管理者」対「技術者」の対立です。

「技術者」チームに所属しているにもかかわらず、私は何年にもわたって、この議論の「管理」側をしっかりと解決してきました。

これにはいくつかの理由があります。

  1. goto を使用して、適切に構造化されたプログラムを読みやすく、適切に作成することは十分に可能です。アセンブラー・プログラマーに聞いてください。条件分岐とプリミティブ do ループだけで動作します。「スタイル」が最新ではないという理由だけで、よく書かれていないという意味ではありません。

  2. それが混乱している場合、完全に書き直す場合に必要なビジネスルールを抽出するのは本当に面倒です。または、プログラムの技術的なリファクタリングを行っている場合は、リファクタリングされたプログラムの動作は「正しい」、つまり古いプログラムとまったく同じ動作をします。

  3. 投資収益率 -- 元のプログラミング スタイルに固執し、変更を最小限に抑えることで、労力を最小限に抑え、顧客の要求を迅速に満たすことができます。リファクタリングに多くの時間と労力を費やすと、費用がかかり、時間がかかります。

  4. リスク -- 書き直しとリファクタリングを正しく行うのは難しく、リファクタリングされたコードの広範なテストが必要であり、「バグ」のように見えるものは、顧客に関する限り「機能」であった可能性があります。レガシー コードを「改善」する際の特定の問題は、ビジネス ユーザーが、そこにあるバグに依存する十分に確立された回避策を持っているか、IT 部門に通知せずにバグの存在を悪用してビジネス手順を変更する可能性があることです。

全体として、経営陣は決定に直面しています。「小さな goto を 1 つ追加して」変更をテストし、2 倍の速さでほとんどリスクを伴わずに本番環境に移行するか、または大規模なプログラミング作業に取り掛かり、ビジネスに悲鳴を上げさせるかです。新しい一連のバグが発生したとき。

そして、もしあなたが 5 年以内にリファクタリングすることに決めたら、鼻の高い大卒者が、あなたのリファクタリングされたプログラムがもはや流行語に準拠していないことを嘆き、何週間もかけて書き直すことを許されるよう要求するでしょう。

壊れていない場合は、修正しないでください。

PS: Joel でさえ、これは悪い考えだと考えています:絶対にやってはいけないこと

アップデート！-

コードをリファクタリングして改善したい場合は、適切に処理する必要があります。

基本的な問題は、あなたがクライアントに「私はこのプログラムに n 週間取り組みたいと思っており、すべてがうまくいけば、現在とまったく同じように機能するでしょう」と言っているということです。-- これは控えめに言っても難しい売りです。

クラッシュや停止の回数、一見小さな変更の分析とプログラミングに費やされた時間、難しすぎたために実行されなかった変更要求の数、システムが迅速に変更できなかったために失われたビジネス機会について、長期的なデータを収集する必要があります。足りる。また、よく構造化されたプログラムを維持するコストと、それを放置するコストに関する学問的データを収集してください。

ビーンカウンターに提示する防水ケースがない限り、予算は得られません。これは直属の上司ではなく、経営陣に売り込む必要があります。

于 2010-05-31T02:05:46.863 に答える
3

原則に戻る:

  • それは読めますか？
  • それは機能しますか？
  • メンテナンス可能ですか？
于 2010-05-26T07:23:38.320 に答える
1

残念ながら、これが書かれている言語には、既製のリファクタリングツールがありません。

マクロ機能を備えたエディターはありませんか？シェルスクリプトはありませんか？私は何年にもわたってたくさんのリファクタリングを行ってきましたが、ブラウザのリファクタリングではほとんど行っていません。

于 2010-07-18T20:10:18.897 に答える
1

私は最近、それ自体がレガシーではないコードに取り組む必要がありましたが、以前の開発者の習慣は確かにそうであり、したがってGOTOはいたるところにありました。私はGOTOが好きではありません。彼らは物事の恐ろしい混乱を引き起こし、デバッグを悪夢にします。さらに悪いことに、それらを通常のコードに置き換えることは必ずしも簡単ではありません。

GOTOをほどくことができない場合は、使用しないことをお勧めします。

于 2010-05-26T04:20:42.827 に答える
1

ここでの根本的な問題は、一部のコードに goto を追加するという点で、おそらく必要な機能の変更を説明する「アナリスト」がいるようです。そして、「プログラマー」の仕事は、その変更を入力し、それについて不平を言うことに限定されているように見えます。

何かを変えるには、それらの人々の間の機能不全の責任の割り当てを変える必要があります。作業を分割するには、さまざまな方法があります: 古典的で従来型の方法 (これはおそらく、あなたの仕事では公式ではあるが無視されているポリシーです) は、アナリストに実装に依存しない仕様ドキュメントを作成させ、プログラマーにそれを次のように実装させることです。可能な限り保守的に。

この理論的アプローチの問題点は、多くの一般的な状況で実際には実行不可能なほど非現実的であることです。特に、それを「適切に」行うには、後輩と見なされている従業員が、より年上の同僚との議論に勝ち、オフィスでより良い社会的つながりを持ち、ビジネスに精通している必要があります。引数「goto は実装に依存しないため、アナリストとしてその言葉を単純に言うことはできません」という引数がワークスペースで飛ばない場合、おそらくこれが当てはまります。

多くの状況では、次のような代替手段の方がはるかに優れています。

  1. アナリストはクライアント向けのコードを書き、開発者はインフラストラクチャを書きます。
  2. アナリストは、単体テストの参照実装として使用される実行可能な仕様を作成します。
  3. 開発者は、アナリストがプログラミングするドメイン固有の言語を作成します。
  4. あなたはハイブリッドだけを持って、彼を一方と他方の区別を落とします。
于 2010-07-18T20:54:05.133 に答える
-1

プログラムの変更に「ちょっとした goto」が必要な場合、そのコードは非常に保守しやすかったと言えます。

これは、レガシー コードを扱う場合によくある問題です。プログラムが最初に書かれたスタイルに固執するか、コードを「最新化」します。私にとっての答えは、完全な書き直しを正当化するような非常に大きな変更がない限り、通常は元のスタイルに固執することです。

また、Java の「throw」ステートメントや SQL の「ON ERROR」などのいくつかの「最新の」言語機能は、実際には変装した「GO TO」であることに注意してください。

于 2010-05-26T05:53:44.553 に答える