소프트웨어 아키텍트로서 로그를 분석하고 다른 버그를 수정하는 데 그 정도를 집중해야합니까?

졸업 후 (2005 년 말) 저는 C ++ 소프트웨어 엔지니어와 같은 회사에서 일하고있었습니다. 1 년 전 저는 소프트웨어 아키텍트로 승진했지만 레벨 2 지원 인 버그 인증 및 수정에 점점 더 관여하고 있음을 알게되었습니다.

내 시간의 50 %가 메모장 ++에서 소프트웨어 로그를 분석하고 무엇이 잘못되었는지 파악하려고했습니다. 다른 사람의 버그를 수정하고 남은 (있는 경우) 개발자 스파게티 코드를 검토하는 30 %.

이 제품을 싫어하고이 회사의 출구 전략에 대해 생각하기 시작했습니다.

이 상황에서 내가 무엇을 할 수 있다고 생각합니까? 다른 소프트웨어 아키텍트가 여전히 코드의 버그를 수정합니까?

대부분의 사람들은 일반적으로 소프트웨어 아키텍트가 주로 높은 수준의 디자인, 표준 설정, 도구 또는 프레임 워크 선택, 제품 평가, 프로토 타입 및 개념 증명 구현, 개발자 교육 및 멘토링에 참여해야한다는 데 동의합니다.

그러나 실제로는 타이틀이 개발자에게 정치적 약속이 될 수도 있고, 프로젝트 개발자를 이끌 수있는 특별한 타이틀이 될 수도 있고, 관리가 필요없는 개발자를 급여 나 요율로 고용하기위한 관리 -HR 해결 방법과 같은 단순한 것일 수도 있습니다. HR 또는 상급 관리자는 소프트웨어 개발자 또는 소프트웨어 엔지니어 타이틀에 적합하지 않습니다.

즉, 제목은 대부분 의미가 없습니다.

Wikipedia 기사는 소프트웨어 아키텍트 를 다음과 같이 정의 합니다 .

컴퓨터 프로그래머 높은 수준의 디자인 선택과 지시 기술 표준을 만드는 소프트웨어 코딩 표준, 도구, 또는 플랫폼을 포함하여, ...

위에서 말한 것처럼, "내 시간의 50 % ... 소프트웨어 로그 분석 ... 다른 버그 수정 30 %" 는 소프트웨어 설계자가 일반적으로 기대하는 것과는 거리가 멀다 는 추정치 입니다.

• 나는 그들이 50+30=80%가짜 에 대해 당신에게 준 제목을 위에서 말하고 싶습니다 .

로그를 분석하거나 다른 버그를 수정하는 것과 같은 활동은 건축가의 시간의 일부를 합법적으로 차지할 수 있습니다 ( 이 역할의 주요 목적 , 즉 높은 수준의 설계 선택 및 기술 표준 수립). 실제로 이것은 모든 종류의 소프트웨어 개발 / 유지 보수 / 테스트 활동에 해당됩니다.

예를 들어, 로그를 분석하여 설계, 툴링 또는 코딩 표준을 개선하여보다 쉽게 ​​만드는 방법에 대한 통찰력을 얻는다면 이는 건축가에게 완벽한 노력이 될 것입니다. 마찬가지로, 특정 디자인 / 프로세스 개선으로 버그 비율이 낮아지는 한, 건축가가 특정 버그를 수정하여 손을 더럽히는 것은 완전히 괜찮습니다.

_{조금 더 긍정적 인 점에서, 귀하의 질문은 건축가에게 매우 중요한 하나 이상의 기술을 보여줍니다. 다른 종류의 활동을 분류하고 이에 대한 노력을 추적하는 능력. "도구 상자"보완 기술을 추가하여 관찰 및 추정치를 요약하고이를 특히 의사 소통을 통해 명확하게 전달하십시오. :)}

소프트웨어 아키텍트로서 로그를 분석하고 다른 버그를 수정하는 데 그 정도를 집중해야합니까?

