私はレール2.3に大きなルビーを持っていますが、これは遅さと多くのバグのために災害でした。私は唯一のプログラマーであり、毎日デバッグを行ったり、髪を引き裂いたりしています。ユーザーはすでに製品を使用していますが、非常に多くのバグやデータが散らばっています。
私は、プロジェクトの開発と管理に関する予備知識なしで雇用されました。今、私は残業が増え、コードを修正する危機に苦しんでいます。
また、このアプリは Rails を学びながら作成したため、見慣れないコードがいくつかあります。
私は何をすべきか？あなたの提案は何ですか？もっと読む必要がある本は何ですか?
助けが必要です。
ありがとう。
Rails 3 にアップグレードすることを強くお勧めします。特に、多くの新しい機能があり、一部の機能が簡素化されているため、将来の保守が容易になります。
しかし、残念ながら、あなたがすでに多くのことを手にしていることを考えると、私は実際にそれを推奨することをためらっています (または単に推奨できません)。
この場合、あなたができる最善のことは、テストを書き始めることです。バグが非常に多い場合は、テストがないか、テスト スイートが不完全であると考えざるを得ません。テストは、何かを修正しようとしたときに何も壊さないという自信を与えるのに役立ちます。
デフォルトの Rails テスト フレームワークは、Ruby on Rails Guides にあります。そうは言っても、多くの人はRSpecテスト フレームワークを好みます。確かに、デフォルトの Rails テスト フレームワークには欠点があります (特に、フィクスチャの脆弱性 -ファクトリー gemの取得、およびモックや期待値、ネストされたコンテキストなどの他の機能を試してください)。
テストフレームワークを読んで、少し試してみてください。ただし、早い段階で 1 つのテスト フレームワークを選択し、すべてのテストを開始してください。
おそらく、テスト スイートに自信を持ち、最も重要なバグを修正したら、Rails をアップグレードする方法についてもっと考える必要があります。もう十分にサポートされていない可能性がある、ますます古い宝石を使用しています。
私が理解したことによると、あなたはプロジェクト管理のヒントと、Rails プロジェクトを管理するためのツールを求めています。
最初に必要なことは、プロジェクトを安定させることだと思います。これを行うには、バグを最小限に抑え、必要な作業をチャート化する必要があります。
これには2つの補完的なアプローチがあります。
すべてのバグを箇条書きにした何らかのリストが必要になるため、これは非常に重要です。
ユーザーがバグを発見すると、突然すべてを削除しなければならないことがあります。その時点で、その 1 つのバグがこれまでで最も重要なバグであり、すぐに解決する必要があるからです。ただし、修正しようとしているバグが多かれ少なかれ重要であることを意味するかどうかを率直に尋ねると、答えは異なる可能性があります。
したがって、ユーザーがその決定プロセスに参加できるようにする明確な方法があれば、それはあなたにとって有利です。共有バグリストがある場合、ユーザーは現在の状態 (作業中のもの) を追跡することもでき、どのバグが自分にとってより重要であるかを示したり選択したりできます。
第二に、項目 (作業/タスク/未解決のバグ/...) のリストがあると、作業の計画にも役立ちます。
ある種のバグ追跡には多くのオプションがありますが、いくつかの簡単/実用的/無料の提案は
バグ/タスクを追跡することで、プロジェクトをコントロールできるようになり、さらに、これがクライアントにもっと見えるようになります。
バグを修正する場合、新しいバグを導入する危険性が常にあります。これは、元は自分のものではないプロジェクトであることは間違いありません。
テストがほとんどないプロジェクトでは、私は常にキュウリから始めることを提案します。きゅうりにはいくつかの利点があります。
test-codeは読みやすく、クライアント/ユーザーに見せることができ、彼らは実際にテストで何がカバーされているかを理解するでしょう (そしてそれを修正/改善することができます)。個人的には、最初のステップはプロジェクトを安定させ、すべてのバグを最小限に抑える/削除する必要があると考えています。Rails 3 へのアップグレードは大きな改善ですが、簡単なプロセスではありません。適切なガイドラインがありますが、今それを行うと、バグがアップグレード中に導入されたのか、それとも以前から存在していたのかわかりません。最初にコードの品質を整えてから、アップグレードを行います。
お役に立てれば。
実際、あなたが求めているのは、プロジェクト全体をクリーンアップするために必要なリファクタリングの量に完全に依存しています。あなたがそれを完全にきれいにするのに十分な時間があなたの手にあるならば。次の手順をお勧めします。
cucumberのテストツールとフレームワークを決定します。rspecfactory girlこのプロセスは、4人のメンバーからなるチームの中規模プロジェクトの場合、約4〜5か月かかります。
特定の混乱がある場合はお知らせください。
残念ながら、現在のソリューションには簡単な修正はありません。アップグレードを真剣に検討している場合、不足しているテストを書いていない場合はそれを埋め、Rails 3 の上にあるテスト フレームワークを選択し、切り替えの準備ができたら必要なデータ移行を行うには時間がかかります。スイッチ。
もう 1 つのオプションは、Rails 2.x を継続することです。これは完全に理解できないわけではありませんが、サポート手段ははるかに制限されます。最優先事項としてテストに取り組み、既存のアプリケーションに存在するさまざまなニュアンスを理解する必要があります。
あなたのシナリオ (以前の経験がほとんどまたはまったくないワンマン ラケット) については、あなたが持っているものに固執し、アップグレードする価値があると感じるポイントまでテスト容易性を改善することが賢明な行動だと思います. どのような行動を取るにしても、短中期的にはかなりの労力を費やす準備をしてください (ただし、技術的負債が蓄積する場合はそうです)。
読むべきもの: http://guides.rubyonrails.org/v2.3.11/デバッグとパフォーマンステストに関する章から始めてください。
今のところ、Rails 3 へのアップグレードは忘れてください。現時点では、多くのバグが発生するだけであり、レガシーの gem やプラグインに多くの問題が発生する可能性があります。また、Rails 3 にアップグレードするには Ruby 1.9 が必要であることを忘れないでください。
ronalchnが示唆したように、テストを追加することは良い考えです。単体テストから始めることをお勧めします。テスト可能にするために、コードを何度も書き直す必要があるかもしれません。(言い換えると、現在のレガシー コードに合わせてテストを試みる代わりに、コードをリファクタリングしてテスト可能にする方が通常は優れています。)