「最低の開発者」としての技術的負債との戦い？

Question

あなたが会社で働いていて、彼らのためにソフトウェアを開発しているとしましょう。全体像を把握していないか、わずかな可能性があります。あなたが持っているのは、課題追跡システムを介してあなたに割り当てられたタスクです。タスクが与えられ、タスクがタスクを説明するように動作させ、送り返します。 2つの整数を追加するように：

function add(a,b){return a + b;}

しかし、後でプロジェクトが進むにつれて、addがより複雑になるにつれて、パラメーターを追加して値を返す関数だけでなく、何らかの形式のアーキテクチャーが必要であることに気付くでしょう。しかし、あなたはそれを知りませんでした。そもそも、必要なのはその単純なaddだけでした。 addがそれほど複雑になるとは予想していませんでした。

プロジェクトは、そもそも予想していなかったより多くの機能を備えて進行します。そして最後に、既存のコードを壊したり書き直したりすることを避けるために、ハックを積み重ね、関数のレイヤーを重ねます。

これらの状況にどのように対処しますか？「最低開発者」としての技術的負債とどのように戦いますか？

説明：

あなたは階層の最下層にある「実装者」です。
あなたは問題を理解していますが、その問題については言いません。
私は技術的な負債を定量化したり、ツールを探したりしていません。
番目の "重複" について
- リファクタリングと書き換え-あなたは自分のタスクにロックされています。あなたは余分をするために支払われません。
- アーキテクチャの概要-システム全体はわかっていますが、アーキテクチャについてはわかりません。
- コードフリーズ-あなたの呼び出しではありません。あなたは管理ではありません。
- モジュール化-アーキテクチャのアイデアはありません。要件の変化に応じてモジュールも変化します。
- 自動テスト-なし。

gnat · Accepted Answer

そのようなことに気づくたびに、新しいチケットを問題追跡システムに入力してください。

primaryのようなツールで問題追跡ツールを使用する習慣をつけてください。そこから、上級の同僚、リード、マネージャー、責任者を簡単に選択、評価、優先順位付けできるからですプロジェクトの問題の追跡の場合。

ジョブに適したツールを使用します。私はいつもそれをしますstrongly同じことをすることをお勧めします。

例として、約1か月前に作成したチケットを示します。特定の機能が完了すると、コードが以前よりも大幅に複雑になることがわかりましたが、機能の実装に指定された期限内に修正することができません。

（実際のトラッカーで使用される機能、チケット、コードの名前は隠されていますが、テキストはそのままコピーされます）。

概要：ParticularPieceOfCodeを含む設計を簡素化します

説明：
TICKET-12345に基づく実装の過程で、ParticularPieceOfCodeの使用を含むコードは少し複雑になり、むしろ読み取り、理解、維持が困難（例を参照）以下のコードスニペット）。

それを簡素化する方法を見つけてください。

再設計が望ましいコードの例は、ClassName#methodNameにあります。

<a piece of code like one behind the right door here:>

FWIW私のアドバイスは、あなたがどの「レベル」であるかに関係なく適用されます。

私はあなたの現在の（「最低」）レベルでそれを使用しており、私のレベルが「最低」からかなり遠く、あなたがそれを呼ぶときに満足のいく「言い方」を持っているので、私はそれを使用しています。常に何があっても。

考えてみてください。レベルはありません。どんなに権限があっても、これ以上の方法はありません。

あなたが「言った」場合ちょっと問題があります、それは単なる空気のがたつきです。そして、あなたのボス/リードが同意して言ったとしてもそうだね、問題があるんだ、これは何も変わらない-それはまだ空気がガタガタ音を立てているだけであり、それは他のものにはなり得ない。

^{発言を（メールなどで）書いた方が良いと思うかもしれませんが、考えてみれば、実際はそうではありません。プロジェクトに大量のメールアクティビティがある場合、書き込まれた内容は失われ、1か月後に長い間忘れられます。}

ジョブに適したツールを使用します。あなたが説明する仕事にとって、issue trackerはまさに適切なツールです。

