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

以下の例は完全に人為的であり、その唯一の目的は私のポイントを理解することです。 SQLテーブルがあるとします： CREATE TABLE rectangles ( width int, height int ); ドメインクラス： public class Rectangle { private int width; private int height; /* My business logic */ public int area() { return width * height; } } ここで、データベース内のすべての長方形の合計面積をユーザーに表示する必要があると仮定します。テーブルのすべての行をフェッチし、それらをオブジェクトに変換して、それらを反復処理することで、それを実現できます。しかし、これはばかげているように見えます。なぜなら、テーブルにはたくさんの長方形があるからです。 だから私はこれをします： SELECT sum(r.width * r.height) FROM rectangles r これは簡単で高速で、データベースの長所を利用します。ただし、ドメインクラスでも同じ計算を行うため、重複したロジックが導入されます。 もちろん、この例では、ロジックの複製は致命的ではありません。ただし、他のドメインクラスでも同じ問題に直面します。これはより複雑です。

21 architecture  maintainability 

私は強力なオブジェクト指向のバックグラウンドから来ており、コードはJavaで書かれていますが、以前よりも優れたオブジェクト指向設計にあまり重点を置いていない組織で働き始めました。私は「あまりにも多くの抽象化」を導入し、代わりに常に行われている方法をコーディングする必要があると言われました。これはJavaの手続き型です。 TDDもここではあまり実践されていませんが、テスト可能なコードが必要です。大きな「神クラス」の静的プライベートメソッドにビジネスロジックを埋め込むことは（このチームの標準と思われます）、あまりテストできません。 私は自分の動機を同僚に明確に伝えることに苦労しています。OOとTDDを使用するとコードのメンテナンスが容易になることを同僚に納得させる方法について、誰かアドバイスがありますか？ 技術的負債に関するこの質問は私の質問に関連しています。ただし、他の問題がカバーする事実の後に返済するのではなく、そもそも借金の発生を回避しようとしています。

21 java  object-oriented  teamwork  communication  maintainability 

あなたが会社で働いていて、あなたがしていることは彼らのためにソフトウェアを開発しているとしましょう。あなたは全体像を知らないか、わずかかもしれません。あなたが持っているのは、問題追跡システムを介して割り当てられたタスクです。タスクが与えられ、タスクがそれらを説明するように動作させ、送り返します。2つの整数を追加するのと同じように： function add(a,b){return a + b;} しかし、後でプロジェクトが進むにつれて、addより複雑になるにつれて、パラメーターを追加して値を返す関数だけでなく、何らかのアーキテクチャが必要になっていることに気付くでしょう。しかし、あなたはそれを知りませんでした。そもそも、彼らが必要とするのはその単純なことだけでしたadd。addがそれほど複雑になるとは思わなかった。 プロジェクトはより多くの機能を備えて進行しますが、そもそもこれは期待していなかった機能です。そして最後には、既存のコードを壊したり書き換えたりすることを避けるために、ハッキングを積み重ね続け、関数のレイヤーを重ねます。 これらの状況にどのように対処しますか？「最低開発者」としての技術的負債とどのように戦いますか？ 明確化： あなたは「実装者」であり、階層の最下位です。 問題は見えますが、問題については発言権がありません。 技術的な負債を定量化したり、ツールを探したりするわけではありません。 3番目の「重複」について リファクタリングとリライト-あなたはあなたのタスクにロックされています。あなたは余分に行うために支払われていません。 アーキテクチャの概要-システム全体は知っていますが、アーキテクチャについてはわかりません。 コードフリーズ-電話ではありません。あなたは管理者ではありません。 モジュール化-アーキテクチャのアイデアはありません。モジュールは要件の変化に応じて変化します。 自動テスト-なし。

