ソフトウェアアーキテクトとして、ログの分析と他のバグの修正に重点を置くべきですか？

卒業（2005年後半）以来、私はc ++ソフトウェアエンジニアと同じ会社で働いていました。1年前、私はソフトウェアアーキテクトとして昇進しましたが、資格の取得とバグの修正、レベル2サポートにますます関与するようになりました。

私の時間の50％は、Notepad ++でソフトウェアログを分析し、何が問題だったのかを把握するために費やしました。30％が他のバグを修正し、残りの（存在する場合）開発者のスパゲッティコードをレビューします。

私はこの製品を嫌い、この会社の出口戦略について考え始めました。

この状況で私にできることは何だと思いますか？他のソフトウェアアーキテクトはまだコードのバグを修正していますか？

ほとんどの人は一般に、ソフトウェアアーキテクトが主に高レベルの設計、標準の設定、ツールまたはフレームワークの選択、製品の評価、プロトタイプとProof Of Conceptの実装、開発者のトレーニングと指導に関与することに同意します。

しかし現実には、タイトルは多くの場合、開発者への政治的な任命、プロジェクトの開発者をリードするために与えられた特別なタイトル、または非常に必要な開発者を給与またはレートで雇うための管理人事回避策のような単純なものでさえあり得る人事部または上級管理職は、ソフトウェア開発者またはソフトウェアエンジニアの肩書きには受け入れられないでしょう。

言い換えれば、タイトルはほとんど意味がありません。

ウィキペディアの記事では、ソフトウェアアーキテクトを次のように定義しています。

コンピュータープログラマー、高レベルの設計の選択を行い、技術基準決定づけるソフトウェアコーディング標準、ツール、またはプラットフォームを含むが、...

上記のように、「私の時間の50％が...ソフトウェアログの分析... 30％が他のバグの修正に費やした」と見積もると、ソフトウェアアーキテクトが通常行うことをはるかに遠ざけます。

• 上記は、彼らが50+30=80%偽物についてあなたに与えたタイトルを作ると思います。

ログの分析や他のバグの修正などのアクティビティ自体は、アーキテクトの時間の一部を正当に占有する可能性があることに注意してください（これらがこの役割の主な目的を果たす場合）。つまり、高度な設計選択を行い、技術標準を確立します。実際、これはあらゆる種類のソフトウェア開発/保守/テスト活動の場合です。

たとえば、ログを分析することで、設計、ツール、またはコーディング標準を改善することにより、ログを簡単にする方法についての洞察が得られた場合、これは建築家にとって完全に正当な努力となります。同様に、設計者が特定のバグを修正するために手を汚すことは完全に問題ありません-特定の設計/プロセスの改善がバグ率の低下などにつながる限りです。

_{もう少し肯定的な注意として、あなたの質問は、建築家にとって非常に重要なスキルを少なくとも1つ示しています。それは、異なる種類の活動を分類し、これらに費やされた努力を追跡する能力です。「ツールボックス」に補完的なスキルを追加して、観測と推定を要約し、特に管理の梯子の上で、これらを明確に伝えることを検討してください。:)}

ソフトウェアアーキテクトとして、ログの分析と他のバグの修正に重点を置くべきですか？

だと思う？はいといいえ。製品の品質と進化パスの全体を担当します-明日機能させるだけでなく、来年も機能させます。
それは、困難な問題を解決するために手を貸すことを意味しますか？絶対に-少なくとも私は。顧客があなたのもとを去ると、明日製品を機能させることはできません。
それはあなたがそれのためにあなたの時間のすべてを捧げるべきであることを意味しますか？絶対違う。あなたは品質と進化の全体を担当しています。問題を追跡するのに多くの時間を費やすことは逆効果です。

あなたは積極的になることになっています：

1. 他の人（開発者/サポート）が負荷を軽減できるように、教育計画を開始します。「男に魚を教える」とジャズ。
2. より迅速で簡単な欠陥分析と根本原因の分離をサポートする方法を考案し、ツールを開発します。あなたがこの退屈だと思うなら、他の、おそらくそれほど才能のない、または経験のある開発者は、これを退屈なだけでなく、困難で恐らくさえ気づくでしょう。彼らが技術によってこれを克服するのを助けてください。
3. 製品の品質を向上させるための取り組みを開始します-単純化、モジュール化、テストフレームワークの作成-例によって主導します。
4. 開発者があなたが何をしているのか、またあなたのマネージャーも知っていることを確認してください。アーキテクトの役割は、コーディングと分析よりも、他の人との関係にあります。これを嫌うかもしれませんが、ここで政治が重要な役割を果たします。同僚に自分の成果を確認させることで、後で自分が正しいと納得させることが容易になります。まだアクセスしていない場合は、調査とPOCで主張を支持してください。
5. 他のすべてが失敗し、物事を改善するために時間を費やした後にのみ、マネージャーに相談してください。あなたのスキルが計画および設計段階でよりよく使われていると言い、現在の状況を変えるために何ができるかを見てください。あなたの製品はピンチに陥っているかもしれませんし、あなたのマネージャーの答えは「私たちはまさに今、このことのためにあなたを必要としている」かもしれません。しかし、長期計画を主張します-現在の状況をどのように変えるか。