あなたは問題に気づき、それらを追跡するために設計されたシステムにそれを入力し、それが そのために設計されただったので、可能な限り最善の方法で残りを処理します= =：

組織の必要に応じて issues のリストを管理および保守するコンピューターソフトウェアパッケージ。一般的に使用されます...報告された顧客の問題、またはその組織の他の人によって報告された問題を作成、更新、解決するために使用されます。従業員...問題追跡システムは " bugtracker "に似ており、多くの場合、ソフトウェア会社が両方を販売し、一部のバグトラッカーは問題追跡システムとして使用でき、その逆も同様です。問題またはバグ追跡システムの一貫した使用は、「優れたソフトウェアチームの特徴」の1つと見なされます¹...

コミュニケーションを選択する他の手段が何であれ、トラッカーにチケットがあると、それだけで簡単になります。

気を散らすを好む場合でも、「TICKET-54321について話し合いたい...」と言うことは、「聞く」の一部について話したい「聞く」よりもしっかりとした出発点になります。少し前に扱ったコード...」そして、チケットへの参照をメールで安全に渡すことができます。メールが失われた場合でも、問題はトラッカーに残っており、伝えたいすべての詳細が含まれています。

svidgen · Answer

あなたはプロです。あなたの雇用主はあなたを専門家に雇いました。したがって、専門家にしたいのと同じように懸念を扱いますあなた雇うの扱い彼ら専門家意見。特に、他の専門家が途中で必要な最適化と修正を行うことを期待します。

たとえば、ランプを交換するために車を整備士に持って行ったとします。整備士は4つのことに気づきます。

ランプにつながるワイヤーはすり切れて危険です。ただし、コストを大幅に増加させることなくトリミングできます。あなたは彼がワイヤーを整えるのに数分かかることを期待するでしょう。
ボルトが緩んでいます。それは全く無関係であり、彼はたまたまそれを見ただけです。必要なドライバーをつかんで締めるのに彼の時間の20秒です。だから、あなたは彼がそれをすることを期待するでしょう。
ランプのシャーシに亀裂があり、ランプががたつく。交換には費用がかかります。そして、それは必須ではありません。それで、彼はそれについて尋ねるようにあなたに電話します-あなたが「いいえ」と言うなら、彼はあなたの訪問概要に書かれた推薦を置きます。
車の下にはかなりの量のブレーキフルードがあります。彼は、誰かが漏れを修理することを許可するまで、あなたが車を使用することを防止する必要があり、専門家として要求されることさえあります。

これらのシナリオのそれぞれ、および他のシナリオは、ソフトウェア開発において類似点があると確信しています-特にあなたがあなた自身を専門家であると考えている場合あらゆるレベルの。非常に少数の例外を除いて、専門家としてのあなたの仕事は、特定の方法で製品を改善するという最終目標に到達することです専門家の理解に従って。

修正が些細なものである場合は、無関係であろうとなかろうと、修正を行います。
修正が重要で不要な場合は、合意した正式なコミュニケーション/問題追跡メカニズムを使用して、正式な推奨を行います。
主なタスクを実行するために修正が必要であるが、予想外のコストが増加する場合は、スコープの変更を伝えてください。
特定された問題がプロジェクトの成功に深刻な脅威をもたらす場合、それを明確にします。正式に。問題を未解決のままにすること（健康、緊急事態、または輸送システムなど）に倫理的な懸念がある場合は、製品の出荷前に問題への対処を主張します（倫理的に必要な場合は、メディアまたは当局に通知してください）。

JensG · Answer

あなたのシナリオについて私が気分を害するのは、まさにあなたが見出しと質問テキストで何度も書いたものです：

あなたはチェーンの最下位の開発者です

なぜその点がそれほど重要なのですか？さて、まず第一に、そして純粋に技術的には、あなたは確かに正しいです。あなたは、物事の「実装者」と呼ばれるもの、つまり与えられたコマンドに作用する働き蜂として雇われます。

