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

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または詳細な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 8年前に閉鎖されました。 ニューヨーク-超高層ビルを震わせた爆発により、83年前の蒸気パイプは、ニューヨークや他の米国の都市の下にある何マイルものチューブ、ワイヤー、鉄が古くなり、危険なほど不安定になる可能性があるという強力なメッセージを送りました。 マンハッタンのバースト蒸気パイプに関する2007年7月のストーリー ソフトウェアの腐敗と技術的負債について聞いたことがあります。 そして、私たちは次のような人から聞いたことがあります： 「ボブおじさん」マーティン-「混乱させることの結果」について私たちに警告した人。 Michael C. Feathers- 「レガシーコードで効果的に作業する」ためのガイダンスをくれた人。 したがって、ソフトウェアエンジニアリングコミュニティはこれらの問題を認識しています。 しかし、私たちの社会全体は、これらの問題が稼働中のシステムやアプリケーションをどのように悩ませるのか理解していないように感じます。 Steve McConnellが指摘するように： ...金銭的負債とは異なり、技術的負債ははるかに目立たないため、人々はそれを無視する方が簡単です。 もしこれが真実であり、そうだと思うなら、政府や企業は手遅れになるまでハッカーに対する定期的な保守と強化を延期するのではないかと恐れています。[NYCや蒸気パイプによく似ています。] 私の質問： NYCや蒸気パイプに相当するソフトウェアを回避する方法はありますか？

15 maintenance  legacy  technical-debt 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 3年前に閉店しました。 タイトルに記載されているように、C＃で使用されるパラメータなどのオプションのパラメータは有用ですか、それともアプリケーションのメンテナンスの妨げになり、コードを理解しにくくするために避けるべきですか？

14 language-features  maintenance 

コードの行を見たときに、ロジックにおけるその役割を忠実に説明するテーマの抽象化に適合できないコード重複のケースに遭遇したことはありますか？それに対処するために何をしましたか？ これはコードの複製であるため、理想的には、たとえば独自の機能を作成するなどの屈折処理を行う必要があります。しかし、コードはそれを記述するための優れた抽象化を持たないため、結果は奇妙な関数になり、良い名前を見つけることすらできず、ロジックの役割はそれを見ただけでは明らかではありません。それは、私にとって、コードの明快さを傷つけます。明快さを保持し、そのままにしておくことはできますが、保守性が損なわれます。 このようなものに対処する最良の方法は何だと思いますか？

14 design  maintenance  refactoring 

私のクラスが所有する列挙型の値を処理するためにswitchステートメントを使用していて、可能な値ごとにケースがある場合-「デフォルト」のケースを処理するコードを追加する価値はありますか？ enum MyEnum { MyFoo, MyBar, MyBat } MyEnum myEnum = GetMyEnum(); switch (myEnum) { case MyFoo: DoFoo(); break; case MyBar: DoBar(); break; case MyBat: DoBat(); break; default: Log("Unexpected value"); throw new ArgumentException() } これは、このコードに到達できない（ユニットテストでも）ことが原因だとは思いません。私の同僚はこれに同意せず、これがMyEnumに追加される新しい値によって引き起こされる予期しない動作から私たちを保護すると考えています。 コミュニティとは何ですか？

14 unit-testing  maintenance  enum 

私はJava / Groovyの強力なバックグラウンドを持ち、管理ソフトウェア用の非常に大きなCコードベースを維持するチームに割り当てられました。 データベース内のblobの処理やPDFおよびExcelでのレポートの生成など、いくつかの問題点はJava Webサービスに外部化されています。 ただし、Java開発者として、コードのいくつかの側面に少し混乱しています。 それは冗長です（特に「例外」を扱う場合） 巨大なメソッドがたくさんあります（2000行以上のメソッド） 高度なデータ構造はありません（リスト、セット、およびマップをたくさん見逃しています） 懸念事項の分離なし（SQLはコード全体でうれしそうに混合されています） その結果、ビジネスは大量の技術コードに隠されており、Object Orientedと関数型プログラミングのピンチで形作られた私の脳は楽ではないと感じています。 プロジェクトの良い面は、コードが単純であることです。フレームワーク、実行時のバイトコード操作、AOPはありません。また、サーバーは、Javaが「hello world」を吐き出すのに必要なメモリよりも少ないメモリを使用することにより、1台のマシンで10000人以上のユーザーに同時に応答できます。 私は、一般に受け入れられている現代の原則に従ってCコードを書く方法を学びたいです。現代のCをどのように記述し構造化するかについて、一般に受け入れられている原則はありますか？ 「Effective Java」本に相当するものに少し似ていますが、C用です。 回答とコメントに照らして編集： 私は自分の考え方をCコードに適合させ、OOPにミラーリングしようとはしません。 コメントから推奨されるコーディングスタイルガイド（The GNU Coding StandardsおよびThe Linux Kernel Coding Style）をスキャンして読み始めました。 次に、このコードスタイルを同僚に提案しようとします。最も難しいのは、同僚に、巨大なメソッドを小さなパーツに分割し、同じ4行のエラー処理コードを繰り返すことをメソッドの助けによって回避できることを納得させることです。

