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

最近、いくつかのプロジェクトと開発環境を切り替えています。それぞれのコーディングスタイルに対する期待は異なります。 さて、私の質問は3つの部分で、最初は好奇心の問題です。 コーディングスタイルをどのように定義して見つけましたか？ どのようにしてそれを増強し、改善し続けますか？ どのように維持しますか？（メンタルノートから、ドキュメントの保持、StyleCopなどのツールの使用）

10 coding-style  maintenance 

2つの言語でコーディングする必要のあるロジック集約型のアルゴリズムがあります（実際には1つの言語で問題なく終了し、もう1つの言語でコーディングを開始しようとしています）。ロジック集約型とは、アルゴリズムが重要であり、注意深く理解する必要があり、さらに重要なことには、将来的にパッチを適用する必要のあるバグ（複雑さと不注意のため）が発生する可能性があることを意味します。 また、私はこのコードが手を変えるときに、最終的には新しいプログラマーを圧倒してはならないことを確認したいと思います。 このシナリオを前提として、コードベースを維持して同期を保つのに役立ついくつかの方法は何ですか？ソフトウェアツール、ベストプラクティスなどを意味します。 参考までに、2つの言語はC ++とJavaです。Androidを含む「その他すべて」のWindows / LinuxおよびJava用のC ++。

10 maintenance  maintainability 

私は現在、制御の反転（IoC）コンテナーを既存のアプリケーションに統合することに直面しており、カップリングを減らし、それによってテスト容易性を高めるという最終的な目標でそれを最も簡単に達成できる方法に関するいくつかの推奨事項を探しています。私は通常、ほとんどのクラスを神のオブジェクトとして分類しませんが、静的、シングルトン、およびインターフェイスの欠如により、それぞれに責任が多すぎ、依存関係が隠されています。 以下は、直面する必要があるいくつかの課題の背景です。 依存性注入はほとんど使用されません 静的メソッドが豊富-ファクトリーメソッドとヘルパーメソッドの両方として シングルトンはかなり普及しています インターフェースを使用すると、きめ細かすぎない オブジェクトは多くの場合、基本クラスを通じて不要な依存関係を取り込みます 私たちの意図は、次に特定の領域で変更を加える必要があるときに、実際には存在するが、シングルトンやスタティックなどのグローバルの背後に隠されている依存関係を取り除くことを試みることです。 IoCコンテナが依存性注入の導入の副次的な要素になると思いますが、これらの依存関係を打開するのに役立つ、実行または推奨できる一連のプラクティスと推奨事項があると思います。

10 design  dependency-injection  maintenance 

閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ 質問を更新して、ソフトウェアエンジニアリングスタック交換のトピックになるようにします。 5年前休業。 見慣れないコードを手動で検査（確認または変更）するとき、3つのオプションがあるようです。 トップダウン読み取り、ファイル名はそうどのように基本的なことで、それぞれ次のソースファイルを選択し、コードの。 私は通常、ほぼすべてを読むことになります。一部のファイルは2回。 幅優先読み取り、私が見つけ、最小限の理解した上で、呼び出すメソッドのすべてを読み、。次に、関数が呼び出したすべての関数を読み取ります。 私のメンタルスタックは、数回の呼び出しで深くすると、オーバーフローする傾向があります。 デバッガですべてのコードをステップ実行する深さ優先の読み取りでは、これに8分かかるのか8時間かかるのかわかりません。 コードの内容を十分に理解するのに十分なコードを読んだら、基本コードが20％以下である一方で、コードベースの80％以上を読んだことをよく反映します。私は多くの時間を無駄にしました。 なじみのないコードをすばやく把握するには、どのツールが役立ちますか？クリティカルコードパスの「全体像」を示し、特定の部分の詳細にドリルダウンできるツールはありますか？

