プロジェクトはほぼ完了しましたが、手続き型のスパゲッティコードです。書き直しますか、それとも出荷しようとしますか？[閉まっている]

私は初心者のWeb開発者です（1年の経験）。

卒業してから数週間後、私は所有者があまり技術者ではない会社のためにWebアプリケーションを構築する仕事を提供されました。彼は、アイデアの盗難、サービス会社が請求する高い開発コストを避け、長期的にプロジェクトを維持するために若い人をオンボードで信頼できるようにするために私を雇いました）。

当時の私は生意気で、コンピューターサイエンスの学位を取得していたので、私は何でも構築できると考えて申し出を受け入れました。

私はショットを呼んでいました。いくつかの調査の後、私はPHPに落ち着き、オブジェクトなしの単純なPHPから始めました。2か月後、すべてが面倒になり、進歩するのは困難でした。Webアプリケーションは巨大です。そこで、私の生活を楽にするMVCフレームワークをチェックアウトすることにしました。そこで私は、PHPコミュニティのクールな子供、Laravelに出会いました。私はそれを愛し、学びやすく、すぐにコーディングを始めました。私のコードはよりきれいで、より組織的に見えました。とてもよかったです。

しかし、やはりWebアプリケーションは巨大でした。会社は最初のバージョンを提供するように私にプレッシャーをかけていました。

Laravelは一緒に仕事をするのが面白かったので、そもそもこの業界を選んだ理由を思い出しました。

だから私は夜に小さなプロジェクトに取り組み始め、方法論とベストプラクティスについて読みました。私はOOPに戻り、オブジェクト指向の設計と分析に移り、ボブおじさんの本Clean Codeを読みました。

これは私が本当に何も知らなかったことに気づきました。ソフトウェアを正しく構築する方法を知りませんでした。しかし、この時点では手遅れであり、今ではほぼ完了です。私のコードはまったくクリーンではなく、スパゲッティコード、バグを修正するための本当に苦痛、すべてのロジックはコントローラーにあり、オブジェクト指向のデザインはほとんどありません。

私は、プロジェクト全体を書き直さなければならないと固執している。しかし、私はそれを行うことはできません...彼らはそれがいつ完了するのかを尋ね続けます。

このコードがサーバーに展開されることは想像できません。さらに、コードの効率性とWebアプリケーションのパフォーマンスについてはまだ何も知りません。

一方では、会社は製品を待っていて、もう待つことができません。一方、実際のコードでこれ以上進むことはできません。仕上げて、まとめて展開することはできましたが、神は、人々がそれを使い始めたときに何が起こるかを知っています。

書き直しますか、それとも出荷しようとしますか、それとも見逃した別のオプションがありますか？

あなたはほとんどのCS教育のアキレス腱につまずきました：彼らはあなたにツールとテクニックを教えますが、貿易は教えません。ソフトウェアの構築は技術であり、長年の実践とソフトウェアの使用経験を通じてのみ習得します（ユーザーは教師よりも厳しい批評家です）。ソフトウェアを構築することもビジネスであることが非常に多く、ビジネス上の目標が技術的な野望を上書きする場合があります。

まず、船。あなたがビジネスオーナーにソフトウェアを見せて、彼らがそれが出荷する準備ができていると感じたら、出荷してください。その時点ではないが、近い場合は終了します。重要な唯一のソフトウェアは、実際に使用されるソフトウェアです。お金を稼ぐ唯一のソフトウェア事業は、製品を持っているものです。

第二に、あなたは多くの貴重なことを学んだので、それがあなたに教えてくれた経験に感謝すべきです：

1. 計画やアーキテクチャのないスリングコードは災害のレシピです
2. プログラミングにはコードを書くこと以上のものがあります
3. 非技術的なビジネスオーナーは、多くの場合、技術的な意思決定の影響（雇用者など）を理解していないため、開発者に説明するのは開発者次第です。
4. ほとんどの問題は、既存のフレームワークで解決するよりもはるかによく解決されています。存在するフレームワークとそれらをいつ使用するかを知ることは有益です。
5. 指導がほとんどない大きなプロジェクトに割り当てられた学校を出たばかりの人は、スパゲッティコードを大量に生成する傾向があります。これは正常です。

