ソフトウェア会社で「リファクタリング/保守グループ」の役割のようなものはありますか？
そのため、私は組み込みソフトウェア開発を行う会社で働いており、他のグループはさまざまな製品のソフトウェアのコア開発に焦点を当てており、工場にある私の部門（別の地理的な場所にあります）もソフトウェア開発を担当する必要があります、ただし、すべての製品で、製品のソフトウェアの問題が原因で回線がダウンした場合にも迅速に修正できるようになっています。
つまり、私たちはジェネラリストであり、他のグループは各製品に特化しています。
地理的に分散していると、コア開発に参加するのは難しいです（まあ、それほど難しいことではないことはわかっていますが、リモートでのコラボレーションの分野に関しては、意図しない文化的/政治的障壁があるかもしれません） ）。
それで、私たちは現在、火を消しているだけで、いくらかアイドル/サブ活用されているため（私たちが新しい部署であるか、それが理由かもしれません）、領域を検出することは、私たちにとって良い役割であると考えましたコードのリファクタリングと再設計、および保守性とモジュール性の管理に関係する可能性のある他のすべての実装の機会。他のグループは、時間がなく、コードの品質を損なう積極的な期限があるため、これに焦点を当てていません（ソフトウェアプロジェクトの永遠の物語）
私のグループ/部門がこの役割を持つ経営陣や他のグループに公式に認められてほしいということですが、この問題について私たちのグループの明確な定義/アイデンティティを思い付くのに苦労しています。
だから私の質問は：この役割はすでに存在するものですか？それとも私がこのようなものを作る最初の役割ですか？
編集：つまり、リファクタリングのイニシアチブを推進しているグループであり、すべてのリファクタリング作業を自分で行っているわけではありません。オープンソースコミュニティのように、オープンソース製品に似ています。
私が働いたりインタビューしたりした会社では、そのようなことを聞いたことがありません。企業は通常、エンドユーザーに測定可能な改善（パフォーマンスの改善など）がある新機能または変更に対してのみ支払いを行います。コードのリファクタリングは、これを直接測定可能な方法で実行しません。
コードの品質を理解し、気にしている企業で私が目撃したのは、開発者はコードを機能するようにリファクタリングすることを推奨されていることです。とにかくファイルに変更を加える場合は、そこにいる間にファイルをクリーンアップすることもできます。単体テストの追加、リファクタリング、静的分析ツールの実行など。
これには2つの目的があります。まず、コードは、そのタスクを開発者だけに委任することなく、時間の経過とともに積極的に改善されます。第二に、とにかく変更する必要のあるコードの改善にのみ時間が費やされます。二度と触れられないコードのモジュールがある場合、それらを維持するために時間を費やすことはあまり意味がありません。彼らはそれを必要としないでしょう。将来変更される可能性が最も高いモジュールのみをリファクタリングすることで、時間を短縮することをお勧めします。
プログラマが他の誰かが自分のコードをリファクタリングすることを知っている場合-彼/彼女は自分の仕事をリファクタリングすることを決してしません。リファクタリングのために別のチームを設定することは、そもそも存在する質の悪いコードを正当化するようなものです。これは、問題が発生することを認識し、それに対応するために会社の組織構造を変更するようなものです。品質の高いコードへの情熱に感心しますが、この場合は多分IS「自分の仕事ではない」と言った方がいいでしょう。リファクタリングは、サードパーティではなく、コードを書くプログラマによるものでなければなりませんそれを書かなかった人。
主よ、これを行わないでください。別の位置にいることを考えてください-あなたはコードを書き、コミットし、他の仕事をします、そしてあなたはあなたのコードにいくつかのバグ修正をするように頼まれます、それであなたはそれが更新されたことに気づき、それをチェックして、それが耐えることを見てくださいあなたが最初に書いたものとは似ていません。
SCMでも多くのトレーサビリティが失われます。これらの移動および名前変更されたメソッドはすべて、最終的に元のコードへの直接のトレースがないことを意味し、diffを使用するには変更されすぎているように見えることがよくあります。
つまり、あなたがしているのは、IDEでいくつかのリファクタリングツールをクリックしてクリックし、他のコーダーにそれを改善したことを伝えることです。スラッシュドットのようなもので、あなたの投稿に対して皮肉な反応を「そこに、あなたのために修正しました」と返信する人が時々います。 /。でユーモラスであれば問題ないかもしれませんが、私のコードでそれを行った場合はそうではありません-それ以降はあなたが所有するものであり、メンテナンスを実行できます。
さて、コードで実際の作業をしている場合、それは異なりますが、それ自体のためにリファクタリングすると、「メンテナンス」のガイドの下でさえ、他のすべての人を困らせるだけであり、それは「私のグループ/部門が欲しい」の2倍になります。経営陣やこの役割を持つ他のグループによって公式に認められること」-「政治的操作」と言えますか？他の部門が顧客サイトでコードがクラッシュしたときに何を言うか想像できますか？ 「私たちが最後に触れたときは大丈夫でした。それを壊したのはリファクタリング部門だったに違いありません。彼らは最後に触れました。」
あなたが試すことができるのは、ソフトウェアのさまざまな部分にもっと注意が必要であると経営陣を説得し、貧しい部分を取り上げ、彼らがそれを改善するために時間を費やすかどうかを確認することです。これが発生している間、コア製品に機能を追加するために、他のワークロードのコアグループのいくつかを利用することを提案できます。それらのコア機能を再実装しようとするのは難しいと思いますが、コアグループにプッシュバックできる機能を追加する部門の能力を向上させると、開発者の責任が増します。
それは、理論的にも実際的にも、リファクタリングと保守性が実際に何を意味するかによって異なります。
以前は、コードのクリーンアップとバグ修正を専門とするグループがありました。当然のことながら、優れた開発者はコードのクリーンアップやバグ修正にすべての時間を費やしたくないため、うまくいきませんでした。
一部の組織は、専用の「ソフトウェアエンジニアリング」チームを選択します。このチームは、コードレビューに多くの時間を費やし、上級開発者の優れた実践方法を指導する傾向があります。ただし、プロジェクト計画、アーキテクチャ、テスト計画、リリースプロセスなどに深く関わっていない限り、これは真のエンジニアリンググループではありません。この全体論的なアプローチと、できればソフトウェアやその他のエンジニアリングに関するある程度のトレーニングを行うことが重要です。そうしないと、上記の「クリーンアップ」に発展する傾向があります。
結論として、開発者は長期的には優れた用務員を作りません。また、真のエンジニアリンググループがある場合でも、そのアプローチは部門の枠を超えたチームでうまく機能する傾向があります。そうしないと、他のチームがその努力を無視したり、憤慨したりして、象牙の塔と見なす可能性があります。
リファクタリングとリファクタリング以外の何もしていない開発者でいっぱいの部屋を持ってはいけません。それだけでは終わりません。
通常、人々がリファクタリングを行うとき、誰もが opportunistic refactoring を使用してそれを行います。ですから、そのような珍しい慣習の一般的な名前を見つけることはないと思います。
しかし、あなたの異常な状況では、全員にリファクタリングを行うのがおそらく理想的ですが、それを試してみるのは理にかなっているように思えます。
ただし、現在、人々が自分のコードをリファクタリングすることを妨げている同じ政治的問題は、おそらくあなたをも倒すでしょう（おそらく、あなたが考えているものに名前がない理由の一部です）。他のチームはOKになりますかあなたと一緒に彼らのコードを「改善」しますか？管理者がそもそも価値があると認識していないことを行う過程で、初めてバグを導入するとどうなりますか？他のチームがあなたの新しいデザインを気に入らない場合はどうなりますか？
いつか他のチームに費用がかからないことを保証することはできません。そして、あなたが正味のプラスの効果をもたらすというほとんどすべての議論は、彼らに彼ら自身をリファクタリングさせることに適用することもできます。
あなたが提案していることは受け入れられるかもしれませんが、他のすべての人にリファクタリングを許可することはできません-しかし、これが起こっていることを私が想像できる唯一の方法は、リファクタリングが長期的には時間を節約するが、短期的に、そしてあなたのチームが短期的に十分な自由時間がある唯一のチームであること。そして、他のチームがあなたにリファクタリングを行うことを信頼し、それが引き起こす問題に喜んで対処する場合。
リファクタリングと保守性のみに焦点を当て、他の開発グループを犠牲にしてそれを実装するグループを持つことは、組織にとって危険です。保守性を改善し、バグを最小限に抑えるためにリファクタリングを介してコードの品質を改善するために、上級管理職、テスター、およびすべての開発グループからのコミットメントが必要です。コードを改善するのは全員の責任です。リファクタリングを実行する必要がある場合は、新機能とともにリリーススケジュールに含める必要があります。進行中の開発プロセスの一環として支払われない場合、技術的負債が製品を急停止させるものであるため、コードを改善するために時間をかけることが長期的に見返りをもたらすことをマネージャーに教育し、理解する必要があります。あなたがしているすべてが絶え間ないバグ修正から絶えず火と戦っている場合、家は火事の危険があり、より良い建設と改修が必要であるため、家は燃え尽きます。
あなたのグループは、より保守しやすい次世代アーキテクチャの開発に専念するアーキテクチャ/ソフトウェアスタッフグループであるべきだと思われます。あなたのグループはおそらく、リファクタリングが「先のとがった」タイプに報いることを示す方法に焦点を当て、開発者に新しい方法とプロセスを奨励し、より優れたコード品質を採用して「バイイン」するように管理の主要な関係者を教育する必要があります。プロセスに。最初に単純な基盤を置くことで、製品をより良いアーキテクチャに移行する計画を考えます。誰もがあなたの製品をサポートすることから学んできた苦痛な教訓を取り入れ、将来的にその苦痛を軽減するための計画を考え出します。
それはかなり一般的です。私はこれが標準であったソフトウェア会社で働いていました。新しい機能の実装に専念するチームがありました。次に、クライアントに問題を引き起こすバグを修正するメンテナンスチームがいました。保守チームは、組織のコンサルタント/サポート部門に分類されました。
その場合、開発者にはメリットがありました。つまり、開発者はクライアントとより緊密に連携し、サイトで時間を費やしていました。新しい開発を行っている製品チームは、クライアントとまったく対話しませんでした（嫌な状況です）。
ソフトウェア会社やアウトソーシングプロバイダーでは、社内での提供よりも一般的であるようです。私は金融関係にあり、過去にこの構造を使用した銀行は1つしかありません。とはいえ、戦術チームがそのような問題を権限の一部として取り上げるのは一般的です。まったく同じではありませんが、似ています。
チームが十分に活用されていない場合は、少し注意する必要があります。十分に活用されていない場合、「不要なコスト」に簡単に変換されるため、XのチームはすぐにX-1のチームになることができます。
望ましいアプローチは、修正にもう少し時間を費やし、バグ修正時間に書き込まれていないリファクタリング時間を組み込むことです。
それはあなたの会社がどのように働くかに依存します。おもしろいのは、よくわからないので、チームリーダーがいる場合は、チームリーダーと話し合う価値があります。彼らが知らない場合は、チェーンの次の人と話してもらいます（それに関与し、それを渡さないでください）。それが経営陣の期待に合うかどうかわからない場合は、資産カテゴリではなく、さらにコストカテゴリに分類される可能性があります。