9 tools  code-reviews  source-code  maintenance 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、専門知識によって裏付けられると期待していますが、この質問は、議論、議論、投票、または拡張ディスカッションを求める可能性があります。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 8年前休業。 私が読んでいたのは、保守のセクションがあるソフトウェアエンジニアリングの事実と誤りです。私は何年もの間メンテナンス開発者でしたので、私は非常に興味深い事実を提示されました。3つあります。 事実41：メンテナンスは通常、ソフトウェアコストの40〜80％（平均、60％）を消費します。したがって、それはおそらくソフトウェアの最も重要なライフサイクルフェーズです。 事実42：拡張機能は、ソフトウェア保守コストの約60％を占めています。エラー訂正は約17％です。したがって、ソフトウェアのメンテナンスは、主に古いソフトウェアに新しい機能を追加することであり、修正することではありません。 事実45：より優れたソフトウェアエンジニアリング開発は、より多くではなくより多くのメンテナンスにつながります。 これは直観に反するものでしたが、変更が簡単なため、優れたソフトウェアのメンテナンスが多いことがわかります。したがって、それはより長く使用され続け、はい、より多くの変更をもたらします。 どのパラダイム（関数型、オブジェクト指向、手続き型など）が保守性が最もよく、これを裏付ける研究はありますか？

9 maintenance  maintainability 

私は大学を出たばかりで、この会社で約8か月間働いていますが、開発者の称号を与えられましたが、ほとんどの時間は他の人のコードの修正とデバッグに費やされていました。 なぜ元の開発者が自分のコードを修正する責任がないのか、いつも疑問に思っています。元の開発者が存在しない場合、他の開発者が仕事を引き継ぐ必要があることを理解していますが、開発者が会社の従業員としてまだ働いている場合はどうなりますか？ 新しい開発者が学習する機会と見なすことは有益であると主張する人もいるでしょうが、私はそれに同意しますが、コードの問題/問題の複雑さが非常に急な場合はどうでしょうか。私の場合、彼らが修正するように彼らに割り当てたコードのほとんどは重要な問題であり、コードに関する元の開発者の質問を常に私自身に尋ねることになります。なぜそれを作成した開発者は、コード化してからそれをよく理解していると、既存の問題を修正できないのでしょうか？そして、私が言及している問題は、1〜2日で修正できるようなささいな問題ではなく、解決策を見つけるためにコードを深く理解する必要がある問題です。 これの背後にある理由は何ですか？それはソフトウェア業界で一般的ですか？

9 maintenance 

バグまたは欠陥のクラスターの存在について多くの主張があります。単純な検索は、例えば、複数の結果を明らかにする： 1、 2、 3、 4、 5。 しかし、引用された証拠はすべて逸話的であり、これを裏付ける具体的なデータは見つかりませんでした。私自身の経験はこれらの主張に矛盾しませんが、パターンがない場合でも人々はパターンを見るのが好きです（バグが均一に分散されてもクラスターが生成され、10箇所ではなく1箇所で10箇所のバグを修正する必要がある場合は覚えやすいでしょう）コードベース全体で無関係なもの）。 この現象が実際に存在するかどうかは本当に気になりますが、欠陥のクラスタリングが実際に発生していることを示す客観的または半目的的なソース（テスト、実験、研究など）さえ見つけることができませんでした。 もちろん、私はバグのクラスタリング仮説を良い習慣として想定しても問題ありません（たとえそれが間違っていても、それほど害はありません）。一方、具体的なデータは、それが発生する理由を明らかにする可能性があります。何故かといえば、（どんな理由であれ）ひどい頭痛がしているからでしょうか。または、コードの一部が難しいだけで、他の部分が簡単なためでしょうか？それとも、互いに嫌いな2人のエンジニアの責任の所でしょうか。 私の質問：欠陥クラスタリング効果は実際に存在しますか？この仮説によって最もよく説明される具体的な非逸話的なデータはありますか？

8 testing  debugging  maintenance  engineering 

プロダクションアプリケーションを見込み顧客にデモできるようにする必要があります。今日のセットアップ方法は簡単です。デモアプリケーションは、現在のクライアントのデータを保護するためにデータベース内のデータが難読化されていることを除いて、運用システムの完全な複製です。アプリケーションの変更を必要としないため、これはうまく機能します。 Bossは本日、潜在的なBOMBSHELLをドロップし、デモシステムには特別なリンクを含める必要があり、デモにのみ表示されると述べました。彼はさらに、将来的にはデモアプリと本番アプリの間には大きな違いがあるかもしれないと説明しました（たとえば、機能の全領域）。私は今何をしますか？ 私がやることについて考えたいくつかのこと： デモシステムに固有のSubversionで別のブランチを維持する デモ用の変更を含むインストールパッケージを作成し、本番インストールパッケージを元に戻してビルドする アプリケーションをモジュール化する（方法がわからない） 説明：「ネジを締めてください！私はそれをしません！」（笑） アプリで何らかの条件付きロジックを使用して、それがデモアプリか本番アプリかを判断します。例（URLに「デモ」が含まれている場合は、それ以外の場合は非表示）。 これまでに推測していない場合、これはWebアプリケーションです。 とにかく、私はこのシナリオでどちらが良いか、またはどれも良いものがないかどうかについての経験はありません。誰かが答え、戦略、何かを持っています！？