続行方法についてのアドバイスを次に示します。

1. 通信、通信、通信します。自信がなく、複数の道筋を見ていたとしても、プロジェクトの状態と進行方法についてのあなたのアイデアについて非常に率直で率直でなければなりません。これにより、事業主は何をすべきかを選択できます。あなたが自分自身に知識を保持している場合、あなたは選択肢を奪います。
2. 完全な書き換えの誘惑に抵抗してください。あなたが書き直している間、ビジネスには製品がありません。また、書き換えがあなたが想像したほど良い結果になることはめったにありません。代わりに、アーキテクチャを選択し、徐々にコードベースを移行してください。恐ろしいコードベースでさえ、この方法で回収できます。リファクタリングに関する本を読んでください。
3. 自動テスト/ 単体テストについて学びます。コードに対する信頼を構築する必要があります。そのための方法は、コードを自動テストでカバーすることです。これはリファクタリングと密接に関連しています。テストがない場合は、手動で包括的にテストします（ユーザーがテストを行うため、コードを壊してみてください）。発見したすべてのバグをログに記録して、優先順位を付けて修正できるようにします（すべてのバグを修正する時間はありません。現実にはバグのないソフトウェアは出荷されません）。
4. Webアプリケーションをデプロイして実行し続ける方法について学びます。本「Webオペレーション：データを時間通りに保つ」は、良いスタートです。

これは、修正するために私に投げられた他のすべてのシステムのように聞こえます。

リラックス、これは多くの人に起こります。経験がなく、助けも支援も指導も受けていない奥深くに投げ込まれたジュニアは、成功の秘exactlyではありません。ジュニアプログラマーを雇って期待して、うまく機能し、パフォーマンスがよく、保守可能なブランドの新しいシステムをゼロから構築することは、現実的ではありません。地獄は、それが上級プログラマーで起こるなら幸運です。

私の意見では、きれいにする必要があります。これは面白くないでしょう。最善を尽くしたと伝えてください（ほとんどの場合）。しかし、うまく機能しない可能性があり、多くのバグがあることを心配しています（常にバグがあります）。上級プログラマーによるレビューが必要であり、彼らは目立ったパフォーマンス/セキュリティの問題を非常に迅速に修正できるはずです。または、彼らはそれを展開し、指を交差させることができます。それは大丈夫になるか、煙の中で上がるでしょう。問題が発生したときに修正できるかもしれません。あなたが大規模なユーザーベースを持っている場合はそうではないでしょう。

または、この状況でほとんどの人がすることをすることができます：お金を取り、姿を消して、彼らにそれを整理させる。倫理的な選択が何であるかを判断するのはあなた次第です。

編集（この質問には多数の票があるため、さらにコンテンツを追加することもできます）

プログラマーであることの喜びの1つは、技術に詳しくない人々（おそらく、マネージャー、間違いなく残りのビジネス）があなたが何をするのかわからないことです。これは良い面と悪い面の両方です。悪い点の1つは、ソフトウェア開発プロジェクトがどのように機能するかを常に説明する必要があることです。計画、要件、コードレビュー、テスト、展開、およびバグ修正。テストの重要性を説明し、テストする時間を確保するのはあなたの仕事です。ここに自分の立場を立てなければなりません。人々はその重要性を理解しません（「私たちはただそれを使い始められないのですか？」）しかし、テストを開始すると（ライブ環境ではありません！）、すぐに利点を理解します。彼らがあなたを雇った理由の一つは、彼らがソフトウェア開発について何も知らないからです。だから彼らを教育するのはあなた次第です。ここでテストとバグ修正の重要性を強調する必要があります-彼らはプログラマーではなく、ゼロ除算と壊れたhtmlタグの違いを知らないことを忘れないでください。

