소프트웨어 아키텍트로서 무엇을 가져와야합니까? [닫은]

StackOverflow 및 Programmers SE 에서의 SA (Software Architect)의 역할에 대한 많은 답변이 있습니다 . 나는 그들보다 약간 더 집중된 질문을하려고합니다. SA의 정의는 광범위하므로이 질문을 위해 SA를 다음과 같이 정의하겠습니다.

소프트웨어 아키텍트는 프로젝트의 전체 디자인을 안내하고, 코딩 노력에 참여하고, 코드 검토를 수행하고, 사용할 기술을 선택합니다.

다시 말해, 나는 경영상의 휴식과 조끼에 대해 말하지 않고있다. SA 유형의 모든 유형을 추구한다면 코딩을 피하고 싶지 않습니다. 고객 및 비즈니스 분석가 등과 연락하기 위해 약간의 시간을 희생 할 수는 있지만, 기술적으로 여전히 관여하고 있으며 회의를 통해 진행되는 일에 대해서만 알고있는 것은 아닙니다.

이러한 점을 염두에두고 SA는 무엇을 가져와야합니까? "법률을 세우고"말하자면, 그들의 가이드 라인, 소스 제어, 패턴, UML 문서 등과 같은 "그들의 길"에 맞는 특정 도구의 사용을 강요해야한다는 생각을 가져야합니까? 아니면 초기 방향과 전략을 지정한 다음 배의 방향을 수정하기 위해 필요에 따라 배치하고 뛰어야합니까?

조직에 따라 작동하지 않을 수 있습니다. 모든 것을 시행하기 위해 TFS에 의존하는 SA는 StarTeam 만 사용하는 고용주에게 계획을 이행하는 데 어려움을 겪을 수 있습니다. 마찬가지로 SA는 프로젝트 단계에 따라 유연해야합니다. 새로운 프로젝트라면 더 많은 선택권이 있지만 기존 프로젝트에는 더 적을 수 있습니다.

다음은 내 질문에 대한 답변이 이러한 문제에 대한 정보를 얻을 수 있기를 희망하는 배경 지식을 공유하는 방법으로 경험 한 SA 사례입니다.

• 나는 문자 그대로 팀의 모든 단일 코드 줄을 코드 검토 한 SA와 함께 일했습니다. SA는 우리의 프로젝트뿐만 아니라 조직의 다른 프로젝트에 대해서도이를 수행 할 것입니다 (이에 소요 된 시간을 상상해보십시오). 처음에는 특정 표준을 시행하는 것이 도움이되었지만 나중에는 무너졌습니다. FxCop은 SA가 문제를 찾는 방법이었습니다. 저를 잘못 이해하지 마십시오, 그것은 주니어 개발자들을 가르치고 그들이 선택한 접근법의 결과에 대해 생각하게하는 좋은 방법이었습니다.

• 하나의 특정 SA는 특정 라이브러리의 사용에 반대하여 느리다고 주장했습니다. 다른 라이브러리는 많은 시간을 절약 할 수 있었지만, 다른 방식으로 달성하기 위해 수많은 코드를 작성해야했습니다. 프로젝트의 마지막 달로 넘어 가고 고객은 성능에 대해 불평했습니다. 유일한 해결책은 개발자의 조기 경고에도 불구하고 원래 무시 된 접근 방식을 사용하도록 특정 기능을 변경하는 것입니다. 이 시점까지 많은 코드가 폐기되어 재사용 할 수 없어 초과 근무와 스트레스를 유발했습니다. 안타깝게도 프로젝트에 사용 된 추정치는 내 프로젝트의 사용이 금지 된 기존의 접근 방식을 기반으로했기 때문에 추정에 대한 적절한 지표가 아니 었습니다. 나는 PM이 "이전에 해본 적이있다"고 말합니다.

• 모든 프로젝트에서 DTO, DO, BO, 서비스 계층 등의 사용을 강제하는 SA 새로운 개발자는이 아키텍처와 SA가 강제로 사용 지침을 배워야했습니다. 지침을 준수하기 어려울 때 사용 지침에 대한 예외가있었습니다. SA는 그들의 접근 방식에 기초를 두었습니다. DTO 및 모든 CRUD 작업에 대한 클래스는 CodeSmith를 통해 생성되었으며 데이터베이스 스키마는 또 다른 유사한 왁스입니다. 그러나이 설정을 모든 곳에서 사용한 SA는 LINQ to SQL 또는 Entity Framework와 같은 새로운 기술에 공개되지 않았습니다.

