私のコードの大部分には大きな設計上の欠陥があります。終了するか、今すぐ修正しますか？[閉まっている]

私は高校生で、私の友人と一緒にC＃プロジェクトに取り組んでいます。私のスキルレベルはほぼ同じです。これまでのところ、100件のコミットで約3,000行のコードと250行のテストコードを記述しました。学校のために、私は数ヶ月プロジェクトを延期し、最近私はそれを再び取り戻すことができました。

バックアップを取得するまでに、レンダラーに過剰なスレッドを含める、エミュレートされたCPU、GPU、ゲームカートリッジ間の相互作用における競合状態の防止が不十分であるなど、記述したコードの設計が不十分であることがわかりました、および単に冗長でわかりにくいコードも同様です。

問題は、プログラムの主要な機能すら完成していないため、真のリファクタリングができないことです。コードの設計に欠陥があることを完全に認識し続けることはできません。同時に、私はプロジェクトを放棄したくありません。かなりの量の進歩があり、作業が無駄になってはいけません。

私はいくつかの選択肢があるように感じます：貧弱なデザインを回避し、すべてが機能したらリファクタリングし、すべてを停止し、残りの機能が完了する前にすべてのもつれを解き、プロジェクトを開始することによって、単に機能を終了するそれがすべて私の心に再び新鮮であるように、または過度のサイズのためにプロジェクトを完全に放棄するように（本質的に「図面に戻る」）。

そのようなプロジェクトにおける他の人の経験に基づいて、自分を正しい軌道に乗せるための手段は何ですか？このサイトの回答から、一般的なコンセンサスは、書き換えは一般的に不要であるが、過剰なコストなしにコードを維持できない場合に利用可能なオプションであるということです。私は本当にこのプロジェクトを追求したいと思っていますが、現状では、私のコードは私が続けるのに十分に設計されておらず、落胆の感覚が私を継続からそらします。

もし私があなたの靴を履いていたなら、おそらく次のように試してみるでしょう。

• 最初に、現在のプロジェクトを（少なくとも部分的に）できるだけ早く、ただし作業状態で終了します おそらく、元の目標を減らす必要があります。「バージョン1.0」で本当に必要な最小限の機能について考えてください。

• そして、とだけにして最初から書き直しを考える（この「バージョン2.0」を呼び出すことができます）。V1.0のコードの一部を再利用できるかもしれません。たぶん、この状況で再び寝た後、V1.0をリファクタリングし、そのほとんどを保存できるという決定に至ります。ただし、「概念実証V1.0」が手元にない前にこの決定をしないでください。

動作中のプログラム「1.0」は、コードが悪い場合でも、他の人に見せることができるものです（自分以外は誰も気にしません）。V2.0の作成中に時間が足りないと気付いた場合でも、V1.0は部分的に成功しているため、士気が大幅に向上します。ただし、V1.0を最初に終了しないと、途中でV2.0を完了できなくなる可能性が高くなります。途中で設計に不満を感じる点があります。V2.0を再び放棄し、V3.0で作業しますか？この終わりのないサークルにぶつかり、終わりに至らないという高いリスクがあります。

これを、プロジェクトを未完成状態のままにする方法を学ぶ機会ではなく、中間目標を達成する方法を学ぶ機会として捉える方がよいでしょう。

完成したITプロジェクトは、障害のあるプロジェクトであっても、未完成のプロジェクトよりもはるかに優れています。

未完成のものもあなたに多くを教えることができますが、完成したものほどではありません。

今は表示されないかもしれませんが、欠陥のあるコードでさえも非常に大きな価値があります。

私の投票は、必要に応じて、仕上げ、そしておそらくリファクタリングに進みます。より多くのプロジェクトで作業を開始すると、驚くほど多くの場合、「リファクタリングされることを意図されていた」部分は何年も変更されず、他の部分が拡張されることがわかります。

雇用の観点から見ると、ほとんどの場合、完成したプロジェクトに対してより多くの称賛を得ます。

私は喜んでプロジェクトをやり直します。

あなたは学生であり、まだ学んでいます。これにより、リンク先の質問とはまったく異なる立場になります。

• コードに対して専門的な責任はありません。プロジェクト全体を今すぐ削除して、立ち去っても、何の影響も受けません。これは開発者にとって大きな利点です。あなたがリンクした質問では、これらの開発者は人々がお金を払っているソフトウェアを維持しようとしています。小さなバグでさえ顧客に大きな問題を引き起こす可能性があり、ゼロから書くのは危険です。その問題はありません。