多くの場合、発生する問題の多くは実際にはバグではありません。それらは、ユーザビリティの問題、見逃された要件、変更された要件、ユーザーの期待（モバイルでこれを使用できない理由）、そして実際の実際の実際のバグです。ライブを開始する前にこれらを解決する必要があります。多くのバグは、数日後に回避または修正できることがよくあります。人々が完璧なシステムを期待するなら、彼らは多くの苦痛を味わうでしょう。彼らがバグを期待しているなら、あなたの人生は今後数週間で大きく楽になるでしょう。

ああ、ユーザーテストと単体テストまたはシステムテストを混同しないでください。

• ユニットテスト-私のコード関数は正しい値を返しますか
• システムテスト-Xをクリックするとエラーがスローされますか
• ユーザー受け入れテスト（UAT）-プログラムは要件に適合していますか？彼らはあなたにそれをさせるように頼んだことをしますか？ライブ配信できますか？

彼らがあなたに何をするよう要求したかを書き留めていなければ、UATははるかに難しくなります。これは多くの人々が倒れるところです。彼らがシステムに望んでいたことを紙に書き留めておけば、あなたの人生はずっと楽になります。彼らは「なぜXをしないのですか？」と言うでしょう。「Yにするように言われた」と言うことができます。プログラムが間違っている場合は、修正してください。要件が間違っている場合は、ドキュメントを修正し、1〜2日余分に要求し（いいえ、それを主張します）、変更を加え、ドキュメントを更新して、再テストします。

このプロセスを数回行ったら、アジャイルを調べることができます。しかし、それは別の世界です:)

TL; DR テストは良い

最初から始めるときはいつでも、ほぼ確実にSecond System Syndrommeが原因で同じ量以上の間違いを犯します。新しいミスは異なりますが、デバッグに必要な時間はほぼ同じであるため、それがどのようにうまく適合しないかについて絶望します。また、最初のバージョンが展開された場合、本番環境への展開または新機能の展開が遅れます。これは会社にとって深刻な問題です。ジョエル・スポルスキーは、「単一の最悪の戦略的ミス」と呼んでいます。これは、あらゆる企業や開発者が犯すことができます。

代わりに、推奨されるアプローチは、メンテナンス中に最初の混乱を少しずつきれいにすることです。そして、そのためだけにリファクタリングしようとさえしないでください。その上、管理者は通常、それをお金の無駄だと見なし（これはよくあることです）、新しいバグを導入する不必要なリスクをもたらします。いったんコードを苦労してデバッグすると、見栄えはよくないかもしれませんが、動作します。そのため、他の理由（バグの修正、新機能、またはマーケティングによって要求された変更など）に触れる必要があるまでお待ちください。次に、調整が最も難しい部品をきれいにします。これはよくボーイスカウトルールと呼ばれます。

そして、その時点で、マネージャーと議論する必要はありません。リクエストの見積もりに必要最小限のリファクタリングを含めるだけです。会社が実際に修正されているために少し譲歩する余裕がある場合、および将来問題を作成したくないだけで、すぐにハッキングする可能性を認めない場合、経験を通じて学習します。

最後に、もう1つお勧めの読書：泥の大玉。

最初に読んだ場所を忘れてしまいましたが、他の人が言ったことをやや力強くエコーしたかっただけです。

配送は機能です。

完璧に機能し、新しいバグなどを導入する既存の（おそらく、ハッキング、い、汚い）コードを「クリーンアップ」し続ける人ほど悪いことはありません。あなたはそれをやった。船。完全にうまく機能するプロジェクトの再設計で迷子にならないでください。たとえそれが内部でunderい場合でもです。修正したら、段階的に修正し、リグレッションができるだけ少なくなるように、自分自身を良いテストスイートにします。

どのプロジェクトでも、以前よりも賢くなります。すべてのプロジェクトの後、最初からそれを手に入れたときに非常に便利だった経験が蓄積されます。私はすべてを再訪せず、あなたが学んだことを適用することは難しいことを知っています。でも覚えておいて：

