ソフトウェア会社で「リファクタリング/保守グループ」の役割のようなものはありますか？

したがって、私は組み込みソフトウェア開発を行う会社で働いており、他のグループはさまざまな製品のソフトウェアのコア開発に焦点を合わせており、工場にある私の部門（別の地理的な場所にある）もソフトウェア開発に対処する必要があります、しかしすべての製品にまたがるので、製品のソフトウェアの問題が原因でラインがダウンした場合にも迅速に修正できます。

つまり、私たちはジェネラリストであり、他のグループは各製品に特化しています。

地理的に分散していると、コア開発に参加するのが少し難しくなります（まあ、それはそれほど難しいことではないのですが、リモートで協力するということになると、意図しない文化的/政治的な障壁があるかもしれません） ）。

だから、私たちは現在、火を消しているだけで、ややアイドル/サブ活用されているので（新しい部門であるか、それが理由かもしれません）、領域を検出することは、私たちにとって良い役割であると考えましたコードのリファクタリングと再設計の機会、および保守性とモジュール性の管理に関連する可能性のある他のすべての実装。他のグループは、時間がないため積極的な期限があり、コードの品質を損なうため、これに焦点を合わせていません（ソフトウェアプロジェクトの永遠の物語）

私のグループ/部門がこの役割を持つ管理職や他のグループによって公式に認識されることを望んでいるということです、そして私はこの問題のために私たちのグループの良い定義/アイデンティティを思いつくのに苦労しています。

だから私の質問は：この役割はすでに存在するものですか？または私はこのようなものを最初に作成したのですか？

編集：つまり、すべてのリファクタリング作業を自分で行うのではなく、リファクタリングイニシアチブを推進するグループです。オープンソースコミュニティーとオープンソース製品のように、今考えてみると、

私が働いたりインタビューしたりした会社では、そのようなことを聞​​いたことがありません。企業は通常、エンドユーザーにとって測定可能な改善（パフォーマンスの改善など）がある新機能または変更に対してのみ支払いたいと考えています。コードのリファクタリングは、直接測定可能な方法でこれを行いません。

コードの品質を理解し、気にしている企業で私が目撃したのは、開発者はコードを機能するようにリファクタリングすることを奨励されていることです。とにかくファイルに変更を加える場合は、そこにいる間にファイルをクリーンアップすることもできます。単体テストの追加、リファクタリング、静的分析ツールの実行など。

これには2つの目的があります。まず、コードは開発者に独占的に委任することなく、時間の経過とともに積極的に改善されます。第二に、時間はとにかく変更する必要があるコードの改善に費やされるだけです。二度と触れられないコードのモジュールがある場合、それらを維持するために時間を費やすことはあまり意味がありません。彼らはそれを必要としないでしょう。将来変更される可能性が最も高いモジュールのみをリファクタリングすることで、より少ない時間を費やす方が良いでしょう。

プログラマが他の誰かが自分のコードをリファクタリングすることを知っている場合-彼/彼女は自分の仕事をリファクタリングすることを決してしないでしょう。リファクタリングのために別のチームを設定することは、そもそも存在しない低品質のコードを正当化することに似ています。問題があることを認め、それに対応するために会社の組織構造を変更するようなものです。高品質のコードに対するあなたの情熱に感心しますが、この場合は「私の仕事ではない」と言った方がいいでしょう。リファクタリングは、コードを記述していないサードパーティではなく、コードを記述したプログラマによるものでなければなりません。

主よ、これを行わないでください。別の位置にいることを考えてください-あなたはコードを書き、コミットし、他のいくつかの仕事をします、そしてあなたはあなたのコードにいくつかのバグ修正をするように頼まれます、それであなたはそれが更新されたことに気づき、それをチェックして、それが耐えることを見てくださいあなたが最初に書いたものに似ていません。

SCMでも多くの追跡可能性が失われます。これらの移動および名前が変更されたメソッドはすべて、最終的なコードに元のコードへの直接の追跡がないことを意味します。多くの場合、差分を使用するには変更が多すぎるように見えます。

ですから、あなたがしているのは、IDEでいくつかのリファクタリングツールをクリックしてクリックし、他のコーダーにそれを改善したことを伝えることです。Slashdotのようなもので、投稿に対して皮肉な反応をする人に「そこに、あなたのために修正しました」と時々返信してもらいます。/。にユーモラスな場合は問題ないかもしれませんが、私のコードにそれをやった場合はそうではありません-それからあなたが所有するのはあなた自身であり、メンテナンスを実行できると私は言います。

さて、コードで実際の作業をしている場合、それは異なりますが、それ自体のためにリファクタリングすると、「メンテナンス」のガイドの下でさえ、他のすべての人を困らせるだけであり、それは「私のグループ/部門が欲しい」の2倍になります。この役割を持つ管理者や他のグループによって公式に認められる」-あなたは「政治的操作」と言えるでしょうか？他の部門が顧客サイトでコードがクラッシュしたときに何を言うか想像できますか？「私たちが最後に触れたときは問題ありませんでした。それを破ったのはリファクタリング部門だったに違いありません。彼らは最後に触れました。」

あなたが試すことができるのは、ソフトウェアのさまざまな部分にもっと注意が必要であると経営陣を説得し、貧しい部分を取り上げ、彼らがそれを改善するために時間を費やすかどうかを確認することです。これが発生している間、コア製品に機能を追加するために、他のワークロードのコアグループのいくつかを取ることを提案できます。それらのコア機能を再実装しようとするのは遠いでしょうが、コアグループにプッシュバックできる機能を追加する部門の能力を高めれば、より多くの開発責任が得られます。

それはあなたがリファクタリングと保守性によってあなたが本当に何を意味するかに依存します-理論と実際の両方で。