20 architecture  software  scalability  maintainability  technical-debt 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 保守性は、専門的なソフトウェア開発の主要な問題です。実際、メンテナンスは、プロジェクトのリリースから基本的に終わりまで続くため、ほとんどの場合、ソフトウェアライフサイクルの最も長い部分です。 さらに、メンテナンス中のプロジェクトは、プロジェクトの総数の大部分を占めています。http://www.vlegaci.com/298/interesting-statistics-%E2%80%93-numbers-of-programmers-in-maintenance-vs-development/によると、メンテナンス中のプロジェクトの割合は約2です/ 3。 私は最近この質問に出くわしました。彼の仕事は主にメンテナンスに関するものであることに気付いた男はかなり驚いているようです。それから、フランスのソフトウェア開発専門家コミュニティ（http://www.developpez.com/）のメインサイトでディスカッション（フランス語）を開くことにしました。ディスカッションのタイトルは、「学生はプロのソフトウェア開発の現実に十分に訓練されていますか？」そして、主に保守性についてです。少なくともフランスでは、人々はその両方の面でメンテナンスに直面する準備が十分に整っていないことが指摘されました。 既存のコードを維持する 保守可能なコードを作成する ここでの私の質問は、この議論と同じであり、保守性を教える良い方法を見つけることを目指しています。 保守性をどのように教えることができますか？ どのような運動を提案しますか？ 保守性に関して十分な訓練を受けている場合、どのような種類のコースを受講しましたか？ [編集]いくつかの誤解の後、私の質問を明確にしなければならないと思います。プロジェクトリーダーおよびソフトウェア開発者として、私はしばしば研修生または卒業したばかりの学生と仕事をしています。私はかつて自分自身を卒業したばかりでした。問題は、通常、プロジェクトの保守性を高めるSOLIDなどの原則に学生が慣れていないことです。私たちはしばしばプロジェクトを発展させる重要な困難を抱えることになります（保守性が低い）。私がここで探しているのは、保守性の重要性と、この特定の点に関してより良いコードを作成する方法に関する成功した教育の具体的な学術的な例です。または生徒の訓練方法を改善するための提案。

18 programming-practices  education  maintenance  maintainability 

私のチームの開発者の1人は、メソッドの署名のEVERYパラメーターにjavadocコメントを書く必要があると考えています。私はこれが必要だとは思わないし、実際、それは有害でさえあると思う。 まず、パラメーター名は説明的で自己文書化されるべきだと思います。パラメータの目的がすぐに分からない場合は、おそらく間違っています。ただし、パラメータの目的が不明な場合があることは理解しています。そのため、その場合は、パラメータを説明するjavadocコメントを作成する必要があります。 しかし、すべてのパラメーターに対してこれを行う必要はないと思います。パラメータの目的がすでに明らかな場合、javadocコメントは冗長です。あなた自身のために余分な仕事を作成しているだけです。さらに、コードを保守する必要がある人のために余分な作業を作成しています。メソッドは時間とともに変化し、コメントを維持することはコードを維持することとほぼ同じくらい重要です。「XはYをZの理由で行う」などのコメントを何回見て、そのコメントが古いことを確認しましたが、実際にはメソッドはXパラメーターさえも取りません。人々はコメントを更新するのを忘れているので、それは常に起こります。誤解を招くコメントは、まったくコメントしないよりも有害であると主張します。したがって、過剰なコメントの危険性があります。不要なドキュメントを作成することにより、 しかし、私は自分のチームの他の開発者を尊重し、おそらく彼が正しいと私は間違っていることを受け入れます。だからこそ、仲間の開発者に質問を投げかけます。実際、すべてのパラメーターにjavadocコメントを書く必要がありますか？ここでは、コードは会社の内部にあり、外部の第三者によって消費されることはないと想定しています。

17 java  documentation  source-code  comments  maintainability 

GUIアプリのUIユニットテストを作成してみましたが、最初に作成したときにはうまく機能しますが、設計が変更されるたびに（つまり、非常に頻繁に）壊れるという問題に直面しています。GUIの保守可能な単体テストを作成するためのガイドラインを見つけるのに苦労しています。 今のところ、私が発見したことの1つは、「このコンポーネントは入力データをどこかに表示する必要がある」というテストが適切であることです（HTMLでは非常に簡単です）。通常、コンポーネントの特定の部分の特定の状態を確認するテストは脆弱です。クリック-クリック-クリック-期待のようなテストは、ユーザーの行動と基礎となるビジネスロジック（最も重要な部分）を追跡しようとするため、通常は脆弱です。良いテストを書くにはどうすればいいですか？ もっと正確に言うと、UIで何をテストできるかについて、正確なテスト方法ではなく、いくつかのパターンを知りたいです。命名規則と固定識別子は優れていますが、コアの問題、つまりGUIが大きく変わるという問題は解決しません。変化する可能性が最も低い動作をテストしたいと思います。テストする正しいものを見つける方法は？