完璧は善の敵です。

クライアントにとって、リリースされることのない完璧なソフトウェアよりも、今すぐ良いソフトウェアを手に入れる方が常に良いのです。

これは最初のプロジェクトでした。将来、さらに多くのプロジェクトがあり、最初から学んだことをすべて適用できます。

私は[...]おじさんのボブのきれいなコードを読みます。

私は、プロジェクト全体を書き直さなければならないと固執している。

この本には、「The Grand Redesign in the Sky」という非常に適切なセクションがあります。

万が一それを作成する時間がある場合には、とにかく同じ問題に直面するため、すべてを書き直そうとしないでください。再設計が終了すると、新しいことを学び、その最初の部分が非常に専門的ではないことを認識するため、再度書き直す必要があります。

再設計と書き換えは優れていますが、動作中のシステムで段階的に行われる場合に限ります。別のユーザーが指摘したように、ボーイスカウトルールに従い、作業中にコードを少しずつリファクタリングします。

あなたは元気です。

あなたのコードは動作し、出荷する準備がほぼ整っていると言いますか？そして、あなたはあなたのコードが大幅に改善されるかもしれないと感じます。良い。

あなたのジレンマは、私が最初にフリーランスで経験したことを思い出させます（多言語POSシステムを作成するために、2年生のときに採用されました）。コードに満足せず、拡張性を望み、より良いホイールを再発明したかったので、私は無限の質問をしました... 一度デプロイすると、まだ多くの校正、テスト、パッチ適用などが必要です...

プロのコードベースを使用した経験はありますか？多くのコードベースは、風変わりでコードを維持するのが困難です。自分で大きなプログラムを作成しようとしてソフトウェアの複雑さを発見する代わりに、他の人が書いた同様に厄介なコードを保守/拡張することもできます。

完全な書き直しが非常に効果的であることがわかった唯一のケースは、チームが新しいツールチェーン/フレームワークを同時に採用した場合です。

基礎となるロジック（プログラムの機能、関数、クラスなどのレイアウトではなく...）が健全な場合、それは同じように機能します。したがって、スパゲッティコードだと思っても意味がありません展開すべきではありません。

顧客に使用できるものを提供する必要があります。次に、改善/機能の追加を求められたら、リファクタリングが必要かどうかを決定し、「新しい機能を統合するには技術的な作業が必要だ」と顧客に知らせてもかまいません。それにより、彼らはより多くのお金がかかることを理解し、より長く待たなければなりません。そして、彼らは理解します（またはあなたは引き出すことができます）。

すべてを書き換えるのに良いタイミングは、別の顧客が似たようなものを作成するように依頼するときです。

要するに、すべてが展開された場合にすべての人の顔に衝撃を与えることを実証できない限り、展開の遅延は専門的ではなく、あなたにもあなたの顧客にも利益をもたらさないでしょう。バグを修正したり、新しい機能を追加したりしながら小さなリファクタリングを行うことを学ぶことは、あなたにとって貴重な経験になります。

あなたの質問に答えて私が言うことのほとんどは、他の人によって言われました。Joel Spolskyによる「あなたがしてはいけないこと、パートI」を読んでください（「建築宇宙飛行士」に関する彼の他の投稿もいくつか読んでください）。「完璧は善の敵」であることを忘れないでください。漸進的にリファクタリングすることを学びます。配送が重要など

私が追加するのはこれです：あなたは、小さなスタートアップ予算/時間枠で働いている単一の新卒者によって実行可能とみなされた何かを課されました。優れた構造化された手続き型プログラミングよりも高度なものは必要ありません。（そして、参考までに、「手続き型プログラミング」は悪い言葉ではありません。ほとんどの場合、それはある程度のレベルで必要であり、多くのプロジェクト全体に完全に適しています。）

構造化された手続き型プログラミングを実際に行うようにしてください。コードの繰り返しは、必ずしも大規模で多形的な構造が必要であることを示すものではありません。これは、繰り返しコードを取得してサブルーチンに入れる必要があることを示す単なるサインです。「スパゲッティ」制御フローは、単にグローバルを排除する機会かもしれません。

