問題タブ [maintenance]

私はいくつかのプログラミングの仕事をしてきました。それぞれに 20 ～ 50 人の開発者が参加し、プロジェクトは 3 ～ 5 年続きます。

毎回同じです。優秀なプログラマーもいれば、平均的なプログラマーもいます。全員が CS の学位を取得しており、全員がデザイン パターンを読んでいます。意図は良いものです。人々は良いコードを書こうと懸命に努力していますが、それでも数年後にはコードがスパゲッティになってしまいます。モジュール A の変更により、突然モジュール B が機能しなくなります。 コードには、それを書いた人以外には誰も理解できない部分が常にあります。インフラストラクチャを変更することは不可能であり、下位互換性の問題により、優れた機能を導入できません。半分の時間は、すべてをゼロから書き直したいだけです。

そして、私よりも経験豊富な人は、これを普通のこととして扱います。それは...ですか？そうでなければなりませんか？これを回避するにはどうすればよいですか、それとも現実として受け入れる必要がありますか?

編集: 皆さん、ここでの回答の量と質に感銘を受けました. このサイトとそのコミュニティロック！

私は現在、非常に迅速で汚い方法で構築されたRailsアプリケーションを担当しています。使用されていない多くのビューファイル（htmlテンプレート）があります。また、使用されていない多くのcssファイルがあります。

削除できるように不要になったファイルを特定するための最良の方法は何ですか？

Rails固有のソリューションではなく、一般的なソリューションを探していますが、Ruby/Railsのみのソリューションは間違いなく歓迎されます。

始めるために、使用されたビューを決定するために私が持っていた1つのアイデア（私は特に好きではありません）は次のとおりです。

1. すべてのビューファイルの先頭にコード行を挿入するスクリプトを記述します。コード行は、ビューの名前をある種のログに追加します。
2. サイト全体を再帰的に取得します
3. ログを調べて重複を削除します-次に、使用されているビューのリストがあります
4. ログにリストされていないビューを削除します

わかりませんが、以前の開発者は、大きな問題もなく、問題なくコーディングに取り掛かったと言われています。ここで上級プログラマーとの簡単なミーティングをマネージャーに依頼するのは間違っているのではないかと思います。用心深く、この時間に敏感なトラッカーを長い道のりで終わらせる方が良いですか、それとも締め切りに間に合うように急ぐ方が良いですか?

余談ですが、このアプリを維持していた以前のプログラマーは、入社して 1 年も経たないうちに全員いなくなりました。何かに関係があるかどうかはわかりません。

私の読書から、仕様パターンはデータをフィルタリングするために必要なメソッドの数を大幅に減らすことができるようです。仕様パターンを使用すると、どのようなメリットがありますか？あなたが気づいた予期せぬ利益がありましたか。逆に、どのような落とし穴に遭遇しましたか？

私が発見したように、多くの開発者は更新 (自動または手動) を避けています。これは、自分が理解していないマシンに変更が加えられる可能性があることや、開発中のソフトウェアが何らかの理由で失敗する可能性があることを恐れているためです。 .

戦略 A.) 可能な限りシステムを現状のままにしておく。

個人的には、自分のシステム (OS とアプリ) をできるだけ「最新」にするのが好きです。

戦略 B.) 常に最新

あなたはどのタイプの開発者ですか？なぜ ？

複数のサーバー間のタスクの調整を容易にするユーティリティ/ライブラリはありますか？私の場合、スケジュールされたタスクを実行し、サーバー間で大量のデータをコピーし、プロセスを再起動する必要があります（クラスター内の異なるマシンで発生する一連の依存操作）。

cronジョブとバッチスクリプトを使用することはできますが、これを実行するためのより堅牢でエレガントな方法があると考えざるを得ません。

新しいSharepoint2007イントラネットのメンテナンスグループを支援するための包括的なドキュメントを作成しようとしています。