• 個人的なプロジェクトとして、これは新しいことを試してミスから学ぶ絶好の機会です。古いコードに問題があることを認識するのは素晴らしいことです。それは、より良い方法を学んだことを意味するからです。試行錯誤による経験は、初心者プログラマーにとって非常に貴重です。

• プロジェクトは比較的小さく、基本的にテストはありません。特に次回から何をするべきかについてのアイデアをすでに持っているので、3000行をゼロから書くのは数晩ほど短いかもしれません。

• 壊れたコードベースで作業することは、書き換えよりもはるかに大きな士気の浪費になります。

余談ですが、これは単体テストでよりモジュール化されたプログラムを作成する大きなチャンスです。そうすることで、長い休憩の後にコードに戻った場合にコードを理解しやすくなり、忘却のために誤って導入する可能性のあるエラーを防ぐのに役立ちます。

最後に、ここでは時々前方に大きなステップを取るために、後方のステップを取るの知恵の意見があります。

あなたはおそらくあなたの開発の「早く学ぶ」部分にいるでしょう。数か月後、新しい素晴らしいデザインが、開始時に気付かなかった方法で恐ろしく壊れている可能性があります。

物事を成し遂げる -これはあなたが学ぶ必要がある唯一の最も重要なことです。私を信じて、私は「プログラマーだけでなく」多くの人々を知っています。「このプロジェクトを始める前に多くを学んだので、ゼロからやり直し続ける」ループに固執しています。問題は、決して終わらないことです-新しいことを学ぶのをやめるまで、これは良い場所ではありません:)

実際に何かを仕上げることができるためにも重要です。最初からやり直すのは、エキサイティングで、クールで、楽しいです...しかし、それを学んだだけでは、何も終わらないでしょう。繰り返しますが、それはあまり有用な能力ではなく、実際に何か有用な（または楽しい）を作成するほど良い感じではありません。人生は短く、時間は限られており、具体的な結果なしで練習を続けることはできません-あなたはそこからかなり怒ってしまいます。どのアプローチを採用するか決められないために作業を開始できない場合は、すでに危険地帯にいます。

やり直す衝動が常にあります。学習環境であっても、それらはおそらく悪い考えです。だからといって、すべてのプロトタイプを実稼働対応のアプリケーションに運ぶ必要があるわけではありません。しかし、少なくともプロトタイプの作業段階に到達する必要があります-それはあなたの士気を高める可能性が最も高く、あらゆる種類の開発者にとって非常に有用な特性です。物事を成し遂げなさい。楽しいのは、プロトタイプを「ゼロから書き直す」のではなく、多くの場合、リファクタリングすればできるのではなく、プロトタイプでできることは何百万もあるということです。あなたがすることはすべて費用がかかります-少なくとも、あなたはその間に何か他のことをしていたかもしれません。

私はソフトウェア開発の「機能させる、正しく機能させる、高速にする」というイデオロギーに従います。

1. 動作させる：プロジェクトが使用できるように、コア機能を作成します。いコードであっても、すべてを機能させるために必要なことを行います。
2. それは右ください：バグを修正し、読んで理解し、維持することが容易になるようにコードをリファクタリング。
3. 高速化：プログラムを最適化し、速度、リソース使用量、保守性のバランスを図ります。

現時点では、ステップ1は完了していません。最初にステップ1を実行してから、コードのhowさを心配することができます。実際に動作する製品を作成することは、新しい開発者が行うのが最も難しいことの1つです。なぜなら、彼らはコードを初めて完璧にしようとすることに夢中になり、最適化の地獄で立ち往生し、実際に仕上げることができないからですすべての機能を実装します。ソフトウェアを機能させることに集中できるように、リファクタリングと最適化についての心配をすべて取り除く方法を学ぶ必要があります。より多くの経験を積めば、最初はより多くのことを自然に行うことができるので、必要なリファクタリングは少なくなります。

留意してください：早すぎる最適化はすべての悪の根源です（良い議論については、このすばらしいProgrammers.SEの質問を参照してください）。コードを改善する方法について考えるのに時間がかかりすぎると、分析の麻痺に陥ります。これによりプロジェクトが強制終了されます。最適化を開始する前に、プロジェクトを完了させることをお勧めします。

