「メンテナンス開発者」になる
だから私は今の自分の立場に腹を立ててきており、これについて他の開発者の意見を聞きたいと思っています。
現在、約11か月間、現在の勤務先にいます。私が始めたとき、私はすべての新機能に取り組んでいました。私はここにいた最初の5〜6か月間、基本的にまったく新しいWebプロジェクトに取り組みました。この後、私はサービス指向の役割（それでも素晴らしい、すべてにとって新しいものでした）に移され、過去5〜6か月間この役割を担っていました。ここで問題が発生します。
基本的に、2日前にサポート/メンテナンスの担当者になりました。今、私たちはITサポートチームを持っているので、そのようなサポートについては話していません。第2レベルのサポート担当者について話しているのです（表面の担当者が問題の根本に到達できない場合）。 、しばらくの間バックログに残っているメンテナンスの問題に取り組むことと相まって。約3年の経験を持つ開発者である私にとって、これは一種の落胆です。
このような作業場所の場合、これらのサポートの問題が私の一日の大半を占めても驚くことはなく、メンテナンスの問題に取り組むことはほとんどありません。また、これらのサポート問題のほとんどはコードにも関係ありません。それらは多かれ少なかれ、システムアーキテクチャを知っていること、サービスが正しく実行されていることを確認していること、適切に開始されていること、不良データを処理/修正していることなどです。開発者なので、この部分は吸う。また、メンテナンス作業の時間がある場合でも、これらは基本的にはバグ修正/不良コードの改善に過ぎないため、これも問題ですが、少なくともコーディングに関連しています。
ここで怒るのは間違いですか？本当に文句を言いたくありませんが、正直言って、この件については何も言われていませんでした。私は、この種のことをしていると私に知らせるメールを送っただけでした。 、それがそれでした。チーム全体が数分かかって、私に彼らの「しゃべる」話をさせてくれました。彼らは私たちの仕事のタイプのサポートにどれほど苛立たしいかを知っているので、それを知らないのは私だけではありません。素晴らしい機会です。
私はどうやって前進するかについて、ちょっとばかり垣間見ています。もちろん、とりあえず仕事を続けるつもりで、誰かに悪い印象を与えるのは無意味ですが、皆さんがこの状況にどのように取り組むか、または私がそれについてどのように感じているべきだと思いますか？あなたたちは感じます.
これは、どちらかというとリンボの時間と見なすことができます。またはそれを成長の機会に変えることができます。
メンテナンス開発者になることの核となる考え方は仕事から抜け出すためです。何かを修正する必要があるたびに;十分に時間をかけて問題を理解してください。解決策（火を消してから数週間後に発生する可能性があります）は、あなた（または他の生きている魂）が再びその問題を解決する必要があることを意味します。
これはサポートしているレガシーシステムであるため、通常、メインライン製品には「問題」がないいくつかのソリューションを使用して方法を得ることができます。 cronを使用して、バグのあるサービスを定期的に再起動できます。その製品を使用する顧客の数は増加しないため、特定の顧客に対して例外的なロジックをハードコーディングできます。
もう1つの部分は、システムから有用な知識を抽出することです。あなたはおそらくこれをしたくないでしょう、それはそれほど楽しくありません。しかし、実際のシステムが何をしているかを文書化することで（たとえそれが間違っていても）、アプリケーションのその部分を管理する作業を1桁簡単にすることができます（3日ではなく、モジュールを説明する2つの段落を読むのに10分かかる）モジュールコードの読み取り）。さらに良いことに、この同じドキュメントを使用してメインライン製品に機能を実装できるため、レガシーシステムのサポートを完全に停止できます（少なくともその機能について）。
あなたがプロジェクトの「頼りになる人」である場合、たとえそれがレガシーメンテナンスであっても、おそらく（または少なくとも、あなたは）自分の方法で問題に取り組むためのかなりの自由度があります。それは、セクションをお好みの言語またはプラットフォームで書き直すか、解決策の代わりに回避策を提案するか、または単に「修正せず、サポートされている製品を使用する」という問題に対応することを意味します。
編集：上司の意図を誤って解釈している可能性があります。メンテナンスには、開発サイクルの他の部分とは異なる一連のスキルが必要です。彼は、彼が利用できるすべての人々の中で、あなたはこの役割にとって最高であると考えているため、あなたを仕事に就かせているのかもしれません。彼があなたが何か他のことをするのに十分なスキルがないと思っているからではありません。
メンテナンスでは、readingコードに重点を置く必要があります。読書が上手であれば、メンテナンスも上手になります。他の人のコードを読むためのknackを持っていない開発者はたくさんいます。 。
あなたがメンテナンスの仕事を辞めたとき、あなたは「より重要な何かをするのに十分良いだろうと経営陣を確信させる」のではなく、あなたは文字通りメンテナンスの仕事を生活から遠ざけています。あなたがその仕事をやめるとき、それはやることが何も残っていないからです。レガシーアプリケーションから移行されたため、手動タスクが自動化されたため、または顧客がそれを望まない、または必要とせず、絶対に必要としないことで、すべての問題が解決されます。あなたの上司が「彼はこれが得意であるので、ここに留めておいた方がよい」と解釈し、何もしない場合、彼はばかです。
メンテナンス開発者であること！=はベンチに残されています。保守開発作業は、元の開発者が見逃した奇妙な問題を修正するときに、世界で最もイライラさせられ、苦痛で迷惑な作業の一部になる可能性があります。
また、個人的にも専門的にも、やりがいのある最もやりがいのある仕事になる可能性があります。 6か月以上システムに存在するバグを取り除くことができ、上司があなたを愛する顧客ベースの10％に直接ノックオン効果がある場合、顧客ベースの10％も同様にあなたを愛します。ソフトウェアを段階的に改善し、効果的に追跡するのに1週間かかるバグを修正することで、そのシステムだけでなく、特定の条件下で潜在的にどのようなバグが見られるかについての知識を高め、それをオンボードにして、より良い開発者。
私はシステムを新しく作成するのが大好きですが、私のプログラミングバッグのトリックのほとんどは、メンテナンス作業を行うことから生まれ、思った以上に便利です。
それをノックしないでください。私はメンテナンスプログラマとして多くの時間を費やしてきました。製品が興味深く、他の開発者が何か良ければ、何かを学ぶかもしれません。そして、それらが悪い場合は、コードを保守不能にする原因を学び、独自のコードを作成するときにその経験を利用できます。そして、しばらくしてから、誰かが小さなサイロだけでなく、コードについて何かを知る必要があるときに、彼らが頼りになるのはあなたです。
そして、コードの使い方を学んだ後は、リファクタリングが必要な部分がわかり、それを行うためのプロジェクトを提案できます。もちろん、完全にリードする準備ができています。
スマート組織では、メンテナンスエンジニアの役割は、他の何かに十分ではないために誰かに与えられるものではありません。特定の役割を処理するのに十分なほど優れているため、彼らに与えられます。既存のシステムを稼働状態に保つことは非常に重要な役割であり、会社によっては、何百万ドルもの資金が、エンジニアが仕事を上手にこなす先端でバランスをとることができます。
そうは言っても、ほとんどのマネージャーは、その役割を処理するために熟練した個人が必要であることを直感的に理解しますが、ほとんどのマネージャーは、そのプログラマーの成果を認識せず、あなたの仕事に対する認識を得るのが難しい場合があります。あなたは熟練しているので、役に就くのは完全に簡単すぎます。昇給や昇進は後で配られるので、忘れられます...役で素晴らしい仕事をしている気配は誰もが自分があなたの役割で素晴らしい仕事をしています。
自分がその役割を果たすためにふさわしいと考えている認識のために戦うことは可能ですが、それが関与する多大な努力の価値があるとは完全には確信していません。代わりに、（他の人が述べたように）利用可能なさまざまな開発者を通じてロールをローテーションするという概念について、マネージャーと話し合うことをお勧めします。可能であれば、少なくとも1人はフルタイムで、もう1人はパートタイムで担当してください。パートタイマーは、システムと、フルタイマーからシステムを維持するために必要なことについて学習できます。ローテーションの時間になると、パートタイマーがフルタイマーを引き継ぐことができ、新しい人がパートタイマーとして登場します（現在のフルタイマーから学習します）。
それで気分が良くなった場合、Opsの人々は同じ立場にいます...優れたOpsの人のしるしは、彼らが自分の仕事をどれほどうまく行っているかに誰も気づいていないことです。ただ、Ops担当者にとっては、IS彼らの主要な役割であるため、実際にローテーションアウトすることはできません。私は常に、公にそして声を上げて協力しているOps担当者を称賛することの大ファンです。なぜなら、devは他のすべての人の生活をどれほど改善できるかを知ることができる数少ないグループの1つだからです。
余計なことはさておき、メンテナンスの位置を変える場合は、次回このロールに入るときに、戻ってきたときにあなたの人生を楽にするような行動をした人を見る前に、チョップの前に人々に与えるようにしてください。役割において...公的にそして声でそうします。
他のコメンターが推奨する建設的なアプローチは非常に優れています。トークンが指摘したように、問題が解決され、何も壊さない限り、そのような立場には多くの余裕があります。
一般的なソリューションを自動化したり、防止したりできる場合は、多くの自由時間を自分で購入できます。これにより、上司があなたの時間に対する要求を知らないままにしておくと、他の種類の仕事をすることができます。それ以上、またはあなたが会社にとってより生産的だと思うこと。私の最初の「プログラミング」ジョブはデータ入力ジョブであることがわかりましたが、多くのデータエントリがスクリプト可能であり、後で生成できることがすぐにわかりました。私は自分の時間の約7/8を解放し、それを使用して、すべてのスクリプトとジェネレーター、より効率的なUIを含め、データ入力システムを最初から書き直すために使用しました。それはとにかく行き止まりの政府の仕事でしたが、その経験は非常に貴重であることがわかりました。
開発者をそのポジションに配置することについて（たとえば、毎月のサイクルなどで）マネージャーに話します。誰もがそれが悪いことを知っているなら、誰もが仕事がチーム全体に分散されている理由を理解するでしょう。たぶんあなたの上司と話していると、あなたはこれがすでに事実であり、あなたがちょうど交代したばかりであることがわかるでしょう。
なぜあなたは誰もが悪いと思う役割に置かれたのかを尋ねる必要があります。あなたの上司が半分頭脳を持っているなら、彼は誰もそれを好きではないことを知っているでしょう、そして彼がそうするものがあると思ったら、彼は少なくとも尋ねることができました。この状況が続く期間と、新しい開発に戻る機会があるかどうかを確認してください。あなたは決して知りません、あなたは翌日オフィスに入り、まったく新しいプロジェクトを与えられるかもしれません。見知らぬものが起こった。