가정? 예, 아니오 당신은 제품 품질과 진화 경로의 전체를 책임지고 있습니다. 내일은 작동하지만 내년에도 작동합니다.
어려운 문제를 해결하기 위해 도움의 손길을 빌려주는 것을 의미합니까? 물론-적어도 나는 그렇습니다. 고객이 떠나면 내일 제품을 작동시킬 수 없습니다.
그것은 당신이 모든 시간을 그것에 바쳐야한다는 것을 의미합니까? 절대적으로하지. 당신은 품질과 진화의 총체를 책임지고 있습니다. 문제를 쫓는 데 많은 시간을 투자하는 것은 비생산적인 일입니다.

능동적으로 행동해야합니다.

1. 교육 계획을 시작하여 다른 사람들 (dev / support)이 짐을 들어 올릴 수 있도록하십시오. "사람에게 낚시를 가르치십시오"그리고 모든 재즈.
2. 더 빠르고 쉬운 결함 분석 및 근본 원인 격리를 지원하는 방법을 개발하고 도구를 개발하십시오. 이 지루한 것을 발견하면 다른 재능이 있거나 경험이 적은 개발자가 지루할뿐만 아니라 어려울 수도 있고 어려울 수도 있습니다. 그들이 기술을 통해이를 극복하도록 도와주십시오.
3. 제품 품질을 높이기위한 노력을 시작하십시오. 단순화, 모듈화, 테스트 프레임 워크 생성 등이 이끄는 위협이 아니라 예를 들어 리드합니다.
4. 개발자가 자신의 업무뿐만 아니라 관리자에게도 알리십시오. 건축가 역할은 다른 사람들과의 관계에 대한 것보다 코딩과 분석에 관한 것입니다. 당신이 이것을 싫어하는 한, 정치는 여기서 중요한 역할을합니다. 동료들이 자신의 업적을 볼 수있게하면 나중에 자신이 옳다는 것을 더 쉽게 설득 할 수 있습니다. 아직없는 경우 연구 및 POC를 통해 소유권 주장을 뒷받침하십시오.
5. 다른 모든 것이 실패하고 더 나은 일을하기 위해 시간을 보낸 후에 만 ​​매니저와상의하십시오. 기술이 계획 및 설계 단계에서 더 잘 사용되고 현재 상황을 변경하기 위해 수행 할 수있는 작업을 확인하십시오. 귀하의 제품이 꼬집어 졌을 수 있으며 관리자의 대답은 "지금 당장이 일을 위해 당신이 필요합니다"일 수 있습니다. 그래도 장기 계획을 고집하고 싶습니다. 현재 상황을 어떻게 바꿀 것입니까?

건축가의 역할이 특권이라고 생각합니다. 당신은 다른 많은 사람들이 이론적으로 더 많은 영향력을 행사할 수있는 방식으로 제품에 영향을 미치게됩니다. 이론상 가장 영향력있는 사람은 제품 R & D 관리자 (및 마케팅) 일뿐입니다.

전통적으로 소프트웨어 아키텍트의 역할은 버그를 수정하지 않습니다. 소프트웨어 아키텍트는 소프트웨어의 설계 문제를 해결하는 데 도움을주기 때문에 버그로 인해 소프트웨어가 설계되는 핵심 방식이보다 취약하거나 확장 / 유지 관리에 어려움을 겪는다면 SA의 역할을 제안하거나 재 설계하는 것이 SA의 역할입니다. 그 문제를 해결하기 위해 소프트웨어.

당신이 말한 것을 감안할 때 :

내 시간의 50 %가 메모장 ++에서 소프트웨어 로그를 분석하고 무엇이 잘못되었는지 파악하려고했습니다. 다른 사람의 버그를 수정하고 남은 (있는 경우) 개발자 스파게티 코드를 검토하는 30 %.

그것은 진정한 SA의 역할이 아니며 대신 개발자 1과 개발자 2 레벨 프로그래머가 선임 개발자와 함께 시작해야 할 것입니다. 특히 회사의 새로운 개발자가 코드 품질 문제에 대해 해당 수준에서 작업함으로써 제품과 코드를 입력하는 데 실제로 도움이된다고 생각합니다. 회사에 새로운 SA가 있고 시스템에 들어가기 위해이 작업을 수행하고 있습니까? 그렇다면 잠시 동안은 괜찮을 것입니다. 이것이 일상적인 일이고 1 년 이상 지속 되었다면 다른 역할을 찾아야 할 때입니다.