建築家の役割には特権があると思います。他の多くの人々にはできない方法で製品に影響を与えます-あなたよりも理論的に影響力があるのは、製品R＆Dマネージャー（そして、おそらくマーケティング）だけです-しかし、彼は管理に忙しいのです。

従来、ソフトウェアアーキテクトの役割にはバグの修正はありません。ソフトウェアアーキテクトはソフトウェアの設計上の問題を修正するのに役立つので、もしバグによってソフトウェアの設計の中核となる方法が脆弱性や拡張/維持の難しさを意味するなら、SAの仕事はその問題を解決するソフトウェア。

あなたが言ったことを考えると：

私の時間の50％は、Notepad ++でソフトウェアログを分析し、何が問題だったのかを把握するために費やしました。30％が他のバグを修正し、残りの（存在する場合）開発者のスパゲッティコードをレビューします。

それは真のSAの役割ではなく、開発者1と開発者2のレベルのプログラマーに上級開発者と一緒に始めさせるものです。特に、私は、それがコード品質の問題についてそのレベルで作業することで、当社の新しい開発者が製品とコードを理解するのに本当に役立つと思うからだと言います。あなたはあなたの会社の新しいSAであり、彼らはあなたがシステムに入るためにあなたにこの仕事をさせていますか？もしそうなら、多分それは短期間で大丈夫かもしれません。これがあなたの毎日の仕事であり、1年以上続いている場合は、おそらく別の役割を探すときです。

私はあなたの不満を理解していますが、あなたがコードを書いたのか、最後に触れたのか、時間が短く、彼らがあなたに連絡できるのか、あなたのタイトルに関係なく多くのマネージャーがあなたにそれを修正するつもりです。

危機にある開発グループにまだ友人がいることを考えて、あなたは助けます。問題は、彼らが、そしてもっと重要なことに、彼らの経営陣があなたの手助けに慣れると、彼らが戻ってくることです。「善行は罰せられない」と言うように、タイトルに関係なく、彼らが問題を解決するためにあなたに頼ることができるなら、あなたはただの開発者であり、彼らが使用できる他の誰かです。

解決するのは難しい問題ですが、私のアドバイスは次のとおりです。

1. この非ソフトウェアアーキテクトのプロジェクト時間に、プロジェクトの請求番号を尋ねます。プロジェクトマネージャーは、説明責任を負う必要がある場合、あなたの時間を尋ねるほど熱心ではありません。

2. どのくらいの時間が失われているのか、どのグループまたはプロジェクトに上司に相談してください。あなたの上司は、彼らを助けないようにあなたに言い、彼のプロジェクトに集中し続けるかもしれません。もしそうなら、他のグループが来て助けを求めます、あなたは彼らにあなたの上司も言わなかったと伝えます。

3. 優先事項を明確に保ち、​​建築プロジェクトの外部にあまり反応しないように、作業を整理します。

4. アーキテクトのように振る舞い、同僚にアーキテクトとして見てもらい、あなたがここ数年ずっと同じデベロッパーとしてではないようにしてください。あなたは開発者としてあなたを扱う習慣を他の人から破りました。

幸運を。

いいえ、あなたは全体像を管理するためにここにいます。

管理上の問題があります：バグを修正し、コード品質を改善することは開発者の仕事です。アーキテクトはガイドラインと実際のアーキテクチャ（UMLまたはボートに浮かぶもの）を発行し、これらのガイドラインが正しく遵守されるように定期的なコードレビューを行う必要があります。

ただし、コアアーキテクチャにバグを実装して修正することはできます。

例：WPF / C＃プロジェクトでPRISM、MEFなどに取り組みますが、スプラッシュスクリーンを表示するためにXAMLには取り組みません。

DB設計に取り組みますが、CRUD操作用のストアドプロシージャは作成しません。