ポリモーフィズム、実装の継承などを正当に要求するプロジェクトの側面がある場合、プロジェクトのサイズが過小評価されている可能性があります。

あなたが持っているジレンマに本当に興味があるなら、「Lean Startup」も読むべきです。あなたがここで与えられている多くのアドバイスは、あなたがその本を読んだ場合、あなたにもっと共鳴します。基本的に、リソース消費率は最悪の敵であり、エンドユーザー/顧客からのフィードバックほど価値のあるものはありません。したがって、製品を実行可能な状態（Minimum Viable Product-またはMVP）にし、ドアから出荷します（実際のコードの外観に関係なく）。顧客にあなたの将来の変更セットとバージョンを指示させてください。そのアプローチに集中すれば、長期的にはあなたと上司の両方が幸せになります。

他の人が徹底的に説明した理由のために、プロジェクトを終了して出荷する時が来ました。

アプリのテストも「仕上げ」の一部であることを強調したいと思います。重要な機能が十分に実行されておらず、正しい結果が確認されていない場合は、このアプリの展開時に人々がこのアプリで問題を抱えることを懸念して正当化されます。

単体テストと自動化された高レベルのテストは優れており、このアプリケーションをリファクタリング（またはリライト）しようとする前に、できる限り用意する必要があります。ただし、すべてのテストを「手作業」で実行し、「目で」正しい機能を確認する必要がある場合でも、現在は主にテストする必要があります。これらのテストを後で自動化する方法を理解できれば、製品の次のバージョンで作業を開始するときに役立ちます。

一部の人々は、アルファテストユーザーとして新しいソフトウェアプロジェクトの前に座って、問題を起こすコツを持っています。つまり、彼らは物を壊すのが得意です。そのような才能のある人があなたと一緒に働いているのに十分幸運であれば、彼らに最初にアプリを試してもらい、明らかなバグを早期に修正する機会を与えてください。このタスクを自分で行う必要がある場合、次のようにします。

• 整然としてください。
• すべての機能を試してください。
• あなたがあなたのアプリケーションに不慣れなユーザーのふりをしてください。愚かな間違いを犯して、ソフトウェアがそれらをどのように扱うかを見てください。
• あなたがやっていることを書き留めて、あなたがあなたが問題を解決したと思った後にあなたがそれをもう一度試すことができるように。

あなたの質問は、「間違って始めたので、最初からやり直すべきか」と言いますが、追加のテキストは実際には「プロジェクトを終了しましたが、間違ってやりました、最初からやり直すべきか」と言います。質問の見出しだけの場合：行ったプログラミング作業の量が必要な作業全体に比べて少ない場合は、最初からやり直すのが理にかなっています。問題は複雑で理解が不十分な場合に多く発生し、問題が実際に何であるかを把握するのにかなりの時間がかかります。悪いスタートを続けても意味がありません。それを捨てて最初からやり直した場合、今回は問題をよく理解しているので、実際に早く終了することを意味します。

これは私が個人的にすることです：

1. 終了し、言い訳をして、あきらめます（給料の一部を返して、見苦しくないようにすることもできます）
2. コードを可能な限りきれいにする
3. 良いデザイン、良いアイデアなど、作品のすべての良い部分に関するドキュメントを作成します。

なぜこれらすべてを提案するのですか？

未来について考えてください。将来、特定の人々がこのコードを入手する時間があります。彼らはあなたとあなたの能力についてあらゆる種類の仮定と判断を下します。彼らはあなたがそれを書いたときに気にしません、彼らは状況を気にしません。彼らは、確認したいものを確認するために、見たいものをその中に見たいだけです。

