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

私は数年前からプログラミングを行ってきましたが、C＃とJavaScriptに非常に慣れてきました。大規模なC＃およびJavaScriptプロジェクトがいくつかありますが、問題なくナビゲートできます。私は最近、PHPの経験がなくても作業するためにPHPとAngularJSプロジェクトを開始しました。 物事のPHP側の流れを追跡するのが難しくなりつつあります（JavaScript側は大きくなりますが、簡単に処理できます）。私が始めたときに犯した主要な設計ミスは山積みになり始め、今後の設計に影響を与えています。新しいものを実装するには、ますます時間がかかります。 私は締め切りが厳しく、良い、乾いた、固い、コードを書くのがますます難しくなっています。コードのチャンクをコピー/貼り付けして、設計時間が長くなるにつれてその動作にわずかな変化を加えることがより魅力的になっています。また、コンテキスト切り替えを行う必要があるときはいつでもコードベースに戻るのに時間がかかります（あるプロジェクトからこのプロジェクトに戻る）。このプロジェクトに戻るときはいつでも恐怖を感じます。 これを解決するためにどのような手順を実行できますか？上司は開発者ではなく、開発やソフトウェアのライフサイクルに精通していないため、時間がかかる可能性があることも正当化する必要があります。そのため、説明は通常より難しい場合があります。

14 php  javascript  web-applications  code-smell  technical-debt 

私は2か月前に6人の開発チームに参加しました。人々は素晴らしいです、すべてが良いです。しかし、私はますますアドホックな考え方を観察します。スタッフはすぐに修正されますが、将来の使いやすさを犠牲にして、テストはほとんどなく、2人の人が喜んで認めています。 これに対処するには？私は例を挙げてリードしたいと思いますが、時間は限られています-ものを設計し、実際に実装するのが好きです。しかし、私はアドホックな考え方が私に感染していることを恐れており、デザインとコードの明快さと単純さを追求するのではなく、それを確立するのは簡単ではありません部外者は分離することができます-スケジュールと管理のためだけに。

13 architecture  coding-style  management  technical-debt 

友達がいます"。はい、良いスタートですが、正直なところこれは私ではありません！ 基本的に、彼は今、約4年間のプロジェクトの成功に取り組んでいます、困難がある技術的負債が追いついたと、彼はそれがほとんど不可能製品サポートを停止するために見つけることだ（これを微調整をしていること）と、実際に上に移動本当の開発。 私はさまざまな提案をしました、あなたのすべての時間を記録し、チケットを作成し、電子メールなどに答えないなど。これに関する問題は、彼が何も「有用な」ことをしていないことを思い出させるだけのように見えることです。 技術的な負債は主に発生しました。なぜなら、最初の例では、ユーザーからのリクエストや電話を受け取り、すぐにそれらを実装することが製品にとって大きな利点だったからです。 私が知りたいのは、誰も彼がこのわだち掘れから抜け出す方法についての提案を持っていることです。その大部分は、ユーザーが何かを鳴らして期待することができないと思うように、ユーザーの認識を変えることですその場で行われます。 サポートの必要性とユーザーからの相対的なプレッシャーを考慮すると、実際の開発を計画することは非常に難しいと理解していますが、計画はより良いと言っています（上記参照）。

13 users  technical-debt  product-management 

