アプリの完成にリファクタリングまたは集中

進行中にアプリをリファクタリングしますか、それとも最初にアプリを完成させることに集中しますか？リファクタリングは、アプリappの進行が遅くなることを意味します。

アプリを完了すると、後でアプリのメンテナンスが非常に難しくなる可能性がありますか？

このアプリは個人的なプロジェクトです。「機能と設計を推進するもの」にどのように答えればよいのか本当に分かりませんが、現在のソフトウェアの非効率性を解決することだと思います。私も最小限の使いやすいソフトウェアが好きです。そのため、いくつかの機能を削除し、役立つと思う機能を追加しています。

動作させる。その後、高速にします。最後に、美しくします。

インターフェイスを使用してコード（プレゼンテーション、ビジネス、およびデータレイヤー）を適切に分離し、それがモノリシックなデザインでない場合、リファクタリングはそれほど難しくないはずです。

リファクタリングがそれほど難しい場合は、おそらくコード臭です-Solid Principlesをご覧になることをお勧めします

重要なポイントはインターフェースをきれいに保つことだと思う。それらの間の通信層が健全である限り、いつでもモジュール/クラス/実装をリファクタリングまたは書き換えることができます。後で簡単に変更できるものとそうでないものを把握するために、少し時間をかけてください。後者を正しくします。

これはTDDの精神と一致しています。適切なテストを作成するには、テストするための適切なインターフェイスが必要です。現時点では舞台裏がどれほど厄介であるかは重要ではありません。後で改善できるからです。

特にTDDを使用して、私は常にリファクタリングを行っています。

1. テストを書く

2. テストに合格する

3. リファクタリング

これにより、完成品のバグが少なくなり、コードが改善されます。また、完了時に維持するコードが少なくなります。

早期かつ頻繁にリファクタリング！それをしないで「保存」する時間は、次の機能をハックして、過度に複雑または混chaとしたコードのバグを検索するために何度も費やされます。

リファクタリングは部屋を拾うようなものです。

物事を整頓すると、コードに対して行っている生産的な作業の量に比例した線形のオーバーヘッド、アルゴリズム学者の用語ではO（n）があります。リファクタリングに10％の時間を費やす（または部屋を整頓する）と仮定すると、その10％は与えられたものであり、時間が経っても一定のままです。

ただし、汚れた服を隅に投げてやり続けると、混乱が複雑になるにつれて、部屋を拾うのに費やす時間は長くなります。汚れた洗濯物の個々の部分が必要なクリーンアップ時間に指数関数的に寄与すると仮定すると、あなたは今、O（e ⁿ）状況にいます。

アルゴリズムの複雑さの概念を掘り下げた経験のある人なら誰でも、損益分岐点がどこかにある、つまり蓄積するのに最適な量の汚れた洗濯物があることに気付くでしょう。それがいくらであるかは、big-O表記で破棄される定数因子に依存します。もう1つの要因は、時間の経過に伴う作業の価値です。作業が今はかなりの価値があるが、来週は安い場合（つまり、この金曜日にこのプロジェクトとさらに3つの期限がありますが、その後はほとんどアイドル状態になります） ）、方程式はリファクタリングしない方が良いかもしれません。

そして、複雑な臨界質量があります。ある時点で、混乱（「重大な混乱」）がひどくなり、部屋全体を燃やして新しい服を買う方が簡単に見えるようになります。現実には通常そうではありませんが、そのように見え、心理的な影響により物事に取り組むのが10倍難しくなります。

そして、明らかに、既に巨大な多重冗長の混乱であるプロジェクトに足を踏み入れた場合、選択肢は限られています。

TL; DR：疑わしい場合は、リファクタリングします。しないと決める前に、本当に良い証拠があるはずです。

機能を追加したり、バグを粉砕して、販売/顧客満足度を向上させる機会がある場合は、それを実行してください。新しい要求が少なくなると、リファクタリングとバランスを取ることができます。ある時点で、人々が望むコードを書いていることを確認する必要があります。すべてが平等であるので、私は1000よりも100時間のコードを捨てたいです。誰も望んでいないなら、あなたはそれをするでしょう。

本当にあなたがどこにいるかに依存します！

考慮すべきその他の事項：

あなたはどのくらい確かですか、あなたは本当に機能的なデザインを正しく持っていますか？ユーザーからのフィードバックを受け取った後、再度デザインし直してもらえますか？

書き換えるよりもリリースしたいです。機能設計を確定した後に最適化してください。

納期に間に合うと確信している限り、必要なすべてをリファクタリングできます。ただし、開発にこだわる方が不確実性が多少あり、わずかな増分ステップでのみリファクタリングできる場合もあります。

あなたがリファクタリングしたい悪いデザインが本当にあなたを傷つけるなら、あなたはそれに依存するより多くのコードを作成するよりも今それを修正した方が良いです。後のリファクタリングはより困難で高価になります。おそらくあなたはもうそれをすることができないでしょう。

一方、もしあなたの唯一の問題がさであるなら、物事を成し遂げることに勝るものはほとんどないので、最初にソフトウェアを完成させたいかもしれません。

リファクタリングは、アプリケーションの完成に取り組む際に非常に重要です。

+ VES

1. 明確なフロー：リファクタリングによりコードが明確になります。コードが構造化されていない場合、しばらくするとコードのフローが理解できなくなり、コードのリファクタリングが困難になり、バグが発生する可能性があるためです。

2. パフォーマンスの改善：アプリケーションの適切なリファクタリングは、間違いなくアプリケーションのパフォーマンスの改善に役立ちます。

3. 保守：最後になりましたが、少なくとも、長期的には保守が容易になります。

-VE

1. 時間の消費：進行のあらゆる段階でより多くの時間がかかります。そのため、完了が遅れる可能性があります。

ボトムライン

プロジェクトの種類に応じて、現在の状況に必要なコードの品質または完了を優先できます。

私の個人的な経験に基づいて、私は通常、最初に到達する期限があるという条件でアプリを完成させに行きます。完了したら、リファクタリングできます。

終了してリファクタリングします。しかし、急ぎや時間枠の期限がない場合は、リファクタリングすることをお勧めします。