이 게시물을 환기 플랫폼으로 사용하지 않습니다. 위에서 언급 한 SA 이야기에 대한 나의 경험에는 긍정적이고 부정적인 측면이있었습니다. 내 질문은 다음과 같이 요약됩니다.

1. SA가 무엇을 가져와야합니까?
2. 의사 결정에서 어떻게 균형을 잡을 수 있습니까?
3. 특정 기본 규칙을 시행해야한다는 생각으로 SA 작업 (앞에서 정의한대로)에 접근해야합니까?
4. 다른 고려 사항이 있습니까?

감사! 이러한 직무가 선임 개발자 나 기술 책임자에게 쉽게 확장 될 수 있으리라 확신합니다.

시스템 아키텍트는 :

1. 고급 아키텍처 지정
2. 코드 리뷰에 참여
3. 사용 된 기술 승인
4. 코딩 노력에서 개발자 지원
5. 개발 일정 유지 및 모니터링
6. UML 다이어그램, Gantt 차트 등과 같은 SA 아티팩트를 생성하십시오.

SA는 코딩 방법을 알고 있어야하며 코딩 작업에 참여하고 손을 젖게해야합니다. 이것은 개발 노력의 gestalt와 연락을 유지합니다. 밥 마틴 아저씨가 한 번 말했듯이 , 건축가는 코딩 작업을 직접 수행해야합니다.

SA는 모든 디자인, 기술 및 코딩 스타일 결정에 대한 마지막 단어를 가져야합니다. 그러나 모든 관리자와 마찬가지로 SA의 역할은 직원의 생산성을 향상시킬 수있는 경로를 마련하는 것입니다. 즉, 대부분의 경우 개발자는 수준에서 문제를 해결하는 방법을 결정해야합니다. 그것은 SA가 뾰족한 머리 보스를 개발자의 칸막이에서 멀리한다는 것을 의미합니다. 그리고 필요에 따라 SA가 도움을주기 위해 노력하고 있음을 의미합니다.

모든 인간과 마찬가지로 SA도 실수를 할 수 있습니다. 좋은 사람들은 그러한 실수로부터 배우고 더 나은 SA가됩니다.

나는 실용적이지 않았기 때문에 유용한 건축가를 만난 적이 없습니다.

나를 위해 가장 큰 문제는 다음과 같습니다.

• 프로세스를 위해 프로세스에 대한 맹목적 준수
• 문제를 알기 전에 기술에 대한 맹목적인 편견
• 정당한 이유없이 규칙을 만들고 시행
• rewrite from scratch 정신력

내가 작업 한 최고의 "건축가"가 테이블에 가져 왔습니다.

• 문제와 잠재적 솔루션에 대한 이해를 높이는 질문.
• 설계 옵션 / 기술 및 그 절충.
• 디자인과 기술의 비난과 보증에 대한 명확하고 합리적인 설명.

저에게있어 문제는 제가 작업 한 최고의 "건축가"입니다. "제목에 건축가가 있습니다. 이들은 특정 문제와 프로젝트에 기초한 소프트웨어 엔지니어들입니다. 대부분의 비즈니스에서 실제 코드베이스를 처음부터 다시 작성하는 것은 실용적이지 않으며 설계 결정을 내리거나 옵션과 그 이유 또는 정당성을 제공합니다. 시간이 지남에 따라 코드베이스를 새로운 아키텍처로 반복하고 모든 기능을 유지하는 방법을 제시합니다. 무엇이든 dejour 또는 친숙한. 그들은 사물이 작동하는 이유와 방법의 일관성있는 비전을 의사 소통을 것입니다, 하지만 더 중요한 것은 그들이 거기 비용을 얻을 수있는 방법을지도한다.

1 SA는 무엇을 가져와야합니까?

• 두꺼운 피부
• 좋은 협상 기술
• 다양한 소프트웨어 계층에 대한 이해 (휘 파른 AJAX 성능에서 저수준 네트워킹 I / O까지) 반드시 전문가가 될 필요는 없지만 어떤 계층에서 어떤 소프트웨어를 실행해야하는지에 대한 중요한 결정을 내릴 것입니다.
• 코드에서 손을 더럽 히려는 의지, 백서 디자인은 그것을 자르지 않습니다.
• 소프트웨어 장인 정신 장려-가능할 때마다 올바른 방법으로 일을하고 다른 경우에는 한계가있는 최선의 방법으로 치어 리더가 되십시오. 소스 제어, TDD, 빌드 및 CI, DOJO 코딩, 코드 검토, 좋은 이슈 추적 시스템 등