以前は、コードのクリーンアップとバグ修正に専念するグループがいました。当然のことながら、優れた開発者はコードのクリーンアップとバグ修正に時間を費やしたくないので、うまくいきませんでした。

一部の組織は、コードレビューにかなりの時間を費やす傾向があり、優れたプラクティスについては上級管理者以外の開発者を指導する傾向のある専用の「ソフトウェアエンジニアリング」チームを持つことを選択します。ただし、プロジェクト計画、アーキテクチャ、テスト計画、リリースプロセスなどに深く関与していない限り、これは真のエンジニアリンググループではありません。この全体論的なアプローチ、できればソフトウェアやその他のエンジニアリングに関するある程度のトレーニングを行うことが重要です。それ以外の場合は、上記の「クリーンアップ」に移行する傾向があります。

結論として、開発者は長期的には優れた管理人を作りません。また、真のエンジニアリンググループが存在する場合でも、そのアプローチは部門横断的なチームとうまく機能する傾向があります。そうでない場合、他のチームはその取り組みを無視するか、または憤慨し、象牙の塔と見なします。

リファクタリングと再設計以外に何もしない開発者でいっぱいの部屋はありません。それだけでは終わりません。

通常、人々がリファクタリングを行うとき、誰もが日和見的リファクタリングを使用してそれを行います。ですから、そのような珍しい慣行の一般的な名前を見つけられるとは思いません。

しかし、通常とは異なる状況では、全員をリファクタリングすることがおそらく理想的ですが、実際に試すことは理にかなっているように思えます。

ただし、現在、人々が自分のコードをリファクタリングすることを妨げている同じ政治的問題は、おそらくあなたをも倒すでしょう（おそらく、あなたが考えていることに名前がない理由の一部です）。他のチームは、コードを「改善」しても大丈夫ですか？最初に管理者が価値のあるものとして認識していない何かを行う過程で初めてバグを導入するとどうなりますか？別のチームがあなたの新しいデザインを気に入らない場合はどうなりますか？

いつか別のチームに費用がかからないという保証はありません。また、正味の正の効果があるというほとんどすべての議論は、彼らに自分自身をリファクタリングさせることにも適用できます。

あなたが提案しているものは受け入れられるかもしれませんが、他のすべての人にリファクタリングを許可しないかもしれません-しかし、これが起こっていることを私が想像できる唯一の方法は、基本的にリファクタリングが長期的には時間を節約できるが、時間がかかることに同意する場合です短期的に、そしてあなたのチームが短期的に十分な自由時間がある唯一のチームであること。そして、他のチームがあなたにリファクタリングをすることを信頼していて、それが彼らに引き起こすあらゆる問題に喜んで対処するなら。

他の開発グループを犠牲にしてリファクタリングと保守性のみに焦点を当てたグループを持つことは、組織にとって危険です。保守性を改善し、バグを最小限に抑えるためにリファクタリングを介してコードの品質を向上させるには、上級管理職、テスター、およびすべての開発グループからのコミットメントが必要です。コードを改善するのは全員の責任であるべきです。リファクタリングを実行する必要がある場合は、新機能とともにリリーススケジュールに含める必要があります。進行中の開発プロセスの一環として支払われない場合、技術的負債が製品を急停止させるものであるため、コードを改善するために時間をかけることは長期的に見返りがあることをマネージャーに教育し、理解する必要があります。あなたがしているすべてが絶え間ないバグ修正から絶えず火と戦っているなら、

あなたは、より保守しやすい次世代のアーキテクチャの開発に専念するアーキテクチャ/ソフトウェアスタッフグループである必要があるように聞こえます。あなたのグループはおそらく、リファクタリングが「先のとがった」タイプに報いることを実証する方法に焦点を当て、開発者に新しい方法とプロセスを奨励し、より良いコード品質を採用して「バイイン」するように管理の主要な利害関係者を教育する必要があります。プロセスに。最初に単純な基盤を置くことで、製品をより良いアーキテクチャに移行する計画を考えます。誰もがあなたの製品をサポートすることから学んできた苦痛な教訓を取り入れ、将来的にその苦痛を軽減するための計画を考え出す。

それはかなり一般的です。私はこれが標準であったソフトウェア会社で働いていました。新機能の実装に専念するチームがいました。次に、クライアントに問題を引き起こすバグを修正するメンテナンスチームがいました。メンテナンスチームは、組織のコンサルタント/サポート部門に分類されました。

その場合、開発者にはメリットがありました。つまり、開発者はクライアントとより緊密に連携し、現場で時間を費やしていました。新規開発を行う製品チームはクライアントとまったく対話しませんでした（嫌な状況imo）。

ソフトウェア会社やアウトソーシングプロバイダーでは、社内で提供する方が一般的です。私は金融関係にあり、過去にこの構造を使用した銀行は1つしかありません。とはいえ、戦術チームがそのような問題を自分たちの権限の一部として取り上げることはよくあることです。まったく同じではありませんが、似ています。

チームが十分に活用されていない場合は、少し注意する必要があります。十分に活用されていない場合は、「不要なコスト」に簡単に変換できるため、XのチームはすぐにX-1のチームになることができます。

推奨されるアプローチは、修正にもう少し時間を費やして、バグ修正時間に未記述のリファクタリング時間を組み込むことです。

それはあなたの会社がどのように働くかに依存します。興味深いのは、あなたが本当に知らないということです。そのため、チームリーダーがいる場合は、チームリーダーと話し合う価値があります。知らない場合は、チェーンの次の人と話してもらいます（それに関与し、手渡さないでください）。それが経営者の期待と一致するかどうかがわからない場合は、資産カテゴリではなく、コストカテゴリにさらに分類される可能性があります。