優れた動機付けのスピーカーを引用するには、それを行うだけです。

いつものように、関連するxkcdがあります。

書き直してください。動作しないコードにはほとんど価値がなく、3000行はあまりコードではありません。あなたが現在持っているコードを書くのにかかったのと同じくらい長くはかかりませんし、ずっと良くなるでしょう。私はしばしば500行または1000行の貧弱なコードを捨てており、多くの場合、書き換えは5分の1の長さです。

「書き直さない」という概念のほとんどは、重要なことを実行し、進化する要件を満たすために絶えず変化する大規模システムに関連しています。使用中の複雑なシステムの書き換えはほとんど成功しません。

あなたの状況は正反対です。ユーザーのいない小さなアプリケーションがあり、唯一の要件は実装することを選択したものです。それでは先に進んで書き直してください。

ゼロからの再起動は、通常、実際のプロジェクトでは、悪い動きで、現実のプロジェクトはnewcoming開発者が認識していないというバグ修正を蓄積する主な理由（例えば、参照あなたが行うべきではありません物事から、ソフトウェア上でジョエルのブログを。）

それにもかかわらず、学校のプロジェクトはそのような歴史を継承せず、通常、コンピューティングの部分的な知識と経験の欠如を同時にコーディングおよび設計することから始まります。あなたの最初のバージョンはプロトタイプであり、失敗したコンセプトの証明として使用され、それを喜んで捨てます（使い捨てと進化のプロトタイプの議論については、使い捨てと進化のプロトタイプの違いは何ですか？を参照してください）

適切なデザインは頭の中で成熟しており、コードに書き留めるのにそれほど時間はかからないはずです。

私は、書き換えは悪いアイデアであるという提案に敬意を持って反対します。

ソフトウェアライフサイクルの領域では、エラーを修正するために必要な時間と労力がライフサイクルの各レイヤーの桁で増加することが一般に受け入れられています。つまり、要件レベルでエラーを修正するのに1時間かかる場合、設計に10時間、コーディングテストに100時間、バグ修正として1000時間かかります。これらの数字はとんでもないように聞こえるかもしれませんが、業界ではほぼ正しいと認められています。明らかに、小規模なプロジェクトでは少なくなりますが、一般的な考え方は残ります。プロジェクトに基本的な設計上の欠陥がある場合は、それを学習体験と呼び、戻って最初の要件を確認し、再設計する方が適切です。

また、構造化された単体テストを使用したテスト駆動開発モデルの検討をお勧めします。それらは苦痛であり、最初は時間の浪費のように見えますが、特に他の誰かのコードと統合するとき、エラーを明らかにする能力は誇張できません。

この文章で私を失った：

問題は、プログラムの主要な機能すら完成していないため、真のリファクタリングができないことです。コードの設計に欠陥があることを完全に認識し続けることはできません。

私は（Systemanticsで述べられている）原則を信じています

• 動作する複雑なシステムは、動作する単純なシステムから進化したものであることが常にわかります。
• ゼロから設計された複雑なシステムは決して機能せず、パッチを適用して機能させることはできません。動作するシンプルなシステムから始めて、最初からやり直す必要があります。

したがって、複雑なシステムの作成には

• 簡単なシステムを書く
• 動作確認

...すなわち、次の手順：

1. コードを少し書く
2. テストして、機能することを確認します
3. もう少しコードを書く
4. もう一度テストする
5. 等。

ステップ3には以下が含まれることがあることに注意してください。

3. もう少しコードを書く
   1. 既存のコードをリファクタリングして、新しい追加のために準備します
   2. リファクタリングをテストして、まだ機能することを確認します
   3. 新しい機能を追加する

また、ステップ2「テストして動作することを確認する」では、動作しない場合は書き換えが必要になる場合があります。

腐敗したコードベースに基づいて構築している場合、さらなる機能を追加することに気が進まないでしょう。そのため、次に実装する作業として、「既存のスレッド実装を単純化する」などのスケジュールを立てたいと思います。進めながらテストを行っていると仮定すると、これをリファクタリングの練習として扱うことができるはずです。この作業フェーズの成功/終了基準は次のとおりです。

• ソースコードはよりシンプルです
• 新しいバグは導入されていません
• （およびいくつかの古いバグが排除されました）

ちなみに、「テストして動作することを確認する」とは必ずしも「単体テスト」を意味するものではありません。チーム構造が単純な場合は、（単純な）システムテスト（代わりに単体テスト）を使用して（単純な）システムをテストできます。

