タグ付けされた質問 「rewrite」

Big Rewritesに関する質問を読んでください。私は自分で答えたいと思っていた質問を思い出しました。 Struts 1.0を使用して古いJavaで書かれた、恐ろしいプロジェクトがあります。テーブルは一貫性のないリレーションシップを持っているか、リレーションシップがまったくないか、プライマリキーまたはフィールドがプライマリキーであることを意図していますが、一意ではありません。どういうわけか、アプリのほとんどは「機能する」だけです。ほとんどのページは再利用（貼り付けられたコードのコピー）およびハードコーディングされています。プロジェクトに携わったことのある人は誰でも、何らかの形でそれを呪いました。 今では、この恐ろしいアプリケーションの全面的な書き換えを上級管理職に提案することを長い間考えていました。私は個人的な時間でゆっくりと試みていますが、それを実現するための専用のリソースが必要だと思います。大きな書き直しに関する記事を読んだ後、私は再考しています。そして、上司に私の書き換えをサポートするように説得したいとき、それは良くありません。（私はかなり小さな会社で働いているので、提案は承認される可能性があります） TL; DRいつ答えが大きく書き換えられ、それをサポートするためにどのような引数を使用できますか？

278 code-quality  rewrite 

私は高校生で、私の友人と一緒にC＃プロジェクトに取り組んでいます。私のスキルレベルはほぼ同じです。これまでのところ、100件のコミットで約3,000行のコードと250行のテストコードを記述しました。学校のために、私は数ヶ月プロジェクトを延期し、最近私はそれを再び取り戻すことができました。 バックアップを取得するまでに、レンダラーに過剰なスレッドを含める、エミュレートされたCPU、GPU、ゲームカートリッジ間の相互作用における競合状態の防止が不十分であるなど、記述したコードの設計が不十分であることがわかりました、および単に冗長でわかりにくいコードも同様です。 問題は、プログラムの主要な機能すら完成していないため、真のリファクタリングができないことです。コードの設計に欠陥があることを完全に認識し続けることはできません。同時に、私はプロジェクトを放棄したくありません。かなりの量の進歩があり、作業が無駄になってはいけません。 私はいくつかの選択肢があるように感じます：貧弱なデザインを回避し、すべてが機能したらリファクタリングし、すべてを停止し、残りの機能が完了する前にすべてのもつれを解き、プロジェクトを開始することによって、単に機能を終了するそれがすべて私の心に再び新鮮であるように、または過度のサイズのためにプロジェクトを完全に放棄するように（本質的に「図面に戻る」）。 そのようなプロジェクトにおける他の人の経験に基づいて、自分を正しい軌道に乗せるための手段は何ですか？このサイトの回答から、一般的なコンセンサスは、書き換えは一般的に不要であるが、過剰なコストなしにコードを維持できない場合に利用可能なオプションであるということです。私は本当にこのプロジェクトを追求したいと思っていますが、現状では、私のコードは私が続けるのに十分に設計されておらず、落胆の感覚が私を継続からそらします。

186 code-quality  refactoring  personal-projects  rewrite 

ジョエル・スポルスキーは、彼の有名な投稿の1つで次のように述べています。 ソフトウェア会社が犯す可能性のある最悪の戦略的ミスは、コードをゼロから書き直すことです。 チャド・ファウラーはこう書いた： ビデオ、ウェブログの投稿、誇大広告を見たことがあるので、Rails（またはJava、.NET、Erlangなど）で製品を再実装することにしました。 気をつけて。これは、予想よりも長く、困難で、失敗しやすいパスです。 BIG Rewriteに参加したことがありますか？ この悲劇的なトピックについてのあなたの経験に興味があります。特に、（もしあれば）成功裏に完了した大きな書き直しに興味があります。

55 rewrite 