私が働いているところに大きな問題があり、その名前は「カスタマイズ」です。私たちは、ITと会計部門は、以前にその古い（10年以上）ベンダーのソフトウェアシステム持って愛さカスタマイズすることを。このソフトウェアは非常にバグが多くなり始めました。その後、私はカスタマイズの大部分の後に雇われました。 システムで見つかったほとんどすべての問題は、カスタマイズの直接的な結果です。私たちが変更するすべてのものは、ビジネスに不可欠な金融ソフトウェアを破壊するリスクがあります。しかし、会計部門は（私たちは常にそう！と言ったので）とのために少し尊敬があるように思われる変化を示唆し続けてインパクトのある方法の変更があるかもしれません。 一部の変更は問題を引き起こしません。ベンダーソフトウェアでフォームをカスタマイズすることができます（また、意図されています）。フォームフィールドを移動したり、削除したりできます。しかし、無害なカスタマイズのたびに、ストアドプロシージャやトリガーなどの変更を提案して、ベンダーアプリケーションのデータベース内のデータを操作します。 私は最近（ほとんど）、情報が完全に互換性がないため、あるベンダープログラムから別のベンダープログラムに顧客をインポートしようとするのをやめさせました。それがどのように解決されたかという私の問題は、システムがユーザー側で機能しなかったことがわかったためです。タスクは思ったより複雑だったので、あきらめました。ユーザー側のタスクがどれほど簡単であるかに関係なく、必要な操作は実行されるべきではありませんでした。 特にデータの有効性が危ぶまれている場合、このシステムの動作方法を変更するとリスクがあることをどのように伝えることができますか？私は新規（6か月）の雇用者であり、現状のままですが、財務データとサポート契約の有効性を危険にさらしています-ベンダーのサポートが「Xがカスタマイズされた」と聞いた場合私たちをサポートしたり、それが私たちのせいだと言ってください。

12 management  communication  technical-debt 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 4年前休業。 毎年少なくなる-Jeff Atwood 私はこの洞察に満ちた記事に出くわしました。投稿から直接引用 私は、謙虚なプログラマーが改善する方法を毎年吸うことが少ないとしばしば思っていました。1年前に書いたコードに不満があるはずです。そうでない場合は、A）1年間何も学習していない、B）コードを改善できない、またはC）古いコードに再度アクセスしないことを意味します。これらはすべて、ソフトウェア開発者にとって死の接吻です。 これはどのくらいの頻度で起こりますか？ コーディングが実際に改善されるまでにどのくらいかかりますか？月、年？ あなたはあなたの古いコードを再訪しますか？ あなたの古いコードはどれくらいの頻度であなたを悩ませますか？または、技術的負債にどのくらいの頻度で対処しなければなりませんか。 古いバグを修正することは間違いなく非常に骨の折れるコードであり、期限とそれらの迅速な修正に迅速に対応するために行った可能性のある汚いコードです。それについての議論はありません。 私が出会った開発者の何人かは、彼らがすでに進化の段階にあり、コーディングを改善する必要がないか、もはや改善することができないと主張しました。 これは起こりますか？ もしそうなら、特定の言語でのコーディングに何年かかりますか？ 関連： あなたの古いコードのいくつかを振り返って、苦痛に満ちていますか？ コード内のスターウォーズモーメント 「ルーク！私はあなたのコードです！」「いいえ！不可能！できません！」

10 self-improvement  technical-debt 