このような問題に遭遇したときに直面している問題の1つは、これまでに何らかの方法で書いたコードに感情的に執着していることです。

同僚は、大学でプログラムを書いている間、有名な教授からレッスンを受けたと言っていました（ダイクストラだと思います）。彼は、教授に1か月以上取り組んでいたコードを見てほしいと頼みました。教授は彼にバックアップを作成したかどうかを尋ねたが、ノーと答えた。その後、教授はすべてのコードを削除し、もう一度書くように指示しました。

彼は腹を立てていましたが、3日後には、よりきれいなコードと、より少ないバグとより少ないコード行でプログラムを終了しました。

プロジェクトで利用可能な時間内に最適なオプションを正直に見積もってください。

3つの選択肢は

• 削除します（完全に、振り返らないでください）
• 古いデザインで作業を続ける
• 移動中にコードをリファクタリングします。

私は10年以上プロのプログラマーであり、私の仕事の中で、最後の選択肢はほとんどの場合選択されたものであると結論付けましたが、常に最良の選択肢とは限りません。

その期間にスキルが大幅に向上したようです。おそらく、そのプロジェクトでの作業がそれに貢献したのでしょう。目的のある学習体験として再び設計することは有益です。

覚えておいて、これは顧客のための実用的なプログラムとして提供する必要があるものではありません。それは特に練習のために書かれました。そのため、代わりに出荷の問題と配送の欠陥を練習したくない限り、「設計の筋肉」を働かせることが実りある開発段階にあると思います。

そうするときは、設計プロセスと計画に焦点を合わせ、既存のものを熟考し、よりよく理解していることを振り返ってください。

リファクタリング。リファクタリング。リファクタリング！リファクター!!!!

正直なところ、あなたがどれほど経験豊富であっても、これはよくある問題です。あなたはコードを書き、何かを学び、古いコードで新しい知識を使いたいと思っています。新しい知識に対して古いコードを測定する必要があります。

それはうまくいきません。その場合、アプリケーション/ゲームは完了しません。代わりに、プロジェクトに時間を割り当てて、「タスク」の一部が不良コードをリファクタリングするようにしてください。たとえば、ゲームを保存する恐ろしい方法があったとしましょう。ゲーム自体の作業を続けますが、その恐ろしい方法をリファクタリング（置換）する時間があります。リファクタリングを小さく保つようにしてください、それは問題ではないはずです。

リファクタリングを必要とするアプリケーションの大部分に到達すると、それは真剣に間違っています。そのリファクタリングを小さなパーツに分解します。コードの記述に7時間、リファクタリングに1時間費やすようにしてください。

プロジェクトが完了し、機能がフリーズすると、リファクタリングに膨大な時間を費やすことができます。とりあえず、ゲームを終わらせてください、それでもいくつかをリファクタリングしてみてください。それはあなたができる最高のことです。

リファクタリングするものが常にあります。

私はそれがあなたが今持っているコードの種類と正確に問題がどこにあるかに少し依存すると言うでしょう。つまり、基盤が優れている場合（ほとんどの部分で適切なクラス設計、適切なデカップリング/結合など、あなたが言及したスレッドのようないくつかの悪い選択）、すべての手段でベアボーン1.0を取得してから、明日はありません。

一方、それが本当に見分けがつかない構造などを持たない、コンパイラを通過する見苦しいスラップされたテキストファイルの束（つまり、概念実証の実地学習プロトタイプ）である場合、それから私はむしろそれを削除してやり直します。

次のバージョンでは、アジャイルアプローチを実行します。2週間など、スケジュールに合った繰り返しタイムラインを設定します。各チャンクの始めに（スプリントと呼びましょう）、2週間で達成可能な目標を設定します。先に進み、それらを実行します。2週間ごとに、抽象的な内部作業だけでなく、友人に見せることができるように目標を設定します。Googleの「スクラム」と「スマートゴール」。一人でいる場合、これはすべて非常に簡単に実行できます。一枚の紙に短い箇条書きをいくつか書き留めます。

それができるなら、最初からやり直すことは良いことです。最初からやり直した後、その奥深くを知っていれば、とにかく現在の場所にたどり着く可能性があります。その後、コードを守り、機能させます。

あなたは雇用主の靴に身を置く必要があります。