私は、アプリケーションの書き直しが悪いことについての複数の投稿、プログラマに関するここでの人々の経験、およびこのテーマに関するJoel Spolskyによる準備ができた記事を見ましたが、確固たる証拠や事例研究はありません。Joelが提供した2つの例とここの他の投稿以外に、悪いコードベースで何をし、実際の研究に基づいてどのようにそれを行うかを決定しますか？ 適切な例として、私が知っているクライアントは2つあり、どちらも古いレガシーコードを持っています。彼らは、書き直しが惨事であり、費用がかかり、コードを大幅に改善することが実際にはできなかったため、彼らはそれに合わせてリンプを続けています。リライタがすぐに見つけたように、その顧客は非常に複雑なビジネスロジックを持っています。 どちらの場合も、これらは企業にとって多くの収益をもたらすミッションクリティカルなアプリケーションです。書き直そうとした人は、将来のある時点でレガシーソフトウェアがアップグレードされなければ、レンガの壁にぶつかると感じていました。私にとって、この種のリスクは、成功する道を確保するための研究と分析を必要とします。 これを調査した実際のケーススタディはありますか？実際の研究に基づいたいくつかのベストプラクティス、落とし穴、成功を知らずに、大規模な書き直しを試みたくありません。 あとがき： さて、さらに検索した結果、ケーススタディに関する3つの興味深い記事が見つかりました。 書き換えまたは再利用。彼らはJavaに変換されたCobolアプリの研究を行いました。 もう1つは、ソフトウェアの再利用：開発者の経験と認識に関するものでした。 再利用または書き換えメンテナンスと書き換えのコストに関する別の研究。 最近、このテーマに関する別の記事を見つけました：The Great Rewrite。そこで、著者は主要な問題のいくつかにぶつかったようです。これに加えて、提案された新しいテクノロジースタックを使用し、開発者がそれを拾った速さを測定することによるプロトタイピングのアイデアがありました。これはすべて書き直しの前奏曲であり、素晴らしいアイデアだと思いました！

36 source-code  planning  code-reuse  rewrite 

製品（プロトタイプ）P_OLDを言語Xで開発し、現在は言語YでP_NEWとして最初から書き直しています。 P_NEWとP_OLDは同じ製品であるため： P_NEWは古いP_OLDのブランチである必要がありますか、それとも独自のリポジトリである必要がありますか？ バージョン管理の観点からこのような大きな変更を処理する通常の方法は何ですか？

29 version-control  git  rewrite 

次の場合に教えてください： Node.jsを使用するとサイトが高速になります！ Node.jsはより少ないサーバーリソースを消費するため、コストを節約できます！ Node.jsにより生産性が向上します！ Node.jsは、クライアント側とサーバー側のJavaScriptコードを共有できることを意味します。 明確にするために、フロントエンドサーバーを書き換えています。これは、既存のRuby on RailsアプリケーションとAPIとして対話します。その間、Ruby on Railsアプリケーションをサービスにリファクタリングします。 既存のアーキテクチャの詳細： HTMLパーシャルキャッシュ用のMemcached セッション用のRedis、および構造化されたデータキャッシング MySQLシングルマスター、マルチスレーブ 多数の書き込みを受け入れる1つの大きなテーブルがあります（ポーリングを想像してください） それ以外の場合はほとんど読み取ります。 一部のメタデータ用のMongoDB Ruby on Rails 3.0 nginxとUnicorn

24 architecture  ruby-on-rails  node.js  rewrite 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 4年前に閉鎖されました。 コンテキスト： それは内部プロジェクトです（多くの人が使用するとは思わない） 古いです 私たちはそれを更新しています 問題： mvcフレームワークを悪用します（モデルの使用、ビューでのビジネスロジックなど） 求められていることは小さいですが、凝集度が低いため、2つのオプションがあります。 物事をやり続ける 大量のコードを移動したり、コードを書き直したりする ソリューション（私が見る）： 引き続き作業し、ベストプラクティスを無視して、すぐに行われ、リファクタリング/リライトによって新しいバグを導入しないことを支持する リファクタリング/書き換え 私の質問は本当にそうだと思います：このプロジェクトに大きな変更を加えたい場合、誰をin辱せずにそれを提案するにはどうすればよいですか？それとも、それが時々（比means的な）ダクトテープを意味していても、単純に流れに行く方が良いでしょうか？