Pivotal Trackerの技術的負債のユーザーストーリーに対して、私たちは何をすべきですか？これらを特徴（ポイントを与える）または雑用（ポイントを与えず、速度を下げる）と見なす必要がありますか？ 私は雑用と見なされるべきものを混乱しています： コードの重複-複数の場所に同じコードを配置した場合、それはコードの習慣としては非常に悪いことであり、チームの開発者はソフトウェアを保守可能にするためにより多くの検討を行い、リファクタリングを行い、コードレビューに時間を費やす必要があることを示しています。これにはすべて、成熟度、時間、コードレベルの経験が必要になるため、提供するポイント数を少なくして、コードの品質が損なわれないようにすることをお勧めします。したがって、そのようなミスは罰せられるべきであり、雑用にポイントを与えないことによって速度を下げる必要があります。 テクノロジーのアップグレード-JS、HTTP2、React、MVCまたはその他の新しい/より優れたテクノロジーのモジュール化への移行のように。これらの手順により、コードのパフォーマンスとメンテナンスが改善されます。しかし、これは雑用か機能か？これがテクノロジーの世界のあり方であり、新しいテクノロジーが時々やって来て、それに移行する必要があると思います。したがって、そのような作業に対してチームの速度にペナルティを課すことには意味がありません。提案？ レガシーコードの複製/サブスタンダードコード-長い間使用されていないコードや、新しいチームが結成されたがコードベースが少し古い場合、この問題に直面します。チームはこのセクションをコーディングしていないので、なぜそれらの負債を作成したことがないので、なぜそのような技術的負債を選ぶことによって彼らの速度にペナルティが課せられるべきであるとチームは言います。 ビジネスの緊急性が原因の標準以下のコード-競合他社/ターゲット/ビジネス/ユーザーのプレッシャーが原因で、開発者は機能をすぐにライブでプッシュしなければならない場合があります。そのような悪いコードのクリーンアップも雑用（ポイントを与えない）と見なす必要がありますか？今回の開発チームに問題はないので、なぜ彼らの速度を下げなければならないのですか？ 上記のすべてのタイプの雑用は、賢明に行えば、将来的にチームの速度を向上させるはずです。しかし、チームの速度を維持しながらバランスを保ち、チームが悪い決定を下すことで技術的なミスを罰する必要があるでしょうか。 質問は次のようなものです。 技術的な負債は機能または雑用（またはバグ）としてスケジュールする必要がありますか？が、4つのポイントすべてを網羅する説得力のある回答が見つからなかったため、別の方法で再投稿しています。

8 agile  scrum  estimation  technical-debt 

私はソフトウェア開発者で、小さなWeb開発会社で働いています。なかなか時間がかかるとミドルマネージャーから聞かれるのはよくあるテーマのようで、見積もりを出すと高すぎると思います。それがより技術的なマネージャーまたは別の開発者である場合、彼らは通常、自分自身の見積も​​りをすでに心に留めており、より速く実行できると考えているため、独自の方法でそれを実装しようとします。 ただし、他の開発者が見積りよりも大幅に多くの時間を費やしてしまう傾向があります。彼らは予算の半分を経て、実装計画では適切に対応できないビジネス上のニーズがあることを認識します。たいていの場合、私の計画はこの必要性に対処するはずでしたが、「あなたはそれを必要としない」機能として肩をすくめられました。 さらに悪いことに、彼らがこの壁にぶつかったとき、彼らは通常、彼らが自分たちが描いたコーナーから抜け出すのを手伝うために私のところに来ますが、私の一日にはほんの数時間しかありません。 最良の場合：これらの中断は、自分の開発作業に割り当てた時間に割り込んだため、他のプロジェクトが遅れたり、「Xを実行できる唯一の人」であるため、残業しなければなりません。 最悪の場合：私は自分でタスク/プロジェクトを引き継ぐ必要があり、その時点では予算に「私の」やり方でそれを行う時間は残っていません。彼らが始めた方法で彼らが始めたものを終わらせなければならないので、「会社はこれ以上お金を失うことはありません」。「私の」ハッキーコードになるので、これはいつも私に噛み付きます。それが壊れると、なぜそれがそのように作成されたのか、人々は私に尋ねます（結局のところ、誰が実際にそれを作成したのかわかりません）。 ですから私の質問は次のとおりです。物事が想像しているほど単純ではなく、クライアントのニーズに対する理解を再評価する必要があるときに、これらの同僚がどのように理解できるようにすることができますか？ [既存の]技術的負債に対処するための経営陣の説得に関するこの同様の質問とは異なり、私の質問は、それが最初から起こらないようにするために、チームが技術的負債を負おうとする前に[積極的に]実現するのを助けるための戦略を求めています。これら2つは密接に関係していますが、私の考えでは明らかに異なります。他の質問の答えは、将来の機能の見積もりにリファクタリング時間を追加することを提案しています。他の開発者（したがってマネージャー）が、将来の機能は実際よりも時間がかからないといつも考えている場合、これは決して機能しません。また、私の見積もりがより現実的であると彼らに納得させることができません。

8 project-management  teamwork  estimation  technical-debt