귀하의 불만을 이해하지만 코드를 작성했거나 마지막으로 만졌거나 시간이 짧고 연락이 닿을 경우 많은 관리자가 귀하의 제목에 관계없이 코드를 수정하려고합니다.

위기에 처한 개발 그룹에 여전히 친구가 있다고 생각하면 도움이 될 것입니다. 문제는 그들이 더 중요하게 그들의 경영진이 당신을 돕는 데 익숙해 져서 계속 돌아올 때입니다. "선한 행동은 처벌받지 않는다"는 말처럼 그들이 제목에 관계없이 문제를 해결하기 위해 당신을 의지 할 수 있다면, 당신은 다른 개발자 일뿐 아니라 다른 사람도 사용할 수 있습니다.

해결하기 어려운 문제이지만 내 조언은 다음과 같습니다.

1. 이 비 소프트웨어 설계자 프로젝트 시간에 프로젝트의 청구 번호를 요청하십시오. 프로젝트 관리자가 책임을 져야 할 경우 귀하의 시간을 간절히 요구하지 않습니다.

2. 얼마나 많은 시간을 잃어 버렸는지, 어떤 그룹이나 프로젝트에 대해 관리자에게 문의하십시오. 당신의 관리자는 당신을 도와주지 말고 그의 프로젝트에 계속 집중하도록 지시 할 것입니다. 그렇다면 다른 그룹이 와서 도움을 요청하면 상사에게도 말하지 않았다고 말합니다.

3. 우선 순위를 명확하게 유지하고 건축 프로젝트 외부에 반응하지 않도록 작업을 구성하십시오.

4. 건축가처럼 행동하고 동료들이 당신을 건축가로 보도록하십시오. 당신은 다른 사람들을 당신을 개발자로 대하는 습관을 잃었습니다.

행운을 빕니다.

아니요, 큰 그림을 관리하기 위해 왔습니다.

관리 문제가 있습니다. 버그를 수정하고 코드 품질을 개선하는 것은 개발자가해야 할 일입니다. 설계자는 지침 및 실제 아키텍처 (UML 또는 보트를 떠 다니는 것)를 발행 한 다음 정기적 인 코드 검토를 통해 이러한 지침을 올바르게 준수해야합니다. .

그러나 핵심 아키텍처에서 버그를 구현하고 수정할 수 있습니다.

예 : WPF / C # 프로젝트에서 PRISM, MEF 등을 작업하지만 스플래시 화면을 표시하기 위해 XAML에서는 작업하지 않습니다.

DB 디자인 작업을 수행하지만 CRUD 작업을위한 저장 프로시 저는 작성하지 않습니다.

기타

대답의 일부는이 짐을 기꺼이 맡을 엔지니어를 찾는 것입니다.

물론 이것이 문제가되는 이유는이 작업이 바람직하지 않다는 것을 알게 되었기 때문에 다른 엔지니어들에게 매력적이라는 메시지를 보내지 않기 때문에 다른 엔지니어들에게도 관심이 없다는 것입니다.

두 가지 가능성이 있습니다.

1. 더 큰 그림 항목을 작업 할 수 있도록 건축가의 직책을 맡았습니다.
   이 경우, 하위 레벨의 지원 역할을 수행 할 사람이 아무도 없기 때문에 이러한 큰 그림 항목에 대해서는 작업 할 수 없다고 경영진에게 언급해야합니다. 그것이 해결해야 할 문제입니다.

2. 제목은 크게 예의입니다.

이 경우 관리 작업이 지원 부담을 줄이는 데 크게 관심이 없을 수 있습니다.

-

귀하의 목표에 분명히 도움이 되지 않는 한 가지는 귀하의 질문에서 누출되는 다른 개발자 및 엔지니어에게 경멸의 태도를 취하는 것입니다. 당신은이 사람들이이 문제들을 스스로 해결하고 자신있게 처리하기를 원하므로 그렇게 할 필요가 없습니다. 그들이 당신이 그들의 솔루션을 잘못 입히고 나중에 그들을 위해 고칠 것이라는 것을 안다면, 그들은 아마도 단계적으로 올라가지 않을 것입니다.