15 refactoring  communication  internship  rewrite 

会社で営業部門のプロジェクトに取り組んでいます。それは私の最初のプロのプログラミングの仕事ですが、私は自分でコーディングして何年も学習しています。プロジェクトの一部では、いくつかのデータを取得し、それを入力と組み合わせて生成およびグラフ化します。次に、データを保存します...など。そのため、私はこのためのコードを1日少しで書きました。翌日、私はプロジェクトスーパーバイザーを見せました。彼はそれを気に入っていましたが、「これがあったらどうだろう」と言って、グラフに何かを追加したかったのです。これはプログラムの外観や機能に対する大きな変更ではありませんでしたが、データの保存や処理などに必要な方法を大幅に変更しました。 この場合も、データベーステーブルを再構築し、この新しい要求をサポートするためにコードを基本的にゼロから書き直すのに約1日かかりました。私はそれを再び彼に持ち帰ったが、まったく同じことが起こった。彼は私がデータを処理するために必要な方法を劇的に変える何か他のものを要求しました。それで、私はそれを再び書き直さなければなりませんでした。最後に彼はそれにサインオフしました、そして願わくば、私は再びそれを書き直す必要がないでしょう。 ただはっきりさせてください、私はマネージャーやそのようなものをバッシングしていません。彼は偉大な人物であり、彼が要求していたことはこの世界からではなく、私が以前にやったことと相容れないものでした。 完全な書き直しを避けるために今後できることはないかと思っています。私は柔軟なコードを作成することを理解しており、それをしようとしていましたが、これを簡単にするために別の方法で行うことができたプラクティスまたは事柄を知りたいので、将来、私は何かに3日を費やしません取るべきでした1。

13 programming-practices  requirements  rewrite 

アジャイル手法を使用してアプリケーション全体を書き直さなければならないとしたら、どうしますか？ 現在のシステムの動作に基づいて、多くのユーザーストーリーを作成できると思います。そして、それらを小さな反復で実装します。しかし、これは私たちが前方に要件を持っているという意味ではないでしょうか？ また、いつリリースを開始しますか？アジャイルは、早期かつ頻繁にリリースすべきだと言っていますが、完全な書き換えが完了する前にリリースすることはあまり意味がありません。

13 agile  scrum  software  extreme-programming  rewrite 

今日、誰もが機敏になりたいと思っています。私が一緒に働いたすべてのチームで、アジャイルの形は異なっていました。いくつかのことは一般的です-毎日のスタンドアップや計画などですが、他の部分は大幅に異なります。 私の現在のチームには、気になることが1つあります。それは機能要件の欠如です。書面による期待が存在しないだけでなく、タスクでは、何を実行する必要があるかが漠然と定義されています。 プロジェクトの目標は、新しいテクノロジーを使用して古いシステムを書き換えることです。古いシステムにも適切なドキュメントはありません。確かに最新のものは存在しません。事業主の要件の説明は、以前と同じように新しい実装で実行しましょう。それは合理的に思えますが、そうではありません。古いシステムは一種のスパゲッティコードであり、そこからビジネス要件を抽出するにはコストがかかります。状況は計画に悪影響を及ぼしているようです。確かに、新しい実装では間違いやバグが発生しやすい（詳細は省略）。 したがって、私は考えています-古いシステムを書き換える場合にビジネス要件がないことは本当に俊敏ですか？

10 agile  legacy-code  rewrite 

最近、RailsConf 2014の「All the Little Things」を視聴しました。この講演中に、Sandi Metzは、ネストされた大きなifステートメントを含む関数をリファクタリングします。 def tick if @name != 'Aged Brie' && @name != 'Backstage passes to a TAFKAL80ETC concert' if @quality > 0 if @name != 'Sulfuras, Hand of Ragnaros' @quality -= 1 end end else ... end ... end 最初のステップは、関数をいくつかの小さなものに分割することです： def tick case name when 'Aged …

9 unit-testing  testing  refactoring  ruby  rewrite