8 c#  asp.net  deployment  maintenance 

私はいくつかの本を読んだ経験から学んだことですが、コードを最適化できないほどに最適化したり、チームで作業したり、作業しているときでも、非常に高速で非常に複雑な問題の解決策を思いついたりすることは望ましくありません。あなた自身で、しばらくしてあなたの賢い解決策を理解する必要があります。 私の質問は、再帰は同じように扱われるべきですか？平均的なプログラマーは再帰を簡単に理解できるので、再帰を免責して使用すべきですか、それとも平均的なプログラマーは再帰をあまりよく理解せず、チーム全体の生産性のために再帰から離れるべきですか？ 「再帰を理解していないプログラマーは一粒の価値がないので、心配しないでください」という簡単な答えがあることは知っていますが、皆さんが実際に体験したい経験があるかどうか疑問に思っていました私が述べたばかりの意見よりも問題を明らかにするであろう共有。

8 maintenance  teamwork  recursion 

これには専門用語があったことは知っています。それが何だったか思い出せない。 タイトルを明確にする必要がある場合、ここに私が意味します。これが古いコードの場合： Result foobar(Param1,Param2,Param3) { code that does abc code that does xyz code that does asdf more code that does something } そしてそれは次のように変更されます： SomeResult do_xyz(SomeParams) { code that does xyz } Result foobar() { code that does abc do_xyz(args); code that does asdf more code that does something }

8 terminology  refactoring  maintenance  technique 

私は大規模なコンピューターサイエンスの学生で、現在、大規模なエンタープライズWebアプリケーションを作成およびサポートしている会社の就職年にいます。現実の世界でソフトウェアがどのように生産されるかを体験した経験を愛しており、既存の機能を維持および拡張するだけでなく、製品の完全に新しい機能を開発する機会を提供する会社を見つけることができてとても幸運です。 とはいえ、これが正しく開発するための完璧な例になる可能性は非常に低いと私は非常に意識しています。実際、それとはかけ離れています。ここでの経験から多くのことを学んでいるように感じます。間違ったことを学んだり、道を進むのが難しいかもしれない同僚から悪い習慣を身につけたりしたくありません。ほとんどの場合、良い点と悪い点を簡単に区別できます。たとえば、ここでの単体テストのカバレッジは、さまざまな理由で事実上存在しません（ほとんどの場合、1つまたは2つの有効なポイントが混じった不十分な言い訳）。しかし最近は、よくわからないことが定期的に発生していることに気づきました。 新しいプロジェクトを始めるときはいつでも、当然、拡張、変更、または削除する必要がある関連コードを見つける必要があります。ほとんどの場合、アプリケーションの最も一般的に使用されるセクション内にないものは、コードベース内で見つけるのに時間がかかります。コードのセクションをよく知っている1人または2人の技術リーダーがいますが、彼らは時々困惑し、必要なものを探すのに長い時間を費やす必要があるか、最近コードのその部分を編集している人に頼る必要があります（誰か）助けを求めて。長い時間を言うとき、私は時間（通常）を意味するわけではありませんが、システムに漠然と精通している誰にとっても、良いコードベースは最低でも数分以内の任意のポイントにナビゲートできるように思えます。 だから、私の質問。上記の問題は、不十分な構造のコードが原因ですか？あるいは、開発者がコードベースについて十分な知識を持っていないためでしょうか？または、大規模なアプリケーションでは、ファイル構造を明確に保つためにどれだけの労力がかかるかに関係なく、それは単に避けられないのでしょうか？ または、確かに...私は本当に重要ではないトピックに私の時間を無駄にしていますか？

8 maintenance  maintainability  code-organization