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

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

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

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

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

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

明確化：

• あなたは「実装者」であり、階層の最下位です。

• 問題は見えますが、問題については発言権がありません。

• 技術的な負債を定量化したり、ツールを探したりするわけではありません。

• 3番目の「重複」について

  • リファクタリングとリライト-あなたはあなたのタスクにロックされています。あなたは余分に行うために支払われていません。
  • アーキテクチャの概要-システム全体は知っていますが、アーキテクチャについてはわかりません。
  • コードフリーズ-電話ではありません。あなたは管理者ではありません。
  • モジュール化-アーキテクチャのアイデアはありません。モジュールは要件の変化に応じて変化します。
  • 自動テスト-なし。

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

そのようなものを伝えるための主要なツールとして課題追跡を使用する習慣を作ります。そこから、プロジェクトの課題の追跡を担当するシニア同僚/リード/マネージャー/誰でも簡単に選択、評価、優先順位付けできるからです。。

ジョブに適したツールを使用します。私は常にそれを行い、同じことを強くお勧めします。

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

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

要約：関与する設計を簡素化するParticularPieceOfCode

説明：
TICKET-12345に基づく実装の過程で、使用に関連するコードParticularPieceOfCodeは少し複雑になり、読み、理解、保守がかなり難しくなりました（以下のコードスニペットの例を参照）。

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

再設計することが望ましいコードの例は、ClassName#methodName次の場所にあります。

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

FWIW私のアドバイスは、あなたの「レベル」とは無関係に適用されます。

私はあなたの現在の（「最低」）レベルでそれを使用してきましたが、私のレベルは「最低」からかなり離れているので、それを使用しています。常に何でも。

考えてみてください。レベルはありません。どれだけの権限を持っているとしても、これ以上良い方法はありません。

あなたが「言う」と私たちが問題を抱えているなら、それはただ空気がたたくだけです。そして、たとえ上司/リードが同意してあなたが正しいと言っても、私たちは問題を抱えています。

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

ジョブに適したツールを使用します。あなたが説明する仕事にとって、課題追跡はまさに正しいツールです。

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

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

他にどのような方法で通信を選択する場合でも、トラッカーにチケットがあると、簡単になります。

「TICKET-54321について話したい」と言って空気をガタガタにしたい場合でも、「以前に扱ったコードについて話を聞きたい」よりも、より堅実な出発点になります。 ...」そして、チケットへの参照をメールで安全に渡すことができます。たとえメールが紛失しても、問題はトラッカーに残り、詳細をすべて伝えたいと思います。

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

あなたはチェーンの中で最低の開発者です

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

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

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

• 問題は見えますが、問題については発言権がありません。
• 技術的な負債を定量化したり、ツールを探したりするわけではありません。
• タスクにロックされています。あなたは余分に行うために支払われていません。
• 電話ではありません。あなたは管理者ではありません。

通常、これは正反対です。お金に見合う価値があることを証明したら、あなたはより多くの報酬を受け取り、あなたの意見はより尊重されます。それは「持っている前に」であり、逆ではありません。

チーム内の人々に期待しているのは、まさにそれです。私たちが構築しようとしているプロジェクトや製品、およびその取り組みに関連するすべてのプロセスに対する責任感。私のチームの誰かが責任を引き継ぐことによって私に感銘を与えるたびに、例えば、改善を提案したり、自分で物事を改善し始めたりすると、これらは昇進する人々です。

別の言い方をすれば、働きバチを昇進させる人は誰もいません。タスクに割り当てられるタスクを受動的に待っている人は、「お金を払っていないから」イニシアチブのほんのわずかな瞬きさえなく、最終的にチャンスがなかったと嘆きます。

もちろん、これはすべて、アーサーによってリンクされた「2つの物語」でジョエルが関係しているものに、あなたの会社の文化に依存します。会社の経営者が本当に自分の人が進歩しないように愚かである場合、変動率はおそらくすでに非常に高く、それから結論を引き出す時が来るかもしれません。しかし、そうでない場合、本当の問題は自分の中にあるかもしれません。

あなたはプロです。あなたの雇用主はあなたをプロとして雇った。ですから、あなたが雇った専門家が彼らの専門的な意見を扱うようにしたいのと同じようにあなたの懸念を扱ってください。特に、他の専門家が途中で必要な最適化と修正を行うことを期待します。ただし、それらの最適化によって予想外にコストが増加することはありません。

たとえば、ランプを交換するために車を整備士のところに持って行くと仮定します。メカニックは4つのことに気づきます。

1. ランプにつながるワイヤはほつれ、危険です。ただし、コストを大幅に増加させることなくトリミングできます。あなたは彼がワイヤーをトリムするのに数分かかると予想していました。
2. ボルトが緩んでいます。それは全く無関係です、彼はたまたまそれを見ました。必要なドライバーをつかんで締めるのは20秒です。だから、あなたは彼がそれをすることを期待するでしょう。
3. ランプのシャーシにひびが入っていると、ランプががたつきます。交換するには費用がかかります。そして、それは必須ではありません。それで、彼はあなたにそれについて尋ねるように電話します-あなたが「いいえ」と言うならば、彼はあなたの訪問要約に書面での推薦をします。
4. 車の下にはかなりの量のブレーキフルードがあります。彼は、誰かがリークを修正できるようになるまであなたが車を使用するのを防ぐために、プロとして必要であり、必要になるかもしれません。

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

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

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

1. 良い例です。 できる限り、クリーンで賢明なコードを作成します。選択肢が与えられたら、要件を満たし、欠点の少ないものを選択してください。（技術的な負債は住宅ローンの負債と同じではないことに注意してください-それを持っていることは必ずしも悪いことではありません。）
2. あなたの懸念を伝えてください。技術的な負債を管理し、企業のリソースを割り当てる実際の責任を持つ、チームリーダー、顧客、またはアーキテクトの誰かが必要です。悪いと思うものを見つけたら、懸念を伝えてください。彼らがあなたのインプットを理解し、それに応答し、信用を与えることに自信がないなら、それを書面（電子メール）に入れてください。
3. 強調しないでください。 技術的負債が企業の雇用終了の失敗を引き起こすことはめったにありません。懸念事項を伝えて仕事をしている限り、技術的な負債などの建築問題は文字通りあなたの問題ではありません。はい、彼らはあなたに影響を与えるかもしれませんが、彼らは保安官の再選が下級警察官の心配である以上、あなたの心配ではありません。

あなたが提供した例では、add完全な機能クリープを被った関数で、数分かかり、それを改善するものの概要をドラフトします。それを実装するために承認が必要な人にそれを送り、先に進んでください。

あなたの企業が非常に有能な人によって管理され、正しく構成されていると仮定すると、あなたの懸念は決定のために適切なシステム設計者に送られるか、提案を実施する余裕が与えられます。ジュニア開発者として、私は技術的な負債よりもあなたの企業がどのように機能するかを学ぶことをもっと心配します-前者を知っていれば、後者を処理する方法は明白なはずです。

従業員の参加を望まない組織について聞いたことはありません。あなたは、あなたが仕事をするためだけに支払われると言います。適切なタスクを念頭に置いていることを心から疑います。あなたは良いソフトウェアを書くために支払われているからです。

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