しかし、あなたがランクに関して最も低い開発者であったとしても、これはまだ完全に正しくはありません。ここで重要なのは、あなたがpercepting自分が最低の開発者であることを認識することです。その自己認識を克服しようと試みたことがありますか何かの責任を引き継ぐ？

取る！誰かがあなたに責任を持たせるまで、待ってはいけません。

あなたは問題を理解していますが、その問題については言いません。

私は技術的な負債を定量化したり、ツールを探したりしていません。

あなたはあなたの仕事にロックされています。あなたは余分をするために支払われません。

あなたの呼び出しではありません。あなたは管理ではありません。

通常、これは正反対です：お金に見合う価値があることを示すと、より多くの報酬が支払われ、あなたの意見がより尊重されます。それは「前に行うこと」であり、逆ではありません。

私のチーム内の人々に期待することは、まさに次のとおりです。私たちが構築しようとしているプロジェクトまたは製品に対する責任感と、その取り組みに関連するすべてのプロセスに対する責任感。私のチームの誰かが責任を引き継ぐことによって私に印象づけるときはいつでも、例えば。改善を提案するか、自分で改善を開始することを推奨します。theseは、宣伝される人々です。

言い換えると、働きバチを宣伝する人は誰もいません。割り当てられたタスクを受動的に待っている人はいない。イニシアチブのほんのわずかな瞬きもない「彼らには報酬が支払われないため」、ついには泣き言彼らはチャンスがなかったことを。

もちろん、これらすべては再びあなたの会社の文化に依存し、アーサーによってリンクされた「2つの物語」でジョエルが関連しているものに依存します。会社のマネージャーが本当に自分の人々が進歩するのを妨げるほど愚かであるならば、変動率はおそらく非常に高いので、そこから結論を出すときかもしれません。しかし、そうでない場合、本当の問題はあなた自身の中にあるかもしれません。

DougM · Answer

これは、法律事務所の店員が非倫理的な行動と戦う、ファーストフード労働者が不衛生な行動と戦う、または駐車場の警察官が警察の腐敗と戦うのと同じ方法で行います。

良い例を示してください。可能な限り、クリーンで実用的なコードを作成してください。選択肢が与えられたら、マイナス面の少ない、要件を満たすものを選択してください。（技術的負債は住宅ローンの負債とは異なります-それを持っているだけで必ずしも悪いことではないことに注意してください。）
懸念を伝える。チームリーダー、顧客、またはアーキテクトのいずれかが、技術的負債の管理と企業のリソースの割り当てを実際に担当する必要があります。自分が悪いと思うものを見つけたら、心配事を伝えてください。あなたの入力を理解し、返信し、クレジットを与える自信がない場合は、書面（メール）で記入してください。
強調しないでください。技術的負債が企業の雇用終了の失敗を引き起こすことはほとんどありません。懸念事項を伝えて作業を行っている限り、技術的な負債などのアーキテクチャの問題は文字通り問題ではありません。はい、それらはあなたに影響を与える可能性がありますが、保安官の再選が下級警官の心配である以上、あなたの心配ではありません。

あなたが提供した例では、完全な機能クリープを被ったadd関数を使用して、数分かかり、それを改善するものの概要を作成します。それを実装するために承認が必要な人に送信して、次に進みます。

あなたの企業が非常に有能な人々によって管理され、正しく構造化されていると仮定すると、懸念は適切なシステム設計者に回されて決定されるか、提案を実装する余裕が与えられます。ジュニアデベロッパーとして、私は技術的負債よりも企業の仕組みを学ぶことについてもっと心配します。前者を知っていれば、後者の処理方法は明白です。

winkbrace · Answer

従業員の参加を望まない組織については聞いたことがありません。あなたはあなたが仕事をするためにだけ支払われると言います。あなたが正しい仕事を心に留めていることを心から疑います。あなたは良いソフトウェアを書くためにお金を払われるからです。

この責任を取ってください。ベースをサポートできない場合は、機能を追加する必要はありません。あなたの専門知識で顧客にアドバイスします。手遅れになる前にブレーキを踏んで、プロジェクト全体を破棄する必要があります。メンテナンスができなくなるためです。