16 unit-testing  language-agnostic  user-interface  maintainability 

バックグラウンド 現在進行中のC＃プロジェクトに取り組んでいます。私はC＃プログラマではなく、主にC ++プログラマです。そのため、基本的に簡単でリファクタリングするタスクが割り当てられました。 コードはめちゃくちゃです。それは巨大なプロジェクトです。お客様が新機能とバグ修正を含む頻繁なリリースを要求したため、他のすべての開発者はコーディング中にブルートフォースアプローチをとることを余儀なくされました。コードはメンテナンスが非常に難しく、他のすべての開発者はそれに同意します。 私は彼らがそれを正しくしたかどうかを議論するためにここにいるのではありません。私はリファクタリングしているので、リファクタリングされたコードが複雑に思えるので、正しい方法でそれをやっているかどうか疑問に思っています！これが簡単な例としての私の仕事です。 問題 6つのクラスがありますA、B、C、D、EとF。すべてのクラスには関数がありますExecJob()。6つの実装はすべて非常に似ています。基本的に、最初A::ExecJob()は書かれました。次に、のB::ExecJob()copy-paste-modificationによって実装されたわずかに異なるバージョンが必要でしたA::ExecJob()。別のわずかに異なるバージョンが必要になったとき、C::ExecJob()書かれたなど。6つの実装すべてに共通のコードがあり、次にいくつかの異なるコード行があり、さらにいくつかの共通コードがあります。実装の簡単な例を次に示します。 A::ExecJob() { S1; S2; S3; S4; S5; } B::ExecJob() { S1; S3; S4; S5; } C::ExecJob() { S1; S3; S4; } SNまったく同じ文のグループはどこにありますか。 それらを共通にするために、別のクラスを作成し、関数内の共通コードを移動しました。パラメータを使用して、実行するステートメントのグループを制御します。 Base::CommonTask(param) { S1; if (param.s2) S2; S3; S4; if (param.s5) S5; } A::ExecJob() // A inherits Base { param.s2 = …

16 self-improvement  refactoring  maintainability 

私は自分自身をプログラミング言語愛好家だと考えています。悪いコード、特に自分のコードを見つけると、理解しにくく、変更しにくく、テストするのが難しくなります。 私の同僚はよく知りません、または気にしません。自分でコードの品質を上げることができないことに不満を感じています。 コードの品質と保守性が自分の基準に達していないときに不満を感じるのは普通ですか？もしそうなら、どのように対処しますか？

12 code-quality  maintainability 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 6年前に閉鎖されました。 私はソースコードにコメントし、ソフトウェア製品を文書化することを提唱しています。私の個人的な経験と観察から、厳密にコメントされているソースコードに取り組んでいると、ソフトウェアの成長や保守が必要になったときにさまざまな方法で役立ったことがわかります。 しかし、コメントすることは最終的に価値がない、またはその価値には疑問があると言う別のキャンプがあります。コメントなしのコーディングの支持者は次のように主張しています。 コードの一部が適切に記述されている場合、それは自明であり、したがってコメントする必要はありません コードが自明でない場合は、コメントを必要としないように、リファクタリングして自明にする テストスイートはライブドキュメントです 時間が経つにつれて、コードとコメントが同期しなくなり、別の頭痛の種になります アジャイルは、ドキュメントの山よりも作業コードの方が重要だと言っているので、コメントを書くことは安全に無視できます。 私にとってこれは単なる教義です。繰り返しになりますが、私の個人的な観察では、賢明で経験豊富な開発者のチームによって作成されたソフトウェアは、最終的に自明ではないかなりの量のコードになります。 繰り返しますが、Java API、Cocoa API、Android APIなどは、高品質のドキュメントを作成して維持したい場合にそれが可能であることを示しています。 これらすべてを言ったが、個人的な信念に基づいたドキュメントの長所と短所およびソースコードへのコメントについての会話は、通常うまく終了せず、満足のいく結論につながらない。 そのため、ソフトウェアドキュメントの影響、特にソースコードのコメント、品質と保守性、およびチームの生産性への影響に関する学術論文と実証研究を探しています。 そのような記事につまずいたことがありますか、もしあればその結果はどうでしたか？