2 의사 결정에서 어떻게 균형을 잡을 수 있습니까?

• 그것의 대부분은 팀과 능력에 달려 있습니다.
• 환경 (예 : 특정 공급 업체의 제품을 사용해야 할 수 있음)
• 전반적으로 상아탑 건축가가 아니고, 직접 참여하고, 팀의 일원이되지 않는 것이 가장 좋습니다. 사람들은 당신의 결정을 그런 식으로 이해할 것입니다.

3 특정 기본 규칙을 시행해야한다는 생각으로 SA 작업 (앞에서 정의한대로)에 접근해야합니까?

• 예, 버전 제어 및 빌드 시스템과 같은 것은 매우 중요하며 개발자는이를 사용해야합니다. 그러나 솔루션의 일부로 만드는 것이 가장 좋습니다.

더 많은 것이 있습니다, 나는 이것에 대해 정말 좋은 대답이 나올 것이라고 생각합니다.

1. SA는 무엇을 가져와야합니까?

"그들은 '법률을 늦추기'라는 정신을 가지고 있어야합니까? 아니면 초기 방향과 전략을 정한 다음 배의 방향을 수정하기 위해 필요에 따라 뛰어 들어야합니까?"

둘 다의 조합은 말할 것입니다. 기술과 프로세스를 결정할 때 의견과 제안에 개방적이면 의사 결정에 귀중한 피드백 / 입력을 제공하고 다른 사람들로부터 배우게 할 수 있습니다. 당신의 팀은 (희망스럽게) 똑똑합니다. 그것을 활용하십시오. 그러나 일단 결정 (귀하의 결정)이 내려지면 법이 제정되었습니다. 자신이 선택하지 않은 것에 대해 불평 할 사람과 무엇이든 선택하고 신경 쓰지 않는 사람을 식별 한 다음 무시하십시오.

기술에 관한 한 : 회사가 StarTeam을 사용하는 경우 보유하고있는 것과 협력하십시오. 특정 제품 / 기술 / 프로세스와 결혼해도 아무런 효과가 없습니다.

2. 의사 결정에서 어떻게 균형을 잡을 수 있습니까?

팀을 듣고 그들이 잘 때 알고 와 잘못이 중요하고, 그들에게하는 배짱이 가진 당신의 결정에 그들이있는 거 잘못 스틱. 듣지 않으면 당신의 결정에 흩날 리듯이 존중의 부족을 가져올 것입니다.

3. 특정 기본 규칙을 시행해야한다는 생각으로 SA 작업 (앞에서 정의한대로)에 접근해야합니까?

항상. 그렇지 않으면, 수감자들은 망명, 명백하게 또는 은밀하게 망명하게됩니다. 그러나 이러한 기본 규칙을 결정하는 것은 팀과의 대화를 통해 이루어질 수 있습니다. 팀의 구성원 수가 항상 같지 않을 수 있으므로 소규모 그룹을 위해 양보를하면 팀이 사라지면 나중에 팀을 방해 할 수 있습니다. 여기에는 SA가 포함됩니다.

4. 고려해야 할 다른 사항이 있습니까?

• 두 번째 예와 관련하여 : 프로젝트 팀은 사내 서브 시스템에 밀접하게 결합 된 것으로 보입니다. 느슨하게 연결된 외관은 타사 코드만을위한 것이 아닙니다. 해당 서브 시스템에 대한 추상화를 작성하면 사내 솔루션이 실패한 경우 해당 라이브러리 사용으로 쉽게 전환 할 수 있습니다. 이것은 소프트웨어 아키텍트에게만 적합한 논리적 솔루션이지만 팀 표현에 관심이있는 프로젝트 관리자의 형태이기도합니다.
• 세 번째 예와 관련하여 : 소프트웨어를 제작하기위한 알려진 아키텍처 나 프로세스를 갖는 것은 좋지 않습니다. 이것은 작동하는 것을 고수합니다. 따라서 새로운 기술을 사용하여 추가 가치를 창출 할 수있는 기회를 찾아야합니다. 이러한 기술을 시도 할 수있는 사내 전용 소프트웨어 또는 소규모 프로젝트는 이상적인 장소입니다. 그러나 기술 채택에 대한 연구되고 설득력있는 시연 / 인수를 제공하는 개발자에게도 책임이 있습니다. SA는 경쟁하는 모든 ORM과 그 강점과 약점을 다른 것으로 비교할 수 없습니다.