내 시간의 50 %가 메모장 ++에서 소프트웨어 로그를 분석하고 무엇이 잘못되었는지 파악하려고했습니다. 다른 사람의 버그를 수정하고 남은 (있는 경우) 개발자 스파게티 코드를 검토하는 30 %.

이것은 분명히이 역할을 위해 당신이하지 말아야 할 일의 유형입니다. 내 경험 / 관찰에 따르면, 설계자 는 해결하거나 피해야하는 응용 프로그램 설계, 개선, 기술 요구 사항 설명 및 잠재적 성능 문제 (매일 로그를 확인하지 않고 주로 심각한 문제 / 오류 분석)에 관여 해야합니다.

다시 말해, 요점 # 1 은 건축가가 기술의 내부 작업이 어떻게 적용 / 적용되고 사용되어야하는지에 대한 실무 경험이있는 고급 디자이너 및 시스템 통합 자입니다.

코드 품질을 할당하고 관리 할 수있는 기회가 있다면 작업 관리 기술을 향상시켜야합니다. 따라서 작업 계획 방법은 "작업 수행 방법"접근 방식에 우선 순위를 두어야합니다.

포인트 # 2 :이 응용 프로그램 (들)에 대한 몇 가지 개발자의 당신이 경우 하나 - 다음이 제목은 또 다른 설탕 같은 "수정을"의 새와 역할을 유지하기 위해 회사의 관리에 의해 유약입니다 멋진 제목을 .

소프트웨어 아키텍트의 역할은 현재 회사에서하고있는 것보다 훨씬 더 중요합니다. 그는 소프트웨어 디자인 표준을 정의하고, 높은 수준의 디자인을 만들고, 코딩 표준을 작성하며, 버그 수정은 실제로는 그렇지 않다고 생각하는 작은 부분으로 간주 될 수 있습니다. 그러나 당신이 말했듯이, 당신은 제품을 개발하고 있습니다. 즉, 소프트웨어 아키텍트는 제품의 신뢰성에 대한 당신의 기대가 상당히 높을 것입니다. 그 경험이 풍부한 제품뿐만 아니라 회사를 도우십시오. 그러나 현재 조직에 대한 관심을 불러 일으킬 새로운 기능 개발 및 새로운 작업에 대한 노출도 제공해야합니다.

소프트웨어 아키텍트로서 로그를 분석하고 다른 버그를 수정하는 데 그 정도를 집중해야합니까?

말하자면 '예'입니다.

내 답변의 자격을 얻는 방법은 다음과 같습니다.

1. 기본적으로 소프트웨어 개발자가 로그를 분석하고 버그를 수정하도록해야합니다.
2. 그러나 ... 당신은 해야한다 , 데이터 손실이 발생 성가신 데이터베이스 롤백을 필요로하는 결함을 인식, 해결하기 위해 개발자를위한 시간이 오래 걸릴, 또는 고객의 사과를 요구합니다.
   1. 일반적으로 직접 보고서는 그러한 결함에 대해 알려야합니다.
   2. 당신은 직접 보고서를 느낄하는 문화를 만들어야 권한을 부여 결함에 대해 얘기 할 수 있지만 강제 사소한 것들에 대해 얘기하기를.

# 2에 대한 추가 정보 :

1. 이러한 유형의 결함은 일반적으로 아키텍처 오류를 의미합니다. 그들이 할 때, 당신은 결함의 정확한 본질을 이해하고 수정을 설계해야합니다.
   1. 따라서 확장을 통해 소스를 직접 코드를 커밋하지 않더라도 로그를 탐색하고 다른 사람의 버그를 수정할 수 있어야합니다.

대답은 아마 아니오입니다. 왜 디버깅과 지원 문제에 많은 시간을 소비합니까? 누군가 그 일을 당신에게 맡기고 있습니까?

해야 할 일을 분명히해야 할 것 같습니다. 버그를 수정해야 할 수도 있습니다. 아마도 대부분의 시간이되어서는 안됩니다.