13 c  maintenance 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 私の最後の3つの仕事では、コードメンテナーでした。3つのすべてのケースで、プロジェクトのコードの大部分が既に書かれた後、私は雇われました。 私は独学のプログラマーです。初めてのプロの仕事を始める前に、私は自分のベルトの下で十数個のプロジェクトを開始し、成功して出荷しました。 新しいコードの作成と既存のコードの保守は、まったく異なる2つの仕事です。航空技術者と航空機整備士を比較するようなものです。 特に、飛行機を何らかの方法で論理的または保守しやすいように設計することを試みなかったエンジニアによって設計された飛行機で作業する航空機整備士である場合、それは残念です。 プロジェクトが最初に開始されたとき、私は周りにいるように感じ始めています。あなたは何らかの形でコンピュータサイエンス分野の人々の残りを超越した特別な人々の一人でなければなりません。その位置にいるには何が必要ですか？ この質問には本当に簡単な答えはないように感じますが、誰かが私に洞察を与えることができますか？新しいプロジェクトの1階に行ったことはありますか？そこに着くのに何が必要でしたか？

13 education  refactoring  training  maintenance  industry 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 当社は巨大な製品のソースコードを取得しようとしています。 ハンドオーバーの開始時に考慮すべきことは何ですか？すべてを確保し、将来的にその製品を維持できるようにするためですか？

12 documentation  maintenance  knowledge-transfer 

既存のコードベースのプロジェクトのコーディング標準/スタイルガイドの進化にどのように対処しますか？あなたのチームの誰かがプログラミング言語でオブジェクトのインスタンス化のより良い方法を発見したとしましょう。古い方法が悪いことやバグがあるということではなく、新しい方法のほうが冗長でなく、はるかにエレガントだと感じるだけです。そして、すべてのチームメンバーが本当に気に入っています。既存のコードをすべて変更しますか？ コードベースが約500.000行以上のコードであるとします。それでも既存のコードをすべて変更しますか？それとも、新しいコードのみを新しい標準に準拠させますか？基本的に一貫性を失いますか？ プロジェクトのコーディング標準の進化にどのように対処しますか？

12 coding-standards  coding-style  maintenance 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 実際、この質問は、ユーザーエクスペリエンスの質を高め、回避可能なサポートコールを減らすためにとるべき注意事項に関するものです。

12 maintenance  bug  user-experience 

私の現在の仕事は、主に私たちが取り組んでいるさまざまなアプリケーションのGUIテストコードを書くことです。ただし、テスト内で多くのコードをコピーして貼り付ける傾向があることがわかりました。この理由は、テストしている領域は、繰り返しが必要なほど似ている傾向があるが、コードをメソッドまたはオブジェクトにカプセル化するほど似ていない傾向があるためです。クラスやメソッドをより広範囲に使用しようとすると、テストの保守が面倒になり、最初から書くのが完全に難しくなることがあります。 代わりに、通常、あるセクションからテストコードの大きな部分をコピーして別のセクションに貼り付け、必要な小さな変更を加えます。オブジェクト指向の原則や関数を使用するなど、構造化されたコーディング方法は使用しません。 テストコードを書くとき、他のコーダーはこのように感じますか？DRYとYAGNIの原則に従うことは明らかですが、テストコード（とにかくGUIテスト用の自動化されたテストコード）を使用すると、これらの原則に従うことが難しくなることがわかります。または、より多くのコーディングの練習とより良い全体的なシステムが必要ですか？ 編集：私が使用しているツールはSilkTestで、4Testと呼ばれる独自の言語です。同様に、これらのテストは主にWindowsデスクトップアプリケーション用ですが、このセットアップを使用してWebアプリもテストしました。

12 testing  code-quality  maintenance  test-automation 

