プロジェクトはほぼ完了していますが、手続き型のスパゲッティコードです。書き直しますか、それとも出荷を続けますか？
私は初心者のWeb開発者です（1年の経験）。
卒業してから数週間後、私は所有者があまり技術者ではない会社のWebアプリケーションを構築する仕事を与えられました。彼は、彼のアイデアの盗難、サービス会社によって請求される開発の高コストを回避し、長期にわたってプロジェクトを維持するために信頼できる若い人を船上に迎えるように私を募集しました（私はこれらの結論に私が雇われてずっと後になりました）。
当時の生意気な私は、コンピューターサイエンスの学位を取得しており、私は何でも構築できると考えて申し出を受け入れました。
私はショットを呼んでいました。いくつかの調査の後、私はPHPに落ち着き、プレーンなPHPから始めました。オブジェクトはなく、醜い手続き型コードです。 2か月後、すべてが乱雑になり、進歩を遂げるのは困難でした。 Webアプリケーションは巨大です。そこで、私は自分の生活を楽にするMVCフレームワークをチェックアウトすることにしました。ここで、PHPコミュニティ：Laravelでクールな子供に出会いました。大好きで、簡単に習得でき、すぐにコーディングを開始しました。コードはよりすっきりとして整理されています。とてもよさそうだ。
しかし、やはりWebアプリケーションは巨大でした。会社は私が最初のバージョンを提供するように私に圧力をかけていました、彼らが明らかに、そして顧客を捜し始めたいと望んでいた最初のバージョンを提供しました。
Laravelで作業するのは楽しかったので、そもそもこの業界を選んだ理由を思い出しました。これは、下品な教育システムで立ち往生しているときに忘れていたものです。
それで、私は夜間に小さなプロジェクトに取り組み始め、方法論とベストプラクティスについて読みました。私はOOPを再考し、オブジェクト指向の設計と分析に移り、 ncle Bob's 本Clean Codeを読みました。
これは私が本当に何も知らないことを理解するのに役立ちました。私はソフトウェアを正しい方法で構築する方法を知りませんでした。しかし、この時点では手遅れで、今ではほぼ完了です。私のコードはまったくクリーンではありません。スパゲッティコードだけで、バグを修正するのは本当に面倒です。すべてのロジックはコントローラーにあり、オブジェクト指向の設計はほとんどありません。
私はプロジェクト全体を書き直さなければならないというこのしつこい考えを持っています。しかし、私はそれを行うことはできません...彼らはそれがすべていつ完了するのかを尋ね続けます。
このコードがサーバーにデプロイされているとは思えません。さらに、コードの効率性とWebアプリケーションのパフォーマンスについてはまだ何も知りません。
一方では、会社は製品を待っており、もう待つことができません。一方で、実際のコードでこれ以上進むことはできません。私は仕上げ、それをまとめて展開することができましたが、神は人々がそれを使い始めたときに何が起こるかを知っています。
書き直しますか、それとも出荷を続けますか、それとも見逃した別のオプションはありますか？
あなたはほとんどのCS教育のアキレス腱に遭遇しました。彼らはツールやテクニックを教えますが、貿易については教えません。ソフトウェアの構築は技術であり、長年の実践とソフトウェアの使用経験を通じてのみ得られるものです（ユーザーは教師よりも厳しい批評家です）。ソフトウェアを構築することもまた、ビジネスであることが多く、ビジネス目標が技術的な野望を無効にする場合があります。
まず最初に、発送します。ビジネスオーナーにソフトウェアを見せて、発送の準備が整っていると感じたら、発送します。その時点までではなく、閉じている場合は、終了します。重要な唯一のソフトウェアは、実際に使用されるものです。お金を稼ぐ唯一のソフトウェアビジネスは、製品を持っているものです。
第二に、あなたは多くの貴重なことを学んだので、それがあなたに教えたことの経験に感謝するべきです：
- 計画やアーキテクチャなしでコードを投げつけることは災害のレシピです
- プログラミングには、コードを書くだけではありません。
- 非技術的なビジネスオーナーは、技術的な決定（採用する人など）の影響を理解していないことがよくあります。開発者が説明するのは開発者次第です。
- ほとんどの問題は、既存のフレームワークで解決するよりもはるかによく解決されています。存在するフレームワークとそれらをいつ使用するかを知ることは価値があります。
- 指導がほとんどなく、大きなプロジェクトに割り当てられたばかりの新しい人は、スパゲッティコードのボウルを作成する傾向があります。これは正常です。
続行する方法について、いくつかのアドバイスを次に示します。
- コミュニケーション、コミュニケーション、コミュニケーション。確信が持てず、複数のパスが見られる場合でも、プロジェクトの状態と、進行方法に関するアイデアについて、非常に率直で率直でなければなりません。これにより、ビジネスオーナーは何をするかを選択できます。知識を独り占めすると、彼らは選択肢を奪います。
- 完全な書き換えの誘惑に抵抗します。あなたが書き直している間、ビジネスには製品がありません。また、書き直しが思ったほどうまくいくことはめったにありません。代わりに、アーキテクチャを選択して、コードベースを徐々にそれに移行してください。恐ろしいコードベースでさえ、この方法で回収することができます。一緒に役立つリファクタリングに関する本を読んでください。
- 自動テストについて学ぶ/ 単体テスト 。コードに対する信頼を築く必要があります。そのための方法は、コードを自動テストでカバーすることです。これはリファクタリングと密接に関連しています。テストがない限り、手動で包括的にテストします（ユーザーが行うため、コードを壊してみてください）。見つけたすべてのバグをログに記録して、優先順位を付けて修正できるようにします（すべてのバグを修正する時間がないため、実際にはバグのないソフトウェアは出荷されません）。
- Webアプリケーションをデプロイして実行し続ける方法について学びます。本 Web Operations：Keeping the Data On Time は良いスタートです。
これは、修正のために私に投げかけられた他のすべてのシステムのように聞こえます。
リラックスしてください、これは多くの人に起こります。経験がなく、手助けもサポートもガイダンスもないディープエンドで投入されたジュニアは、成功の秘訣ではありません。ジュニアプログラマーを雇って、うまく機能し、パフォーマンスがよく、保守可能なまったく新しいシステムをゼロから構築することを期待することは、現実的ではありません。それがすべて上級プログラマーで起こったら、あなたは幸運です。
私の意見では、あなたはきれいに来なければなりません。これは楽しくありません。最善を尽くしたことを伝え、それは（ほとんど）機能しますが、うまく機能しない可能性があり、多くのバグがある（alwaysバグがある）と心配しています。上級プログラマーによるレビューが必要であり、目立ったパフォーマンス/セキュリティ問題をかなり迅速に修正できるはずです。または、展開して指を交差させることもできます。それは大丈夫か、煙の中で上がるでしょう。問題が発生したときに、問題を修正できるかもしれません。あなたが大規模なユーザーベースを持っている場合はそうでないかもしれません。
または、あなたはこの状況でほとんどの人がすることをすることができます：お金を取って、消えて、彼らにそれを整理させてください。私は倫理的な選択が何であるかを解明するためにあなたに任せます。
編集（この質問には多くの票があるため、さらにコンテンツを追加することもできます）
プログラマーであることの喜びの一部は、技術者ではない人々（おそらくあなたの上司、間違いなく残りのビジネス）があなたが何をするかわからないということです。これは良い面と悪い面の両方です。悪い点の1つは、ソフトウェア開発プロジェクトの仕組みを常に説明しなければならないことです。計画、要件、コードレビュー、テスト、展開、バグ修正。テストの重要性を説明し、テストする時間を確保するのはあなたの仕事です。あなた持っているここにあなたの立場を立てる。人々は重要性を理解しませんが（ "それを使い始めることはできませんか？"）彼らはテストを開始すると（ライブ環境ではありません！） ）彼らはすぐにメリットを理解します。彼らがあなたを雇った理由の1つは、彼らがソフトウェア開発について何も知らないからです、それで彼らを教育するのはあなた次第です。ここでテストとバグ修正の重要性を強調する必要があります。覚えておいてください、彼らはプログラマーではなく、ゼロ除算と壊れたhtmlタグの違いを知りません。
多くの場合、発生する問題の多くは実際にはバグではありません。それらは、ユーザビリティの問題、見落とされた要件、変更された要件、ユーザーの期待（モバイルでこれを使用できない理由）、そして実際の実際の実際のバグです。稼働する前にこれらを解決する必要があります-多くの場合、多くのバグは数日後に回避または修正できます。人々が完璧なシステムを期待するなら、彼らは多くの苦痛を味わうことになるでしょう。彼らがバグを期待しているなら、あなたの人生は次の数週間で非常に楽になるでしょう。
ああ、ユーザーテストをユニットテストやシステムテストと混同しないでください。
- ユニットテスト-私のコード関数は正しい値を返しますか
- システムテスト-Xをクリックするとエラーが発生しますか
- ユーザー受け入れテスト（UAT）-プログラムは要件に準拠していますか？それは彼らがそれをするようにあなたに頼んだことをしますか？ライブにできますか？
あなたが彼らに何をするように要求したかの要件を書き留めていないなら、[〜＃〜] uat [〜＃〜]ははるかに難しくなります。これは多くの人々が倒れるところです。システムが紙に書いてほしいことを彼らに伝えれば、あなたの人生はずっと楽になります。彼らは「なぜXをしないのか」と言うでしょう。そして、「あなたはそれをYにするように私に言った」と言うことができます。プログラムが間違っている場合は修正します。要件が間違っている場合は、ドキュメントを修正し、1〜2日余分に要求して（いいえ、それを主張します）、変更を加え、ドキュメントを更新して再テストします。
このプロセスを数回実行すると、アジャイルの調査を開始できますが、それは別の世界です:)
TL; DRテストは良好です
Second System Syndromme を使用すると、ゼロから始めると、ほぼ間違いなく同じ量以上の間違いを犯します。あなたの新しい間違いは異なりますが、デバッグに必要な時間は同じであるため、どのように適切でないかについて絶望します。また、最初のバージョンが導入された場合、本番環境への導入または新機能の導入が遅れます。これは、会社にとって深刻な問題となります。 Joel Spolskyはそれを "単一の最悪の戦略的誤り" と呼んでいます。
代わりに、メンテナンス中に最初の混乱を少しずつ取り除くことをお勧めします。そして、それだけのためにそれをリファクタリングしようとさえしないでください。さらに、管理者は通常、それをお金の浪費（多くの場合それである）と見なし、新しいバグを導入する不要なリスクをもたらします。ひどくコードをデバッグしたら、それはきれいではないかもしれませんが、動作します。したがって、他の理由（バグ修正、新機能、またはマーケティングによって要求された変更など）でそれに触れる必要があるまで、それを維持してください。次に、調整が最も難しい部分をクリーンアップします。これはしばしば ボーイスカウトルール と呼ばれます。
その時点で、マネージャーと議論する必要はありません。リクエストの見積もりに必要な最小限のリファクタリングを含めるだけです。会社が実際に修正されているために少し余裕をもてる可能性があり、将来問題を発生させたくない場合や、迅速にハッキングする可能性を認めない場合は、経験を通じて学習します。
最後に、もう1つお勧めの読み物 泥の大きなボール 。
どこで最初に読んだか忘れてしまいましたが、他の人が言ったことを、もう少し力強くエコーしたかっただけです。
配送は機能です。
完全にうまく機能する、既存のコード（おそらくハック、醜い、汚い）を "クリーンアップ"し続ける1人の男よりも悪いことはありません。新しいバグなどを導入します。 あなたの仕事を成し遂げる。あなたはそれを成し遂げた。 Ship。たとえ内部が醜くても、完璧に機能するプロジェクトの再設計で迷子にならないでください。修正する場合は、段階的に修正し、退行ができるだけ少なくなるように自分自身を適切なテストスイートにします。
すべてのプロジェクトは、以前よりも賢くなります。すべてのプロジェクトの後に、最初からそれを持っているときに非常に便利だったはずの経験が蓄積されます。私はすべてを再訪せず、あなたが学んだことを適用するのは難しいことを知っています。でも覚えておいて：
完璧は善の敵です。
クライアントにとっては、リリースされることのない完璧なソフトウェアよりも、今すぐ良いソフトウェアを手に入れる方が常に良いでしょう。
これはちょうどあなたの最初のプロジェクトでした。将来的には、最初から学んだことすべてを適用できるプロジェクトがさらに増えるでしょう。
私はおじさんのボブクリーンなコードを読みました。
私はプロジェクト全体を書き直さなければならないというこのしつこい考えを持っています。
この本には、「Grand Redesign in the Sky」という非常に適切なセクションがあります。
すべてを書き直そうとしないでください。万が一、それを作成する時間がある場合でも、とにかく同じ問題に直面することになります。再設計を完了すると、新しいことを学び、その最初の部分は専門家ではないことに気付くので、もう一度書き直す必要があります。
再設計と書き換えは優れていますが、稼働中のシステムで段階的に行われる場合に限られます。別のユーザーが指摘したように、ボーイスカウトルールに従い、作業に応じてコードを少しずつリファクタリングします。
あなたは元気です.
あなたのコードは動作し、出荷する準備がほぼ整っていると言いますか？そして、あなたはあなたのコードが大幅に改善されるかもしれないと感じています。良い。
あなたのジレンマは、私の最初のフリーランスの経験を思い出させます（多言語POSシステムを作成するためにuniで2年目に採用されました）。コードに満足せず、スケーラビリティが必要で、より優れたホイールを再発明したかったので、私は無限の質問に答えました...しかし、プロジェクトを延期しただけで（たとえば、約12か月ほど）、...何ですか？いったんデプロイした後も、多くの校正、テスト、パッチ適用などが必要です...
プロのコードベースを使用した経験はありますか？多くのコードベースは、風変わりで、保守が難しいコードでいっぱいです。大きなプログラムを自分で作成してソフトウェアの複雑さを発見する代わりに、他の人が書いた同じように厄介なコードを維持または拡張することもできます。
完全な書き換えが非常に効果的であると私が見た唯一のケースは、チームが同時に新しいツールチェーン/フレームワークを採用したときです。
基盤となるロジック（関数やクラスなどのレイアウトではなく、プログラムが行うこと）が適切である場合、それは同じように機能します。そのため、スパゲッティコードはそれを意味しないと考えますデプロイしないでください。
あなたは顧客に彼らが使用できる何かを持たせる必要があります。次に、改善または機能の追加を依頼されたときに、リファクタリングが必要かどうかを決定し、「新しい機能を統合するためにいくつかの技術的な作業が必要」であることを顧客に知らせても大丈夫です。それによって彼らはそれが彼らにもっとお金がかかることを理解し、彼らはより長く待たなければならないでしょう。そして、彼らは理解するでしょう（またはあなたは引き出すことができます）。
すべてを書き直すのに適した時間は、別の顧客が同様のものを作成するように依頼したときです。
要するに、展開されたときに全体がすべての人の顔に吹きつけることを証明できない限り、展開を遅らせることは専門的ではなく、あなたにもあなたの顧客にも利益をもたらしません。バグを修正したり、新しい機能を追加したりしながら、小さなリファクタリングを行うことを学ぶことは、あなたにとって貴重な経験になります。
あなたの質問に対して私が言うことのほとんどは、他の人から言われました。 Joel Spolskyによる「絶対にしてはいけないこと、パートI」（および「建築宇宙飛行士」に関する彼の他の投稿のいくつか）を読んでください。 「完璧は善の敵」であることを忘れないでください。段階的にリファクタリングする方法を学びます。発送等は重要です.
私が付け加えるのはこれです：あなたは、小さなスタートアップ予算/時間枠で働いている単一の新卒者によって実行可能であると考えられた何かで任務を与えられました。 必要優れた構造化された手続き型プログラミングよりもはるかに洗練されたものは使用しないでください。 （そして、参考までに、「手続き型プログラミング」は悪い言葉ではありません。ほとんどの場合、ある程度必要であり、多くのプロジェクト全体に完全に適しています。）
実際にdo構造化された手続き型プログラミングであることを確認してください。コード内での繰り返しは、壮大で多様な構造が必要であることを示すものではありません。それは単に、繰り返されたコードを取り、それをサブルーチンに入れる必要があるという兆候である可能性があります。 「スパゲッティ」の制御フローは、単にグローバルを取り除くチャンスかもしれません。
合法的にがポリモーフィズムや実装の継承などを必要とするプロジェクトの側面がある場合、プロジェクトのサイズが過小評価されていた可能性があります。
他の人が徹底的に説明した理由により、プロジェクトを完成させて出荷する時が来ました。
testingアプリも「仕上げ」の一部であることを強調したい。重要な機能の一部が完全に実行されておらず、正しい結果が確認されていない場合、このアプリが展開されたときに人々がこのアプリで問題を抱えるという懸念があることは正当化されます。
単体テストと自動化された高レベルのテストは素晴らしいものであり、このアプリケーションをリファクタリング（またはリライト）する前に、できる限り多くのものが必要です。しかし、現時点では主にtestを行う必要があります。すべてのテストを「手動」で実行し、「目で」正しく機能していることを確認する必要がある場合でも同様です。これらのテストを後で自動化する方法を理解できれば、製品の次のバージョンの作業を開始するときに役立ちます。
一部の人々は、アルファテストユーザーとして新しいソフトウェアプロジェクトの前に座って、物事をうまく進めるためのコツがあります。つまり、物事を壊すのが得意です。そのような才能のある人があなたと協力できるほど幸運である場合は、最初にアプリを試してみて、明らかなバグを早期に修正する機会を得られるようにしてください。このタスクを自分で行う必要がある場合は、次のようにします。
- 系統立ててください。
- すべての機能を試してください。
- アプリケーションに不慣れなユーザーのふりをしてください。愚かな間違いを犯し、ソフトウェアがそれをどう処理するかを見てください。
- 問題を修正したと思った後でもう一度試すことができるように、何をしているかを書き留めてください。
自分が抱えているジレンマに本当に興味がある場合は、「リーンスタートアップ」も読んでください。あなたがここで与えられている多くのアドバイスは、あなたがその本を読んだ方があなたに共鳴するでしょう。基本的に、 resource burn-rate はあなたの最悪の敵であり、nothingはエンドユーザー/よりもあなたとあなたの組織にとってより価値がありますお客様の声。したがって、製品を実行可能な状態（Minimum Viable Product-またはMVP）にしてから、（コードが実際にどのように見えるかに関係なく）出荷します。顧客が将来のチェンジセットとバージョンを指示できるようにします。その逆ではありません。あなたがそのアプローチに焦点を当てれば、あなたと上司の両方が長期的には幸せになるでしょう。
あなたの質問は、「最初は間違っていた、最初からやり直さなければならない」と言っていますが、追加のテキストは実際には「プロジェクトが終了しましたが、最初からやり直した場合は間違っていました」と言っています。質問の見出しのみの場合：実行したプログラミング作業の量が必要な総作業と比較して少ない場合は、最初からやり直すことは理にかなっています。これは、問題が複雑で理解が不十分な場合に多く発生し、実際に問題が何であるかを理解するためにかなりの時間が費やされます。悪いスタートを続けても意味がありません。それを捨てて最初からやり直すと、今回は問題を十分に理解しているので、実際には早く終了します。
これは私が個人的にすることです：
- 辞め、言い訳をしてあきらめてください（給料の一部を返済して、見栄えが悪くならないようにすることもできます）
- コードを可能な限りクリーンにする
- 優れたデザイン、優れたアイデアなど、作品のすべての優れた部分に関するドキュメントを作成します。
これらすべてを提案するのはなぜですか？
未来を考えるからです。将来、特定の人々がこのコードを手に入れることになるでしょう。彼らはあなたとあなたの能力についてあらゆる種類の仮定と判断を下します。あなたがそれを書いたとき、彼らは気にしません、彼らは状況を気にしません。彼らは確認したいものは何でも確認するために見たいものだけを見たいのです。
あなたは悪い名前としてブランド化され、彼らがあなたに悪影響を与える可能性がある言葉です。そして、将来的には、技術的な能力、スキル、知識、スタイルの点でまったく異なる可能性があり、状況が大きく異なる場合でも、このコードはあらゆる方法であなたに対して使用されます。それは彼らがあなたとあなたのコードとデザインについてのすべての悪いことを言うことができ、あなたもそれを知らないのであなたが自分自身を説明し、守ることができる裁判所のようなものです。 （そして、あなたはそれらが深く間違っていることを頻繁に学ぶかもしれません、繰り返し）それでそれをしないでください。あきらめる。
信じてください。あなたがどんな目的のためにどんな瞬間に何かをしたので、あなたについて多くの仮定をした人々がいます。彼らにとって、もしあなたが状況Aでこのようにしたなら、あなたは状況Bでそれをするでしょう。彼らは非常に単純だと思います。
さらに2つの提案があります。私は、あなたがまだ行っていないこれらのうち少なくとも1つを賭けます。
1）バグトラッカーを配置し、上司に使用するように伝えます。これは、あなたがどのように失敗したか、よく学んだこと、そしてそれを修正する方法についての会話の一部になる可能性があります計画的に
2）バージョン管理の使用を開始します。
小規模なアカウントで上記の両方を無料で提供するホストされたシステムが山ほどあります。私はFogBugzが特に好きです。FogBugzには、適切に管理された方法で問題に取り組んでいることを上司にさらに確実に伝える、優れた見積もりおよびタスク完了システムがあります。
編集
うわー、誰かが本当にこれを好まなかった-反対票と削除フラグ？どうして？
私は30年以上にわたり、多くのコンサルティング作業や他の人のコードの継承を含め、ソフトウェアを開発してきました。私が見た問題のシステムの膨大な数は、人々がピットを掘ったところにあり、彼らがそこに到達した方法に関する詳細なメモがなく、バージョン管理もありませんでした。