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

一般的な応答が「jquery」などの包括的ステートメントである場合、「高度に最適化され、クロスブラウザーと互換性があるためjQueryを使用する必要がある」または「エンティティフレームワークはクールであり、モデルが自動的に処理されるのでクールです」などのアイデアをどのように販売できますか。十分に機能しない」または「エンティティが必要なのは、10で十分な場合、エンティティはテーブルに12列を取り込む」でしょうか。 私は、経験を通して開発した公理を信頼する傾向がある実用的な人です（目に見える減速があるまではパフォーマンスの問題ではありません）。他の極端が当てはまる特定の「カテゴリ」があるかどうかはわかりませんが、他に証明されない限り、またはここで通信を開始する場所まで、すべてがパフォーマンスの問題です。

10 communication  performance  maintainability 

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

9 maintenance  maintainability 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 5年前休業。 現在、基本的にUIのみを構築するメソッドをリファクタリングする方法について頭を悩ませています。 この方法は、1500行を超えるコード（LOC）であり、カウントされます。それは成長しました、これにどのように取り組むかという計画はありませんでした。あなたは可能性がある、このおなじみのを見つけます。 とにかく、これは基本的に、次のような少し大きな1つの大きなメソッドです。 . . . # null checks null_checks_bx = Box(True) null_checks_ck = CheckBox() null_checks_ck.set_text('Null checks throwing exceptions of type:') if 'doNullChecks' in options: null_checks_ck.set_active(options['doNullChecks']) else: null_checks_ck.set_active(True) # dict to sorted list: extract values from dict by list comprehension exceptions = sorted([exception.get_full_name() for exception in JavaTypes.exception_types]) …

8 python  refactoring  maintainability  methods  modules 

したがって、私は組み込みソフトウェア開発を行う会社で働いており、他のグループはさまざまな製品のソフトウェアのコア開発に焦点を合わせており、工場にある私の部門（別の地理的な場所にある）もソフトウェア開発に対処する必要があります、しかしすべての製品にまたがるので、製品のソフトウェアの問題が原因でラインがダウンした場合にも迅速に修正できます。 つまり、私たちはジェネラリストであり、他のグループは各製品に特化しています。 地理的に分散していると、コア開発に参加するのが少し難しくなります（まあ、それはそれほど難しいことではないのですが、リモートで協力するということになると、意図しない文化的/政治的な障壁があるかもしれません） ）。 だから、私たちは現在、火を消しているだけで、ややアイドル/サブ活用されているので（新しい部門であるか、それが理由かもしれません）、領域を検出することは、私たちにとって良い役割であると考えましたコードのリファクタリングと再設計の機会、および保守性とモジュール性の管理に関連する可能性のある他のすべての実装。他のグループは、時間がないため積極的な期限があり、コードの品質を損なうため、これに焦点を合わせていません（ソフトウェアプロジェクトの永遠の物語） 私のグループ/部門がこの役割を持つ管理職や他のグループによって公式に認識されることを望んでいるということです、そして私はこの問題のために私たちのグループの良い定義/アイデンティティを思いつくのに苦労しています。 だから私の質問は：この役割はすでに存在するものですか？または私はこのようなものを最初に作成したのですか？ 編集：つまり、すべてのリファクタリング作業を自分で行うのではなく、リファクタリングイニシアチブを推進するグループです。オープンソースコミュニティーとオープンソース製品のように、今考えてみると、

8 architecture  refactoring  maintainability  organization 

一般に、保守性インデックスは多くの要因に依存しています。たとえば、Visual Studioでは、循環的複雑度、継承の深さ、クラス結合、コード行に依存しています。これらの4つの値はできるだけ低くする必要があります。 同時に、コードメトリックツールでも、書籍でも、循環的複雑度（CC）とコード行（LC）のみの比較を見たことはありません。 そのような比率を計算することは意味がありますか？コードについてどのような情報が提供されますか？言い換えると、LCを下げるよりもLCを下げる方が良いでしょうか？ 私が気づくのは、小規模なプロジェクトの場合、CC / LCの比率が低い（1/2以下）ことです。つまり、LCは高く、CCは低くなります。大規模なプロジェクトでは、CC / LCはほとんどの場合thanより大きくなります。どうして？

8 complexity  maintainability  code-metrics  cyclomatic-complexity 

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

8 maintenance  maintainability  code-organization