これはかなり曖昧な質問ですが、適切な設計について読んだときに満足のいく方法で答えられたとは思っていませんでした。 一般に、オブジェクト指向プログラミング、抽象化、因数分解などについて学ぶとき、設計の聖杯-そして、あなたが問題の開発技術を使用していると常に主張する理由-は、プログラムを「変更しやすくする」ことです、「維持可能」、「柔軟」、またはそのような生産的な響きの概念を表現するために使用される同義語のいずれか。ivarをプライベートとしてマークし、コードを多くの小さな自己完結型のメソッドに分割し、インターフェイスを一般的な状態に保つことで、プログラムを完全に簡単かつ優雅に変更できるようになります。 比較的小さな変更の場合、これは私にとってはうまくいきました。クラスがパフォーマンスを向上させるために使用する内部データ構造の変更は大きな困難ではありませんでした。また、テキスト入力システムの再設計やゲームプレイ要素のグラフィックのオーバーホールなど、APIに依存しないユーザーインターフェイスエンドの変更もありません。 これらの変更はすべて、本質的に自己完結型のようです。それらのいずれも、外部コードに関する限り、変更されるプログラムのコンポーネントの動作または設計への変更を伴いません。手続き型であろうと大規模な機能であろうと小規模であろうとOOスタイルであろうと、これらはあなたが適度に良いデザインしか持っていなくても簡単に変更できます。 しかし、変更が大きくて毛深いものになったとき、つまりAPIに変更が加えられたときはいつでも、私の貴重な「パターン」はどれも助けになりません。大きな変化は大きなままで、影響を受けるコードは影響を受けたままで、何時間もバグを生み出す作業が私の前にあります。 だから、私の質問はこれです。適切な設計がどの程度大きな変更を促進できると主張していますか？私には未知の、または実装に失敗した、さらにスティッキーなサウンドの修正を本当に単純にする、またはその約束（非常に多くの異なるパラダイムによって行われたと聞いた）は単に素晴らしいアイデアである、いくつかのさらなる設計技術がありますか？ソフトウェア開発の不変の真実から完全に切り離されていますか？ツールベルトに追加できる「変更ツール」はありますか？ 具体的には、私がフォーラムに導かれた問題はこれです：私は解釈されたプログラミング言語（Dで実装されていますが、それは関係ありません）の実装に取り​​組んでおり、クロージャの引数は現在の位置ではなく、キーワードベース。これには、匿名関数を呼び出す既存のすべてのコードを変更する必要がありますが、幸いなことに、私は言語の開発の初期段階（2000行未満）であるため、かなり小さいですが、後の段階でこの決定を行った場合は非常に大きくなります。そのような状況では、設計の適切な先見によって、この変更を簡単にすることができたのでしょうか、それとも特定の（ほとんどの）変更が本質的に広範囲に及ぶのでしょうか？これが何らかの形で自分自身の設計スキルの失敗であるかどうかに興味があります-もしそうなら、私は 明確にするために、私はOOPや一般的に使用されている他のパターンのいずれにも決して懐疑的ではありません。ただし、私にとっては、それらの長所は、コードベースの保守ではなく、元の記述にあります。継承を使用すると、繰り返しパターンを適切に抽象化できます。ポリモーフィズムを使用すると、機械が理解する効果（switchステートメントのブランチ）ではなく、人間が理解する機能（クラス）でコードを分離できます。非常に快適な「ボトムアップ」スタイルで記述します。しかし、私は彼らの柔軟性の主張に懐疑的です。

11 design  object-oriented  maintenance  abstraction  changes 

私は最近、一握りのプログラマーと一緒に新しい会社で働き始めました。約70人の従業員を抱える中規模の会社ですが、IT部門の従業員数は9〜10人で、私の横には3人の「プログラマー」がいます。しかし、これらの人たちの経験は非常に限られており、非常に多くのことをやっています。たとえば、プロジェクトの1つはPHP Webサイトです。コードの大部分は20,000行のPHPコントローラーに保存され、PHPには〜6000行のJavaScriptが埋め込まれています。 私はあちこちで小さな提案をし続けていますが、誰も聞いていません。みんなが忙しすぎて私の提案を実行できないと言っています。事は、彼らはそんなに忙しくてはいけないし、物事が正しく行われていなければいけません。彼らはほとんどの時間を、壊れ続けるものの修理に費やしています。各プロジェクトが正しくビルドされていれば、自分ですべてを行うことができました。 これらの人やマネージャーに、物事を変える必要があること、そして物事を変えることで時間を節約できることを納得させるには、どのようなアプローチを取るべきでしょうか？同僚が説得しようとするのをスキップして、会社が正しいことを始めた場合に会社がたくさんのお金を節約する方法についてのビジネス上の提案で、マネージャーに直行しますか？

11 programming-practices  maintenance 

2年ほど前に書いたソフトウェアがいくつかあり、それに追加する機能が必要です。私など、それはひどい混乱にだことに気づき、私は周りのすべてを移動する衝動を持って、きちんとアップしましたIましたが、読んで再起動していないソフトウェアについての記事でジョエルを、その前方に最良の方法はいただきましたか！？

11 refactoring  maintenance 

これらのどれが保守性に優れていますか？ if (byteArrayVariable != null) if (byteArrayVariable .Length != 0) //Do something with byteArrayVariable または if ((byteArrayVariable != null) && (byteArrayVariable.Length != 0)) //Do something with byteArrayVariable 私は2番目のものを読み書きすることを好みますが、そのようなことを行うと保守性が悪くなることを完全なコードで読んだことを思い出します。 これはif、最初の部分がfalseであり、すべての言語がそれを行うわけではない場合、2番目の部分を評価しないように言語に依存しているためです。（nullで評価された場合、2番目の部分は例外をスローしますbyteArrayVariable。） それが本当に心配なのかどうかわからないので、質問に対する一般的なフィードバックをお願いします。 ありがとう。

11 programming-practices  coding-standards  maintenance  readability 

時間の経過とともに、ますます多くのオープンソースコードが生成され、さまざまな無料または部分的に無料のリポジトリに追加され、その後一般に放棄されているのが私の印象です。 放棄されたコードを処分するための一般的に受け入れられている基準はありますか？これはリポジトリによって強制されるのでしょうか、それとも元のコード作成者がやるべきことなのでしょうか？

10 open-source  maintenance