あなたは悪い名前、ブランドがあなたに悪影響を与えるために思いつく可能性のあるものとしてブランド化されます。そして、将来のあなたは技術的な能力、スキル、知識、スタイル、そして状況がまったく違うかもしれませんが、このコードはあらゆる方法であなたに対して使用されます。それは彼らがあなたとあなたのコードとデザインに関するすべての悪いことを言うことができる裁判所のようなものであり、あなたはあなた自身を説明して守ることができるので、あなたもそれを認識していません。（そして、あなたはそれらが繰り返し深く深く間違っていることを非常に頻繁に学ぶかもしれません）それでそれをしないでください。あきらめる。

私を信じてください、あなたがどんな瞬間でもどんな目的のためにでも何かをしたので、あなたについて多くの仮定をした人々がいます。彼らに、あなたが状況Aでこのようにしたならば、あなたは状況Bでそれをするでしょう。彼らは非常に単純だと思います。

さらに2つの提案があります。これらのうち少なくとも1つはまだ行っていないことでしょう。

1）バグトラッカーを設置し、上司に使用を教える。これは、あなたがどのように失敗したかについての会話の一部である可能性があり、より良く学習し、計画的な方法でそれを修正しようとしている

2）バージョン管理の使用を開始しますが、既にそうしていることを願っています。

小規模なアカウントで上記の両方を無料で提供するホストシステムが山ほどあります。FogBugzが特に好きです。FogBugzには、優れた見積もりとタスク完了システムがあり、上司が管理の行き届いた方法で物事に取り組んでいることをさらに確実にします。

編集する

うわー、誰かが本当にこれを好きではなかった-ダウン投票と削除フラグ？どうして？

私は、多くのコンサルティング作業や他の人のコードの継承を含め、30年以上ソフトウェアを開発してきました。私が目にした膨大な数の問題システムは、人々がピットを掘り、そこにどのように到達したかについての詳細なメモもバージョン管理もしていなかった場所でした。

あなたの質問に答えるために：他の多くの人が言ったように、いいえ。出荷し、バグを修正するプロセスで少しずつクリーンアップします。

さらに、books / StackExchange / webforumsは優れた学習リソースですが、他のプログラマーと仕事をすること（または単に仕事について議論すること）で得られる学習に匹敵するものはないことに気付くでしょう。使用している、または学習したい技術の地元のグループを見つけて参加することは、あなたの時間の素晴らしい投資です。取得する技術的な知識に加えて、将来のギグを楽しみにして非常に貴重なネットワークへの簡単な方法です。

上司はあなたを雇ったときにあなたの経験レベルを知っていました。あなたの懸念を表明し、あなたがそれについて緊張していることを彼に知らせてください。また、あなたがどれだけ学んだか、次のプロジェクトをどれだけ上手くできるかを彼に知らせてください。

あなたは最初のWeb開発者であり、アドバイスをする良い開発者がいないため、上司はこれを十分に知っていると雇いました。誰もがあなたに期待しているのと同じくらいうまくやっていると思います。実際、あなたは仕事がより良くなる可能性があるという洞察を持っているという事実、そしてあなたが実際にあなたがそれをより良くすることを可能にするであろうことを学んだという事実は、あなたがほとんどより良くやっていることを意味します。あなた自身の正気のために、仕事を始めたあなたのバージョンがそれをより良くすることができなかったことを思い出してください。より経験豊富な（したがって、より良い給料を支払った）誰か、または1つのプロジェクトに相当する経験がある人であれば、それをもっとうまくやることができただろう。

何をするか今：あなたは一年前より良い開発者であることを幸せになります。次のプロジェクトの方がうまくいきます（そして最後には、より多くの経験を積むことになり、自分がやったことに不満を感じるでしょう。それは正常です）。最後のプロジェクトを変更または書き直しても、ビジネスはコストに対してほとんど利益をもたらしません。あなたができることは、とにかく変更を加える必要があるときに、悪いコードを良いコードに置き換えることです。保守性の悪いコードを修正するのは、適切なコードに置き換えるよりも困難な場合があるためです。また、経験の浅い新しい開発者を助けてもらう場合は、このコードはコピーすべき例ではないことを伝えてください。