ほとんどの採用担当者にとって、この方法を採用すれば最も価値があります。-作成する新しいコードで100％のテストを行って終了します。-古い（悪い設計の）コードのテストを追加します。-リファクタリングして、デザインとして必要なものを実現します。

すべてを適切なバージョン管理プロセス、ブランチ、タグで行います。

書き換えはしばしばセクシーなアイデアですが、多くの場合、新参者が持っているアイデアであり、実生活ではちょっと危険です。ゼロから始めることは、あなたが真面目な人であることの良い兆候ではなく、あなたがすでにやった仕事の質を改善したいと思っていることを示します。

ただし、明らかに書き換えることはできますが、その場合は別のプロジェクトにします。

過去の経験の一部をミックスに追加するだけです。予備の数分を得るたびに、私はもう1年以上サイドプロジェクトに取り組んでいます。このプロジェクトは、単純なテストベッドから静的クラス、そして現在のオブジェクト指向のスリムラインデザインになりました。

これらのすべての変更を通じて、バグ修正とパフォーマンス上の利点を除いて、コードの同じ機能を維持しました（できるだけ速くする必要があります）。リファクタリングされたものの、同じコードベースは同じままであるため、コードを最初から書き直して時間を無駄にすることなく大幅に改善しました。

これは、以前よりも速くコードを改善できることを意味します。それはまた、私が行っていたときに、何を削除する必要があるか、つまり不要なクラス、そして私の心の中にある古いアイデアで書き直すよりも簡単にできるものを伝えるのが簡単だったことを意味しました。

したがって、私のアドバイスは、コードをリファクタリングし、そこから先に進み、必要に応じて改善することです。ゼロから書き直すことにした場合は、古いプロジェクトの良いアイデアを取り入れて、それらを詳しく調べて、どこに欠陥があるかを確認する必要があります。つまり、古いコードを新しいプロジェクトにコピーするだけではありません。

答えは、私が「複雑さの上限」と呼ぶものに依存します。コードベースにどんどん追加していくと、コードベースはますます複雑になり、整理されなくなります。ある時点で、「複雑さの上限」に達し、その時点で前進が非常に困難になります。総当たりで移動し続けるのではなく、バックアップし、再編成/書き換えを行ってから、前進し続ける方が良いでしょう。

あなたのコードベースは非常に悪く、複雑さの限界に近づいていますか？そうだと感じた場合は、先に進む前に少し時間をかけて整理して整理してください。クリーンアップする最も簡単な方法が一部の部分を書き換えることである場合、それは問題ありません。

どちらでもない？両方？

先に進み、既存のデザインの修正に時間を費やし、新しい機能を追加します。

際どいやり取りがある場合は、そこから始めるのが良いかもしれません（「レンダラーの過剰なスレッド」は、正確性の問題を引き起こすものではなく、非効率のように聞こえます）。レース（および場合によってはデッドロック）を回避する一般的な方法、または少なくとも複数の特定の方法を理解できるかどうかを確認します。

デッドロックや競合検出器のようなものがC＃でどの程度利用可能かはわかりませんが、存在する場合は、問題の特定や修正が機能していることの確認に役立つ場合があります。

私は、一般に、何かを有用なことを行うコードの問題を修正し、それを捨てて再びゼロから開始するよりもやる気があると感じています。焼け焦げたフィールド（グリーンフィールドやブラウンフィールドと同様）の開発がより満足のいく場合がありますが、それは通常、既存のアプローチが本来あるべきところから外れており、もはや間違っていないということです。

コードがモジュール式である場合、不適切に作成されたコンポーネントの周りの残りのコードを終了し、残りのコードに影響を与えることなく、不適切に作成されたコンポーネントを書き直すことができるはずです。

その場合、正しく記述されていないコンポーネントを書き直すのはあなた次第です。ひどく記述されたコンポーネントが非常にひどく記述されていて、完成したコードがそのままでは動作しない場合、残りのコードを終了する前にそれらを書き直す必要があります。

自問すべき最初の質問は、「欠陥はどれほど悪いですか？」です。

正確に何を間違えましたか？

何かがひどくて問題を処理しようとして何時間も無駄にしたり、機密データ（パスワード/クレジットカード）を公開したり、悪い脆弱性を引き起こしたりする場合は、編集する必要があるかもしれませんが、ほとんどの場合持っているものを取り出して仕上げ、問題を後で修正します。