11 productivity  documentation  code-quality  maintainability  engineering 

どちらがより保守性が高いと考えられますか？ if (a == b) c = true; else c = false; または c = (a == b); Code Completeで調べてみましたが、答えが見つかりません。 最初のほうが読みやすいと思います（文字通り大声で読むことができます）。2番目の方法は確かに理にかなっており、コードを削減しますが、C＃開発者にとってそれが保守可能であるかどうかはわかりません（たとえば、このイディオムはPythonでもっと見られると思います）。

11 .net  code-quality  readability  maintainability  clean-code 

アプリケーションに新しい機能を追加することを目的とする小さなプロジェクトを考えると、導入された変更は、特定の領域でこれらを更新することを含む既存のコードに影響を与えます。実装中に、更新されたこれらのコードの一部にリファクタリングの候補があることがわかりました。 これは、影響を受けるコンポーネントのリグレッションテストを必要とするリファクタリングの適切な時間ですか（したがって、元々プロジェクトの一部ではないスコープを導入している可能性があります）？または、機能を延期し、機能を完成させ、おそらくリファクタリングのための別個のプロジェクトを用意する必要があります（ただし、ビジネスユーザーは、コードの保守性を重視しない限り、機能を追加しないプロジェクトを完全に後援できないため、少しためらっています...）？

11 testing  refactoring  decisions  maintainability  scope 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 別の開発者から引き継いだプログラムで、次の条件に遭遇しました。 if (obj.Performance <= LOW_PERFORMANCE) { obj.NeedsChange = true; } else { obj.NeedsChange = false; } このコードは冗長で見苦しいと思うので、比較に基づいて単純なブール割り当てと考えていたものに変更しました。 obj.NeedsChange = obj.Performance <= LOW_PERFORMANCE; これを見ると、私のコードをレビューしている人が、私の変更は機能的には正しいものの、他の人がそれを見て混乱させるかもしれないとコメントしました。彼は、三項演算子を使用すると、この割り当てがより明確になると信じていますが、私はより冗長なコードを追加するのは好きではありません： obj.NeedsChange = (obj.Performance <= LOW_PERFORMANCE) ? true : false; 彼の推論は、他の開発者があなたがやったことを正確に止めて困惑させなければならないなら、最も簡潔な方法で何かをすることは価値がないということです。 ここでの本当の問題は、ブール値に値を割り当てるこれら3つの方法のうち、どれがobj.NeedsChange最も明確で保守しやすいのかということです。

10 clean-code  maintainability  boolean 

この場合はNetbeansで作成されたプロジェクトを追加したいのですが、この質問はほとんどのIDEで一般的です。それは単に、リポジトリに何を含めるべきかということです。たとえば、Netbeansはnbprojectフォルダーを作成し、eclipseは.settingsフォルダーを作成します。これらをリポジトリに含めた場合、プロジェクト固有の設定を含めるか含めないことの利点/欠点は何ですか。 この場合、それは個人的なプロジェクトなので、他の人がプロジェクトに取り掛かることはないと思いますが、最小限のプロジェクト設定を追加して、プロジェクト自体が別のマシンで簡単に作業を開始できるようにするとよいでしょう。

10 programming-practices  git  project  maintainability 

アプリケーションフレームワークで、パフォーマンスへの影響を無視できる場合（最大で1秒あたり10〜20イベント）、 モジュール間の通信の優先媒体として使用するのに、より保守的で柔軟なものは何ですか？イベントまたは先物/プロミス/モナド？ イベント（pub / sub、メディエーター）は疎結合を許可するため、より保守しやすいアプリであるとよく言われます...私の経験ではこれが否定されます。20以上のイベントがあると、デバッグが困難になり、リファクタリングも行われます-誰が、いつ、なぜ使用するのかを確認するのは非常に難しいためです。 約束（私はJavascriptでコーディングしています）は、イベントよりも醜くて気難しいものです。ただし、関数呼び出し間の接続を明確に確認できるため、アプリケーションロジックがより簡単になります。私が恐れていること。ただし、Promiseはそれらとのより強い結合をもたらすでしょう... PS：答えはJSに基づく必要はありません。他の関数型言語の経験は大歓迎です。

10 architecture  maintainability  async  event-programming  monad 

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

10 maintenance  maintainability