c++ - 「あとで直す」という悪癖を克服する

Question

コードをゼロから書き始めると、すべてを 1 つの関数にすばやく書き込んでしまうという悪い癖があります。その後、製品が動作するようになり、それを修正しようとすると、関数を作成し、何を渡す必要があるかを把握する必要があります。

プロジェクトがほぼ完了したときにクラスを再設計することが非常に困難になるため、最悪の事態になります。たとえば、通常、コードを書き始める前に計画を立てます。プロジェクトが完了したときに、クラスをよりモジュール化したり、継承を使用したりできたはずだと気づきました。基本的に、私は十分な計画を立てていないと思います。また、1 レベル以上の抽象化も行っていません。

結局、私は大きなメイン関数、1 つのクラス、およびいくつかのヘルパー関数を含むプログラムに行き詰まっています。言うまでもなく、再利用性はあまり高くありません。

誰かが同じ問題を抱えていて、これを克服するためのヒントはありますか? 私が念頭に置いていたことの 1 つは、メイン関数を疑似コードで作成することでした (詳細はあまりありませんが、必要なオブジェクトと関数を確認するには十分です)。基本的にトップダウンのアプローチです。

これは良い考えですか？他の提案はありますか？

score 5 · Accepted Answer

「まず私たちは習慣を作り、それから習慣が私たちを作ります。」

これは、良い習慣にも悪い習慣にも当てはまるようです。悪いものがあなたを捕まえたようですね。

「私のやり方と同じ」になるまで、前もってよりモジュール化する練習をしてください。

score 3 · Accepted Answer

はい、慣れるまでには時間がかかりますが、解決策は簡単です。座ってリファクタリングを行うだけの「後で」あると決して主張しないでください。代わりに、引き続きコード (またはテスト) に機能を追加し、この段階で小規模な増分リファクタリングを実行します。「後で」は基本的に「常に」ですが、実際に毎回新しいことをしているフェーズに隠されています。

score 1 · Accepted Answer

1

TDD Red-Green-Refactor 規律が驚異的に機能することがわかりました。

于 2009-07-20T22:46:49.393 に答える

score 1 · Accepted Answer

私の経験則では、LoC が 20 を超えるものはすべてクリーンである必要があります。IME のすべてのプロジェクトは、製品コードになることを決して意図していなかったいくつかの「概念実証」に基づいています。ただし、これは避けられないように思われるため、20 行の概念実証コードであっても明確にする必要があります。これは、大きなプロジェクトの基盤の 1 つになる可能性があるためです。

私のアプローチはトップダウンです。私は書きます

while( obj = get_next_obj(data) ) {
  wibble(obj);
  fumble(obj);
  process( filter(obj) );
}

後でこれらすべての関数を書き始めるだけです。(通常、それらはinline名前のない名前空間に入ります。場合によってはワンライナーであることが判明し、後でそれらを削除する可能性があります。)

このようにして、アルゴリズムにコメントする必要もありません。関数名は十分な説明です。

score 0 · Accepted Answer

リファクタリングは、それを行うための優れたツールがあれば、それほど怖くありません。質問に「C++」のタグを付けたようですが、どの言語でも同じことが言えます。メソッドの抽出と名前変更、変数の抽出などが簡単にできるIDEを入手し、そのIDEを効果的に使用する方法を学びます。そうすれば、StefanoBoriniが言及する「小さな段階的なリファクタリング」はそれほど難しくありません。

score 0 · Accepted Answer

あなたのアプローチは必ずしも悪いわけではありません-以前のよりモジュール化された設計は、過剰設計になる可能性があります。

リファクタリングする必要があります-これは人生の事実です。問題はいつですか？手遅れであり、リファクタリングは非常に大きな作業であり、リスクが発生しやすいものです。早すぎると、過剰に設計されている可能性があります。そして、時間が経つにつれて、あなたは再びリファクタリングする必要があります..そして何度も。これは、ソフトウェアの自然なライフサイクルの一部にすぎません。

秘訣はすぐにリファクタリングすることですが、早すぎることはありません。そして頻繁に、しかしあまり頻繁ではありません。どのくらい早く、どのくらいの頻度で？それが科学ではなく芸術である理由です:)

score 0 · Accepted Answer

ほとんど何も入れずに、メイン関数を最小限に記述します。ほとんどの gui プログラム、sdl ゲームプログラム、open gl、またはあらゆる種類のユーザーインターフェイスを備えたものでは、メイン関数はイベントを食べるループにすぎません。そうしないと、コンピューターが応答していないように見える時間が常に長く続き、オペレーティングシステムは、メッセージに応答していないためにシャットダウンする可能性があると考えます.

メインループを取得したら、すぐにそれをロックダウンします。新しい機能ではなく、バグ修正のためだけに変更します。これは問題を別の関数に置き換えるだけかもしれませんが、イベントベースのアプリケーションでモノリシック関数を使用することはかなり困難です。100 万個の小さなイベントハンドラーが常に必要になります。

モノリシックなクラスがあるかもしれません。私はそれをしました。主にそれに対処する方法は、依存関係の精神的または物理的なマップを維持しようとし、そこにある場所に注意することです...たとえば、機能のグループが共有状態または共有変数に明示的に依存していない穴、裂け目などがありますクラスの他の関数。そこで、その関数のクラスターを新しいクラスにスピンオフできます。それが本当に巨大なクラスであり、本当に絡み合っている場合、私はそれをコードの匂いと呼んでいます。そのようなものを再設計して、それほど大きくなく、相互依存しないようにすることを考えてください。

あなたができるもう一つのことは、あなたがコーディングしているときです.関数が1つの画面に収まらないサイズに成長すると、おそらく大きすぎることに注意してください.その時点で、複数に分割する方法を考え始めます.より小さな機能。

score 0 · Accepted Answer

あなたはほとんど問題を特定しました。十分な計画がありません。開発しようとしているソリューションを分析し、それを機能に分割し、それらを実装するのに最適な方法を特定し、アプリケーションのレイヤー (UI、ビジネスロジック、データアクセスレイヤーなど) を分離してみてください。）。

OOP の観点から考えて、理にかなっているできるだけ早くリファクタリングします。すべてが完成してから行うよりもはるかに安価です。

c++ - 「あとで直す」という悪癖を克服する

8 に答える 8

Related

Reference