プログラマーはアプリケーションを改善して「できる限り最高のもの」にしたいと望んでいますが、それは正しいアプローチではありません。

できるだけ早くアプリケーションをリリースすると、100％でなくてもバグがすべて発生します。バージョン1.1のバグやその他の問題を修正する時間があれば、他のユーザーからフィードバックを受け取ることができます。他の人々は、あなたがアプリケーションをより良くするのを手伝うことができるでしょう、そして、あなたは人々が嫌うかもしれない何かをするのに時間を浪費したかもしれません。

それで、あなたの場合、そこにそれを出して、フィードバックを得てください、そして、あなたはすべての変更でバージョン2.0を構築して、あなたが持っている欠陥を修正することができます。

覚えておくべきもう1つのことは、私たちは常に改善しているということです。1年前のコードを見て、それが悪いとわかるなら、それはあなたがまだ改善していることを意味するという格言があり、それは素晴らしいことです。

それはあなたのコードが台無しになっていることに依存します。

• コードを過度に複雑または冗長にする実際のn00bエラーを作成した場合は、それらの部分を書き直すことをお勧めします。

• とにかく修正しなければならない重大なバグがあると思われる場合は、バグを修正したかどうかを確認できる単体テストを作成します（まだプログラムを起動できないため）。バグを早期に修正することをお勧めします。また、コードが何をしているのかを覚えている間にバグを修正することは間違いなく優れています。

• メソッドの呼び出し方、メソッドが属するクラス、またはそのような小さなものが気に入らない場合は、IDEを使用してください。（これはC＃であり、javascript、python、perl、phpなどではありません。）影響を受けるコンポーネントを使用するコードで作業しているときに、そのコンポーネントが何をすべきかを明確に把握している場合、 IDEで問題がなければ、リファクタリングします。

それ以外の場合は、機能させて次のプロジェクトでスキルを磨きます。

他の人が示唆しているように、これは個人的なプロジェクトであり、（まだ）プロのプロジェクトではないので、書き換えを真剣に検討します。

ただし、ここで実験を実行することにより、科学的な方法を活用できます。まず、仮説を立てます。私の場合は、「おそらく書き換えの時間です」。時間を節約し、失敗のコストを削減し、先験的なバイアスをある程度制限するために、さらにプログラミングを行う前に、時間の長さ（「タイムボックス」）を決定します。おそらく4時間の実時間をお勧めします。また、仮説を評価するための方法論を決定します。利害関係は低いので、方法論として、「自分がこれをやったことがうれしい」と自問することをお勧めします。さあ、実験を始めましょう。選択した時間ボックスの後、仮説の評価は何ですか？例えば、私の例から、あなたがそれをするのに4時間を費やした今、あなたが書き直しを始めてうれしいですか？その後、おそらく正しい選択です。

世界のすべてのアドバイスを求めることができますが、経験的に仮説を検証することほど良いものはありません。

書き換えを実験として選択することを検討するいくつかの理由：

• 私の経験では、通常はもっと楽しいです。書き直しがプロの状況でしばしば選択されない大きな理由は、楽しみが唯一の基準から遠いことです。しかし、あなたはまだコーディングが比較的新しいので、楽しみはおそらくかなり重要な基準であり、この初期段階であなたにとって無形かもしれない他の要因の指標でもあります（楽しみはあなたがもっと学ぶことを示唆するなど）。
• あなたの経験とおそらくしつこい良心の感覚は、書き直しを検討する価値があるとあなたに言っているようです。もしあれば、その声を聞いてください。アドバイスに従わなくても、少なくとも聞いてください。将来的には外部からの声が増え、自分の良識を聞く練習が必要になります。
• 書き直しをすると、コードをよりモジュール化する可​​能性が高くなります。モジュールを作成すると、他のプロジェクトで活用できる、再利用可能で信頼性の高いコンポーネントが得られます。最終的に、メインプロジェクトの単なるモジュールのように見えたものが、あなたが書いたコードの中で最も興味深く価値のあるものであることが判明するかもしれません。

何かを仕上げることは良い考えですが、真空中ではありません。書き換えを開始する場合、特定のサブモジュールを終了することで何かを終了することを選択できます。上記の実験の後、それを最初の目標として設定できます。終了は、最初のメインプロジェクトをまだ終了することを意味する必要はありません。必要に応じて、元のプロジェクトのスコープ全体の書き換えが完了するまで、モジュールを完了した後、別のモジュールを完了します。