等

答えの一部は、この負荷を引き受けてくれるエンジニアを見つけることです。

もちろん、これが問題である理由は、この作業が望ましくないことであり、他のエンジニアにとって魅力的であるというメッセージを送信しないため、彼らもそれを拾いたがらないからです。

2つの可能性があります。

1. あなたは建築家の地位を与えられたので、より大きな絵のアイテムに取り組むことができました。
   この場合、下位レベルのサポートの役割を引き受けるために誰もステップアップしていないため、これらの大きな画像項目に取り組むことができないことを経営陣に言及する必要があります。それが彼らの解決すべき問題です。

2. タイトルは主に儀式的なものです-あなたを維持するためにあなたに投げかけられる骨。

この場合、管理はサポートの負荷を軽減することにあまり関心がないかもしれません。

-

間違いなくあなたの目標に役立たないことの1つは、他の開発者やエンジニアを軽emptする態度を採用することです。これらの人々がステップアップし、自信を持ってこれらの問題を処理するようにしたいので、必要はありません（途中でいくつかの間違いを犯す可能性があります）。彼らがあなたが彼らの解決策をひどく口にするだけで、後でそれを修正することを彼らが知っているならば、彼らはたぶんステップアップするつもりはないでしょう。

私の時間の50％は、Notepad ++でソフトウェアログを分析し、何が問題だったのかを把握するために費やしました。30％が他のバグを修正し、残りの（存在する場合）開発者のスパゲッティコードをレビューします。

これは間違いなく、この役割のために行うべきではないタイプの作業です。私の経験/観察によれば、アーキテクトは、対処または回避する必要があるアプリケーションの設計、改善、技術要件の明確化、および潜在的なパフォーマンスの問題（ログを毎日チェックするのではなく、主に重大な問題/エラーを分析する）に関与する必要があります。

言い換えれば、私のポイント＃1は-建築家は、技術の内部作業がどのように機能/適用され、使用される必要があるかについての実地経験を持つ、高レベルのデザイナーおよびシステムインテグレーターです。

コード品質を割り当てて管理する機会がある場合は、作業管理スキルを向上させる必要があります。したがって、作業の計画は、「作業の実行方法」アプローチの優先事項である必要があります。

ポイント＃2：あなたがこれらのアプリケーションの数少ない開発者の一人である場合、このタイトルは、会社の経営陣があなたを同じ「修正」の役割で新しいファンシーなタイトルに保つための別の砂糖glです 。

ソフトウェアアーキテクトの役割は、現在の会社でやっていること以上のものです。彼は、ソフトウェア設計標準の定義、高レベルの設計、コーディングの標準などの作成を担当し、バグの修正は実際にはそうではないと考えられるほんの一部に過ぎないと見なされる場合があります。しかし、あなたが言ったように、あなたは製品に取り組んでいます、つまり、ソフトウェアアーキテクトであることを意味しますあなたはその経験が豊富なので、製品だけでなく会社も助けてください。ただし、現在の組織への関心を深めるために、新機能の開発や新しいタスクに触れる機会も提供する必要があります。

ソフトウェアアーキテクトとして、私はログの分析と他のバグの修正にそれほど集中することになっていますか？

言えば、「はい」です。

回答をどのように修飾するかを以下に示します。

1. デフォルトでは、ソフトウェア開発者にログを分析させ、バグを修正させる必要があります。
2. ただし...データの損失が発生したり、面倒なデータベースのロールバックが必要であったり、開発者が解決するのに長い時間がかかったり、顧客の謝罪が必要な欠陥に注意する必要があります。
   1. 原則として、直属の部下はそのような欠陥について知らせるべきです。
   2. 直属の部下がこのような欠陥について説明する権限を与えられているが、些細な欠陥について説明することを強いられない文化を作成する必要があります。

＃2の詳細：

1. これらのタイプの欠陥は一般に、アーキテクチャの失敗を意味します。その場合、欠陥の正確な性質を理解し、修正を設計する必要があります。
   1. そのため、拡張機能によって、ログを精査し、他の人のバグを修正する準備ができて、喜んで、できる必要があります（コードをソースコードリポジトリに直接コミットしない場合でも）。

答えはおそらくノーです。デバッグとサポートの問題に多くの時間を費やしているのはなぜですか？誰かがその仕事をあなたに割り当てていますか？

何をすべきかを明確にする必要があるようです。バグを修正する必要があるかもしれません。それはおそらくあなたの時間の大半ではないはずです。