私が判断するのに問題があるのは、さまざまな要素を顧客の承認および本番環境に移行するための適切なツールは何かということです。将来的には、新しいリスト、新しいカスタムタイプ/リストテンプレート、変更されたページ、新しいページなどを処理する必要があると予想されます。

つまり、サブサイト全体を追加するのは比較的簡単だと思いますが、既存の領域に段階的に変更を加えるのは簡単ではないようです。特に、生産現場には顧客が更新するさまざまなリスト（掲示板など）があるためです。

これまでのところ、最良の答えはhttp://www.codeplex.com/SPDeploymentWizardのようですが、いくつかの問題が残っています。

1）ベータ版であり、Microsoftの公式製品ではありません。そのため、お客様はあまり自信がない場合があります。2）変更を配信するすべてのサーバーにインストールする必要があり、GUIコンポーネントを介して機能します。これもまた、顧客があまり満足しないものになるでしょう（彼らのものはサードパーティによって管理されています。EDSまたは同様の会社を考えてみてください）。

誰かが本番関連のシナリオで自信を持ってそれを使用しましたか？提案するさまざまな選択肢がありますか？

TIA、

パオロ。

Windows サービスとして使用される C# プログラムがあるとします。サービスが暴走し、CPU とメモリを狂ったように消費しているとしましょう。これは本番システムであるため、すぐに再起動する必要があります。そのため、実行時の情報を収集する時間があまりありません。たぶん、タスクマネージャーをざっと見てください...それだけです。

その後、私が持っているのは、事後分析用のlog4netログファイルとWindowsイベントログだけです。

問題の原因がわかったとします。他の誰かがそれを修正し、おそらくプログラマーが追加のログを追加するので、次回同様の問題をより迅速に見つけることができます. それにもかかわらず、私はまだログ ファイルの品質に依存しており、次回は何らかの形でログに問題が現れることを願っています。

事後分析を行う他の方法もありますか? スレッド ダンプ (Java など)、メモリ ダンプなど、事後分析に役立つものでしょうか? ビルトインの .NET フレームワーク ツールが役立つのではないでしょうか?

私は実際のプロジェクトの経験と、ほとんどのプログラマーにとって非常に現実的なこのメンテナンスの問題にどのように取り組もうとしているのかに非常に興味があります。

ひどい質問のタイトルで申し訳ありませんが、もう少し冗長に説明してみます。

私は自分のソフトウェア プロジェクトに Git を使用しています (ただし、この場合、特定のソフトウェアは重要ではないと思います)。多くのプロジェクトと同様に、さまざまなリリースを予定しています。リリースがあるときは、おそらくコミットにタグを割り当てます。たとえば、「1.0」などです。時が経ち、コードがハッキングされ、最終的に別のタグが付いたリリースがあります - 今回は「2.0」です。

ある日、リリース 1.0 と 2.0 の両方に存在する深刻なバグに気付きました。これは修正する必要があります。物事を難しくするために (そしておそらくより現実的にも)、現在のマスター/トランクで修正して、誰もがそれを使用していると仮定することはできません。アップグレードしたくない。

では、この種の動作をサポートするためには、どのようなスキームを用意すればよいでしょうか: 古いバージョンで変更を加えることができるようにすることです。git describeコマンド (" ")の出力のため、Git はあるレベルでタグをリリースと同一視しているよう[latest tag]-[commits since the tag]-[current commit hash]です。では、タグを完全に使用することはおそらく避けられません。

タグとブランチの組み合わせはいいアイデアだと思いますが、なぜかこれでは詳細が頭に浮かびません。

Do you have a naming convention for APIs or Classes that are being phased in to replace an older version that performed the same function / filled the same role?

E.g. Windows does this by adding "Ex" to the end of the function:

What do you prefer, and what are you reasonings?

• Appending 2, V2, New, NowInStereo?
• Doing a one-time rename of the old API from Something to SomethingOld and using Something for the new stuff? This option worries me when it comes to version control, but it also seems the least likely to be burdened with a V3 or ReallyNew problem in the future.
• Making up a completely different name that may describe the function less accurately, but at least is different.