タグ付けされた質問 「technical-debt」

技術的負債は、コードベース内の貧弱なソフトウェアアーキテクチャとソフトウェア開発の最終的な結果の隠喩です。

16
プロジェクトはほぼ完了しましたが、手続き型のスパゲッティコードです。書き直しますか、それとも出荷しようとしますか？[閉まっている]
私は初心者のWeb開発者です（1年の経験）。 卒業してから数週間後、私は所有者があまり技術者ではない会社のためにWebアプリケーションを構築する仕事を提供されました。彼は、アイデアの盗難、サービス会社が請求する高い開発コストを避け、長期的にプロジェクトを維持するために若い人をオンボードで信頼できるようにするために私を雇いました）。 当時の私は生意気で、コンピューターサイエンスの学位を取得していたので、私は何でも構築できると考えて申し出を受け入れました。 私はショットを呼んでいました。いくつかの調査の後、私はPHPに落ち着き、オブジェクトなしの単純なPHPから始めました。2か月後、すべてが面倒になり、進歩するのは困難でした。Webアプリケーションは巨大です。そこで、私の生活を楽にするMVCフレームワークをチェックアウトすることにしました。そこで私は、PHPコミュニティのクールな子供、Laravelに出会いました。私はそれを愛し、学びやすく、すぐにコーディングを始めました。私のコードはよりきれいで、より組織的に見えました。とてもよかったです。 しかし、やはりWebアプリケーションは巨大でした。会社は最初のバージョンを提供するように私にプレッシャーをかけていました。 Laravelは一緒に仕事をするのが面白かったので、そもそもこの業界を選んだ理由を思い出しました。 だから私は夜に小さなプロジェクトに取り組み始め、方法論とベストプラクティスについて読みました。私はOOPに戻り、オブジェクト指向の設計と分析に移り、ボブおじさんの本Clean Codeを読みました。 これは私が本当に何も知らなかったことに気づきました。ソフトウェアを正しく構築する方法を知りませんでした。しかし、この時点では手遅れであり、今ではほぼ完了です。私のコードはまったくクリーンではなく、スパゲッティコード、バグを修正するための本当に苦痛、すべてのロジックはコントローラーにあり、オブジェクト指向のデザインはほとんどありません。 私は、プロジェクト全体を書き直さなければならないと固執している。しかし、私はそれを行うことはできません...彼らはそれがいつ完了するのかを尋ね続けます。 このコードがサーバーに展開されることは想像できません。さらに、コードの効率性とWebアプリケーションのパフォーマンスについてはまだ何も知りません。 一方では、会社は製品を待っていて、もう待つことができません。一方、実際のコードでこれ以上進むことはできません。仕上げて、まとめて展開することはできましたが、神は、人々がそれを使い始めたときに何が起こるかを知っています。 書き直しますか、それとも出荷しようとしますか、それとも見逃した別のオプションがありますか？
17
経営者に技術的負債を処理するよう説得するにはどうすればよいですか？
これは、開発者と仕事をするときによく自問する質問です。私はこれまで4つの会社で働いてきましたが、コードをクリーンに保ち、ソフトウェアアプリの将来の進歩を妨げる技術的負債に対処することに注意が払われていないことに気付きました。たとえば、最初に勤務した会社は、MySQLのようなものを使用するのではなく、ゼロからデータベースを作成し、アプリケーションをリファクタリングまたは拡張するときにチームのために地獄を作りました。マネージャーが予測について議論するとき、私はいつもマネージャーに正直で明確にしようとしましたが、経営陣はすでにあるものを修正することに興味がないようで、チームの士気に与える影響を見るのは恐ろしいです。 この問題に取り組む最善の方法について、あなたはどう思いますか？私が見たのは、荷物をまとめて帰る人たちです。同社はその後、開発者が出入りしてコードを悪化させる回転ドアになります。これを経営者にどのように伝えて、技術的負債の整理に興味を持たせますか？
19
すぐにユーザーに見えない改善に価値が見られない管理に対処する
スケジュールのプレッシャーを理解できます。ユーザーは会社の生命線であるため、ユーザーを喜ばせたいと考えています。ただし、特定の変更により、今後すべてが簡単になることも事実です。残念ながら、私の組織の経営陣はそのような変化に対して本能的な抵抗を持ち、この抵抗は非常に強いため、長期的な改善の妨げになります。 たとえば、Appleは最近、iOSプログラム用の自動参照カウントを導入しました。これは、以前は使用する必要があった手動の保持/解放呼び出しを大幅に改善したものです。コードは記述しやすく、保守しやすいです。切り替え自体がクラッシュを引き起こす可能性があります。しかし、それらが解決されると、ランダムな奇妙なクラッシュの数は減少する可能性があります。 最近、上司に、自動参照カウントに切り替えたいと言いました。彼の応答は、目に見える改善に集中したかったということでした。この反応は、彼の上からの圧力、そしておそらくCEOからの圧力によって引き起こされた可能性があります。 同様の例がたくさんあります。一般的なスレッドは、何かを修正する必要があるが、修正の短期的な費用は短期的な利益を上回り、「短期」は「今後数週間以内」と定義されます。 状況をどのように処理すればよいですか？ 編集：回答いただきありがとうございます。来てください。私の状況に関連しているため、マネージャーとCEOはどちらもプログラマーであることを明確にする必要があります。どうやら彼らのプログラマー側は他の圧力に圧倒されているようです。
11
DRYはソフトウェアプロジェクト管理の敵ですか？
ソフトウェア開発の最も基本的で広く受け入れられている原則の1つはDRYです（繰り返してはいけません）。また、ほとんどのソフトウェアプロジェクトには何らかの管理が必要であることも明らかです。 では、管理が簡単なタスク（見積もり、スケジュール、制御）は何ですか？正しい反復タスク、DRYに従って回避すべきタスク。 そのため、プロジェクト管理の観点からは、既存のコードを100回コピーしてタスクを解決し、必要に応じて各コピーに若干の修正を加えることは素晴らしいことです。常に、あなたが行った仕事の量と残っている量を正確に知っています。すべてのマネージャーはあなたを愛します。 代わりに、DRYの原則を適用して、重複するコードを多かれ少なかれ除去する抽象化を見つけようとすると、状況は異なります。通常、多くの可能性があります、あなたは決定を下し、研究を行い、創造的でなければなりません。短い時間でより良いソリューションを思いつくかもしれませんが、失敗することもあります。ほとんどの場合、どれだけの作業が残っているかを実際に言うことはできません。あなたはプロジェクトマネージャーにとって最悪の悪夢です。 もちろん大げさですが、明らかにジレンマがあります。私の質問は次のとおりです。開発者がDRYをやりすぎているかどうかを判断する基準は何ですか？どうすれば良い妥協点を見つけることができますか？または、妥協を見つけるだけでなく、このジレンマを完全に克服する方法はありますか？ 注：この質問は、前の質問「ソフトウェア開発における日常作業の量と推定への影響」と同じ考えに基づいていますが、それが私のポイントをより明確にするので、繰り返して申し訳ありません:)。
11
プロジェクトに存在する技術的負債の量をどのように定量化できますか？
ある種のコードメトリックとして、コードベースの技術的負債に数字を付ける何らかのツールがあるかどうか、誰もが知っていますか？そうでない場合、誰かがアルゴリズムまたはヒューリスティックのセットを知っていますか？ これまでのところそれらのいずれも存在しない場合、私はそのようなことから始める方法のアイデアに興味があります。つまり、メソッド、クラス、名前空間、アセンブリなどによって発生した技術的負債をどのように定量化できますか。 私はC＃コードベースの分析と評価に最も関心がありますが、特に概念が言語を超越している場合は、他の言語でも気軽に声をかけてください。
21
リファクタリングを非技術者にどのように説明しますか？
リファクタリング（および技術的負債）を非技術者（通常はPHBまたは顧客）にどのように説明しますか？（「なんと、目に見える違いなくあなたの仕事に1か月かかるでしょうか！」） 更新これまでのすべての回答に感謝します。このリストは、適切な人を指すことができるいくつかの有用な類推を提供すると思います（PHBへの参照を編集するのは賢明かもしれません！）
7
リファクタリングの潜在的な価値を測定する方法
技術的な負債を抱える古い大規模なプロジェクトでは、リファクタリングコードの利点をどのように確実に推定または測定できますか？ たとえば、古い言語で記述されたソフトウェアスタックソリューション内のコンポーネントと、新しい言語で記述された後のコンポーネントがあるとします。このソリューションには、開発チームによって常に新しい機能とバグ修正が追加されています。 開発者は、既存の古い言語コンポーネントを新しいバージョンに置き換えることは「良いこと」だと提案します。ただし、この作業によって追加の機能は追加されず、x開発日数かかります。 営業担当者は、「すばらしい新機能」を追加することを提案しています。会社は数式を使用して提案の価値を測定します。すなわち。x dev-daysの作業コストで、t年間でFポンドを獲得します。 どうすれば会社はリファクタリングの提案に意味のあるコストをかけることができますか？そして、どのような状況下でそれが会社にとって最も収益性の高いオプションになる可能性がありますか？
6
技術的負債を処理することでどのような見返りがありますか？
技術的負債に関するこの記事には、次のような優れた点があります。 「技術的な問題」に取り組むことは、ストーリーによって推進されるときに最も効果的です。コードベースはおそらくどこでも作業を必要としますが、ユーザーに面した理由でコードが作業される場所でのみペイオフが受け取られます。ストーリーがなかなか難しい領域を通過しない場合、その作業はほとんど無駄になります。 したがって、私はいつものように（しかしおそらくそれよりも少ない）物語を取り上げ、あなたが見つけたよりもキャンプ場を去るという「ボーイスカウトのルール」に従うアプローチを好む。言い換えれば、ストーリーが私たちを導くところはどこでも、より多くのテストを書きましょう、より積極的にリファクタリングしましょう。 このアプローチには、少なくとも次の利点があります。 「賢明な」ストーリーの流れを維持します。 チームのすべての才能からの支援を提供します。 チーム全体がコードをクリーンに保つ方法を学習できるようにします。 改善が必要な場所に正確に焦点を合わせます。 「必要な」改善を無駄にしない; コードの品質が長期的な生産性に非常に大きな影響を与えるのを見てきましたので、技術的な負債を処理する必要があると考えています。上記の投稿は理にかなっていると思いますが、最後の2つのポイントについてはよくわかりません。たとえユーザーのストーリーに関係していなくても、技術的な負債を取り除くことで得られるメリットの実際の経験を見つけることに興味があります。 コードベースを整理し、技術的な負債をなくすことで、どのようなプラスのメリットがありましたか？仕事を成し遂げるためにどのような方法を使用しましたか？
2
歴史的に成長したソフトウェアに名前付きのアンチパターンはありますか？[閉まっている]
複数の開発者がシステムに新しい機能を追加しただけで、アーキテクチャ全体を実際に監視したり、リファクタリングを実行したりしない、歴史的に成長したソフトウェアシステムを説明するアンチパターンはありますか？ これは、管理者/顧客が絶えず新しい機能を要求し、誰も何もリファクタリングせず、他の開発者が以前に行ったことに追加するだけの場合に起こると思います。 開発者がソフトウェアシステムに圧倒されており、現在どのように機能するかを実際に理解していないため、コードをリファクタリングして変更するのではなく、最後にコードを追加/接着するだけの場合もあります。 そのため、時間の経過とともに、システムの保守がますます難しくなっています。 （これらの種類のアンチパターンの写真は、プログラミング全体に誰もがこれをより明確にするためにありますか？全体的なデザインを考えずに機能を追加するだけで構築された車のように。後方に移動しながらトレーラーを牽引し、エンジニアが車両の前面に牽引バーを溶接するだけです。作業は完了しました。しかし、カウルはもう開きません。）
5
「最低の開発者」として技術的負債と戦う？
あなたが会社で働いていて、あなたがしていることは彼らのためにソフトウェアを開発しているとしましょう。あなたは全体像を知らないか、わずかかもしれません。あなたが持っているのは、問題追跡システムを介して割り当てられたタスクです。タスクが与えられ、タスクがそれらを説明するように動作させ、送り返します。2つの整数を追加するのと同じように： function add(a,b){return a + b;} しかし、後でプロジェクトが進むにつれて、addより複雑になるにつれて、パラメーターを追加して値を返す関数だけでなく、何らかのアーキテクチャが必要になっていることに気付くでしょう。しかし、あなたはそれを知りませんでした。そもそも、彼らが必要とするのはその単純なことだけでしたadd。addがそれほど複雑になるとは思わなかった。 プロジェクトはより多くの機能を備えて進行しますが、そもそもこれは期待していなかった機能です。そして最後には、既存のコードを壊したり書き換えたりすることを避けるために、ハッキングを積み重ね続け、関数のレイヤーを重ねます。 これらの状況にどのように対処しますか？「最低開発者」としての技術的負債とどのように戦いますか？ 明確化： あなたは「実装者」であり、階層の最下位です。 問題は見えますが、問題については発言権がありません。 技術的な負債を定量化したり、ツールを探したりするわけではありません。 3番目の「重複」について リファクタリングとリライト-あなたはあなたのタスクにロックされています。あなたは余分に行うために支払われていません。 アーキテクチャの概要-システム全体は知っていますが、アーキテクチャについてはわかりません。 コードフリーズ-電話ではありません。あなたは管理者ではありません。 モジュール化-アーキテクチャのアイデアはありません。モジュールは要件の変化に応じて変化します。 自動テスト-なし。
6
「カスタムソフトウェア会社」は技術的な負債をどのように処理しますか？
この質問はして移行され、それがソフトウェア工学スタック所に答えることができるので、スタックオーバーフローから。 7年前に移行され ました。 「カスタムソフトウェア会社」とは何ですか？ 「カスタムソフトウェア会社」とは、主にカスタムの1回限りのソフトウェアを構築することで収益を得ている会社を意味します。例は、代理店またはミドルウェア企業、またはRedifyのような請負業者/コンサルタントです。 「カスタムソフトウェア会社」の反対は何ですか？ 上記のビジネスモデルの反対は、展開可能なデスクトップ/モバイルアプリであろうとSaaSソフトウェアであろうと、長期的な製品に焦点を当てている企業です。 技術的負債を積み上げる確実な方法： 私は、一連のSaaS製品に集中しようとする会社で働いています。ただし、特定の制約のために、特定のクライアントの意志に屈することがあり、そのクライアントにのみ使用できるカスタムソフトウェアのビルドを終了します。 これは技術的な負債を負う確実な方法です。これで、コア製品に何も追加しない、維持するソフトウェアが少しあります。 カスタム作業が技術的な負債を増やす確実な方法である場合、代理店はそれをどのように処理しますか？ それで私は考えました。ビジネスモデルの中心としてコア製品を持っていない企業は、常にカスタムソフトウェア作業を行っています。彼らはどのように技術的負債の概念に対処しますか？どうして彼らを技術的な破産に追い込まないのですか？
4
技術的な負債は、機能または雑用（またはバグ）としてスケジュールする必要がありますか？
私のPivotal Trackerボードにいくつかの技術的負債に対処するユーザーストーリーをいくつか追加しました。それらを機能（速度レベルを維持）または雑用/バグ（速度を低下）として考慮する必要がありますか？どちらか一方を一貫してやったとしても、長期的には何の違いも生じないことは理解していますが、技術的な負債のストーリーを追加するたびに判断しなければなりません。 いくつかの考え： それらは実際にはバグではなく、何も壊しません ユーザーに影響を与えないのは低レベルの実装であるため、ユーザーは何も要求していませんが、長期的な開発を容易にします あなたもユーザに付加価値を話、などの機能を定義した場合）彼らは、ユーザーが行うすべての直接的な利益が、その後B）は表示されませんしない限り、彼らはその可能な将来の開発/メンテナンスを行うために行い、追加値を、ちょうど今ではない 私は実際に作業を行うかどうか、またはいつスケジュールするかを決定していません。プロジェクト管理ツールで技術的負債と呼ぶべきものとその理由を知るだけです。
6
恐ろしく設計されたデータベースの上に良いコードを書く希望はありますか？
これが私の苦境です。私が最近継承したいくつかのプログラムの1つは、バックエンドに恐ろしいデータベースで構築されています。尊敬されているクリエイターは、どうやらリレーショナルコンセプトを高く評価していなかったようです。一意のクライアントIDとして名前が付けられた、すべてのクライアントのテーブル。83の暗号化された名前のフィールド。コードはすべて手続き型であり、多数のインラインSQLステートメントが連結されています。 同じデータベースから実行される重要な補助アプリケーションが提供されなかったため、私はそれをゼロから再作成するという任務を負っていました。私は唯一の開発者であり、少なくとも半分の時間は運用に費やされているため、私の第一の責任でもありません。これから30日間の避けられない期限が設定されます。 私は経験が浅いにも関わらず、このデータベースと既存のアプリケーションを以前よりもはるかに良く設計できたと確信していますが、データベースを変更し、既存のアプリケーションを調整し、私がそうしなかったことを確認するのは現実的ではないと思います追加のアプリケーションをこれほど迅速に作成する必要がある間、何も壊しません。 だから私はひどいデータベースにこだわっていると仮定しましょう。このような悪い構造で作業する必要がある場合、それに準拠するものを書くと、何かが完全に壊れたり新しい機能が必要になるまで技術的な負債が山積みになってしまいますか？どうすればこの状況にアプローチし、うまくいけば機能するアプリケーション以外に何か良いものを得ることができますか？ 編集：誰かが興味を持っている場合、この恐ろしいデータベースとそれを実行したアプリケーションを廃棄することになりました。補助的なアプリケーションの作成を外部委託しました（私はこの設定には関与していませんでした）が最終的に2人の異なる請負業者に委託されました。私は、今日もまだ使用されている3日間で、部分的に機能する恐ろしい修正のハックを急いで行かなければならなくなりました。
9
全体として：レガシーシステムをどのように維持しますか？[閉まっている]
現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または詳細な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 8年前に閉鎖されました。 ニューヨーク-超高層ビルを震わせた爆発により、83年前の蒸気パイプは、ニューヨークや他の米国の都市の下にある何マイルものチューブ、ワイヤー、鉄が古くなり、危険なほど不安定になる可能性があるという強力なメッセージを送りました。 マンハッタンのバースト蒸気パイプに関する2007年7月のストーリー ソフトウェアの腐敗と技術的負債について聞いたことがあります。 そして、私たちは次のような人から聞いたことがあります： 「ボブおじさん」マーティン-「混乱させることの結果」について私たちに警告した人。 Michael C. Feathers- 「レガシーコードで効果的に作業する」ためのガイダンスをくれた人。 したがって、ソフトウェアエンジニアリングコミュニティはこれらの問題を認識しています。 しかし、私たちの社会全体は、これらの問題が稼働中のシステムやアプリケーションをどのように悩ませるのか理解していないように感じます。 Steve McConnellが指摘するように： ...金銭的負債とは異なり、技術的負債ははるかに目立たないため、人々はそれを無視する方が簡単です。 もしこれが真実であり、そうだと思うなら、政府や企業は手遅れになるまでハッカーに対する定期的な保守と強化を延期するのではないかと恐れています。[NYCや蒸気パイプによく似ています。] 私の質問： NYCや蒸気パイプに相当するソフトウェアを回避する方法はありますか？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.